On Tue, Nov 8, 2022 at 5:37 PM Surya Kumari Jangala <jskum...@linux.vnet.ibm.com> wrote: > > Hi Richard, > > On 21/09/22 1:03 pm, Richard Biener wrote: > > On Tue, Sep 20, 2022 at 9:18 AM Surya Kumari Jangala via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> > >> Hi Jeff, Richard, > >> Thank you for reviewing the patch! > >> I have committed the patch to the gcc repo. > >> Can I backport this patch to prior versions of gcc, as this is an easy > >> patch to backport and the issue exists in prior versions too? > > > > It doesn't seem to be a regression so I'd error on the safe side here. > > Can you please clarify, should this patch be backported? It is not very clear > what "safe side" means here.
Not backporting is the safe side. Richard. > Thanks! > Surya > > > > > Richard. > > > >> Regards, > >> Surya > >> > >> > >> On 31/08/22 9:09 pm, Jeff Law via Gcc-patches wrote: > >>> > >>> > >>> On 8/23/2022 5:49 AM, Surya Kumari Jangala via Gcc-patches wrote: > >>>> sched1: Fix -fcompare-debug issue in schedule_region [PR105586] > >>>> > >>>> In schedule_region(), a basic block that does not contain any real insns > >>>> is not scheduled and the dfa state at the entry of the bb is not copied > >>>> to the fallthru basic block. However a DEBUG insn is treated as a real > >>>> insn, and if a bb contains non-real insns and a DEBUG insn, it's dfa > >>>> state is copied to the fallthru bb. This was resulting in > >>>> -fcompare-debug failure as the incoming dfa state of the fallthru block > >>>> is different with -g. We should always copy the dfa state of a bb to > >>>> it's fallthru bb even if the bb does not contain real insns. > >>>> > >>>> 2022-08-22 Surya Kumari Jangala <jskum...@linux.ibm.com> > >>>> > >>>> gcc/ > >>>> PR rtl-optimization/105586 > >>>> * sched-rgn.cc (schedule_region): Always copy dfa state to > >>>> fallthru block. > >>>> > >>>> gcc/testsuite/ > >>>> PR rtl-optimization/105586 > >>>> * gcc.target/powerpc/pr105586.c: New test. > >>> Interesting. We may have stumbled over this bug internally a little > >>> while ago -- not from a compare-debug standpoint, but from a "why isn't > >>> the processor state copied to the fallthru block" point of view. I had > >>> it on my to investigate list, but hadn't gotten around to it yet. > >>> > >>> I think there were requests for ChangeLog updates and a function comment > >>> for save_state_for_fallthru_edge. OK with those updates. > >>> > >>> jeff > >>>
