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.

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 ; [#uses=1]
New = or long %tmp37, %tmp38 ; : [#uses=0]
IC: DCE: %tmp39 = or ulong %tmp37, %tmp38 ; [#uses=0]
IC: MOD = %tmp37 = bitcast ulong %tmp37 to long ; [#uses=0]
IC: DCE: %tmp37 = lshr ulong %tmp35, ubyte %tmp36 ;
[#uses=0]
IC: Old = %tmp36 = trunc int %tmp36 to ubyte ; [#uses=1]
New = trunc long %tmp36 to ubyte ; : [#uses=0]
IC: DCE: %tmp36 = trunc long %tmp36 to int ; [#uses=0]
IC: DCE: %tmp35 = bitcast long %tmp35 to 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

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