similar to: [LLVMdev] New Type System Questions

Displaying 20 results from an estimated 11000 matches similar to: "[LLVMdev] New Type System Questions"

2011 Jul 25
0
[LLVMdev] New Type System Questions
Hi Talin, On Jul 25, 2011, at 1:59, Talin wrote: > So far I'm really liking the new type system -- I've been able to simplify my code generator in a number of areas. And the IR is now vastly more readable, both in the debugger (using dump()) and when printing modules via llvm-dis. It's a tremendous improvement. > > I do have a few comments / questions: > > -- I think
2011 Jul 25
1
[LLVMdev] New Type System Questions
On Mon, Jul 25, 2011 at 6:35 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Talin, > > On Jul 25, 2011, at 1:59, Talin wrote: > > > So far I'm really liking the new type system -- I've been able to > simplify my code generator in a number of areas. And the IR is now vastly > more readable, both in the debugger (using dump()) and when printing
2011 Jul 26
3
[LLVMdev] Linking opaque types
On Jul 25, 2011, at 10:58 PM, Talin wrote: > To handle the fact that types do not (and can not, at least as long as we intend to support obscure languages like "C" :) have linkage, the the linker uses a "best effort" approach. It attempts to merge types and rewrite IR to use the merged types where it can, but it doesn't make any guarantees. > > I want to add an
2011 Feb 21
2
[LLVMdev] A working garbage collector - finally :)
Well, after many months of effort, my LLVM-based garbage collector is finally passing its unit tests. This represents a significant milestone for me in the development of my programming language, Tart. The collector itself is fairly rudimentary - a single-generation, copying collector. It does not yet support multi-threaded programs, but in practice there's no serious obstacle to supporting
2010 Nov 07
3
[LLVMdev] Next round of DWARF issues/questions
After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. However, I'm also seeing a lot of new problems which weren't exposed before. After spending the better part of two
2011 Oct 16
2
[LLVMdev] Static destructor problem with recent HEAD
On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"
2011 Apr 07
1
[LLVMdev] More DWARF problems
On Apr 7, 2011, at 12:14 PM, Talin wrote: > > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] =
2011 Oct 16
0
[LLVMdev] Static destructor problem with recent HEAD
Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +
2010 Oct 23
2
[LLVMdev] Cast failure in SelectionDAGBuilder
I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*
2010 Aug 29
0
[LLVMdev] "Cannot fine DIE"
On Sat, Aug 28, 2010 at 4:05 PM, Talin <viridia at gmail.com> wrote: > On Mon, Aug 23, 2010 at 5:58 PM, Devang Patel <devang.patel at gmail.com>wrote: > >> >> On Sun, Aug 22, 2010 at 12:50 PM, Talin <viridia at gmail.com> wrote: >> >>> I recently started getting this error when I try to debug my >>> LLVM-compiled program in GDB:
2010 Nov 09
2
[LLVMdev] Next round of DWARF issues/questions
On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > > After to speaking to Devang and a number of other people at the developer's > conference, I was able to make some forward progress on getting debugging to > work. I'm now able to actually single-step through my program and set > breakpoints,
2010 Sep 25
2
[LLVMdev] Strange exception in SelectionDAGBuilder
I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {
2010 Nov 26
3
[LLVMdev] Next round of DWARF issues/questions
On Tue, Nov 9, 2010 at 9:04 AM, Devang Patel <dpatel at apple.com> wrote: > > > On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel < <dpatel at apple.com> > dpatel at apple.com> wrote: > >> >> On Nov 6, 2010, at 7:35 PM, Talin wrote: >> >> After to speaking to Devang
2011 Apr 03
2
[LLVMdev] More DWARF problems
On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > > On Mar 29, 2011, at 7:29 PM, Talin wrote: > > I've been trying to track down the problem with the DWARF info that is > being emitted by my front end, which has been broken for about a month now. > Here's what happens when I attempt to use gdb to debug one of my programs on > OS X:
2010 Nov 09
0
[LLVMdev] Next round of DWARF issues/questions
On Nov 8, 2010, at 10:52 PM, Talin <viridia at gmail.com> wrote: > On Mon, Nov 8, 2010 at 9:56 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 6, 2010, at 7:35 PM, Talin wrote: > >> After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now
2010 Nov 08
0
[LLVMdev] Next round of DWARF issues/questions
On Nov 6, 2010, at 7:35 PM, Talin wrote: > After to speaking to Devang and a number of other people at the developer's conference, I was able to make some forward progress on getting debugging to work. I'm now able to actually single-step through my program and set breakpoints, and examine function parameters. > > However, I'm also seeing a lot of new problems which
2010 Sep 26
0
[LLVMdev] Strange exception in SelectionDAGBuilder
Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a
2011 Apr 07
0
[LLVMdev] More DWARF problems
On Sat, Apr 2, 2011 at 11:03 PM, Talin <viridia at gmail.com> wrote: > > > On Wed, Mar 30, 2011 at 11:17 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Mar 29, 2011, at 7:29 PM, Talin wrote: >> >> I've been trying to track down the problem with the DWARF info that is >> being emitted by my front end, which has been broken for
2009 Oct 21
1
[LLVMdev] A few more questions about DIFactory and source-level debugging.
Well, I am much happier now that I understand about dsymutil, and can actually step through my program in gdb. However, there are still some issues that are puzzling me. 1) First off, the debugger appears to stop at odd points. The IR for my main function looks correct to me: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*
2009 Oct 03
2
[LLVMdev] Internalize pass
Well, after some investigation I have a few more clues as to what is going on. I have a module which contains a call to an external native function. This native function lives in a static library, and there is an external declaration for it in the module. I find that I can run "llvm-ld -disable-opts -native -l mylibrary test.bc" and it works fine. That is, llvm-ld is able to