This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, 6 Feb 2014, Jakub Jelinek wrote:

> On Thu, Feb 06, 2014 at 10:13:25AM +0100, Richard Biener wrote:
> > > trunk?  Alternatively we could special case BUILT_IN_SETJMP_RECEIVER instead
> > > in call_can_make_abnormal_goto, there is probably no need to have AB edge
> > > out of __builtin_setjmp_receiver, we already have one out of
> > > __builtin_setjmp_setup and receiver is really expanded just to load of frame
> > > pointer, so it doesn't jump anywhere.
> > > 
> > > Note that this fixes both the CK tests on x86_64-linux, on i686-linux
> > > neither of them timeout, but catch_exc.cc still fails:
> > >  FAIL: g++.dg/cilk-plus/CK/catch_exc.cc  -O1 -fcilkplus execution test
> > >  FAIL: g++.dg/cilk-plus/CK/catch_exc.cc  -O3 -fcilkplus execution test
> > >  FAIL: g++.dg/cilk-plus/CK/catch_exc.cc  -g -O2 -fcilkplus execution test
> > 
> > I don't like special-casing BUILT_IN_SETJMP_RECEIVER - we don't
> 
> 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?

So why would there be extra edges from the receiver?

> > currently have a suitable exported stmt_starts_bb_p () (the existing
> > one is too special), but similar to is_ctrl_altering_stmt we could
> > add a is_ctrl_receiving_stmt that covers nonlocal labels and other
> 
> Yes, that works for me.  I wondered if insert_backedge_copies wouldn't do
> harm if it inserts the assignments before normal setjmp call or other
> call that returns twice.

Yeah, it disrupts the CFG (unfortunately we don't verify that abnormal
edge receievers start a BB, or rather that if a BB receives abnormal
edges there is a stmt at the beginning that receives them).  Adding
such verification to gimple_verify_flow_info would be nice.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]