After updating LLVM and applying recent patches to llvm-gcc (CUMMULATIVE-276.patch sent to llvm-commits today), the llvm-gcc build now fails while compiling libgcc, with: cc1: LiveInterval.cpp:227: void llvm::LiveInterval::removeRange(unsigned int, unsigned int): Assertion `I->contains(Start) && I->contains(End-1) && "Range is not entirely in interval!"' failed. Stack trace: #0 0x00826402 in __kernel_vsyscall () #1 0x00321ee9 in raise () from /lib/libc.so.6 #2 0x003234f1 in abort () from /lib/libc.so.6 #3 0x0031b859 in __assert_fail () from /lib/libc.so.6 #4 0x08735631 in llvm::LiveInterval::removeRange (this=0xaa2f1f0, Start=14, End=115) at LiveInterval.cpp:226 #5 0x0873cd73 in llvm::LiveInterval::removeRange (this=0xaa2f1f0, LR={start = 14, end = 115, ValId = 0}) at /proj/llvm/llvm-1/include/llvm/CodeGen/LiveInterval.h:253 #6 0x0873bbce in llvm::LiveIntervals::runOnMachineFunction (this=0xaa410e0, fn= #7 0x0856a4aa in llvm::MachineFunctionPass::runOnFunction (this=0xaa410e0, F= #8 0x088c13c8 in llvm::FPPassManager::runOnFunction (this=0xaa3fda8, F=@0xaa55978) at PassManager.cpp:998 #9 0x088c162a in llvm::FunctionPassManagerImpl::run (this=0xaa3fac8, F=@0xaa55978) at PassManager.cpp:953 #10 0x088c16ec in llvm::FunctionPassManager::run (this=0xaa3e0f8, F=@0xaa55978) at PassManager.cpp:895 #11 0x0833b8d8 in llvm_asm_file_end () at ../../src-1/gcc/llvm-backend.cpp:473 #12 0x0830bdc9 in toplev_main (argc=0, argv=0xbfed1fc4) at ../../src-1/gcc/toplev.c:1167 #13 0x0030f4e4 in __libc_start_main () from /lib/libc.so.6 #14 0x0804e171 in _start ()
Command line options (to cc1) used to generate this: -quiet -v -I. -I. -I../../src-1/gcc -I../../src-1/gcc/. -I../../src-1/gcc/../include -I../../src-1/gcc/../libcpp/include -I/proj/llvm/llvm-1/include -I/proj/llvm/llvm-1/include -iprefix /proj/llvm/cfe/build-1/gcc/../lib/gcc/i686-pc-linux-gnu/4.0.1/ -isystem /proj/llvm/cfe/build-1/gcc/include -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_eprintf -isystem /proj/llvm/cfe/install-1/i686-pc-linux-gnu/include -isystem /proj/llvm/cfe/install-1/i686-pc-linux-gnu/sys-include -isystem ./include ../../src-1/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mtune=generic -auxbase-strip libgcc/./_eprintf.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -o /tmp/ccQbquX1.s
Created attachment 670 [details] Bytecode generated by -emit-llvm switch to llc This attachment was generated with these commands: cc1 -quiet -v -I. -I. -I../../src-1/gcc -I../../src-1/gcc/. -I../../src-1/gcc/../include -I../../src-1/gcc/../libcpp/include -I/proj/llvm/llvm-1/include -I/proj/llvm/llvm-1/include -iprefix /proj/llvm/cfe/build-1/gcc/../lib/gcc/i686-pc-linux-gnu/4.0.1/ -isystem /proj/llvm/cfe/build-1/gcc/include -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DL_eprintf -isystem /proj/llvm/cfe/install-1/i686-pc-linux-gnu/include -isystem /proj/llvm/cfe/install-1/i686-pc-linux-gnu/sys-include -isystem ./include ../../src-1/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -mtune=generic -auxbase-strip libgcc/./_eprintf.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -o /tmp/pr1207.ll -emit-llvm llvm-as /tmp/pr1207.bc Unfortunately, running llc on this doesn't replicate the problem.
Confirmed here. Reproducible via "llc -relocation-model=pic"
Yup, stack trace for 'llc -relocation-model=pic pr1207.bc' is: #0 0x00b25402 in __kernel_vsyscall () #1 0x00137ee9 in raise () from /lib/libc.so.6 #2 0x001394f1 in abort () from /lib/libc.so.6 #3 0x00131859 in __assert_fail () from /lib/libc.so.6 #4 0x08720431 in llvm::LiveInterval::removeRange (this=0xa0b0a60, Start=14, End=115) at LiveInterval.cpp:226 #5 0x08727b73 in llvm::LiveInterval::removeRange (this=0xa0b0a60, LR= {start = 14, end = 115, ValId = 0}) at /proj/llvm/llvm-1/include/llvm/CodeGen/LiveInterval.h:253 #6 0x087269ce in llvm::LiveIntervals::runOnMachineFunction (this=0xa0a64a8, fn=@0xa0ad958) at LiveIntervalAnalysis.cpp:148 #7 0x083dff42 in llvm::MachineFunctionPass::runOnFunction (this=0xa0a64a8, F=@0xa09d810) at /proj/llvm/llvm-1/include/llvm/CodeGen/MachineFunctionPass.h:37 #8 0x0882adb0 in llvm::FPPassManager::runOnFunction (this=0xa09e9b0, F=@0xa09d810) at PassManager.cpp:998 #9 0x0882b012 in llvm::FunctionPassManagerImpl::run (this=0xa0a24d0, F=@0xa09d810) at PassManager.cpp:953 #10 0x0882b0d4 in llvm::FunctionPassManager::run (this=0xbfa77df4, F=@0xa09d810) at PassManager.cpp:895 #11 0x083b593f in main (argc=4, argv=0xbfa77ee4) at llc.cpp:290
Since this doesn't seem to be getting attended to, I'm going to revert Evan's patches if it resolves this issue.
Created attachment 671 [details] Script to revert Evant's changes. I'm not going to commit this, but here's a little script that revert's Evans changes. This allows llvm-gcc to compile. However, there are still dejagnu failures. Additionally, a change to llvm-gcc was needed. To use this, 1. Save to /tmp/pr1207.revert 2. cd llvm 3. . /tmp/pr1207.revert
Evans changes have been reverted. These alleviates the issue, but I'm not closing this until Evan can figure out why his changes caused the bug and reapplies with a fix. Assigning to Evan.
Reapplied with fix. llvm-gcc builds fine on Mac OS X. Reid / Anton, please trye to d a llvm-gcc build on Linux. Thanks.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044770.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044771.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044772.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044776.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044773.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044777.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044774.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044778.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044775.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044779.html
libgcc is ok for me now. I'm starting building Qt. If everything will be ok, this bug can be closed. Ok?
Seems, llc -debug is broken somehow. Try attached bytecode. It should: 1. Compile ok with just "llc" 2. Cycle with "llc -relocation-model=pic". It seems to do so, but adding -debug lead llc to segfault.
Created attachment 672 [details] Bytecode
Created attachment 673 [details] LLVM source code
Anton, I think llc -debug is a separate issue. Can you close this bug and open a new one for that? Thanks!
Qt is heavily broken. I'm investigating.
Evan, this change definitly breaks Qt. Are there any fails in nightlytests? I'm investigating the problem, but don't know, how much time it will take. I'm also attaching patch which will undo recent LiveVars change.
Created attachment 676 [details] LiveVars patch. Use "patch -p1 -R" to revert.
There are some significant regressions which I am trying to track down. They appear to be unrelated to liveintervalanalysis. I'll let you know what the bug is fixed so you can try again.
Well. Ok. I'm waiting.
I've fix the bug which breaks a bunch of tests that use double. Anton, can you test QT again?
Surely.
It's building now. However, I don't understand how this issue can cause segfaults... But will surely check.
Qt is still broken. It just segfaults....
Reduced miscompilation just to one .o. Comparing.
Created attachment 677 [details] LLVM source
Created attachment 678 [details] "Bad" output
Created attachment 679 [details] "Good" output
Evan, recent LiveVariables patches caused the folowing regression to Qt. Please see attached LLVM source and 2 assembler listings. One ("Good") - without LiveVars patch and another - with. I think, you should compile .ll with "--relocation-model=pic" llc option. There are only few differences, but they seems to be very strange.
I'm sorry. "Good" output should be "Bad" and vice versa.
Comment on attachment 678 [details] "Bad" output Fixed mark
Comment on attachment 679 [details] "Good" output Fixed mark
Ah, ok. I'd suspected that. I'll try to fix this today.
Anton, can you confirm _ZNK11QMetaObject6methodEi is the offending function? For Linux / PIC, EBX must always point to the GOT, right? I see now codegen (thanks to smarter liveintervalanalysis) is making use of EBX as a general purpose register.
No. Not always. Any register can be used as GOT pointer with only one restriction: during function calls via PLT GOT pointer should be in %ebx (there is special %ebx loading inside call lowering). I'll check function separately and let you know.
Well. Yes. It seems, that %ebx is changed before calls via PLT. This applies for all 3 functions found in diff between "bad" and "good"
Needed to add an implicit use of EBX so the result of the instruction that calculate GOT is not dead right after defintion. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070219/044839.html Anton, can you verify if this fixes QT?
Verifying...
Evan, patch fixes issue with that file. Thanks. I'll close this bug just after Qt will be rebuilt.
Fixed, thanks, Evan.