[RFA][PATCH][PR middle-end/61118] Improve tree CFG accuracy for setjmp/longjmp

Jakub Jelinek jakub@redhat.com
Fri Mar 2 23:07:00 GMT 2018

On Fri, Mar 02, 2018 at 03:18:05PM -0700, Jeff Law wrote:
> On 02/28/2018 03:43 AM, Richard Biener wrote:
> [ More snipping ]
> > 
> >> It's actually pretty easy to fix the CFG.  We  just need to recognize
> >> that a "returns twice" function returns not to the call, but to the
> >> point immediately after the call.  So if we have a call to a returns
> >> twice function that ends a block with a single successor, when we wire
> >> up the abnormal dispatcher, we target the single successor rather than
> >> the block containing the returns-twice call.
> > 
> > Hmm, I think you need to check whether the successor has a single
> > predecessor, not whether we have a single successor (we always have
> > that unless setjmp also throws).  If you fix that you keep the CFG
> > "incorrect" if there are multiple predecessors so I think in addition
> > to properly creating the edges you have to work on the BB building
> > part to ensure that there's a single-predecessor block after
> > returns-twice function calls.  Note that currently we force returns-twice
> > to be the first (and only) stmt of a block -- your fix would relax this,
> > returns-twice no longer needs to start a new BB.
> So I found the code which makes the setjmp start a new block. But I
> haven't found the code which makes setjmp end a block.  I'm going to
> have to throw things into the debugger  to find the latter.
> We ought to remove the code that makes the setjmp start a new block.
> That's just unnecessary.   setjmp certainly needs to end the block though.

At least in gimple, having setjmp start the block is intentional;
we have abnormal edges from all the (possible) spots which might have
longjmp to abnormal dispatcher artificial bb and from that block abnormal
edges to all the sigjmp starts, which is how we emulate the fact that
longjmp might return in a setjmp location.  Edges are created by


More information about the Gcc-patches mailing list