https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121370
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
it's SCEV I believe:
(set_scalar_evolution
instantiated_below = 2
(scalar = e_8)
(scalar_evolution = {2147483647, +, 2147483647(OVF)}_1))
SCEV happily combines the -2147483647 and -2 increment. Further:
set_scalar_evolution
instantiated_below = 2
(scalar = _3)
(scalar_evolution = {-2147483647, +, -2147483647(OVF)}_1))
and from there niter analysis based on UB of integer overflow "breaks".
I think the evolution is simply not affine? e_8 goes
2147483647, -2 - but there's no increment value in type int that goes
from 2147483647 to -2 without integer overflow.
A "hack" might be to turn all chrecs with (OVF) into chrec_dont_know.
The following fixes the PR, but it might be better done somewhere
beyond analyze_scalar_evolution and apply this to the full CHREC
(or only CHREC_RIGHTs?). That said, we know SCEV is full of those
issues and this will only detect the cases for constants, not those
when building the CHREC is invalid re-association (we've backed out
a wider fix due to optimization fallout).
diff --git a/gcc/tree-chrec.cc b/gcc/tree-chrec.cc
index a7c2f8de0d5..23dbe1b97ec 100644
--- a/gcc/tree-chrec.cc
+++ b/gcc/tree-chrec.cc
@@ -361,9 +361,15 @@ chrec_fold_plus_1 (enum tree_code code, tree type,
return fold_build_pointer_plus (fold_convert (type, op0),
op1);
else
- return fold_build2 (code, type,
- fold_convert (type, op0),
- fold_convert (type, op1));
+ {
+ tree res = fold_build2 (code, type,
+ fold_convert (type, op0),
+ fold_convert (type, op1));
+ if (TREE_CODE (res) == INTEGER_CST
+ && TREE_OVERFLOW (res))
+ return chrec_dont_know;
+ return res;
+ }
}
else
return chrec_dont_know;
