llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.11k stars 12.01k forks source link

crash in X86 DAG->DAG Instruction Selection #7196

Closed llvmbot closed 13 years ago

llvmbot commented 14 years ago
Bugzilla Link 6824
Resolution INVALID
Resolved on Mar 01, 2011 05:03
Version trunk
OS FreeBSD
Attachments Beter testcase based on clang -E output. Requested by rdivacky
Reporter LLVM Bugzilla Contributor
CC @lattner

Extended Description

cat fopen.c

include

int main () { FILE *f = fopen ("conftest.out", "w"); }

clang -v clang version 1.5 (trunk 101035) Target: i386-unknown-freebsd8.0 Thread model: posix clang -O2 fopen.c Stack dump:

  1. Program arguments: /usr/local/clang/bin/clang -cc1 -triple i386-unknown-freebsd8.0 -S -disable-free -main-file-name fopen.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4 -resource-dir /usr/local/clang/lib/clang/1.5 -O2 -ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-rrmzgR.s -x c fopen.c
  2. parser at end of file
  3. Code generation
  4. Running pass 'X86 DAG->DAG Instruction Selection' on function '@main' clang: error: compiler command failed due to signal 11 (use -v to see invocation)

-O1 also crashes, -O0 works. This testcase works with clang revision 100677.

llvmbot commented 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

lattner commented 14 years ago

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.

llvmbot commented 14 years ago

when I compile llvm/clang with -O2 instead of -O3 the problem goes away

llvmbot commented 14 years ago

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                                                                                                                                        

​0 0x0831cbdc in llvm::SelectionDAG::getGlobalAddress ()

​1 0x081ad91e in llvm::X86TargetLowering::LowerGlobalAddress ()

​2 0x081af645 in llvm::X86TargetLowering::LowerGlobalAddress ()

​3 0x0821b858 in llvm::X86TargetLowering::LowerOperation ()

​4 0x08419cf3 in llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo,

    llvm::DenseMapInfo<unsigned int> >::grow ()                                                                                                     

​5 0x0842ce93 in llvm::DenseMap<llvm::SDValue, unsigned int, llvm::DenseMapInfo,

    llvm::DenseMapInfo<unsigned int> >::grow ()                                                                                                     

​6 0x0842d5c6 in llvm::SelectionDAG::Legalize ()

​7 0x083d3118 in llvm::SelectionDAGISel::CodeGenAndEmitDAG ()

​8 0x083d648e in llvm::SelectionDAGISel::SelectBasicBlock ()

​9 0x083d6c28 in llvm::SelectionDAGISel::SelectAllBasicBlocks ()

​10 0x083d7955 in llvm::SelectionDAGISel::runOnMachineFunction ()

​11 0x08507d3a in llvm::MachineFunctionPass::runOnFunction ()

​12 0x088b7b4f in llvm::FPPassManager::runOnFunction ()

​13 0x088b7c60 in llvm::FunctionPassManagerImpl::run ()

​14 0x088b800d in llvm::FunctionPassManager::run ()

​15 0x08122a10 in main ()

lattner commented 14 years ago

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?

llvmbot commented 14 years ago

bitcode file I found out that this problem only happens on i386. I can't reproduce it on x86_64.

llvmbot commented 14 years ago

Please attach a bitcode file, thanks.