https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102659
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-10-11
Summary|[false diagnosis] extra |-O2 vectorization
|warning info after O2 |if-conversion produces
|vectorization for |wrong code for
|gcc.dg/torture/pr69760.c |gcc.dg/torture/pr69760.c
Component|debug |tree-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords|diagnostic |wrong-code
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
With -flto we have range info on the test_func function arguments (w/o -flto as
well if you make the function static).
# RANGE [10000000, 10000000] NONZERO 10000000
int L_16(D) = L;
# RANGE [0, 400] NONZERO 508
int m_13(D) = m;
# RANGE [4, 4] NONZERO 4
int n_15(D) = n;
# RANGE [400, 400] NONZERO 400
int N_12(D) = N;
the warning is emitted from the max_loop_iterations call in
vect_truncate_gather_scatter_offset, so it's not because something is
vectorized but because we run the vectorizer. It's also emitted on
the if-converted code only because only then the address computation
of the a[L * k] = 0.0; store can be used to bound the number of iterations.
And indeed the address calculation overflows 32bit memory so this is a problem
with if-conversion since n == 4 and thus
if (k >= 0 && k < n)
a[L * k] = 0.0;
will never trigger in iteration 54.
if-conversion doesn't check whether it makes conditional integer overflow
non-conditional. I think we might have a duplicate report of the problem
somewhere though.
