[llvm] r204107 - DwarfDebug: Only unique retained types instead of all types.
Adrian Prantl
aprantl at apple.com
Mon Mar 31 20:59:58 PDT 2014
Hello 谷汶翰,
could you please verify if r205279 fixes the problem?
thanks,
Adrian
On Mar 31, 2014, at 4:34 PM, Adrian Prantl <aprantl at apple.com> wrote:
> Hi WenHan,
>
> I can’t reproduce your error, but from looking at your .bc files, I’m pretty sure the problem is the DIImportedEntity doesn’t use DIScopeRefs, so all DW_TAG_imported_declarations from a.bc refere to the forward declaration in a, which should have been uniqued.
> I’ll fix that.
>
> thanks for reporting this!
> Adrian
>
> On Mar 30, 2014, at 7:20 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com> wrote:
>
>> Sorry for late response.
>>
>> My company blocks email file upload, I use google drive.
>> If cannot access, please kindly let me know.
>>
>>
>> The command is simple:
>> clang++ -g -emit-llvm -std=c++11 -c a.ii b.ii
>> llvm-link a.bc b.bc | llc
>>
>>
>> The dump info: (DIDescriptor & MDNode)
>> Ty:
>> [ DW_TAG_structure_type ] [tm] [line 133, size 0, align 0, offset 0] [decl] [from ]
>> !{i32 786451, metadata <badref>, null, metadata !"tm", i32 133, i64 0, i64 0, i32 0, i32 4, null, null, i32 0, null, null, metadata !"_ZTS2tm"} ; [ DW_TAG_structure_type ] [tm] [line 133, size 0, align 0, offset 0] [decl] [from ]
>>
>> resolve(Ty.getRef()):
>> [ DW_TAG_structure_type ] [tm] [line 133, size 448, align 64, offset 0] [def] [from ]
>> !{i32 786451, metadata <badref>, null, metadata !"tm", i32 133, i64 448, i64 64, i32 0, i32 0, null, metadata <badref>, i32 0, null, null, metadata !"_ZTS2tm"} ; [ DW_TAG_structure_type ] [tm] [line 133, size 448, align 64, offset 0] [def] [from ]
>>
>>
>> llc_crash_after_r204107.tar.xz
>>
>>
>>
>> 2014-03-28 23:37 GMT+08:00 Adrian Prantl <aprantl at apple.com>:
>> 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)
>>
>>
>>
>>
>> --
>> Best Regards,
>> WenHan Gu (Nowar)
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
More information about the llvm-commits
mailing list