search for: resume_unwinding

On Jul 27, 2011, at 11:10 AM, John McCall wrote: >> >> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction >> "Resume" since in the English language it is so ambiguous (resume normal execution following >> the conclusion of handing an exception, verses resume throwing an exception). IE cosmetics >> do

...n interpolating them as in the source code (otherwise, all calls to foo should unwind to the catch area, not cleanups). 2. In catch.handlers, the resume label is to %onto.catch.handlers, right? 3. In onto.catch.handlers you resume to %lpad. Which basic-block is this? Shouldn't this be a "resume_unwinding" call of some sort (if Q2 is right)? 4. Your catch handlers return void, shouldn't then branch to %return instead? In this case, a front-end would probably call that label a "%finally" and that would branch to %return, or return directly. Which brings me to my final question:...

On Jul 27, 2011, at 11:17 AM, Chris Lattner wrote: > On Jul 27, 2011, at 11:10 AM, John McCall wrote: >>> 6) it would be nice if the existing UnwindInst could be retained. I wince at naming an instruction >>> "Resume" since in the English language it is so ambiguous (resume normal execution following >>> the conclusion of handing an exception, verses resume

...ormal calls to the d'tors that we expect. > 2. In catch.handlers, the resume label is to %onto.catch.handlers, right? > Oh…I forgot to fill that in. It should to go %yikes. > 3. In onto.catch.handlers you resume to %lpad. Which basic-block is > this? Shouldn't this be a "resume_unwinding" call of some sort (if Q2 > is right)? > This was necessary to keep the invariant that only resume or unwind edges may jump to a landing pad (%lpad in this instance). Otherwise, I would have the invoke in a.dtor to directly to %lpad on the "normal" edge. > 4. Your catch ha...

On Dec 1, 2010, at 1:12 AM, Renato Golin wrote: > On 1 December 2010 07:04, Bill Wendling <wendling at apple.com> wrote: >> The unwind edge from an invoke instruction jumps to a landing pad. That landing pad contains code which performs optional cleanups, and then determines which catch handler to call (if any). If no catch handlers are applicable, the exception resumes propagation

On Wed, Dec 1, 2010 at 11:37 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 1 December 2010 09:46, Bill Wendling <wendling at apple.com> wrote: >> Nor these. Basically, I want the basic block that's labeled a "landing pad" to be jumped to by only a dispatch resume or unwind edge of invoke. We could do this with the c.dtor and ch.int here, but it would

On Jul 27, 2011, at 10:27 AM, Peter Lawrence wrote: > 3.b) I have been thinking about other possible control-flow-graph invariants of the > landingpad blocks and the catch blocks that they lead to, but so far have not come up > with very muchl, I wonder if anyone else is thinking about this...?... > > for example cleanups come before __cxa_begin_catch, but it isn't clear what

> > 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 > all ready gotten a lot of feedback from Chris, John, Jim, Eric, and > many others. > Now is your turn! > > Please read this proposal and send me your comments, suggestions, > and