[llvm-dev] lld/lto/win32 crash on DIE code

[Carlo Kok via llvm-dev]

I have a fairly recent LLD/LTO llvm crashing on

DIE *ContextDIE = getOrCreateContextDIE(Context)
being null for a (local) variable. (Context is a DICompileUnit in this 
case, but it's not present in MDNodeToDieMap so it returns null. 
callstack is:

llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) 
Line 718	C++
llvm::DwarfUnit::addType(llvm::DIE & Entity, const llvm::DIType * Ty, 
llvm::dwarf::Attribute Attribute) Line 768	C++
llvm::DwarfCompileUnit::applyVariableAttributes(const llvm::DbgVariable 
& Var, llvm::DIE & VariableDie) Line 897	C++
llvm::DwarfCompileUnit::finishVariableDefinition(const llvm::DbgVariable 
& Var) Line 725	C++
llvm::DwarfDebug::finishVariableDefinitions() Line 655	C++
llvm::DwarfDebug::finalizeModuleInfo() Line 677	C++
llvm::DwarfDebug::endModule() Line 768	C++
llvm::AsmPrinter::doFinalization(llvm::Module & M) Line 1348	C++
llvm::FPPassManager::doFinalization(llvm::Module & M) Line 1559	C++
`anonymous namespace'::MPPassManager::runOnModule(llvm::Module & M) Line 
1615	C++
llvm::legacy::PassManagerImpl::run(llvm::Module & M) Line 1700	C++
llvm::legacy::PassManager::run(llvm::Module & M) Line 1732	C++
compileModule(char * * argv, llvm::LLVMContext & Context) Line 572	C++

The input of this testcase is huge, full repro.tar is here: (14mb)
https://www.dropbox.com/s/ugv9sfqouhlszff/repro.tar?dl=0

With lld /lldsavetemps I managed to narrow down what it actually fails 
on, specifcally from the Island.Tests.Windows.exe.0.5.precodegen.bc 
(which fails too when passed to llc -O1)

This is the pattern that it generates:
https://gist.github.com/carlokok/fb0f1bf213ee4599d8f2442e37b23f03

If I read this correctly it somehow ends up using two compile units at 
once from the same type and failing because of that. I don't know if 
that's a merging bug or something I'm doing, but none of my input bc 
files has more than 1 compileunit per file, so I don't know how this 
could have happened.

What can I do to solve this?


Thanks,

carlo Kok