[LLVMbugs] [Bug 6482] New: llvm-link asserts with "Type mismatch in constant table!" depending on linking order

[bugzilla-daemon at llvm.org]

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: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


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.