similar to: [LLVMdev] LongTy in LowerInvoke.cpp

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

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

Hi, I have this call instruction to printf inserted which is causing an assertion failure. Any pointers to where I am wrong : Code Dump : Function *printFn=M.getNamedFunction(std::string("printf")); Constant *str=ConstantArray::get("Value : %d\n"); std::vector<Value *> Args(2); std::vector<Constant *> GEPIndices(2);

On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > I have this call instruction to printf inserted which is causing > an assertion failure. Any pointers to where I am wrong : > > Function *printFn=M.getNamedFunction(std::string("printf")); std::string() is unnecessary here as it's implicit. > Constant *str=ConstantArray::get("Value :

Constant *strcon==ConstantArray::get("Value : %d\n"); Sorry Typo. On Tue, 21 Dec 2004, Misha Brukman wrote: > On Tue, Dec 21, 2004 at 03:45:33PM -0700, Sriraman Tallam wrote: > > I have this call instruction to printf inserted which is causing > > an assertion failure. Any pointers to where I am wrong : > > > > Function

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

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

Although most of the leaks I detected in LLVM were from singleton objects, there also seem to be some real leaks. One such leak (which is creating problems for me when I try to get rid of the constant singletons) seems to be a GlobalVariable created on line 145 of Transforms/Scalar/lowerInvoke.cpp -- any suggestions how I can make sure this GlobalVariable gets deleted? Actually I'm a bit

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

Right now I am trying to capture the function name and the number of arguments , so this following is the pass I wrote . ------------------------------------------------------------- struct pass06a : public ModulePass { virtual bool runOnModule(Module &M) { std::vector<const Type*> pList; pList.push_back( PointerType::get(Type::SByteTy) ); pList.push_back(

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,

Okay, I'm past the GEP "have to dereference pointer first" problem of my last post. I now have a linkage error (I get undefined symbol when I try to assemble the program). gcc -o test.o test.s says: > /tmp/cczhiFk7.o(.text+0x7): In function `a': > : undefined reference to `_index_' _index_ is defined like this: > %_index_ = external global long ;

>>> >>> >>> The reason for the difference is that e.g "long" in >>> >>>> bool GOMP_loop_runtime_next(long, long) >>> >>> has a different size on different architectures. >>> >>> Currently we generate the prototypes and functions ourselves: >>>> declare i8 @GOMP_loop_runtime_next(i64*,

On 12/26/2010 01:31 AM, Eric Christopher wrote: >>>> >>>> >>>> The reason for the difference is that e.g "long" in >>>> >>>>> bool GOMP_loop_runtime_next(long, long) >>>> >>>> has a different size on different architectures. >>>> >>>> Currently we generate the prototypes and

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

Thank you, Duncan. I rewrote the code, please help check why it still does not work: //declare global variable const Type *IntTy = Type::getInt32Ty(M.getContext()); const Type *ATyC = ArrayType::get(Type::getInt64Ty(M.getContext()), 1); GlobalVariable *CounterSize = new GlobalVariable(M, ATyC, false, GlobalValue::InternalLinkage,

The functions that I placed in ScalarTargetTransformInfo are functions what were used by LSR and LowerInvoke. getJumpSize and getJumpAlignment are used by LowerInvoke. Do you suggest that I remove them from TargetLowering and keep them in ScalarTargetTransformInfo ? Thanks, Nadav On Oct 9, 2012, at 5:47 PM, Evan Cheng <evan.cheng at apple.com> wrote: > Hi Nadav, > > The

Eli Friedman-2 wrote: > > > Try llvm::Constant::getNullValue(). > > I'm trying this: llvm::Constant* one = llvm::Constant::getNullValue(llvm::IntegerType::get(mod->getContext(), 64)); llvm::ConstantInt* two = llvm::ConstantInt::get(mod->getContext(), llvm::APInt(32, llvm::StringRef("1"), 10)); std::vector<llvm::Value*> indices;