similar to: [LLVMdev] Assertion failure in llc when using exception handling

Hi, My transformation phase inserts an if-the-else construct into a BB. If that BB contains llvm.eh.exception, I get an Assertion at some later point: lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:212: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. Is

Hi Kostya, > My transformation phase inserts an if-the-else construct into a BB. > If that BB contains llvm.eh.exception, I get an Assertion at some later point: > > lib/CodeGen/SelectionDAG/FunctionLoweringInfo.cpp:212: > void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == > CatchInfoLost.size() && "Not all catch info was assigned to a

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 >

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

Here it is: llc: SelectionDAGISel.cpp:358: virtual bool llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&): Assertion `FuncInfo->CatchInfoFound.size() == FuncInfo->CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 libLLVM-2.7.so 0x0140e2c8 Stack dump: 0. Program arguments: llc -O0 bullet.linked.bc.opt 1.

I'm getting a very stubborn assertion failure that I don't understand. After I insert a call to an externally defined function into an invoked function, llc spits out the following assertion failure when I compile the bytecode: llc: SelectionDAGISel.cpp:4912: virtual bool llvm::SelectionDAGISel::runOnFunction(llvm::Function&): Assertion `FuncInfo.CatchInfoFound.size() ==

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

Hi Shivram, > I'm trying to compile an llvm program which makes use of exception > handling. While compiling the code with llc i get the following > assertion failure an unfortunate weakness of the code generators is that they require calls to eh.selector to be in a landing pad (landing pad = where an invoke unwinds to). They can also handle some simple cases when the selector call

Forgot to reply all. Duncan suggested that I put the selector call before the store but that didn't help. I get the same assertion failure. On Thu, Jun 10, 2010 at 2:50 PM, Shivram Khandeparker <shivramk at gmail.com>wrote: > HI Duncan, > > On Thu, Jun 10, 2010 at 1:58 PM, Duncan Sands <baldrick at free.fr> wrote: > >> an unfortunate weakness of the code

Hi Duncan, I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. The hacked is contained within the attached patch. Motivation: I recently created a decent amount of hand coded IR (via the llvm C++ API). In order to help me runtime debug the code, I created automatic constructors which would trace entries into the

Hi Garrison, > I hacked together a version of DwarfEHPrepare.cpp which tries to deal with the ordering of llvm.eh.exception and llvm.eh.selector. > The hacked is contained within the attached patch. it looks like you tried to copy the code for eh.exception. There are two problems with this: (1) the eh.exception code really needs to be rewritten to make use of the new SSAUpdator (then all

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

Here is an alternative proposal to Bill's. It is closer to what we already have (which can be seen as a good or a bad thing!), and is also closer to what gcc does. It is more incremental than Bill's and introduces fewer new concepts. Executive summary ----------------- Remove the personality and list of catches out of eh.selector and stick them directly on invoke instructions. The

I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior of the call depends on the function called even though none of the

Hi, An incoming call is redirected to another number by our asterisk server. In the incoming call the caller name is present but when redirect the call, the end receiver is not able to see the callerid name. The caller id number is visible. our related changes to extensions conf is below. exten => {MY_EXT},14,Set(CALLERID(name)=OH ${CALLERID(name)})<br> exten =>

(Moving this discussion on list as this could be of general interest.) My current work-in-progress implementation is attempting to map out the blocks used by a landing pad before it starts outlining. It creates a table of catch and cleanup handlers with the block at which each one starts. During outlining I intend to have another mechanism to check to see if we’ve already outlined the handler

Since llvm-gcc is a rather large code base, which I have never looked at (or even run), could you give me a starting point of where to look? One thing I'd be interested in knowing is whether the llvm.eh.exception() intrinsic can be called more than once in a landing pad. Say for example I have a nested try block, so that there are two landing pads, one for the inner try block, and one for

Hi Shivram, > lpad: ; preds = %return7 > %46 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] > store i8* %46, i8** %22 > %47 = call i32 (i8*, i8*, ...)* @llvm.eh.selector(i8* %46, i8* > bitcast (i32 (...)* @__gxx_personality_v0 to i8*), i8* null) ; <i32> >

(Mail system seems to have eaten this, sorry if it's a repeat) On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote: > Hi Dale, > >> - Why was C++ claiming that every selector has a catch-all handler? > > this is easy: because the semantics of invoke require it. Yes, > really. > If unwinding reaches an invoke then control is required to jump to the > unwind basic

On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote: >>> ... If you force a "cleanup" by changing the selector call to: >>> %eh_select8.i = tail call i32 (i8*, i8*, ...)* >>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)* >>> @__gxx_personality_v0 to i8*), i32 0) >>> then it doesn't work either: the unwinder observes that