https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84353
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we are code-generating
for (int c0 = 0; c0 <= 1; c0 += 1)
S_5(c0);
S_21();
if (((-P_9 + 18446744073709551615) % 18446744073709551616) + P_1 <=
18446744073709551614 || ((-P_9 + 18446744073709551615) % 18446744073709551616)
+ P_1 >= 18446744073709551616)
S_7();
S_9();
for (int c0 = 0; c0 < -P_2; c0 += 1)
S_8(c0);
S_22();
specifically we ICE on -P_9 + 18446744073709551615. Of course we can't
materialize 18446744073709551616 for the comparisons either.
We have no way of preserving the infinite precision math ISL does here with
the set of types on i?86-linux where __int128_t is missing. And of course
we generally miss a strategy to deal with the fact that ISL generated math
is infinite precision but our input is not.
The best idea here is to figure out why the condition ends up in the above
form from the "simple" zq != (long long unsigned int) qi. The complication
is of course the modulo "reduction" constraints we build from the
(long long unsigned int) qi cast. This gets expressed as
(P_9 - 18446744073709551616*floor((P_9)/18446744073709551616))
which looks even wrong to me. This doesn't properly produce -1UL from -1.
Hmm.
