On March 9, 2018 8:42:16 PM GMT+01:00, Jeff Law <l...@redhat.com> wrote: >On 03/08/2018 06:22 AM, Richard Biener wrote: >> 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 >And I'm seriously thinking we may want to hold off on the fix for 61118 >for gcc-8. We still might want to fix 21161 though. I still need to >digest all the discussion. > > >> >> 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? >Someone mentioned that possibility in one of the related BZs. The >concern was the factoring of the handler could really hinder good >dataflow analysis. We could end up making things worse :( > > >> >> 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. >Possibly. It's clear from the discussion and multitude of BZs that >this >is complex and easily goof'd. > >I believe part of the "trick" here is that once we compute (in RTL) the >set of objects live across the setjmp the allocators then refuse to >allocate those values into call-saved registers (hence the other >discussion thread) with Peter and co. Of course the RTL analysis get >this wrong in a roughly similar manner (21161). > > >> Not sure if the PR testcase is amongst the cases fixed by such >change. >Unclear -- it'd likely depend on where we do the analysis. It's >certainly the case that for 61118 that if the analysis happens in RTL >and we haven't addressed our CFG correctness issues that we're going to >fail.
Note that on RTL the CFG does not have any abnormal edges for setjmp and thus code is freely moved across it. Maybe addressing that would also help. Richard. > >jeff.
