[llvm] r204107 - DwarfDebug: Only unique retained types instead of all types.

[Adrian Prantl]

Preprocessed files (output of clang -E + the command line options would be good enough for me :-)

thanks!

adrian

On Mar 28, 2014, at 8:36 AM, David Blaikie <dblaikie at gmail.com> wrote:

> Could you provide each of the files involved (ideally: two source
> files, two preprocessed files, and for bonus points, the two LLVM IR
> files - and the full (-cc1) command lines)?
> 
> (preferably as email attachments, possibly in a tar.gz if necessary)
> 
> On Fri, Mar 28, 2014 at 1:28 AM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com> wrote:
>> Finally I found a way to reproduce this not depending on my local project.
>> I cannot submit this to bugzilla, the post_bug.cgi seems break.
>> 
>> Could you help reproduce this? IMHO this may be a bug.
>> 
>> If I #include <chrono> and <locale> to the same file, then llc works.
>> but if I #include them separately on a.cpp and c.cpp, then after llvm-link,
>> llc crashes.
>> My workstation is x86_64, ubuntu13.10, 3.11.0-15-generic.
>> 
>> Thanks!
>> 
>> 
>> HOWTO:
>> 
>> $ cat a.cpp
>> #include <chrono>
>> 
>> $ cat b.cpp
>> #include <locale>
>> 
>> $ clang -g -emit-llvm -std=c++11 -c a.cpp b.cpp
>> $ llvm-link a.bc b.bc | llc
>> 
>> llc: /home/mtk03872/works/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:984:
>> llvm::DIE *llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode *):
>> Assertion `Ty == resolve(Ty.getRef()) && "type was not uniqued, possible ODR
>> violation."' failed.
>> 0  llc             0x00000000011a2255 llvm::sys::PrintStackTrace(_IO_FILE*)
>> + 37
>> 1  llc             0x00000000011a29a3
>> 2  libpthread.so.0 0x00007f271ef28bb0
>> 3  libc.so.6       0x00007f271df3cf77 gsignal + 55
>> 4  libc.so.6       0x00007f271df405e8 abort + 328
>> 5  libc.so.6       0x00007f271df35d43
>> 6  libc.so.6       0x00007f271df35df2
>> 7  llc             0x0000000000ca3dd4
>> 8  llc             0x0000000000c87579
>> llvm::DwarfDebug::constructImportedEntityDIE(llvm::DwarfCompileUnit*,
>> llvm::DIImportedEntity const&, llvm::DIE*) + 281
>> 9  llc             0x0000000000c83ff2 llvm::DwarfDebug::beginModule() + 1234
>> 10 llc             0x0000000000c83a79
>> llvm::DwarfDebug::DwarfDebug(llvm::AsmPrinter*, llvm::Module*) + 1801
>> 11 llc             0x0000000000c73e70
>> llvm::AsmPrinter::doInitialization(llvm::Module&) + 1008
>> 12 llc             0x000000000113bc86
>> llvm::FPPassManager::doInitialization(llvm::Module&) + 86
>> 13 llc             0x000000000113c09e
>> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 734
>> 14 llc             0x0000000000561622 main + 6370
>> 15 libc.so.6       0x00007f271df27de5 __libc_start_main + 245
>> 16 llc             0x000000000055ea2d
>> Stack dump:
>> 0.      Program arguments: llc
>> Aborted
>> 
>> 
>> 2014-03-28 0:51 GMT+08:00 Adrian Prantl <aprantl at apple.com>:
>> 
>>> 
>>> On Mar 27, 2014, at 9:43 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>> 
>>>> On Thu, Mar 27, 2014 at 9:39 AM, Adrian Prantl <aprantl at apple.com>
>>>> wrote:
>>>>> 
>>>>> On Mar 26, 2014, at 11:15 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Adrian,
>>>>>> 
>>>>>> After this commit, there's sometimes assert fail on large bitcodes on
>>>>>> my environment.
>>>>> 
>>>>> Is there any chance you can provide me with a reduced example that
>>>>> reproduces this?
>>>>> 
>>>>>> According to my result, two types seems the same, and I take out the
>>>>>> assert fail can still build and run.
>>>>>> Is any possible that the contained MDNode is not the same (since it is
>>>>>> a pointer comparison indeed) but this is reasonable?
>>>>>> Thanks!
>>>>> 
>>>>> Since the MDNodes are kept in a FoldingSet there should be no two
>>>>> identical nodes. What may happen in your case is that the source code
>>>>> contains two conflicting definitions of the same type in two compilation
>>>>> units. This is illegal C++ (violation of the ODR), but the compiler
>>>>> currently has no way to diagnose such a situation.
>>>>> 
>>>>> On a related note, this made me realize that this assertion should only
>>>>> be enabled for C++ compilation units; I will fix this soon. This will not
>>>>> fix your problem, unfortunately.
>>>> 
>>>> Hmm? The assertion should still be true in any case, shouldn't it?
>>>> (the 'reference' will just be a straight MDNode when we don't have a
>>>> mangled name there) But perhaps I'm forgetting the exact schema.
>>> You’re right, while there may be conflicting definitions for a type in a
>>> non-ODR-language, resolve() would also be a noop (no such thing as an ID
>>> field in a C DIType), so this would still be safe.
>>> 
>>> -- adrian
>> 
>> 
>> 
>> 
>> --
>> Best Regards,
>> WenHan Gu (Nowar)