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

LiveVariables assertion prevents llvm-gcc build #1579

Closed
llvmbot opened this issue Feb 18, 2007 · 39 comments
Closed

LiveVariables assertion prevents llvm-gcc build #1579

llvmbot opened this issue Feb 18, 2007 · 39 comments
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:codegen

Comments

@llvmbot
Copy link
Member

llvmbot commented Feb 18, 2007

Bugzilla Link 1207
Resolution FIXED
Resolved on Feb 22, 2010 12:48
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @asl,@lattner

Extended Description

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 ()

@llvmbot
Copy link
Member Author

llvmbot commented Feb 18, 2007

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

@llvmbot
Copy link
Member Author

llvmbot commented Feb 18, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 18, 2007

Confirmed here.
Reproducible via "llc -relocation-model=pic"

@llvmbot
Copy link
Member Author

llvmbot commented Feb 18, 2007

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

@llvmbot
Copy link
Member Author

llvmbot commented Feb 18, 2007

Since this doesn't seem to be getting attended to, I'm going to revert Evan's
patches if it resolves this issue.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 18, 2007

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

@llvmbot
Copy link
Member Author

llvmbot commented Feb 19, 2007

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.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 19, 2007

Reapplied with fix. llvm-gcc builds fine on Mac OS X. Reid / Anton, please trye to d a llvm-gcc build on
Linux. Thanks.

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

libgcc is ok for me now. I'm starting building Qt. If everything will be ok,
this bug can be closed. Ok?

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

Bytecode

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

LLVM source code

@llvmbot
Copy link
Member Author

llvmbot commented Feb 20, 2007

Anton, I think llc -debug is a separate issue. Can you close this bug and open a new one for that?

Thanks!

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

Qt is heavily broken. I'm investigating.

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

LiveVars patch.
Use "patch -p1 -R" to revert.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 20, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

Well. Ok. I'm waiting.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 20, 2007

I've fix the bug which breaks a bunch of tests that use double. Anton, can you test QT again?

@asl
Copy link
Collaborator

asl commented Feb 20, 2007

Surely.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

It's building now. However, I don't understand how this issue can cause
segfaults... But will surely check.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

Qt is still broken. It just segfaults....

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

Reduced miscompilation just to one .o. Comparing.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

LLVM source

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

"Bad" output

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

"Good" output

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

I'm sorry. "Good" output should be "Bad" and vice versa.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

"Bad" output
Fixed mark

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

"Good" output
Fixed mark

@llvmbot
Copy link
Member Author

llvmbot commented Feb 21, 2007

Ah, ok. I'd suspected that. I'll try to fix this today.

@llvmbot
Copy link
Member Author

llvmbot commented Feb 21, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

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.

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

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"

@llvmbot
Copy link
Member Author

llvmbot commented Feb 21, 2007

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?

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

Verifying...

@asl
Copy link
Collaborator

asl commented Feb 21, 2007

Evan, patch fixes issue with that file. Thanks. I'll close this bug just after
Qt will be rebuilt.

@asl
Copy link
Collaborator

asl commented Feb 22, 2007

Fixed, thanks, Evan.

@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
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:codegen
Projects
None yet
Development

No branches or pull requests

2 participants