similar to: [LLVMdev] Leaking GlobalVariable from lowerInvoke pass

All, I'm looking at the lowerinvoke pass as a starting point for getting SJLJ based exception handling working on ARM, but am having some troubles with it. When I run a simple testcase (attached) through llc and specify -enable-correct-eh-support, llc asserts on me. It appears there's been some bitrot somewhere. SelectDAGBuild and SelectionDAGISel cooperate to track landing pads

Hi Jim, > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through llc > and specify -enable-correct-eh-support, llc asserts on me. It appears > there's been some bitrot somewhere. SelectDAGBuild and >

On Apr 21, 2009, at 1:53 PM, Jim Grosbach wrote: > All, > > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through > llc and specify -enable-correct-eh-support, llc asserts on me. It > appears there's been some

On Thu, 11 Nov 2004, Morten Ofstad wrote: > I guess the issue of singleton objects leaking is not something that he > LLVM team is very concerned about, since there has been no replies to my > first mail... But for me it is a big problem. I can't use LLVM in our > project if it triggers our leak detection system, since it will hide > other problems. Hi Morten, I appologize for

On Fri, 2005-05-13 at 08:06 +0200, Markus F.X.J. Oberhumer wrote: > Actually that's the only case I stumbled over this problem in a somewhat > larger C++ program, and it's clearly the wrong type in LowerInvoke.cpp - > it really should be IntPtrTy. But maybe we could use just IntTy here to > avoid target dependencies. Wait a minute. You want to lower a 64 bit thing to a 32

Hello, Jim > -enable-correct-eh-support, llc asserts on me. It appears there's been some > bitrot somewhere. Well, correct. Because many places expects exceptions to be dwarf-style. > Is it reasonable to expect that lowerinvoke is a good place to start for > doing what I'm after? I really don't think so. Since you're trying to map dwarf-based structures into sjlj

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

Hi, it would be nice to be able to specify workers as singletons. By this I mean that every call to the new_worker method returns the same instance of said worker. This can be done transparently either by adding a new argument to new_worker (something like :singleton => true) or adding a new method, like I did in my installation of BackgrounDrb: def get_worker_by_class(klass)

Hi I have IR Code like ... @path = private constant [6xi8] c"abcde\00" ... --- Code from Pass --- GlobalVariable * GVPath = .... // contains @path I want to convert "abcde" to StringRef. Can you help me with GlobalVariable API? GlobalVariable::getInitializer() --> Constant* // How to get exact value äbcde from here? ~mahesh -------------- next part --------------

Hi Good day. I am facing issue with creating a GlobalVariable. I already have an extern for that global in a header file to use it in the following way extern const void* DATA_TABLE[]; And with a LLVM PASS, I am trying to create this array with the same name and with initializer. So, I have following: GlobalVariable *gvar_data = new GlobalVariable( M, blockItems->getType(), true,

I'm a bit confused. For the Type did you mean something like: ArrayType *type = ArrayType::get(Type::getInt8PtrTy(M.getContext()), 4); This does not work, it gives me ""Wrong type in array element initializer" at runtime. Also it doesn't look like ConstantExpr inherits ConstantArray, so I'm not sure how I could use this instead. Thanks On Thu, Oct 20, 2011 at

I'm trying to create a ConstantArray(whose contents will be of types Function*, GlobalVariable *) so I can immediately create a new GlobalVariable(that will be in its own section). I'm doing this so I have these address stored. In order to create this ConstantArray I need a valid ArrayType, but I'm not sure what to use for the element type. I want this to be done at compile time, so I

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> Ah ok, in that case, the CBE should be fixed. There are other cases that >> could cause long arguments to exist on 32-bit systems. If the C compiler >> takes issue with this, it would be best to tell the CBE to emit casts to C >> (long) or something. > > Actually that's the only case I stumbled over this

For LLDB I'm writing a dumb module pass that removes all global variables, by running the following code: bool erased = true; while (erased) { erased = false; for (Module::global_iterator gi = llvm_module.global_begin(), ge = llvm_module.global_end(); gi != ge; ++gi) { GlobalVariable *global_var =

excuse me for bother you again . a little supplement Constant* c = findValue(m,"E1$entry"); Constant* c2 = findValue(m,"E1$str"); I can get string object from c2 string s = cast<ConstantArray>(c2)->getAsString(); but it is not applicable for c string s= cast<ConstantArray>(c)->getAsString(); // Assert Fail because c is ConstantExpr::GetElementPtr

I guess the issue of singleton objects leaking is not something that he LLVM team is very concerned about, since there has been no replies to my first mail... But for me it is a big problem. I can't use LLVM in our project if it triggers our leak detection system, since it will hide other problems. Since actually deleting these objects is proving difficult (types can have circular

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > There is still one unneeded LongTy in LowerInvoke.cpp - something like this > pseudo-diff should probably get applied. What does this impact? -Chris > Index: LowerInvoke.cpp > =================================================================== > RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerInvoke.cpp,v >

On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: > Chris Lattner wrote: >> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote: >> >>> There is still one unneeded LongTy in LowerInvoke.cpp - something like >>> this pseudo-diff should probably get applied. >> >> >> What does this impact? > > This causes code like > > write(2,

On 10/20/11 11:34 AM, ret val wrote: > I'm a bit confused. For the Type did you mean something like: > ArrayType *type = ArrayType::get(Type::getInt8PtrTy(M.getContext()), 4); I assume that creates an ArrayType of 4 elements whose elements are pointers to 8-bit values. If so, then this is what I meant. > This does not work, it gives me ""Wrong type in array

On 10/20/11 10:43 AM, ret val wrote: > I'm trying to create a ConstantArray(whose contents will be of types > Function*, GlobalVariable *) so I can immediately create a new > GlobalVariable(that will be in its own section). I'm doing this so I > have these address stored. In order to create this ConstantArray I > need a valid ArrayType, but I'm not sure what to use for