Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should document gcc 3.4.4 as known-broken on x86-64 #1428

Closed
llvmbot opened this issue Dec 16, 2006 · 17 comments
Closed

Should document gcc 3.4.4 as known-broken on x86-64 #1428

llvmbot opened this issue Dec 16, 2006 · 17 comments

Comments

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Dec 16, 2006

Bugzilla Link 1056
Resolution FIXED
Resolved on Feb 22, 2010 12:47
Version trunk
OS FreeBSD
Attachments Preprocessed version of file causing crash., Bytecode output from -emit-llvm -O0
Reporter LLVM Bugzilla Contributor
CC @asl

Extended Description

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.

@asl
Copy link
Collaborator

@asl asl commented Dec 17, 2006

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)

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 17, 2006

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.

@asl
Copy link
Collaborator

@asl asl commented Dec 17, 2006

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.

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 17, 2006

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.

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 17, 2006

Nope, it doesn't crash for me on 32-bit Windows built with VC++.

@asl
Copy link
Collaborator

@asl asl commented Dec 17, 2006

No crash here too (gcc/linux and gcc-mingw32/windows).

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 17, 2006

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.

@lattner
Copy link
Collaborator

@lattner lattner commented Dec 17, 2006

Alternatively, can you include the output of 'opt -instcombine -debug' on the .bc file?

Thanks,

-Chris

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 17, 2006

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)

@lattner
Copy link
Collaborator

@lattner lattner commented Dec 19, 2006

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

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 20, 2006

GDB session
Two 'c' are too many. 254 'n' are needed to hit the crash after the first 'c'.

@lattner
Copy link
Collaborator

@lattner lattner commented Dec 21, 2006

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

@lattner
Copy link
Collaborator

@lattner lattner commented Dec 23, 2006

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

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Dec 24, 2006

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

@lattner
Copy link
Collaborator

@lattner lattner commented Dec 25, 2006

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.

@llvmbot
Copy link
Collaborator Author

@llvmbot llvmbot commented Apr 1, 2007

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.

@lattner
Copy link
Collaborator

@lattner lattner commented Apr 1, 2007

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants