Closed llvmbot closed 13 years ago
I just ran into this bug on OpenBSD 4.8 i386. Running llvm/clang compiled with the system compiler produces the same "X86 DAG->DAG" seg fault when compiling most source files, including the given fopen example. As Roman says, recompiling clang with Makefile.config lowered to -O2 from the default -O3 fixes the issue. Looks like gcc 4.2 does something wrong when optimizing llvm, here's my system compiler version:
Target: i386-unknown-openbsd4.8 Configured with: OpenBSD/i386 system compiler Thread model: posix gcc version 4.2.1 20070719
Sounds like your system compiler is miscompiling llvm. This works for me in debug, release, and release-asserts builds.
If clang successfully bootstraps for you, you could build it at -O0 then use that to build clang at -O3.
when I compile llvm/clang with -O2 instead of -O3 the problem goes away
to reproduce this you have to have release build as the testcase works ok with debug build :(
the backtrace for the release build (although probably wrong) is:
(gdb) r fopen.o -o -
Starting program: /usr/local/bin/llc fopen.o -o -
(no debugging symbols found)...[New LWP 100179]
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...[New Thread 29004140 (LWP 100179)]
.file "fopen.o"
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 29004140 (LWP 100179)]
0x0831cbdc in llvm::SelectionDAG::getGlobalAddress ()
(gdb) bt
llvm::DenseMapInfo<unsigned int> >::grow ()
llvm::DenseMapInfo<unsigned int> >::grow ()
I can't reproduce this at all, either with the .bc file or with the .c file (using the clang -cc1 invocation). Does "llc fopen.o" crash for you? Can you get a stack trace of the failure at least?
bitcode file I found out that this problem only happens on i386. I can't reproduce it on x86_64.
Please attach a bitcode file, thanks.
Extended Description
-O1 also crashes, -O0 works. This testcase works with clang revision 100677.