https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123417
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Andrew Pinski <[email protected]>: https://gcc.gnu.org/g:3ebe697f32197ec4a429fbf8dd9cce3155c0c9ba commit r16-6679-g3ebe697f32197ec4a429fbf8dd9cce3155c0c9ba Author: Andrew Pinski <[email protected]> Date: Fri Jan 9 02:02:01 2026 -0800 cfgcleanup: Protect latches always [PR123417] So it turns out LOOPS_MAY_HAVE_MULTIPLE_LATCHES is set in places along compiling. Setting it only means there might be multiple latches currently. It does not mean let's go in an delete them all; which is what remove_forwarder_block does currently. This was happening before my set of patches too but since it was only happening in merge_phi pass, latches were not cleared away al of the time and then recreated. This solves the problem by protecting latches all of the time instead of depedent on LOOPS_MAY_HAVE_MULTIPLE_LATCHES not being set. vect-uncounted_7.c needs to be xfailed here because we no longer vectorize the code. Note the IR between GCC 15 and after this patch is the same so I think this was just a case were the testcase was added after the remove forwarder changes and should not have vectorized (or vectorize differently). Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/123417 gcc/ChangeLog: * tree-cfgcleanup.cc (maybe_remove_forwarder_block): Always protect latches. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-uncounted_7.c: xfail vect test. Signed-off-by: Andrew Pinski <[email protected]>
