similar to: [LLVMdev] svn update and make failures

Garrison Venn wrote: > Just wanted to note that this morning that I had to (for a complete, including examples, build): > > 1) Move llvm/cmake/modules/LLVMLibDeps.cmake.old out of way for svn update to work > 2) Modfiy llvm/examples/Makefile to remove TracingBrainF in order for a subsequent make to work > > Don't know if the current repository changes will fix this, or if

Sorry, these IRBuilder methods are really in IRBuilderBase. Garrison On Jul 11, 2011, at 11:54, Garrison Venn wrote: > Are the get type methods for IRBuilder, such as const IntegerType *getInt32Ty(), going to have > their return type const qualifiers removed? Doing so would match the semi equivalent static > methods of Type, such as static IntegerType *getInt32Ty(LLVMContext &C).

Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) The patch is offset from HEAD. The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break in the exception JIT context; both in

Ok thanks I'll try that. I was trying to avoid re-building llvm-gcc. Garrison On Dec 10, 2010, at 12:12, Bob Wilson wrote: > > On Dec 10, 2010, at 6:11 AM, Garrison Venn wrote: > >> Hey Chris, >> >> Ok, so I'm working on creating this trivial patch, for starters, but I'm trying to identify >> a controlled unit test for tblgen. So all of the

So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics? Garrison On Dec 7, 2009, at 12:21, Chris Lattner wrote: > > On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > >> Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of

Attached is a patch for the non ExceptionDemo demos which gets rid of the old const qualifier usage for Type. Although I recently commited the ExceptionDemo changes, I did not want to touch code that I did not "own" without other's approval. Even though trivial, I did not test this patch. Garrison -------------- next part -------------- A non-text attachment was scrubbed... Name:

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

Hi Garrison, Does r101453 fix this? -Chris On Mar 22, 2010, at 12:35 PM, Garrison Venn wrote: > Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant > to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) > The patch is offset from HEAD. > > The patch is a hack which

Hi Chris, Thanks for the review! I believe I caught most of the syntax style issues with the attached patch. It only contains these style changes. On Dec 12, 2010, at 19:30, Chris Lattner wrote: > > On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > >> >> Hey Chris, >> >> The following patch removes all global references to a RecordKeeper instance for the

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > So I gather this means that malloc was removed from the IR because > there are platforms that don't have non-stack allocation semantics? No, it was removed because it wasn't necessary, and the malloc 'instruction' didn't support 64-bit targets. -Chris > > Garrison > > On Dec 7, 2009, at 12:21, Chris

On Dec 10, 2010, at 10:17 AM, Garrison Venn wrote: > Ok thanks I'll try that. I was trying to avoid re-building llvm-gcc. You don't need llvm-gcc to run most of the "make check" tests. The FrontEnd tests use it, but that's all. If you run configure with "--without-llvmgcc --without-llvmgxx", then it shouldn't use llvm-gcc at all. > > Garrison >

Hi Chris, The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the associated personality's first unwind search phase, which happens to have no language specific context, and is returning a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to the example. However I'm not sure why then this wasn't seen in one

Yes, I did -- it made no difference. Should it? Note that I have since discovered that this is not a problem on Windows -- the exception drops through as expected. pz On 2011-07-21, at 5:45 PM, Garrison Venn wrote: > Sorry Peter, just saw this. > > If you are still having the problem: > > Did you set: llvm::JITExceptionHandling = true; ? > > Garrison > > On Jul

Hey all, Attached you will find an experimental patch which allows me to play with a derived JIT class. With this patch I've alleviated my concerns with forcing cross module behavior for all users of JIT. However this introduces some new semantics, and kind of circumvents the EngineBuilder API. More important though, I have not addressed any concern about using stub functions in eager

Is there a way using llvm::TargetData to determine the alignment of what would be equivalent to __attribute__((__aligned__))? I'm looking for something like a max alignment number for the target platform so that I know what the max alignment of an address returned by malloc(...) will be. Thanks in advance Garrison

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take