search for: curtis_faith

...se_end(); I != E; ++I) dbgs() << "Use still stuck around after Def is destroyed:" << **I << "\n"; } #endif assert(use_empty() && "Uses remain when a value is destroyed!"); On Sat, Jun 5, 2010 at 6:24 AM, Curtis Faith <curtis_faith at yahoo.com> wrote: > Thanks for forwarding Jeffrey's tip Paul. > > Unfortunately, coming mostly from the application programming side, I haven't seriously used a command line debugger since the Apple IIe days in the early 80s (geez, i guess that makes me kinda old as far as pr...

Thanks for forwarding Jeffrey's tip Paul. Unfortunately, coming mostly from the application programming side, I haven't seriously used a command line debugger since the Apple IIe days in the early 80s (geez, i guess that makes me kinda old as far as programmers go). So I'm not familiar with gdb even at an intermediate level. Not that gdb isn't ubiquitous for tools development or

On 06/04/10 05:12, Curtis Faith wrote: > I concur. I've run into this exact assert at least 10 different times in the last two weeks since I started with LLVM as I'm learning the particulars of the typing system for function calls in particular. > > It would be nice if it would tell you what expected signature was, what the value of i was so you know which parameter went wrong,

Felix, It really depends on what you are doing with the JIT. In my case, I have a scripting language that has a limited set of base data types. I wanted to be able to trivially interface to new C++ methods and classes, so I'm interfacing to C++ classes by creating external definitions much like the way Kaleidoscope accesses external C functions. I only have to deal with a few types so I can