https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674586.html fixes the
issue it seems. That's a "correct" side-effect in that the
int h = 0;
do {
int b = 0;
int *l = &b;
h = 0;
for (int j = 0; j < 10; j++) {
for (int k = 0; k < f; k++)
h+= !!l[k];
}
} while (h);
is not known to be finite. In the end this tickles down via ranges to
-Loop 4 iterates at most 14 times.
-Loop 4 likely iterates at most 14 times.
+Loop 4 iterates at most 61 times.
+Loop 4 likely iterates at most 61 times.
(that's the main vector loop).
Looking at Andrews testcase we have
int f = c - 5; // f == -5
//__builtin_printf("%d\n", f);
int h = 0;
do {
int b = 0;
int *l = &b;
h = 0;
for (int j = 0; j < 10; j++) {
for (int k = 0; k < f; k++) // 0 < -5, so the loop doesn't
enter
h+= !!l[k];
but with -O3 we hit a vector load of &b that was hoisted across the f > 0
check by LIM and that traps.
