https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127981
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Biener <[email protected]>: https://gcc.gnu.org/g:ab8d26c0d68f49841a8225be53a7f947fb664476 commit r17-5503-gab8d26c0d68f49841a8225be53a7f947fb664476 Author: Richard Biener <[email protected]> Date: Mon Oct 19 12:49:11 2026 +0200 middle-end/127981 - stack var conflicts for addresses live via PHIs Since r15-6655-g0014a858a14 add_scope_conflicts_1 processes the PHI results of a block with visit_op even when generating conflicts. visit_op only marks the stack variables as live without recording any conflicts with the variables already live on entry to the block. visit_conflict in turn only records conflicts when a variable becomes live for the first time in the block, so a variable whose address only reaches a block through a PHI argument never conflicts with variables that were already live coming in. For a block with multiple predecessors this is papered over by the merge handling which makes all live variables conflict with each other, but for a block with a single predecessor it is not. In the testcase we have <bb 2>: cr = &dl; ... <bb 8>: # dk_64 = PHI <&dj(2)> ... dj = 0; *cr.123_21 = &MEM <int[3]> [(void *)&cq + 8B]; ... _57 = *dk_64; and dj and dl end up sharing a stack slot, so the store through cr clobbers dj. Fix this by using visit (which is visit_conflict when generating conflicts) for PHI results again, like before r15-6655. PR middle-end/127981 * cfgexpand.cc (add_scope_conflicts_1): Use visit rather than visit_op for PHI results. * gcc.dg/torture/pr127981.c: New test.
