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

[WenHan Gu (谷汶翰)]

Also, in the former case, the MDNode dump result is the same.


2014-03-28 16:28 GMT+08:00 WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>:

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



-- 
Best Regards,
WenHan Gu (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140328/2626fa8b/attachment.html>