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

Richard Biener richard.guenther@gmail.com
Thu Mar 8 13:26:00 GMT 2018

On Thu, Mar 8, 2018 at 2:22 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>> On Wed, 7 Mar 2018, Peter Bergner wrote:
>>> On 3/7/18 12:01 AM, Jeff Law wrote:
>>> > I believe so by nature that the setjmp dominates the longjmp sites and
>>> > thus also dominates the dispatcher.  But it's something I want to
>>> > explicitly check before resubmitting.
>>> Are we sure a setjmp has to dominate its longjmp sites?
>> No, they don't have to dominate.  For lack of better term I used something
>> like "ordered after" in my mails :)
>>> Couldn't you have something like:
>> Yeah, exactly.
> So given all the discussion _iff_ we want to change the CFG we generate then
> let's invent a general __builtin_receiver () and lower setjmp to
>   setjmp ();
>   res = __builtin_receiver ();
> and construct a CFG around that.  Remember that IIRC I added the abnormal
> edges to and from setjmp to inhibit code-motion across it so whatever CFG
> we'll end up with should ensure that there can't be any code-motion optimization
> across the above pair nor "inbetween" it.  The straight-forward
> CFG of, apart from the fallthru from setjmp to the receiver, a abnormal edge
> to the dispatcher from setjmp and an abnormal edge from the dispatcher to
> the receiver would do that trick I think.
> I'd rather not do that for GCC 8 though.  So to fix the warning can't we do
> sth else "good" and move the strange warning code from RTL to GIMPLE?
> Or re-do the warning?  Since in the other thread about setjmp side-effects
> we concluded that setjmp has to preserve all call-saved regs?  I don't see
> that reflected in regno_clobbered_at_setjmp or its caller -- that is,
> we should only warn for call clobbered and thus caller-saved regs because
> normal return may clobber the spilled values.
> Not sure if the PR testcase is amongst the cases fixed by such change.

Ah, slight complication is we warn from IRA but _before_ RA.  Not sure if
there's a place where hardregs are assigned but not yet spilled (and those
hardreg assignments hold in the end) where we can move the warning to.


> Richard.
>> Ciao,
>> Michael.

More information about the Gcc-patches mailing list