
<div dir="ltr">Big thanks!  Fixed!<div class="gmail_extra"><br><div class="gmail_quote">2014-04-01 11:59 GMT+08:00 Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span>:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello 谷汶翰,<br>

<br>

could you please verify if r205279 fixes the problem?<br>

<br>

thanks,<br>

Adrian<br>

<div class="HOEnZb"><div class="h5"><br>

On Mar 31, 2014, at 4:34 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>

<br>

> Hi WenHan,<br>

><br>

> 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.<br>


> I’ll fix that.<br>

><br>

> thanks for reporting this!<br>

> Adrian<br>

><br>

> On Mar 30, 2014, at 7:20 PM, WenHan Gu (谷汶翰) <<a href="mailto:wenhan.gu@gmail.com">wenhan.gu@gmail.com</a>> wrote:<br>

><br>

>> Sorry for late response.<br>

>><br>

>> My company blocks email file upload, I use google drive.<br>

>> If cannot access, please kindly let me know.<br>

>><br>

>><br>

>> The command is simple:<br>

>> clang++ -g -emit-llvm -std=c++11 -c a.ii b.ii<br>

>> llvm-link a.bc b.bc | llc<br>

>><br>

>><br>

>> The dump info: (DIDescriptor & MDNode)<br>

>> Ty:<br>

>> [ DW_TAG_structure_type ] [tm] [line 133, size 0, align 0, offset 0] [decl] [from ]<br>

>> !{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 ]<br>


>><br>

>> resolve(Ty.getRef()):<br>

>> [ DW_TAG_structure_type ] [tm] [line 133, size 448, align 64, offset 0] [def] [from ]<br>

>> !{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 ]<br>


>><br>

>><br>

>> llc_crash_after_r204107.tar.xz<br>

>><br>

>><br>

>><br>

>> 2014-03-28 23:37 GMT+08:00 Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>>:<br>

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

>><br>

>> thanks!<br>

>><br>

>> adrian<br>

>><br>

>> On Mar 28, 2014, at 8:36 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>

>><br>

>>> Could you provide each of the files involved (ideally: two source<br>

>>> files, two preprocessed files, and for bonus points, the two LLVM IR<br>

>>> files - and the full (-cc1) command lines)?<br>

>>><br>

>>> (preferably as email attachments, possibly in a tar.gz if necessary)<br>

>>><br>

>>> On Fri, Mar 28, 2014 at 1:28 AM, WenHan Gu (谷汶翰) <<a href="mailto:wenhan.gu@gmail.com">wenhan.gu@gmail.com</a>> wrote:<br>

>>>> Finally I found a way to reproduce this not depending on my local project.<br>

>>>> I cannot submit this to bugzilla, the post_bug.cgi seems break.<br>

>>>><br>

>>>> Could you help reproduce this? IMHO this may be a bug.<br>

>>>><br>

>>>> If I #include <chrono> and <locale> to the same file, then llc works.<br>

>>>> but if I #include them separately on a.cpp and c.cpp, then after llvm-link,<br>

>>>> llc crashes.<br>

>>>> My workstation is x86_64, ubuntu13.10, 3.11.0-15-generic.<br>

>>>><br>

>>>> Thanks!<br>

>>>><br>

>>>><br>

>>>> HOWTO:<br>

>>>><br>

>>>> $ cat a.cpp<br>

>>>> #include <chrono><br>

>>>><br>

>>>> $ cat b.cpp<br>

>>>> #include <locale><br>

>>>><br>

>>>> $ clang -g -emit-llvm -std=c++11 -c a.cpp b.cpp<br>

>>>> $ llvm-link a.bc b.bc | llc<br>

>>>><br>

>>>> llc: /home/mtk03872/works/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:984:<br>

>>>> llvm::DIE *llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode *):<br>

>>>> Assertion `Ty == resolve(Ty.getRef()) && "type was not uniqued, possible ODR<br>

>>>> violation."' failed.<br>

>>>> 0  llc             0x00000000011a2255 llvm::sys::PrintStackTrace(_IO_FILE*)<br>

>>>> + 37<br>

>>>> 1  llc             0x00000000011a29a3<br>

>>>> 2  libpthread.so.0 0x00007f271ef28bb0<br>

>>>> 3  libc.so.6       0x00007f271df3cf77 gsignal + 55<br>

>>>> 4  libc.so.6       0x00007f271df405e8 abort + 328<br>

>>>> 5  libc.so.6       0x00007f271df35d43<br>

>>>> 6  libc.so.6       0x00007f271df35df2<br>

>>>> 7  llc             0x0000000000ca3dd4<br>

>>>> 8  llc             0x0000000000c87579<br>

>>>> llvm::DwarfDebug::constructImportedEntityDIE(llvm::DwarfCompileUnit*,<br>

>>>> llvm::DIImportedEntity const&, llvm::DIE*) + 281<br>

>>>> 9  llc             0x0000000000c83ff2 llvm::DwarfDebug::beginModule() + 1234<br>

>>>> 10 llc             0x0000000000c83a79<br>

>>>> llvm::DwarfDebug::DwarfDebug(llvm::AsmPrinter*, llvm::Module*) + 1801<br>

>>>> 11 llc             0x0000000000c73e70<br>

>>>> llvm::AsmPrinter::doInitialization(llvm::Module&) + 1008<br>

>>>> 12 llc             0x000000000113bc86<br>

>>>> llvm::FPPassManager::doInitialization(llvm::Module&) + 86<br>

>>>> 13 llc             0x000000000113c09e<br>

>>>> llvm::legacy::PassManagerImpl::run(llvm::Module&) + 734<br>

>>>> 14 llc             0x0000000000561622 main + 6370<br>

>>>> 15 libc.so.6       0x00007f271df27de5 __libc_start_main + 245<br>

>>>> 16 llc             0x000000000055ea2d<br>

>>>> Stack dump:<br>

>>>> 0.      Program arguments: llc<br>

>>>> Aborted<br>

>>>><br>

>>>><br>

>>>> 2014-03-28 0:51 GMT+08:00 Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>>:<br>

>>>><br>

>>>>><br>

>>>>> On Mar 27, 2014, at 9:43 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>

>>>>><br>

>>>>>> On Thu, Mar 27, 2014 at 9:39 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>><br>

>>>>>> wrote:<br>

>>>>>>><br>

>>>>>>> On Mar 26, 2014, at 11:15 PM, WenHan Gu (谷汶翰) <<a href="mailto:wenhan.gu@gmail.com">wenhan.gu@gmail.com</a>><br>

>>>>>>> wrote:<br>

>>>>>>><br>

>>>>>>>> Hi Adrian,<br>

>>>>>>>><br>

>>>>>>>> After this commit, there's sometimes assert fail on large bitcodes on<br>

>>>>>>>> my environment.<br>

>>>>>>><br>

>>>>>>> Is there any chance you can provide me with a reduced example that<br>

>>>>>>> reproduces this?<br>

>>>>>>><br>

>>>>>>>> According to my result, two types seems the same, and I take out the<br>

>>>>>>>> assert fail can still build and run.<br>

>>>>>>>> Is any possible that the contained MDNode is not the same (since it is<br>

>>>>>>>> a pointer comparison indeed) but this is reasonable?<br>

>>>>>>>> Thanks!<br>

>>>>>>><br>

>>>>>>> Since the MDNodes are kept in a FoldingSet there should be no two<br>

>>>>>>> identical nodes. What may happen in your case is that the source code<br>

>>>>>>> contains two conflicting definitions of the same type in two compilation<br>

>>>>>>> units. This is illegal C++ (violation of the ODR), but the compiler<br>

>>>>>>> currently has no way to diagnose such a situation.<br>

>>>>>>><br>

>>>>>>> On a related note, this made me realize that this assertion should only<br>

>>>>>>> be enabled for C++ compilation units; I will fix this soon. This will not<br>

>>>>>>> fix your problem, unfortunately.<br>

>>>>>><br>

>>>>>> Hmm? The assertion should still be true in any case, shouldn't it?<br>

>>>>>> (the 'reference' will just be a straight MDNode when we don't have a<br>

>>>>>> mangled name there) But perhaps I'm forgetting the exact schema.<br>

>>>>> You’re right, while there may be conflicting definitions for a type in a<br>

>>>>> non-ODR-language, resolve() would also be a noop (no such thing as an ID<br>

>>>>> field in a C DIType), so this would still be safe.<br>

>>>>><br>

>>>>> -- adrian<br>

>>>><br>

>>>><br>

>>>><br>

>>>><br>

>>>> --<br>

>>>> Best Regards,<br>

>>>> WenHan Gu (Nowar)<br>

>><br>

>><br>

>><br>

>><br>

>> --<br>

>> Best Regards,<br>

>> WenHan Gu (Nowar)<br>

><br>

><br>

</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>

> llvm-commits mailing list<br>

> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>

> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>

<br>

</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div>WenHan Gu (Nowar)</div></div>

</div></div>