<div dir="ltr">Also, in the former case, the MDNode dump result is the same.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-28 16:28 GMT+08:00 WenHan Gu (¨¦¨Z¿«) <span dir="ltr"><<a href="mailto:wenhan.gu@gmail.com" target="_blank">wenhan.gu@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Finally I found a way to reproduce this not depending on my local project.</div>I cannot submit this to bugzilla, the post_bug.cgi seems break.<div>
<br></div><div>Could you help reproduce this? IMHO this may be a bug.</div>
<div><br></div><div>If I #include <chrono> and <locale> to the same file, then llc works.<br></div><div><div>but if I #include them separately on a.cpp and c.cpp, then after llvm-link, llc crashes.</div><div>
My workstation is x86_64, ubuntu13.10, 3.11.0-15-generic.</div>
<div><br></div><div>Thanks!<br></div><div><br></div><div><br></div><div>HOWTO:</div><div><br></div><div>$ cat a.cpp</div><div>#include <chrono></div><div><br></div><div>$ cat b.cpp</div><div>#include <locale></div>
<div><br></div><div>$ clang -g -emit-llvm -std=c++11 -c a.cpp b.cpp</div><div>$ llvm-link a.bc b.bc | llc</div><div><br></div><div>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.</div>
<div>0 llc 0x00000000011a2255 llvm::sys::PrintStackTrace(_IO_FILE*) + 37</div><div>1 llc 0x00000000011a29a3</div><div>2 libpthread.so.0 0x00007f271ef28bb0</div><div>3 libc.so.6 0x00007f271df3cf77 gsignal + 55</div>
<div>4 libc.so.6 0x00007f271df405e8 abort + 328</div><div>5 libc.so.6 0x00007f271df35d43</div><div>6 libc.so.6 0x00007f271df35df2</div><div>7 llc 0x0000000000ca3dd4</div><div>8 llc 0x0000000000c87579 llvm::DwarfDebug::constructImportedEntityDIE(llvm::DwarfCompileUnit*, llvm::DIImportedEntity const&, llvm::DIE*) + 281</div>
<div>9 llc 0x0000000000c83ff2 llvm::DwarfDebug::beginModule() + 1234</div><div>10 llc 0x0000000000c83a79 llvm::DwarfDebug::DwarfDebug(llvm::AsmPrinter*, llvm::Module*) + 1801</div><div>11 llc 0x0000000000c73e70 llvm::AsmPrinter::doInitialization(llvm::Module&) + 1008</div>
<div>12 llc 0x000000000113bc86 llvm::FPPassManager::doInitialization(llvm::Module&) + 86</div><div>13 llc 0x000000000113c09e llvm::legacy::PassManagerImpl::run(llvm::Module&) + 734</div><div>
14 llc 0x0000000000561622 main + 6370</div><div>15 libc.so.6 0x00007f271df27de5 __libc_start_main + 245</div><div>16 llc 0x000000000055ea2d</div><div>Stack dump:</div><div>0. Program arguments: llc</div>
<div>Aborted</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-03-28 0:51 GMT+08:00 Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span>:<div>
<div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
On Mar 27, 2014, at 9:43 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<br>
> On Thu, Mar 27, 2014 at 9:39 AM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br>
>><br>
>> On Mar 26, 2014, at 11:15 PM, WenHan Gu (¨¦¨Z¿«) <<a href="mailto:wenhan.gu@gmail.com" target="_blank">wenhan.gu@gmail.com</a>> wrote:<br>
>><br>
>>> Hi Adrian,<br>
>>><br>
>>> After this commit, there's sometimes assert fail on large bitcodes on my environment.<br>
>><br>
>> Is there any chance you can provide me with a reduced example that reproduces this?<br>
>><br>
>>> According to my result, two types seems the same, and I take out the assert fail can still build and run.<br>
>>> Is any possible that the contained MDNode is not the same (since it is 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 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.<br>
>><br>
>> 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.<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>
</div>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.<br>
<span><font color="#888888"><br>
-- adrian</font></span></blockquote></div></div></div><br><br clear="all"><div class=""><div><br></div>-- <br><div dir="ltr">Best Regards,<div>WenHan Gu (Nowar)</div></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Best Regards,<div>WenHan Gu (Nowar)</div></div>
</div>