search for: _z1bv

...he landing pad in b() only has one case to worry about, so it's naturally going to immediately enter the catch handler for 'int'. This is obviously semantically wrong if the combined invoke unwinds there. Here is the LLVM IR for functions "b" and "c". define void @_Z1bv() { entry: invoke void @_Z1av() to label %return unwind label %"<L1>" personality @__gxx_personality_v0 catches %struct.__fundamental_type_info_pseudo* @_ZTIi "<L1>": ; preds = %entry %exc_ptr = tail call i...

On Dec 1, 2010, at 1:37 PM, Duncan Sands wrote: > 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() > to

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