134 lines
4.8 KiB
HTML
134 lines
4.8 KiB
HTML
<html>
|
|
|
|
<head>
|
|
<title>Installing GCC: Testing</title>
|
|
</head>
|
|
|
|
<body>
|
|
<h1 align="center">Installing GCC: Testing</h1>
|
|
|
|
<p><strong>Please note that this is only applicable to current development
|
|
versions of GCC and GCC 3.0 or later. GCC 2.95.x does not come with a
|
|
testsuite.</strong></p>
|
|
|
|
<p>Before you install GCC, you might wish to run the testsuite. This
|
|
step is optional and may require you to download additional software.</p>
|
|
|
|
<p>First, you must have <a href="download.html">downloaded the
|
|
testsuites</a>. The full distribution contains testsuites; only if you
|
|
downloaded the "core" compiler plus any front ends, you do not have the
|
|
testsuites.</p>
|
|
|
|
<p>Second, you must have a current version of dejagnu installed;
|
|
dejagnu 1.3 is not sufficient.</p>
|
|
|
|
<p>Now you may need specific preparations:</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
In order to run the libio tests on targets which do not fully
|
|
support Unix/POSIX commands (e.g. Cygwin), the references to the dbz
|
|
directory have to be deleted from libio/configure.in.
|
|
</li>
|
|
|
|
<li>
|
|
<p>The following environment variables must be set appropriately, as in
|
|
the following example (which assumes that dejagnu has been installed under
|
|
/usr/local):</p>
|
|
|
|
<blockquote><code>
|
|
TCL_LIBRARY = /usr/local/share/tcl8.0<br>
|
|
DEJAGNULIBS = /usr/local/share/dejagnu
|
|
</code></blockquote>
|
|
|
|
<p>On systems such as Cygwin, these paths are required to be actual
|
|
paths, not mounts or links; presumably this is due to some lack of
|
|
portability in the dejagnu code.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Finally, you can run the testsuite (which may take a long time):</p>
|
|
<blockquote><code>
|
|
cd <i>objdir</i>; make -k check
|
|
</code></blockquote>
|
|
|
|
<p>The testing process will try to test as many components in the GCC
|
|
distribution as possible, including the C, C++ and Fortran compilers as
|
|
well as the C++ runtime libraries.</p>
|
|
|
|
|
|
<h2>How can I run the test suite on selected tests?</h2>
|
|
|
|
<p>As a first possibility to cut down the number of tests that are run it is
|
|
possible to use `<code>make check-gcc</code>` or `<code>make check-g++</code>`
|
|
in the gcc subdirectory of the object directory. To further cut down the
|
|
tests the following is possible:</p>
|
|
|
|
<blockquote><code>
|
|
make check-gcc RUNTESTFLAGS="execute.exp <other options>"
|
|
</code></blockquote>
|
|
|
|
<p>This will run all gcc execute tests in the testsuite.</p>
|
|
|
|
<blockquote><code>
|
|
make check-g++ RUNTESTFLAGS="old-deja.exp=9805* <other options>"
|
|
</code></blockquote>
|
|
|
|
<p>This will run the g++ "old-deja" tests in the testsuite where the filename
|
|
matches 9805*.</p>
|
|
|
|
<p>The *.exp files are located in the testsuite directories of the GCC
|
|
source, the most important ones being compile.exp, execute.exp, dg.exp
|
|
and old-deja.exp. To get a list of the possible *.exp files, pipe the
|
|
output of `<code>make check</code>` into a file and look at the
|
|
"<code>Running ... .exp</code>" lines.
|
|
|
|
|
|
<h2>How to interpret test results</h2>
|
|
|
|
<p>After the testsuite has run you'll find various *.sum and *.log
|
|
files in the testsuite subdirectories. The *.log files contain a
|
|
detailed log of the compiler invocations and the corresponding
|
|
results, the *.sum files summarize the results. These summaries list
|
|
all the tests that have been run with a corresponding status code:</p>
|
|
|
|
<ul>
|
|
<li>PASS: the test passed as expected</li>
|
|
<li>XPASS: the test unexpectedly passed</li>
|
|
<li>FAIL: the test unexpectedly failed</li>
|
|
<li>XFAIL: the test failed as expected</li>
|
|
<li>UNSUPPORTED: the test is not supported on this platform</li>
|
|
<li>ERROR: the testsuite detected an error</li>
|
|
<li>WARNING: the testsuite detected a possible problem</li>
|
|
</ul>
|
|
|
|
<p> It is normal for some tests to report
|
|
unexpected failures. At the current time our testing harness does not allow
|
|
fine grained control over whether or not a test is expected to fail. We expect
|
|
to fix this problem in future releases.</p>
|
|
|
|
|
|
<h2>Submitting test results</h2>
|
|
|
|
<p>If you want to report the results to the GCC project, use the
|
|
<code>contrib/test_summary</code> shell script. Start it in the objdir with</p>
|
|
<blockquote><code>
|
|
<i>srcdir</i>/contrib/test_summary -p your_commentary.txt -m gcc-testresults@gcc.gnu.org |sh
|
|
</code></blockquote>
|
|
|
|
<p>This script uses the <code>Mail</code> program to send the results, so
|
|
make sure it is in your PATH. The file your_commentary.txt is
|
|
prepended to the testsuite summary and should contain any special
|
|
remarks you have on your results or your build environment. Please
|
|
do not edit the testsuite result block or the subject line, as these
|
|
messages are automatically parsed and presented at the <a
|
|
href="http://gcc.gnu.org/testresults/">GCC testresults</a> web
|
|
page. Here you can also gather information on how specific tests
|
|
behave on different platforms and compare them with your results. A
|
|
few failing testcases are possible even on released versions and you
|
|
should look here first if you think your results are unreasonable.</p>
|
|
|
|
</body>
|
|
</html>
|