list of available analysis passes.
<p>
- <li> -dsa-track-integers
- <br>
- Track integers as potential pointers.
- <p>
-
<li> -profile-info-file <filename>
<br>
Specify the name of the file loaded by the -profile-loader option.
when attempting to reduce test programs. If you're trying to find
a bug in one of these passes, <tt>bugpoint</tt> may crash.<p>
+ <li><tt>-enable-correct-eh-support</tt><br>
+ Make the -lowerinvoke pass insert expensive, but correct, exception
+ handling code.<p>
+
+ <li><tt>-internalize-public-api-file <filename></tt><br>
+ Preserve the symbols listed in the file <tt>filename</tt>.<p>
+
+ <li><tt>-internalize-public-api-list <list></tt><br>
+ Preserve the symbols listed in <tt>list</tt>.<p>
+
<li> <tt>-help</tt><br>
Print a summary of command line options.<p>
<tt>bugpoint</tt> will attempt to generate a reference output by
compiling the program with the C backend and running it.<p>
+ <li><tt>-profile-info-file <filename></tt><br>
+ Profile file loaded by -profile-loader.<p>
+
<a name="opt_run-"><li><tt>-run-{int,jit,llc,cbe}</tt><br>
Whenever the test program is compiled, <tt>bugpoint</tt> should generate
code for it using the specified code generator. These options allow
Specify the output filename.
<p>
- <li> -dsa-track-integers
- <br>
- Track integers as potential pointers.
- <p>
-
<li> -profile-info-file <filename>
<br>
Specify the name of the file loaded by the -profile-loader option.
<li>I've built LLVM and am testing it, but the tests freeze.</li>
<li>Why do test results differ when I perform different types of builds?</li>
<li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
+ <li>When I use the test suite, all of the C Backend tests fail. What is
+ wrong?</li>
</ol></li>
<li><a href="#cfe">Using the GCC Front End</a>
affects projects other than LLVM. Try upgrading or downgrading your GCC.</p>
</div>
+<div class="question">
+<p>
+When I use the test suite, all of the C Backend tests fail. What is
+wrong?
+</p>
+</div>
+
+<div class="answer">
+<p>
+If you build LLVM and the C Backend tests fail in <tt>llvm/test/Programs</tt>,
+then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH
+environment variable does not contain the libcrtend.a library.
+</p>
+
+<p>
+To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory
+and that libcrtend.a is inside. For pre-built LLVM GCC front ends, this
+should be the absolute path to
+<tt>cfrontend/<<i>platform</i>>/llvm-gcc/bytecode-libs</tt>. If you've
+built your own LLVM GCC front end, then ensure that you've built and installed
+the libraries in <tt>llvm/runtime</tt> and have LLVM_LIB_SEARCH_PATH pointing
+to the <tt>LLVMGCCDIR/bytecode-libs</tt> subdirectory.
+</p>
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section">
<a name="cfe">Using the GCC Front End</a>
<li>Linux on x86 (Pentium and above)
<ul>
- <li>Approximately 918 MB of Free Disk Space
+ <li>Approximately 1.02 GB of Free Disk Space
<ul>
- <li>Source code: 28 MB</li>
- <li>Object code: 850 MB</li>
+ <li>Source code: 45 MB</li>
+ <li>Object code: 956 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
</ul>
<li>Solaris on SparcV9 (Ultrasparc)
<ul>
- <li>Approximately 1.52 GB of Free Disk Space
+ <li>Approximately 1.75 GB of Free Disk Space
<ul>
- <li>Source code: 28 MB</li>
- <li>Object code: 1470 MB</li>
+ <li>Source code: 45 MB</li>
+ <li>Object code: 1705 MB</li>
<li>GCC front end: 50 MB</li>
</ul></li>
</ul>
<li>FreeBSD on x86 (Pentium and above)
<ul>
- <li>Approximately 918 MB of Free Disk Space
+ <li>Approximately 935 MB of Free Disk Space
<ul>
- <li>Source code: 28 MB</li>
+ <li>Source code: 45 MB</li>
<li>Object code: 850 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
<li>MacOS X on PowerPC
<ul>
<li>No native code generation
- <li>Approximately 1.20 GB of Free Disk Space
+ <li>Approximately 1.25 GB of Free Disk Space
<ul>
- <li>Source code: 28 MB</li>
+ <li>Source code: 45 MB</li>
<li>Object code: 1160 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
automake from 1.4p5 on should work; we only use aclocal from that
package.</p></li>
- <li><A href="http://www.codesourcery.com/qm/qmtest">QMTest</A></li>
+ <li><A href="http://www.codesourcery.com/qm/qmtest">QMTest 2.0.3</A></li>
<li><A href="http://www.python.org">Python</A>
- <p>These are needed to use the LLVM test suite.</p></li>
+ <p>
+ These are needed to use the LLVM test suite. Please note that newer
+ versions of QMTest may not work with the LLVM test suite. QMTest 2.0.3
+ can be retrieved from the QMTest CVS repository using the following
+ commands:
+ <ul>
+ <li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository login</tt>
+ </li>
+ <li>When prompted, use <tt>anoncvs</tt> as the password.
+ </li>
+ <li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm</tt>
+ </li>
+ </ul>
+ </p></li>
</ul>
<dt><tt>llvm/lib/Target/</tt><dd> This directory contains files that
describe various target architectures for code generation. For example,
- the llvm/lib/Target/Sparc directory holds the Sparc machine
+ the llvm/lib/Target/SparcV9 directory holds the Sparc machine
description.<br>
<dt><tt>llvm/lib/CodeGen/</tt><dd> This directory contains the major parts
</ul>
</li>
<li><a href="http://llvm.cs.uiuc.edu/PR253">LLVM now no longer depends on the boost library</a>.</li>
-<li>The X86 backend now generates <b>substantially</b> better native code, and is faster.</li>
+<li>The X86 backend now generates <b>substantially</b> better native code and is faster.</li>
<li>The C backend has been turned moved from the "llvm-dis" tool to the "llc"
tool. You can activate it with "<tt>llc -march=c foo.bc -o foo.c</tt>".</li>
<li>LLVM includes a new interprocedural optimization that marks global variables
"constant" when they are provably never written to.</li>
-<li>LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which is often improve the performance of C++ programs substantially.</li>
+<li>LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which often improves the performance of C++ programs substantially.</li>
<li>Bugpoint can now do a better job reducing miscompilation problems by
reducing programs down to a particular loop nest, instead of just the function
being miscompiled.</li>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR16">Exception handling in the X86
& Sparc native code generators</a> is now supported</li>
-<li>The C/C++ front-end now support the GCC <tt>__builtin_return_address</tt> and <tt>__builtin_frame_address</tt> extensions. These are also supported by the X86 backend and by the C backend.</li>
+<li>The C/C++ front-end now supports the GCC <tt>__builtin_return_address</tt> and <tt>__builtin_frame_address</tt> extensions. These are also supported by the X86 backend and by the C backend.</li>
<li><a href="http://llvm.cs.uiuc.edu/PR249">[X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808</a></li>
<li>The C/C++ front-end <a href="http://llvm.cs.uiuc.edu/PR273">now supports</a>
the "<a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">labels as values</a>" GCC extension, often used to build "threaded interpreters".</a></li>
QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.sunos.qmr
endif
+ifeq ($(OS),Darwin)
+QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.darwin.qmr
+endif
+
#
# This is configuration information used by the test suite. In QM Test, it's
# called a 'context.'
projects / oota-llvm.git / commitdiff