https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Last reconfirmed| |2024-01-04
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #3 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks,
Indeed the patch for PR 113137 won't fix this one as it looks like the peeling
code has gotten confused about which exit is which when adjusting
virtual_operands.
It looks like it's swapped them, and this happens because non of the loop exits
are counting one so it just picks a random one.
Looks the one it picks is not the latch connected one:
perl.c:10:8: note: using as main loop exit: 11 -> 7 [AUX: (nil)]
perl.c:10:8: note: === get_loop_niters ===
perl.c:10:8: note: Loop has 2 exits.
perl.c:10:8: note: Analyzing exit 0...
perl.c:10:8: note: Analyzing exit 1...
which then incorrectly peels:
# iters_46 = PHI <iters_12(21), iters_4(26)>
which should be:
# iters_46 = PHI <iters_4(21), iters_12(26)>
I started implemented a fix for this same situation earlier for PR 113178 but
didn't finish it because I didn't think we'd get this far with a legit loop.
I'll finish that part. Thanks for the testcase!
