https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115782
--- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:44fc801e97a8dc626a4806ff4124439003420b20 commit r15-1972-g44fc801e97a8dc626a4806ff4124439003420b20 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Thu Jul 11 14:44:11 2024 +0100 recog: Avoid validate_change shortcut for groups [PR115782] In this PR, due to the -f flags, we ended up with: bb1: r10=r10 ... bb2: r10=r10 ... bb3: ...=r10 with bb1->bb2 and bb1->bb3. late-combine successfully combined the bb1->bb2 def-use and set the insn code to NOOP_MOVE_INSN_CODE. The bb1->bb3 combination then failed for... reasons. At this point, everything should have been rewound to its original state. However, substituting r10=r10 into r10=r10 gives r10=r10, and validate_change had an early-out for no-op rtl changes. This meant that validate_change did not register a change for the bb2 insn and so did not save its old insn code. The NOOP_MOVE_INSN_CODE therefore persisted even after the attempt had been rewound. IMO it'd be too cumbersome and error-prone to expect all users of validate_change to be aware of this possibility. If code is using validate_change with in_group=1, I think it has a reasonable expectation that a change will be registered and that the insn code will be saved (and restored on cancel). This patch therefore limits the shortcut to the !in_group case. gcc/ PR rtl-optimization/115782 * recog.cc (validate_change_1): Suppress early exit for no-op changes that are part of a group. gcc/testsuite/ PR rtl-optimization/115782 * gcc.dg/pr115782.c: New test.
