On Thu, Mar 8, 2018 at 1:54 PM, Michael Matz <m...@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. Richard. > > Ciao, > Michael.
