similar to: [LLVMdev] Does llc support exception handling?

Hi, 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 llc: FunctionLoweringInfo.cpp:163: void llvm::FunctionLoweringInfo::clear(): Assertion `CatchInfoFound.size() == CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 llc

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

On Nov 24, 2010, at 11:49 PM, John McCall wrote: > On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: >> On Nov 24, 2010, at 6:41 PM, John McCall wrote: >>>> We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of

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

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

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,

Pardon the basic question, but does this apply to clang, llvm-gcc, or both? Thanks, -David -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Tuesday, April 12, 2011 3:05 PM To: llvmdev List Subject: [LLVMdev] Exception Handling Problems Exception handling in LLVM is broken. It's as simple as that. We

On Nov 20, 2009, at 2:15 AM, Jay Foad wrote: >> Please read and let me know your opinions! > > This definitely seems like an improvement on the current situation. > >> .---------. >> | convoke | >> `---------' >> | >> v >> .-----------------------. >> |

I've been working recently to get the following test case working for an x86_64-pc-windows-msvc target. void test1() { try { try { throw 1; } catch(...) { throw; } } catch (...) { } } I committed a patch earlier in the week to get the WinEHPrepare pass to produce IR that I thought was sufficient, but as I mentioned in the review I was still seeing runtime errors

Nice. This seems like a good starting design for some patches. I'm not sure exactly how step 3.a works. Does it stem from step 4.b which assigns the same eh_state to two catch handlers? It seems like these rules would come into play in these examples: // 'catch int' and 'catch float' have the same incoming eh_state range try { f(); } catch (int) { g(); } catch (float) { h();

> Please read and let me know your opinions! This definitely seems like an improvement on the current situation. >            .---------. >            | convoke | >            `---------' >                 | >                 v >     .-----------------------. >     |                       | >     v                       | >  %normal  

Hi John, >> Inlining >> -------- >> >> Many a plausible seeming exception handling scheme has fallen by the way-side >> because it interacts poorly with inlining. >> >> Here is how inlining would work with this scheme. It's pretty close to how >> it works right now. Suppose you have >> >> invoke void @foo() >>

Exception handling in LLVM is broken. It's as simple as that. We can simulate exception handling in most cases, but we cannot handle all cases. (For instance, SingleSource/UnitTests/ObjC/exceptions.m in our testsuite doesn't work on ARM at anything optimization level above -O0.) And there's no way to coerce it to work with our current EH scheme. We don't follow the exception

On Nov 24, 2010, at 6:41 PM, John McCall wrote: > On Nov 24, 2010, at 5:07 PM, Bill Wendling wrote: > >> On Nov 24, 2010, at 11:18 AM, John McCall wrote: >> >>> I think my model has some nice conceptual advantages; for one, it gives you the constraint that only EH edges and dispatch instructions can lead to landing pads, which I think will simplify what EH

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > Executive summary > ----------------- > > Remove the personality and list of catches out of eh.selector and stick them > directly on invoke instructions. > > The invoke instruction > ---------------------- > > The invoke instruction is modified by adding extra catch info to it: > > <result> = invoke

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? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > What? Yet another EH proposal?! This one is different from the others in that > I'm planning to start implementing this shortly. But I want your feedback! I've

I have a couple of questions/concerns. The main one has to do with the opacity of exception types - in other words, will it still be true that the exception types are opaque identifiers, and are only interpreted by the personality function? Since my object representations are not C++-like, I am not using any of the cxa_* C++ library functions. Instead, my code calls the _Unwind functions

Yes, it seems like WinEHPrepare should always be able to move landing pad code to somewhere appropriate. Even if there's some involved code to handle the cases that force #1, it's great that the complexity is contained in WinEHPrepare. I'm still confused about the apparent lack of constraints after WinEHPrepare. Can we simply require/assume that WinEHPrepare be run after any passes

>> As I understand it, when you generate native code, at each landing pad >> the exception pointer appears magically in a well-known native >> register. > Well, it's not entirely magical. :-) It gets the exception object by calling > __cxa_get_exception_ptr __cxa_get_exception_ptr returns an "adjusted" pointer to the exception object, but you still have to

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > > Hi James, >> >> >> I've been trying to get a minimal test function to work, which simply >>> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >>> when I run it my personality function is not getting