[llvm] r204107 - DwarfDebug: Only unique retained types instead of all types.
WenHan Gu (谷汶翰)
wenhan.gu at gmail.com
Fri Mar 28 01:28:36 PDT 2014
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,
My workstation is x86_64, ubuntu13.10, 3.11.0-15-generic.
$ cat a.cpp
$ cat b.cpp
$ clang -g -emit-llvm -std=c++11 -c a.cpp b.cpp
$ llvm-link a.bc b.bc | llc
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*)
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::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
0. Program arguments: llc
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>
> >> On Mar 26, 2014, at 11:15 PM, WenHan Gu (谷汶翰) <wenhan.gu at gmail.com>
> >>> 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
WenHan Gu (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits