On Fri, Apr 11, 2025 at 6:23 PM Vladimir Makarov <vmaka...@redhat.com> wrote: > > > On 4/11/25 2:29 AM, Uros Bizjak wrote: > > Hello! > > > > I would like to backport PR115568 and PR119689 to release branches. > > > > Author: Richard Biener <rguent...@suse.de> > > Date: Wed Apr 9 14:36:19 2025 +0200 > > > > rtl-optimization/119689 - compare-debug failure with LRA > > > > The previous change to fix LRA rematerialization broke compare-debug > > for i586 bootstrap. Fixed by using prev_nonnote_nondebug_insn > > instead of prev_nonnote_insn. > > > > PR rtl-optimization/119689 > > PR rtl-optimization/115568 > > * lra-remat.cc (create_cands): Use prev_nonnote_nondebug_insn > > to check whether insn2 is directly before insn. > > > > * g++.target/i386/pr119689.C: New testcase. > > > > (cherry picked from commit 088887de7717a22b1503760e9b79dfbe22a0f428) > > > > Author: Vladimir N. Makarov <vmaka...@redhat.com> > > Date: Wed Feb 5 14:23:23 2025 -0500 > > > > [PR115568][LRA]: Use more strict output reload check in > > rematerialization > > > > In this PR case LRA rematerialized a value from inheritance insn > > instead of output reload one. This resulted in considering a > > rematerilization candidate value available when it was actually > > not. As a consequence an insn after rematerliazation used the > > unexpected value and this use resulted in fp exception. The patch > > fixes this bug. > > > > gcc/ChangeLog: > > > > PR rtl-optimization/115568 > > * lra-remat.cc (create_cands): Check that output reload insn is > > adjacent to given insn. Update a comment. > > > > gcc/testsuite/ChangeLog: > > > > PR rtl-optimization/115568 > > * gcc.target/i386/pr115568.c: New. > > > > OK for branches? > > > Yes, but only when the both patches are committed as mine patch had a > flaw and Richard's patch fixed this flaw.
Sure. Forgot to say, that the patch combination was bootstrapped and regression tested on x86_64-linux-gnu for gcc-12, gcc-13 and gcc-14 branches. Uros.
