<div dir="ltr"><div>Sorry for late response.</div><div><br></div>My company blocks email file upload, I use google drive.<div>If cannot access, please kindly let me know.</div><div><br></div><div><br></div><div>The command is simple:</div>
<div>clang++ -g -emit-llvm -std=c++11 -c a.ii b.ii</div><div>llvm-link a.bc b.bc | llc</div><div><br></div><div><br></div><div>The dump info: (DIDescriptor & MDNode)</div><div><div>Ty:</div><div>[ DW_TAG_structure_type ] [tm] [line 133, size 0, align 0, offset 0] [decl] [from ]</div>
<div>!{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 ]</div>
<div><br></div><div>resolve(Ty.getRef()):</div><div>[ DW_TAG_structure_type ] [tm] [line 133, size 448, align 64, offset 0] [def] [from ]</div><div>!{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 ]</div>
</div><div><br></div><div><br><div><div class="gmail_chip gmail_drive_chip" style="width:396px;height:18px;max-height:18px;background-color:#f5f5f5;padding:5px;color:#222;font-family:arial;font-style:normal;font-weight:bold;font-size:13px;border:1px solid #ddd">
<a href="https://drive.google.com/file/d/0BwR5L-mAgdKlZmJULTFzRk4tUzA/edit?usp=drive_web" target="_blank" style="display:inline-block;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;text-decoration:none;padding:1px 0px;border:none;width:100%"><img style="vertical-align: bottom; border: none;" src="https://ssl.gstatic.com/docs/doclist/images/icon_10_generic_list.png"> <span dir="ltr" style="color:#15c;text-decoration:none;vertical-align:bottom">llc_crash_after_r204107.tar.xz</span></a></div>
<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-28 23:37 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">Preprocessed files (output of clang -E + the command line options would be good enough for me :-)<br>
<br>
thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
adrian<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div>WenHan Gu (Nowar)</div></div>
</div>