similar to: [LLVMdev] mkpatch patch

The document: http://llvm.org/docs/DeveloperPolicy.html refers to using utils/mkpatch. However when using mkpatch it complains about directories no longer under version control. Specifically directories lib/Debugger and win32 in mkpatch's source line: svn diff -x -u >> "$NAME".patch.raw 2>&1 \ autoconf docs utils include lib/System lib/Support lib/VMCore

Hello, The 0.9.9 2.4.10pre4 patch doesn't apply. There are 5 rejects. The first three are easy to fix, but the fourth in vmscan.c will be very difficult without being a developer. The fifth I am not sure about. This brings up the fact that many of us are using ext3 and have to patch every time a new kernel comes out. I really think we need to strong arm Linus or something and get

Here's the version of the unit test patch, incorporating the feedback I have received so far. Some notes on the patch: - This patch doesn't include googletest itself, that will need to be checked in separately. The source distribution will live in llvm/utils/unittest/googletest. (The reason for the extra directory level is so that the LLVM-specific makefiles can live in

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

2008/12/30 Talin <viridia at gmail.com> > Here's the version of the unit test patch, incorporating the feedback I > have received so far. > Looks good, a few comments below. > Some notes on the patch: > > - This patch doesn't include googletest itself, that will need to be > checked in separately. The source distribution will live in >

Hi Tanya, On Sun, 2007-07-01 at 19:38 -0700, Tanya M. Lattner wrote: > > The current SVN repository has several modules at the top level (llvm, > > test-suite, java, stacker, etc.). The modules contain the software that > > makes up the LLVM Project. However, there is nothing at the top level > > that explains any of this. So, I am considering doing the following at >

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

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

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

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

[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

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

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

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

+++ unittests/TestMain.cpp (revision 0) +//===--- unittest.cpp - unittest driver -----------------------------------===// +++ unittests/ADT/DenseMapTest.cpp (revision 0) +//===- llvm/unittest/DenseMapMap.h - DenseMap unit tests --------*- C++ -*-===// You probably want to update these file headers to match their real names. 2008/12/30 Misha Brukman <brukman at gmail.com> >

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [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] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

Hi Eli So I found this in Attributes.h: const Attributes UWTable = 1<<30; ///< Function must be in a unwind ///table What does this mean? In particular what does it mean not to add this as a function attribute to a function? I'm obviously going down the wrong road in my interpretation, as I

Is it consistent to have a Pass instance's run method's implementation use getAnalysisIfAvailable<AnalysisType>() (vs just using getAnalysis< AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage &au) implementation invokes au.addRequired<AnalysisType>()? For example in the implementation of SelectionDAGISel::runOnMachineFunction(...) (called