If LLVM is configured with --enable-optimization --enable-assertions and built with gcc-4.2/g++-4.2 on x86-32 linux, then the llvm-gcc build fails (see below). This does not occur if gcc-4.3 or gcc-4.4 is used. .../gcc/xgcc -B/home/duncan/LLVM/gcc-4.2.llvm-objects-32/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../gcc-4.2.llvm/gcc -I../../gcc-4.2.llvm/gcc/. -I../../gcc-4.2.llvm/gcc/../include -I../../gcc-4.2.llvm/gcc/../libcpp/include -I../../gcc-4.2.llvm/gcc/../libdecnumber -I../libdecnumber -I/home/duncan/llvm-2.8/Phase1/Release/llvmCore-2.8-rc1.obj/include -I/home/duncan/llvm-2.8/llvmCore-2.8-rc1.src/include -g0 -finhibit-size-directive -fno-inline-functions -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-omit-frame-pointer \ -c ../../gcc-4.2.llvm/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o ../../gcc-4.2.llvm/gcc/crtstuff.c:378: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://llvm.org/bugs/> for instructions.
Revision 102553 works ok, while 102604 onwards fail in the way described here. The revisions between these fail to build in various different ways.
It looks to be due to this commit: r102604 | edwin | 2010-04-29 08:43:12 +0200 (Thu, 29 Apr 2010) | 7 lines Fix PR6910. Limit alignment in SmallVector 8, otherwise GCC assumes 16 byte alignment. opetaror new, and malloc only return 8-byte aligned memory on 32-bit Linux, which cause a crash if code is compiled with -O3 (or -ftree-vectorize) and some SmallVector code is vectorized. Index: include/llvm/ADT/SmallVector.h =================================================================== --- include/llvm/ADT/SmallVector.h (revision 102603) +++ include/llvm/ADT/SmallVector.h (revision 102604) @@ -59,7 +59,7 @@ // number of union instances for the space, which guarantee maximal alignment. struct U { #ifdef __GNUC__ - char X __attribute__((aligned)); + char X __attribute__((aligned(8))); #else union { double D;
(In reply to comment #2) > It looks to be due to this commit: > That is interesting. Without this commit you crash at -O3, and with this commit you crash at -O2? Can you get a stacktrace from the segmentation fault?
It thinks that FreeList is null. There's no obvious use of SmallVector in the back-trace. Curiously, BumpPtrAllocator makes use of aligned in almost exactly the same was as SmallVector did before Edwin changed it. #0 Allocate<llvm::SDNode, llvm::BumpPtrAllocator> (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=<value optimized out>, Chain=..., Ptr=..., Offset=..., MemVT=..., MMO=0x95048dc) at /home/duncan/tmp/tmp/bisect/llvm/include/llvm/Support/Recycler.h:97 #1 Allocate<llvm::BumpPtrAllocator> (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=<value optimized out>, Chain=..., Ptr=..., Offset=..., MemVT=..., MMO=0x95048dc) at /home/duncan/tmp/tmp/bisect/llvm/include/llvm/Support/Recycler.h:102 #2 llvm::RecyclingAllocator<llvm::BumpPtrAllocator, llvm::SDNode, 136u, 4u>::Allocate (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=<value optimized out>, Chain=..., Ptr=..., Offset=..., MemVT=..., MMO=0x95048dc) at /home/duncan/tmp/tmp/bisect/llvm/include/llvm/Support/RecyclingAllocator.h:46 #3 operator new<llvm::BumpPtrAllocator, llvm::SDNode, 136u, 4u> (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=<value optimized out>, Chain=..., Ptr=..., Offset=..., MemVT=..., MMO=0x95048dc) at /home/duncan/tmp/tmp/bisect/llvm/include/llvm/Support/RecyclingAllocator.h:63 #4 llvm::SelectionDAG::getLoad (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=<value optimized out>, Chain=..., Ptr=..., Offset=..., MemVT=..., MMO=0x95048dc) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3942 #5 0x089361dc in llvm::SelectionDAG::getLoad (this=0x94e9e38, AM=llvm::ISD::UNINDEXED, dl=..., ExtType=llvm::ISD::EXTLOAD, VT=..., Chain=..., Ptr=..., Offset=..., SV=0x945730c, SVOffset=0, MemVT=<value optimized out>, isVolatile=false, isNonTemporal=false, Alignment=1) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3899 #6 0x0893674f in llvm::SelectionDAG::getExtLoad (this=0x94e9e38, ExtType=llvm::ISD::EXTLOAD, dl=..., VT=..., Chain=..., Ptr=..., SV=0x945730c, SVOffset=0, MemVT=..., isVolatile=<value optimized out>, isNonTemporal=<value optimized out>, Alignment=1) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3966 #7 0x08a85f35 in llvm::DAGTypeLegalizer::PromoteIntRes_LOAD (this=0xffffbc48, N=0x9506bb0) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:375 #8 0x08a8f00e in llvm::DAGTypeLegalizer::PromoteIntegerResult (this=0xffffbc48, N=0x9506bb0, ResNo=0) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:63 #9 0x08a1df2c in llvm::DAGTypeLegalizer::run (this=0xffffbc48) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:235 #10 0x08a1eee2 in llvm::SelectionDAG::LegalizeTypes (this=0x94e9e38) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:1109 #11 0x089c176d in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x94e96f0, BB=0x9504668) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:468 #12 0x089c3f14 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x94e96f0, BB=0x9504668, LLVMBB=0x943ea10, Begin=..., End=..., HadTailCall=@0xffffc147) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:243 #13 0x089c4b09 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x94e96f0, Fn=...) at /home/duncan/tmp/tmp/bisect/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:809 #14 0x089c51d9 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x94e96f0, mf=...)
Symptom of original crash I fixed was a crash in llvm::PassManager::PassManager() See here for a testcase: http://llvm.org/bugs/show_bug.cgi?id=6910 See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1984 for full details, especially https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1984#c14 which explains why the aligned attribute is wrong, and need to limit it to 8. Does reverting my patch fix the crash in llvm-gcc? And does it cause in turn the testcase from #6910 to crash?
I tried a variant of your patch: changing struct U { #ifdef __GNUC__ char X __attribute__((aligned%
(In reply to comment #6) > I tried a variant of your patch: changing > > struct U { > #ifdef __GNUC__ > char X __attribute__((aligned% What was the result?
LLVM-GCC has reached its end of life as far as llvm.org releases go. Please migrate to Clang or DragonEgg when possible. The llvm-gcc SVN repo will still continue to exist, so additional patches can go into it if you so desire, but since we have no more releases of it coming, it doesn't make sense to track bugs for it anymore. If this is a problem that still exists with clang or DragonEgg, please file a new bug to track it. Thanks! -Chris