http://llvm.org/bugs/show_bug.cgi?id=6482
Summary: llvm-link asserts with "Type mismatch in constant
table!" depending on linking order
Product: new-bugs
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P5
Component: new bugs
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
The attached two bitcode files are both individually fine, but llvm-link from
trunk (r97652) asserts if one links them in the order 'one.bc' 'two.bc':
$ llvm-link one.bc two.bc >/dev/null
llvm-link: src/llvm/trunk/lib/Bitcode/Reader/BitcodeReader.cpp:203:
llvm::Constant* llvm::BitcodeReaderValueList::getConstantFwdRef(unsigned int,
const llvm::Type*): Assertion `Ty == V->getType() && "Type mismatch in constant
table!"' failed.
Stack dump:
0. Program arguments: llvm-link one.bc two.bc
Doing it in the other order is fine though:
$ llvm-link two.bc one.bc | llvm-dis | wc -l
1267
llvm-link from LLVM 2.6 copes fine regardless of the order, but it does produce
different output for the two cases. (Not necessarily unexpected?)
I think that this is the same problem that is preventing me from bugpointing a
misoptimization: bugpoint dies in the same way when it starts splitting the
testcase.
Using the 'delta' tool for several CPU-hours I managed to bring 'two.bc' down
from over a megabyte to the current 43K, but it's still a bit big; I hope it's
not so big as to make finding the problem unduly difficult.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
