1.9 Prerelease Available for Testing

LLVMers,

The LLVM 1.9 Prerelease is available for testing:
http://llvm.org/prereleases/1.9/

If anyone can spare some time, please download the appropriate tarballs for your platform and test the release (at least with make check). I'd also appreciate any documentation reviews.

Please note that llvm-gcc3 on x86 may not have a clean dejagnu run. You should see one XPASS for Regression/CFrontend/2006-07-31-PR854.c. If you are getting different failures or unexpected passes, please let me know. All other platforms should be clean.

If you find any problems, please email the list. I would appreciate this testing and documentation review to be completed by Friday, November 17th at 5:00PM PST.

If you plan to contribute llvm-gcc4 binaries for another platform, please complete them by the deadline above as well or send me an email with your status.

Thanks,
Tanya Lattner

Hi,

When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment):

make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen', needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop.
make: *** [install] Error 1

when doing:

$LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT --disable-optimized --enable-targets=host-only --enable-doxygen

LLVM 1.8 compiled fine before though.

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University

bug.txt (22 KB)

When building LLVM 1.9 on OSX 10.4.8, I get (after a while, see attachment):

make[1]: *** No rule to make target `/path/to/llvm-build/Debug/bin/tblgen', needed by `/path/to/llvm-build/lib/VMCore/Debug/Intrinsics.gen.tmp'. Stop.
make: *** [install] Error 1

when doing:

$LLVM_SRC/configure --prefix=$LLVM_INSTALL --with-llvmgccdir=$LLVM_FRONT --disable-optimized --enable-targets=host-only --enable-doxygen

LLVM 1.8 compiled fine before though.

I'm able to reproduce this if I skip doing a "make" and directly do a "make install" after configuring. I believe we require people to do a full build before attempting to install. So I don't think its really a bug. Could you try doing a make first and then install? Please let me know if you have any more problems.

-Tanya

Hi,

I'm able to reproduce this if I skip doing a "make" and directly do a
"make install" after configuring. I believe we require people to do a full
build before attempting to install. So I don't think its really a bug.
Could you try doing a make first and then install? Please let me know if
you have any more problems.

You were right. Doing a proper "make ; make install" did the trick.

After making necessary adjustments to my LLVM-app (due to disappearing of ConstantSInt and ConstantUInt, and replacement of RegisterOpt by RegisterPass), all its tests passed. Didn't check LLVM's test suite.

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University

a full
build before attempting to install. So I don't think its really a bug.
Could you try doing a make first and then install? Please let me
know if
you have any more problems.

You were right. Doing a proper "make ; make install" did the trick.

After making necessary adjustments to my LLVM-app (due to
disappearing of ConstantSInt and ConstantUInt, and replacement of
RegisterOpt by RegisterPass), all its tests passed. Didn't check
LLVM's test suite.

Thanks for the update!

-Tanya

Hi,

There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says :

SharedLibKindMessage := "Lodable Module"

instead of

SharedLibKindMessage := "Loadable Module"

Didn't check
LLVM's test suite.

Doing the simple LLVM-tests (on Slackware 10.2) gets:

                 === Summary ===

# of expected passes 1411
# of unexpected failures 140
# of expected failures 33

I also ran the comprehensive test suite, but I'm not sure how to get similar numerical results like the simple tests yield (I only get lots of textual traces).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University

There is a typo in $LLVM_SRC/Makefile.rules on line 750 where it says :
SharedLibKindMessage := "Lodable Module"
instead of
SharedLibKindMessage := "Loadable Module"

Thanks, I updated mainline CVS.

-Chris

Didn't check
LLVM's test suite.

Doing the simple LLVM-tests (on Slackware 10.2) gets:

                === Summary ===

# of expected passes 1411
# of unexpected failures 140
# of expected failures 33

Can you send the log file to the list? Is this ppc or?

I also ran the comprehensive test suite, but I'm not sure how to get
similar numerical results like the simple tests yield (I only get
lots of textual traces).

You should do "make TEST=nightly report" to get a comprehensive report of the llvm-test suite.

-Tanya

Hi,

Bram Adams wrote:

Tanya M. Lattner wrote:

               ===  Summary ===

# of expected passes            1411
# of unexpected failures        140
# of expected failures          33
    
Can you send the log file to the list? Is this ppc or?
  

No ppc, but x86 (Slackware 10.2) with LLVM 1.9 and its associated GCC4-based frontend (recompiled for my machine). I put the log file in attachment. A lot of failures arose from the fact that the ppc, alpha, … backends were not built and hence not found.

You should do "make TEST=nightly report" to get a comprehensive report of 
the llvm-test suite.
  

Ah, thanks. I ran the test suite and attached the results.

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

reports.tar.bz2 (10.6 KB)

No ppc, but x86 (Slackware 10.2) with LLVM 1.9 and its associated GCC4-based frontend (recompiled for my machine). I put the log file in attachment. A lot of failures arose from the fact that the ppc, alpha, ... backends were not built and hence not found.

Ah yes I see. The test framework needs to be modified to handle this but we havent gotten around to it. There is already a bug filed. Otherwise, test results are fine.

> You should do "make TEST=nightly report" to get a comprehensive report > of the llvm-test suite.
>

Ah, thanks. I ran the test suite and attached the results.

Thanks. I did a quick glance and for the most part things look ok.

-Tanya

We could just make the testsuite detect that all the targets weren't built, and refuse to run the tests...

-Chris

No ppc, but x86 (Slackware 10.2) with LLVM 1.9 and its associated
GCC4-based frontend (recompiled for my machine). I put the log file in
attachment. A lot of failures arose from the fact that the ppc, alpha, ...
backends were not built and hence not found.

Ah yes I see. The test framework needs to be modified to handle this but
we havent gotten around to it. There is already a bug filed. Otherwise,
test results are fine.

We could just make the testsuite detect that all the targets weren't
built, and refuse to run the tests...

No. I don't think thats a good solution. There are many other tests that should be run. I just need to fix that bug so we only run tests for the specific target we are on.

-Tanya

The issue is that we have many tests that work in cross compile mode. For example, test/Regression/CodeGen/PowerPC/vec_spat.ll contains:

; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vspltw | wc -l | grep 2 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g3 | grep stfs | wc -l | grep 4 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vsplti | wc -l | grep 3 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vsplth | wc -l | grep 1

We want this test to run on all hosts, regardless of whether or not they are PPC or even have altivec.

We could make the test system know that this specific test requires the PPC target to be built and disable it, but that would result in incomplete testing.

Bugs *are* found due to cross builds like this, I think it's important to keep these tests. Besides, marking all the dependencies the test has seems like a lot of work, there are lots of tests like this.

-Chris

No. I don't think thats a good solution. There are many other tests that
should be run. I just need to fix that bug so we only run tests for the
specific target we are on.

The issue is that we have many tests that work in cross compile mode. For
example, test/Regression/CodeGen/PowerPC/vec_spat.ll contains:

; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vspltw | wc -l | grep 2 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g3 | grep stfs | wc -l | grep 4 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vsplti | wc -l | grep 3 &&
; RUN: llvm-as < %s | llc -march=ppc32 -mcpu=g5 | grep vsplth | wc -l | grep 1

We want this test to run on all hosts, regardless of whether or not they
are PPC or even have altivec.

We could make the test system know that this specific test requires the
PPC target to be built and disable it, but that would result in incomplete
testing.

Bugs *are* found due to cross builds like this, I think it's important to
keep these tests. Besides, marking all the dependencies the test has
seems like a lot of work, there are lots of tests like this.

Alright. Well disabling ALL tests it not a good solution either. Perhaps its better to disable just CodeGen tests if you don't build all targets OR just have it run the one specific target you are on if you only built for it.

-Tanya

If someone says 'make check' and hasn't built all targets, I propose just having it run tests and then, at the end, print " *** NOT ALL TARGETS BUILT, YOUR TEST RESULTS PROBABLY HAVE MANY FAILURES" of something.

That is all :slight_smile:

-Chris

In the longer term it is more helpful to the developer (and QA) to
not run cross build tests if target is not built.

Tanya,

Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5)

HIGH LEVEL COMMENTS
  * The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't
that be llvm-1.9?
  * LLVM was built in Release mode in all cases
  * I don't think this is ready for release. In particular the llvm-gcc4
binary
    seg faults on FC 5 for most of llvm-test programs.
  * I'm going to re-try without using the binaries and building
everything from scratch.

BUILD LLVM WITH GCC 4.1.1 20060525 (FAIL)
  * DwarfWriter.cpp:2400: warning: overflow in implicit constant
conversion
     Line looks like: EmitInt32(DW_CIE_ID); EOL("CIE Identifier
Tag");
     I don't know the code well enough to make a suggestion.
  
  The run of llvm-test failed about 50%, some didn't even compile. I
didn't bother
  running the whole thing as it was clear that GCC 4.1.1 (still)
mis-compiles LLVM.

BUILD LLVM WITH GCC 3.4.6 WITH LLVM-GCC3 CONFIGURED (PASS)
  * PASS: make, except these innocuous warnings from GCC 3.4.6 linker
(known 3.4.6 bug)
    /proj/install/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' referenced in section `.rodata' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o): defined in discarded section `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o)

  * PASS: make install, except these doc linkage errors:
      /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<ar(1)> in
paragraph 51.
      /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<nm(1)> in
paragraph 51.
      /usr/bin/pod2html: llvm-ar.pod: cannot resolve L<ar(1)> in
paragraph 114.

  * PASS: make check, except:

XPASS: /proj/llvm/rel1.9/llvm/test/Regression/CFrontend/2006-07-31-PR854.c
      # of expected passes 1542
      # of unexpected successes 1
      # of expected failures 41

LLVM-TEST NIGHTLY WITH LLVM-GCC3 (FAIL)
  * The following tests fail:
TEST-FAIL: compile /SingleSource/UnitTests/2006-01-23-InitializedBitField
TEST-FAIL: llc /SingleSource/UnitTests/2006-01-23-InitializedBitField
TEST-FAIL: jit /SingleSource/UnitTests/2006-01-23-InitializedBitField
TEST-FAIL: cbe /SingleSource/UnitTests/2006-01-23-InitializedBitField
TEST-FAIL: compile /SingleSource/UnitTests/2006-01-23-UnionInit
TEST-FAIL: llc /SingleSource/UnitTests/2006-01-23-UnionInit
TEST-FAIL: jit /SingleSource/UnitTests/2006-01-23-UnionInit
TEST-FAIL: cbe /SingleSource/UnitTests/2006-01-23-UnionInit
TEST-FAIL: llc /SingleSource/Benchmarks/CoyoteBench/fftbench
TEST-FAIL: jit /SingleSource/Benchmarks/CoyoteBench/fftbench
TEST-FAIL: cbe /SingleSource/Benchmarks/CoyoteBench/fftbench
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ackermann
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ackermann
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/ackermann
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ary2
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ary2
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/ary2
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ary3
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ary3
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/ary3
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/ary
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/ary
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/ary
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/except
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/except
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/except
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/fibo
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/fibo
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/fibo
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/hash2
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/hash2
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/hash2
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/hash
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/hash
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/hash
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/hello
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/hello
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/hello
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/lists1
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/lists1
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/lists1
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/lists
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/lists
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/lists
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/matrix
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/matrix
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/matrix
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/methcall
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/methcall
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/methcall
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/nestedloop
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/nestedloop
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/nestedloop
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/objinst
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/objinst
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/objinst
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/random
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/random
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/random
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/reversefile
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/sieve
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/sieve
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/sieve
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/spellcheck
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/strcat
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/strcat
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/strcat
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/sumcol
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/sumcol
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/sumcol
TEST-FAIL: llc /SingleSource/Benchmarks/Shootout-C++/wc
TEST-FAIL: jit /SingleSource/Benchmarks/Shootout-C++/wc
TEST-FAIL: cbe /SingleSource/Benchmarks/Shootout-C++/wc
TEST-FAIL: llc /SingleSource/Benchmarks/Misc-C++/bigfib
TEST-FAIL: jit /SingleSource/Benchmarks/Misc-C++/bigfib
TEST-FAIL: cbe /SingleSource/Benchmarks/Misc-C++/bigfib
TEST-FAIL: llc /MultiSource/Applications/hexxagon/hexxagon
TEST-FAIL: jit /MultiSource/Applications/hexxagon/hexxagon
TEST-FAIL: cbe /MultiSource/Applications/hexxagon/hexxagon
TEST-FAIL: llc /MultiSource/Applications/oggenc/oggenc
TEST-FAIL: jit /MultiSource/Applications/oggenc/oggenc
TEST-FAIL: cbe /MultiSource/Applications/oggenc/oggenc
TEST-FAIL: jit /MultiSource/Applications/JM/ldecod/ldecod
TEST-FAIL: llc /MultiSource/Applications/JM/lencod/lencod
TEST-FAIL: jit /MultiSource/Applications/JM/lencod/lencod
TEST-FAIL: cbe /MultiSource/Applications/JM/lencod/lencod
TEST-FAIL: jit /MultiSource/Applications/obsequi/Obsequi
TEST-FAIL: llc /MultiSource/Applications/kimwitu++/kc
TEST-FAIL: jit /MultiSource/Applications/kimwitu++/kc
TEST-FAIL: cbe /MultiSource/Applications/kimwitu++/kc
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/city/city
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/city/city
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/city/city
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/deriv1/deriv1
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/deriv2/deriv2
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/employ/employ
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/employ/employ
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/employ/employ
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/garage/garage
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/garage/garage
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/garage/garage
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/office/office
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/office/office
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/office/office
TEST-FAIL: llc /MultiSource/Benchmarks/Prolangs-C++/shapes/shapes
TEST-FAIL: jit /MultiSource/Benchmarks/Prolangs-C++/shapes/shapes
TEST-FAIL: cbe /MultiSource/Benchmarks/Prolangs-C++/shapes/shapes

BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL)
  * Configure failed to find llvm-gcc4 when the directory provided to
--with-llvmgccdir
    was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball.
The 5-line
    warning message at the end of configure run was produced. I don't
know what configure
    is looking for, but its not finding it.
  * FAIL: 'make' failed in runtime library. Althought the runtime
library isn't needed
    with llvm-gcc4, it shouldn't fail to compile it:
    make[3]: Entering directory
`/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend'
    llvm[3]: Compiling crtend.c for Release build (bytecode)
    crtend.c:16: internal compiler error: Segmentation fault
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <URL:http://llvm.org/bugs> for instructions.
  * PASS: 'make tools-only'

RUN LLVM-TEST WITH LLVM-GCC4 (FAIL)
  * Most of the test (90%) fail compile with seg fault.

PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm
sse.expandfft.c:268: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.
make[5]: [Output/sse.expandfft.ll] Error 1 (ignored)
cp -f Output/sse.expandfft.ll Output/sse.expandfft.linked.rll
cp: cannot stat `Output/sse.expandfft.ll': No such file or directory

First, thanks for testing this!

Here's the results for GNU/Linux, 2.6.18-1.2200.fc5smp (Fedora Core 5)

HIGH LEVEL COMMENTS
* The llvm-1.9.tar.gz file unpacks to a dir named "llvm". Shouldn't
that be llvm-1.9?

We have always labeled the dir just llvm which is fine. If you build llvm it will know its version 1.9.

* LLVM was built in Release mode in all cases

Thats the default, so thats good.

* I don't think this is ready for release. In particular the llvm-gcc4
binary
   seg faults on FC 5 for most of llvm-test programs.
* I'm going to re-try without using the binaries and building
everything from scratch.

Does llvm-gcc4 seg fault for make check? I've done extensive testing with llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am curious as to whats going on. If you could look into this, that would be great. Please triple check that you are using a clean llvm-test directory (ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is being used.

BUILD LLVM WITH GCC 4.1.1 20060525 (FAIL)
* DwarfWriter.cpp:2400: warning: overflow in implicit constant
conversion
    Line looks like: EmitInt32(DW_CIE_ID); EOL("CIE Identifier
Tag");
    I don't know the code well enough to make a suggestion.

The run of llvm-test failed about 50%, some didn't even compile. I
didn't bother
running the whole thing as it was clear that GCC 4.1.1 (still)
mis-compiles LLVM.

We have noted in the Getting started guide that LLVM won't compile with gcc 4.1.1, so this is not a show stopper.

BUILD LLVM WITH GCC 3.4.6 WITH LLVM-GCC3 CONFIGURED (PASS)
* PASS: make, except these innocuous warnings from GCC 3.4.6 linker
(known 3.4.6 bug)
   /proj/install/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' referenced in section `.rodata' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o): defined in discarded section `.gnu.linkonce.t._ZN4llvm11SCEVVisitorINS_12SCEVExpanderEPNS_5ValueEE5visitEPNS_4SCEVE' of /proj/llvm/rel1.9/llvm/Release/lib/libLLVMAnalysis.a(ScalarEvolutionExpander.o)

Right, thats fine.

* PASS: make install, except these doc linkage errors:
     /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<ar(1)> in
paragraph 51.
     /usr/bin/pod2html: llvm-nm.pod: cannot resolve L<nm(1)> in
paragraph 51.
     /usr/bin/pod2html: llvm-ar.pod: cannot resolve L<ar(1)> in
paragraph 114.

Please file a bug for this. This isn't a show stopper though.

* PASS: make check, except:

XPASS: /proj/llvm/rel1.9/llvm/test/Regression/CFrontend/2006-07-31-PR854.c
     # of expected passes 1542
     # of unexpected successes 1
     # of expected failures 41

LLVM-TEST NIGHTLY WITH LLVM-GCC3 (FAIL)

This all looks pretty normal for llvm-gcc3. There are no plans to fix llvm-gcc3 problems/regressions with llvm-test. So not a show stopper.

BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL)
* Configure failed to find llvm-gcc4 when the directory provided to
--with-llvmgccdir
   was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball.
The 5-line
   warning message at the end of configure run was produced. I don't
know what configure
   is looking for, but its not finding it.

Interesting. This must be a bug in the configure script. This probably should be fixed.

* FAIL: 'make' failed in runtime library. Althought the runtime
library isn't needed
   with llvm-gcc4, it shouldn't fail to compile it:
   make[3]: Entering directory
`/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend'
   llvm[3]: Compiling crtend.c for Release build (bytecode)
   crtend.c:16: internal compiler error: Segmentation fault
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See <URL:http://llvm.org/bugs> for instructions.
* PASS: 'make tools-only'

I'll have to defer to Chris on this and if its a show stopper.

-Tanya

Tanya,

You asked some questions below. I don't know the answer. I'm in the
middle of trying a compiler upgrade to 4.0.3 so I can't answer the
questions right now. I'll try to get this all recompiled with 4.0.3 by
COB tomorrow.

Reid.

* I don't think this is ready for release. In particular the llvm-gcc4
binary
   seg faults on FC 5 for most of llvm-test programs.
* I'm going to re-try without using the binaries and building
everything from scratch.

Does llvm-gcc4 seg fault for make check? I've done extensive testing with
llvm-gcc4 on x86 and did not have any problems with llvm-gcc4... so I am
curious as to whats going on. If you could look into this, that would be
great. Please triple check that you are using a clean llvm-test directory
(ie. did not use llvm-gcc3 previously) and that the correct llvm-gcc is
being used.

This is also quite possibly a problem with llvm-gcc being built on a non-FC5 machine and pulling in different libraries. This is why binary distros on linux doesn't usually work very well. If so, there really isn't anything we can do about this, other than labeling the binary with the linux version it was built on.

BUILD LLVM WITH LLVM-GCC4 CONFIGURED (PASS/FAIL)
* Configure failed to find llvm-gcc4 when the directory provided to
--with-llvmgccdir
   was the llvm-gcc4-1.9-x86-linux directory unpacked from the tarball.
The 5-line
   warning message at the end of configure run was produced. I don't
know what configure
   is looking for, but its not finding it.

Interesting. This must be a bug in the configure script. This probably
should be fixed.

Reid, are you sure you passed the current directory to the configure script?

* FAIL: 'make' failed in runtime library. Althought the runtime
library isn't needed
   with llvm-gcc4, it shouldn't fail to compile it:
   make[3]: Entering directory
`/proj/llvm/rel1.9/llvm/runtime/GCCLibraries/crtend'
   llvm[3]: Compiling crtend.c for Release build (bytecode)
   crtend.c:16: internal compiler error: Segmentation fault
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See <URL:http://llvm.org/bugs> for instructions.
* PASS: 'make tools-only'

I'll have to defer to Chris on this and if its a show stopper.

Something is wrong with your configuration, probably related to not finding llvmgcc4 right. You should get this message:

llvm[0]: Warning: These runtime libraries only need to be built with
llvm[0]: Warning: llvm-gcc version 3. They are automatically included
llvm[0]: Warning: with llvm-gcc version 4 and beyond

if you try to build in llvm/runtime.

* Most of the test (90%) fail compile with seg fault.

PATH="/proj/llvm/rel1.9/llvm/Release/bin:/proj/install/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/reid/bin:/opt/j2sdk_1.4.2/j2sdk1.4.2/bin:/opt/oracle/bin" /proj/llvm/rel1.9/llvm-gcc4-1.9-x86-linux/bin/llvm-gcc -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm-test/SingleSource/UnitTests/Vector/SSE -I/proj/llvm/rel1.9/llvm/include -I/proj/llvm/rel1.9/llvm-test/include -I../../../../include -I/proj/llvm/rel1.9/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__NO_MATH_INLINES -O2 -msse2 -msse2 -O0 -S sse.expandfft.c -o Output/sse.expandfft.ll -emit-llvm
sse.expandfft.c:268: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.

It's not clear to me if this is with the binary distro of llvm-gcc4 (which is apparently incompatible with your system) or with one you built yourself...

-Chris