diff options
Diffstat (limited to 'gcc/tree-scalar-evolution.cc')
-rw-r--r-- | gcc/tree-scalar-evolution.cc | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc index 43311e5..3b3748a 100644 --- a/gcc/tree-scalar-evolution.cc +++ b/gcc/tree-scalar-evolution.cc @@ -670,6 +670,17 @@ scev_dfs::add_to_evolution_1 (tree chrec_before, tree to_add, gimple *at_stmt) to_add = chrec_convert (type, to_add, at_stmt); right = chrec_convert_rhs (type, right, at_stmt); right = chrec_fold_plus (chrec_type (right), right, to_add); + /* When we have an evolution in a non-wrapping type and + in the process of accumulating CHREC_RIGHT there was + overflow this indicates in the association that happened + in building the CHREC clearly involved UB. Avoid this. + In building a CHREC we basically turn (a + INCR1) + INCR2 + into a + (INCR1 + INCR2) which is not always valid. + Note this check only catches few invalid cases. */ + if ((INTEGRAL_TYPE_P (type) && ! TYPE_OVERFLOW_WRAPS (type)) + && TREE_CODE (right) == INTEGER_CST + && TREE_OVERFLOW (right)) + return chrec_dont_know; return build_polynomial_chrec (var, left, right); } else @@ -3088,7 +3099,7 @@ iv_can_overflow_p (class loop *loop, tree type, tree base, tree step) type_max = wi::max_value (type); /* Just sanity check that we don't see values out of the range of the type. - In this case the arithmetics bellow would overflow. */ + In this case the arithmetics below would overflow. */ gcc_checking_assert (wi::ge_p (base_min, type_min, sgn) && wi::le_p (base_max, type_max, sgn)); |