Re: [PATCH] Fix up __builtin_setjmp_receiver handling (PR c++/60082)

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Feb 06, 2014 at 10:33:54AM +0100, Richard Biener wrote:
> > Not even in call_can_make_abnormal_goto?  I mean, as we split
> > __builtin_setjmp into __builtin_setjmp{_setup,_receiver} and the former
> > has abnormal edge out of it, there is no need to have another abnormal edge
> > out of the receiver.
> 
> longjmp has outgoing abnormal edges, setjmp has
> incoming abnormal edges.  So how's the dispatcher working exactly?
> It receives all abnormal edges from all possibly longjmp calling
> stmts and dispatches them to all setjmp calls?

I've actually removed the special __builtin_setjmp_dispatcher and replaced
it with the same ABNORMAL_DISPATCHER used for normal setjmp/returns_twice
calls.  __builtin_setjmp_receiver actually is not really a returns_twice
function, it only has the abnormal predecessor edge (from
ABNORMAL_DISPATCHER) and no other predecessor edge, so it really works as a
normal call with just the requirement that it is at the start of the bb.
We just need to treat it as receiver of the abnormal edges (we do already).
It is __builtin_setjmp_setup that has both normal fallthru edge and abnormal
edge to the dispatcher.  The dispatcher is expanded as nothing at all (it's
basic block is actually removed), the receiver as loading of frame pointer
etc. from somewhere and setup as saving frame pointer somewhere.

> So why would there be extra edges from the receiver?

That is what I'd like to change.  The reason for the extra edge from the
receiver is that it is a non-leaf call.  Supposedly if we set ECF_LEAF on
__builtin_setjmp_receiver, it might work, but that looks too dangerous to
me, at least right now.

> > > stmts we add abnormal edges to.  Btw, why isn't BUILT_IN_SETJMP_RECEIVER
> > > ECF_RETURNS_TWICE?
> > 
> > See PR60003, #c5 in particular which really didn't work at all, and Eric's
> > preference in #c8.
> 
> Hmm, but it really is ECF_RETURNS_TWICE ...

It is not.

	Jakub