The last file compiled during the build of llvm-gcc when it crashes: /usr/home/jeffc/llvm-gcc/obj/gcc/xgcc -B/usr/home/jeffc/llvm-gcc/obj/gcc/ -B/home/jeffc/llvm-gcc/install/amd64-unknown-freebsd6.1/bin/ -B/home/jeffc/llvm-gcc/install/amd64-unknown-freebsd6.1/lib/ -isystem /home/jeffc/llvm-gcc/install/amd64-unknown-freebsd6.1/include -isystem /home/jeffc/llvm-gcc/install/amd64-unknown-freebsd6.1/sys-include -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/usr/home/jeffc/llvm/include -I/home/jeffc/llvm/obj/include -DL_lshrdi3 -c ../../gcc/libgcc2.c -o libgcc/./_lshrdi3.o WARNING: 128-bit integers not supported! ../../gcc/libgcc2.c: In function '__lshrti3': ../../gcc/libgcc2.c:412: internal compiler error: Segmentation fault: 11 This is apparently due to an optimization bug in LLVM. The crash goes away if the -O2 option is removed. The preprocessed version of the file, as well as the bytecode file produced with -emit-llvm -O0 is attached.
Created attachment 520 [details] Preprocessed version of file causing crash.
Created attachment 521 [details] Bytecode output from -emit-llvm -O0
I've tried to run all optimization passes, which llvm-gcc actually runs. Unfortunately, there was no crash. 1. Does llvm-gcc crash at -O1? 2. Could you please try ./opt -verify -lowersetjmp -funcresolve -raiseallocs -simplifycfg -mem2reg -globalopt -globaldce -ipconstprop -deadargelim -instcombine -simplifycfg -prune-eh -inline -simplify-libcalls -argpromotion -raise -tailduplicate -simplifycfg -scalarrepl -instcombine -predsimplify -condprop -tailcallelim -simplifycfg -reassociate -licm -loop-unswitch -instcombine -indvars -loop-unroll -instcombine -load-vn -gcse -sccp -instcombine -condprop -dse -dce -simplifycfg -deadtypeelim -constmerge -funcresolve -internalize -ipsccp -globalopt -constmerge -deadargelim -inline -prune-eh -globalopt -globaldce -argpromotion -instcombine -predsimplify -scalarrepl -globalsmodref-aa -licm -load-vn -gcse -dse -instcombine -simplifycfg -verify failed_bytecode.bc | llc and check, whether llc crashes. (This is the full list of optimizations run by llvm-gcc4 at -O2)
The crash does occur with -O1. Only -O0 compiles successfully. The opt command you give does crash on my machine (llc never sees any bytecode). The stack trace is: (gdb) where #0 0x00000030008a9a3d in ?? () #1 0x00007fffffffd7a0 in ?? () #2 0x0000000000d58e00 in ?? () #3 0x00007fffffffd910 in ?? () #4 0x000000000088f04b in (anonymous namespace)::InstCombiner::visitOr (this=0x7fffffffd7a0, I=@0xd58e00) at /usr/home/jeffc/llvm/lib/Transforms/Scalar/InstructionCombining.cpp:3481 Previous frame identical to this frame (corrupt stack?) Looks like stack corruption.
Well, there are 4 instcombine's in the list. Could you please find, which one segfaults? And after - prepare bytecode just before that instcombine, so just "opt -instcombine newbytecode.bc" crashes. Also, try "bugpoint -find-bugs oldbytecode.bc" to get somehow reduced bytecode. If valgrind is avaiable on your system you might also try to prepend "-enable-valgrind" to bugpoint command line.
Created attachment 523 [details] Simplified bytecode file causing crash The first -instcombine is what crashes. bugpoint reduced the bytecode significantly. The following command reproduces the crash: opt bugpoint-reduced-simplified.bc -instcombine But probably not on your machine. It may be reproducible only on x86_64 machines, or worse on FreeBSD systems only.
Nope, it doesn't crash for me on 32-bit Windows built with VC++.
No crash here too (gcc/linux and gcc-mingw32/windows).
Jeff, since you've got the only platform on which this fails, could you please gdb opt and set a breakpoint on InstructionCombiner::visitOr ? Then step through the code until it breaks. Send me the output from that debug session and I'll see if I can figure out where it goes wrong. Anything else you learn from this might be useful too.
Alternatively, can you include the output of 'opt -instcombine -debug' on the .bc file? Thanks, -Chris
Output from opt -instcombine -debug: IC: Old = %tmp41 = getelementptr %struct.DWstruct* %tmp40, int 0, uint 0 ; <long*> [#uses=1] New = %tmp41 = getelementptr { { long, long } }* %w, int 0, uint 0, uint 0 ; <long*> [#uses=0] IC: DCE: %tmp40 = getelementptr %struct.DWunion* %w, int 0, uint 0 ; <%struct.DWstruct*> [#uses=0] IC: Old = %tmp39 = bitcast ulong %tmp39 to long ; <long> [#uses=1] New = or long %tmp37, %tmp38 ; <long>:<badref> [#uses=0] IC: DCE: %tmp39 = or ulong %tmp37, %tmp38 ; <ulong> [#uses=0] IC: MOD = %tmp37 = bitcast ulong %tmp37 to long ; <long> [#uses=0] IC: DCE: %tmp37 = lshr ulong %tmp35, ubyte %tmp36 ; <ulong> [#uses=0] IC: Old = %tmp36 = trunc int %tmp36 to ubyte ; <ubyte> [#uses=1] New = trunc long %tmp36 to ubyte ; <ubyte>:<badref> [#uses=0] IC: DCE: %tmp36 = trunc long %tmp36 to int ; <int> [#uses=0] IC: DCE: %tmp35 = bitcast long %tmp35 to ulong ; <ulong> [#uses=0] Segmentation fault (core dumped)
Very strange. Okay, please try this: gdb --args opt -debug -instcombine bugpoint.xxx.bc > b InstCombiner::visitGetElementPtrInst > r > c > c > n > n .... Just keep nexting until you crash, it shouldn't be too long. When it crashes, please info about the code that was just being next'ed over. Thanks Jeff, -Chris
Created attachment 526 [details] GDB session Two 'c' are too many. 254 'n' are needed to hit the crash after the first 'c'.
Okay, this is even more confusing :( It looks like there is a bogus instruction being put on the worklist. I can't reproduce this, and nicholas wasn't able to reproduce this with valgrind on x86. Do you have valgrind? Does it report anything when you run it on 'opt -instcombine' here? If not, can I get access to a jail or something to track this down? -Chris
I suspect that this is related to Bug 1063, which I think is GCC miscompiling LLVM when targetting x86-64. I'm not going to have time to investigate this until after the holidays unfortunately, -Chris
The problem disappears when building with gcc 4.0.4 (instead of the 3.4.4 that FreeBSD 6.1 comes with). However, there are still other problems. There appear to be some scripting bugs, though it's not clear what the consequences are: checking whether llvm-gcc is sane... yes test: /home/jeffc/llvm/install: unexpected operator This isn't the only place the "unexpected operator" occurs: checking for sin in -lm... yes test: FreeBSD: unexpected operator checking for library containing lt_dlopen... no
Very interesting. We should add x86-64 3.4.4 to know "known bad" list of GCC's in the getting started guide. The scripting but is probably a real bug.
Shouldn't this be closed? GCC 3.4.x is definitely generating bad x86_64 code. GCC 4.0.x works. I already fixed the scripting bugs.
Yes, you're right, patch here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070326/046611.html