similar to: [LLVMdev] question about the DIBuilder::createStructType

Hello, Richard Thanks a lot ! On Fri, Dec 19, 2014 at 10:04 AM, RICHARD STUCKEY < richard.stuckey at virgin.net> wrote: > > Hi, Hui Zang, > > It helps to remember that at runtime a variable of a structure type has to > be allocated store, and to think about how that variable is laid out in > store. > > You must use createMemberType to create a DIType for *each*

Hi - attached is a patch to enable building DragonEgg (x86_64) for LLVM3.3 and LLVM3.4. That is, add these changes to the 3.3 release, and it becomes possible to build DragonEgg against a llvm3.4 compiler. Regards, Richard Gorton Cognitive Electronics rcgorton at cog-e.com ---------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

On 24/02/11 22:34, Jason Kim wrote: > On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel<dpatel at apple.com> wrote: >> Hi All, >> DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs >> to encode debugging information. We are replacing this interface with new >> simple interface, DIBuilder. >> Here is one example that demonstrates

On Feb 25, 2011, at 2:28 AM, Duncan Sands wrote: > It does make me wonder how you are supposed to represent types which cannot > be properly represented by LLVM types, for example structs with fields at > variable offsets from the start and/or of variable size; or structs with > fields that may or may not be present depending on the value of other fields. > Such types occur in Ada

Hi Devang, >> It does make me wonder how you are supposed to represent types which cannot >> be properly represented by LLVM types, for example structs with fields at >> variable offsets from the start and/or of variable size; or structs with >> fields that may or may not be present depending on the value of other fields. >> Such types occur in Ada for example. >

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 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

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 =

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

Hi, I'm trying to use DIBuilder to build my debug info and export it into a PDB, but I don't understand the way some DIBuilder method work. My question might have a straightforward answer but I don't see it ... (and I can't find any example code using these methods anywhere). Indeed createClassType takes an "Elements" argument, and createMemberType takes a

At least for generating DWARF the scope of of a composite type member should be irrelevant since it will always be nested inside its parent. -- adrian > On Feb 6, 2019, at 10:24 AM, David Blaikie <dblaikie at gmail.com> wrote: > > A good rough rule of thumb here is "what would/does Clang do?" & it looks (to me, on a very cursory glance) like Clang mostly passes the

Hi list, Is there a standards based reason why the DIFlags enum is set to uint32_t[1]? I am sure my DWARF-std-reading-fu is not up to snuff and so I cannot seem to find it. The reason I ask is that we are running out of space for our own DIFlags and would like to nail this down before deciding on an approach. Thanks! Sohail [1] The code in question:

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: > >>> > >>>

Hi, When generating debugging information for a data member (e.g., a struct field), Clang doesn't set the member's context to the enclosed class/struct/union type --- it currently sets the context to the file instead. The attached patch corrects this. Thanks. - xi -------------- next part -------------- A non-text attachment was scrubbed... Name: clang.diff Type:

On Jun 18, 2011, at 3:14 PM, Xi Wang wrote: > Hi, > > When generating debugging information for a data member (e.g., a struct field), Clang doesn't set the member's context to the enclosed class/struct/union type --- it currently sets the context to the file instead. The attached patch corrects this. Thanks. Do you have a test case ? Please update createMemberType() directly,

On Oct 27, 2011, at 10:39 PM, Talin wrote: > On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > >> Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.) >> >>

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Oct 23, 2011, at 12:03 AM, Talin wrote: > > Just a follow up on this - I am still having problems, I never did figure > out a solution. (I've been running with debug off for the last month so that > I could get work done.) > > Here's what I am seeing: I am definitely calling

I think it might be. I’m attaching a preprocessed file that can show the problem. Compile it with ToT. $ clang++ -g -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcovered-switch-default -Wno-uninitialized -Wno-missing-field-initializers -c

I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then use that to build a Debug+Asserts version. Include all of the bells and whistles, like the clang-extras and compiler-rt libraries. The reason I suspect debug info is because of this stack trace: [morbo:llvm]

Hi Bill Is this a recent regression? I recently changed the debug info verifier to fix a bug. Thanks, Manman > On Nov 17, 2013, at 5:52 PM, Bill Wendling <isanbard at gmail.com> wrote: > > I think that debug info is slowing a self-hosting build down. This build has been going for ages now and shows no sign of quitting. To reproduce, build a Release+Asserts build of clang. Then