similar to: Find uses of Metadata / DITypes

Is there a more convenient way to obtain a DIType given a Type than matching up the strings for the names? For example, given: struct S { int x, y; } s; void foo(S *a) { a->x = 0; a->y = 1; } There are DIType nodes for the struct Type: !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !3, line: 1, size: 64, flags: DIFlagTypePassByValue,

On Mon, Jul 21, 2014 at 3:48 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 3:41 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie

On Mon, Jul 21, 2014 at 3:35 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 21, 2014 at 1:14 PM, David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: >> > >> > >> > >> > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren

On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> We still have access to types via MDNodes directly and the assertion that >> assumes all accesses to DITypes are accessing the resolved DIType will fire >> >> i.e

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

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

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > Here is a patch that does just that. This does not work. I'm getting llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function ‘llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DICompileUnit)’: /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: error:

We still have access to types via MDNodes directly and the assertion that assumes all accesses to DITypes are accessing the resolved DIType will fire i.e assert(Ty == resolve(Ty.getRef())) One example is the access to DIType via DIArray in SubroutineType. If all elements in the type array are DITypes we can create a DITypeArray and use that for SubroutineType's type array instead. But we

OK so the problem is that the compiler sees '0' and can't decide whether its an integer or a null pointer of type Constant *. I guess the new functions will have to have slightly different names. On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > > Here is a patch

Here is a patch that does just that. On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote: > On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > >> > >> On Sep 22, 2009, at 4:49 PM, Talin wrote: > >>> > >>>

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via

> On 2014-Nov-10, at 08:30, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 9, 2014, at 5:02 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> In response to my recent commits (e.g., [1]) that changed API from >> `MDNode` to `Value`, Eric had a really interesting idea [2] -- split >> metadata entirely from the `Value` hierarchy, and

I have no objections to any of this FWIW :) -eric On Tue, Mar 29, 2016 at 6:46 PM Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > > > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> > wrote: > >> +pcc, who had some other

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

> On 2016-Mar-22, at 20:11, Eric Christopher <echristo at gmail.com> wrote: > >> On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: >> +pcc, who had some other ideas/patch out for improving memory usage of debug info >> +Reid, who's responsible for the windows/CodeView/PDB debug info which is motivating some of the ideas about

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

Hello Adrian, sorry for the delay with the response. Somehow I missed your message.. On 09/13/2016 12:43 AM, Adrian Prantl wrote: >> On Sep 10, 2016, at 12:50 PM, Victor Leschuk via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I am currently implementing support for DWARFv5 DW_AT_alignment attr and I got a question about align field in

On Tue, Mar 22, 2016 at 8:04 PM David Blaikie <dblaikie at gmail.com> wrote: > +pcc, who had some other ideas/patch out for improving memory usage of > debug info > +Reid, who's responsible for the windows/CodeView/PDB debug info which is > motivating some of the ideas about changes to type emission > > So I discussed this with Adrian and Mehdi at the social last