[llvm] r204107 - DwarfDebug: Only unique retained types instead of all types.
WenHan Gu (谷汶翰)
wenhan.gu at gmail.com
Tue Apr 1 01:32:49 PDT 2014
Big thanks! Fixed!
2014-04-01 11:59 GMT+08:00 Adrian Prantl <aprantl at apple.com>:
> 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
>
>
--
Best Regards,
WenHan Gu (Nowar)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140401/ebec5d74/attachment.html>
More information about the llvm-commits
mailing list