similar to: [LLVMdev] Issues with clang-llvm debug info validity

+Adrian & Manman, Looks like this is a case of non-DIRef references ending up in the IR, and thus the references not being deduplicated. This could lead to some of the IR bloat that you guys implemented the DIRef stuff to reduce/avoid. The specific issue is that the type is slightly different in the two TUs (since the namespace scope it's contained within is different in the two TUs -

On Tue, Jun 24, 2014 at 2:38 PM, Adrian Prantl <aprantl at apple.com> wrote: > I will take this. > > !5 = metadata !{metadata !"./test.h", metadata !"/Volumes/Data/radar/17052973"} > !6 = metadata !{i32 786489, metadata !5, null, metadata !"test", i32 1} ; [ DW_TAG_namespace ] [test] [line 1] > !4 = metadata !{i32 786434, metadata !5, metadata !6,

>> Without needing to change how namespaces are handled. >> >> Yes, using DIRefs for namespaces would cause the actual type nodes to >> be deduplicated when they aren't even with the patch above, and that >> would help reduce debug info metadata further if that's >> useful/necessary. > > Exactly. While the above patch will cover up the problem, we

I looked into this a little. My proposal is this: - extend DINamespace with an extra UniqueID filed (analogous to DICompositeType) - add an extra case to DIScope::getRef() - Let CGDebugInfo create a mangled name for each namespace to use as UID -> the UID of the anonymous namespace is null. For example: namespace a { namespace b {} } -> “_ZN1a", “_ZN1a1b" !0 = [compile unit]

> On Jun 27, 2014, at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: > > On Fri, Jun 27, 2014 at 1:49 PM, Adrian Prantl <aprantl at apple.com> wrote: >> I looked into this a little. > > Thanks for taking a look! > >> My proposal is this: >> >> - extend DINamespace with an extra UniqueID filed (analogous to DICompositeType) >> -

On Fri, Jun 27, 2014 at 2:19 PM, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Jun 27, 2014 at 2:15 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >>> On Jun 27, 2014, at 1:58 PM, David Blaikie <dblaikie at gmail.com> wrote: >>> >>> On Fri, Jun 27, 2014 at 1:49 PM, Adrian Prantl <aprantl at apple.com> wrote: >>>>

Hello, I'm having this error and couldn't find a resolution from online, any help would be greatly appreciated: clang: /export/home/hzhang86/chapel/chapel-llvm36/chapel/third-party/llvm/llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp:839: void llvm::DwarfUnit::addType(llvm::DIE&, llvm::DIType, llvm::dwarf::Attribute): Assertion `Ty && "Trying to add a type that doesn't

Seems like something infinite-recursion like to me: $ clang --version clang version 6.0.0 (trunk 317833) Target: powerpc64le-unknown-linux-gnu $ clang -c test.ll warning: overriding the module target triple with powerpc64le-unknown-linux-gnu [-Woverride-module] ... #255 0x0000000012b07a78 llvm::DwarfUnit::getOrCreateTypeDIE(llvm::MDNode const*) ... So I'd say it reproduces. On Wed, Nov 15,

I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 On Jun 4, 2015 12:04 PM, "Hui Zhang" <wayne.huizhang at gmail.com> wrote: > Is there any clue for this error ? > > Thanks > > On Tue, Jun 2, 2015 at 5:47 PM, Hui Zhang <wayne.huizhang at gmail.com> > wrote: > >> Hello, >> >> I'm having this error and couldn't find a

Upgrade clang? I can't reproduce it with trunk. On 4 June 2015 at 14:48, Hui Zhang <wayne.huizhang at gmail.com> wrote: > Yes, I found this link, but what's the solution?? > > On Thu, Jun 4, 2015 at 1:09 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> I think this is https://llvm.org/bugs/show_bug.cgi?id=16846 >> >> On

I have a test case where lld-5.0 fails to detect an undefined symbol (this bug also happens with clang/lld 4.0). I haven't narrowed down exactly all the circumstances when this can occur, but in this case it was for a virtual method in a class defined in a shared library. If I build the executable with the raw object files, the linker notices the missing method (see test1 vs test2). This

With shared libraries, it is always possible that you end up running with a different set of libraries than you actually linked with. However, how often is that actually the case? It seems at the very least there should be an option to tell the user that unless they switch libraries, their code won't be runnable. In most cases, everything is available to the linker to detect the situation

Hi Mehdi, Peter and David (and anyone else who sees this), I've been playing with some examples to handle the weak symbol cases we discussed in IRC earlier this week in the context of D28523. I was going to implement the support for turning aliases into copies in order to enable performing thinLTOResolveWeakForLinkerGUID on both aliases and aliasees, as a first step to being able to drop

Thanks, David and Peter. Some responses to Peter's email below. Teresa On Fri, Jan 13, 2017 at 3:21 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi Teresa, > > I think that to answer your question correctly it is helpful to consider > what is going on at the object file level. For your test1.c we conceptually > have a .text section containing the body of f, and

Hi, I believe we should get it right (and simpler) if (when…) we move to the representation we discussed last spring: https://llvm.org/bugs/show_bug.cgi?id=27866 <https://llvm.org/bugs/show_bug.cgi?id=27866> Our conclusion was that we should always have alias pointing to private anonymous and nothing else, so when we currently have: @a = global i32 0 @b = alias @a It should always

On 07/25/2015 08:57 PM, Andrew Wilkins wrote: > On Sun, 26 Jul 2015 at 06:48 Rodney M. Bates <rodney_bates at lcwb.coop <mailto:rodney_bates at lcwb.coop>> wrote: > > In trying to write a C binding for DIBuilder of llvm 3.6.1, I can't see a way to unwrap > llvm::DITypeRef, declared in include/llvm/IR/DebugInfo.h. This is a class with one > data member, a

> On Jan 14, 2017, at 8:14 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > > On Fri, Jan 13, 2017 at 9:54 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > Hi, > > I believe we should get it right (and simpler) if (when…) we move to the representation we discussed last spring:

> On Jan 18, 2017, at 7:11 AM, Teresa Johnson <tejohnson at google.com> wrote: > > > >> On Sat, Jan 14, 2017 at 12:15 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: >> >>> On Jan 14, 2017, at 8:14 AM, Teresa Johnson <tejohnson at google.com> wrote: >>> >>> >>> >>> On Fri, Jan 13, 2017 at 9:54 PM, Mehdi

I have a fairly recent LLD/LTO llvm crashing on DIE *ContextDIE = getOrCreateContextDIE(Context) being null for a (local) variable. (Context is a DICompileUnit in this case, but it's not present in MDNodeToDieMap so it returns null. callstack is: llc.exe!llvm::DwarfUnit::getOrCreateTypeDIE(const llvm::MDNode * TyNode) Line 718 C++ llvm::DwarfUnit::addType(llvm::DIE & Entity, const

On 03.09.2020 01:36, David Blaikie wrote: > > > On Wed, Sep 2, 2020 at 3:26 PM Alexey <avl.lapshin at gmail.com > <mailto:avl.lapshin at gmail.com>> wrote: > > > On 02.09.2020 21:44, David Blaikie wrote: >> >> >> On Wed, Sep 2, 2020 at 9:56 AM Alexey <avl.lapshin at gmail.com >> <mailto:avl.lapshin at gmail.com>>