https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112344
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
In particular the final jump is miscalculated somehow, possibly path-ranger
mishandles the situation. For the loop header we thread through we
first clear dependent ranges (good) but then do compute_ranges_in_phis
(weird, we know the incoming edge?), doing
Value_Range r (TREE_TYPE (name));
if (range_defined_in_block (r, name, bb))
m_cache.set_range (name, r);
where this ends up calling ssa_range_in_phi, resulting in
[irange] int [1, 1]$69 = void
Hmm, so we have
_41 : [irange] int [1073741833, 1073741833]
_42 : [irange] int [+INF, +INF]
and
<bb 4> [local count: 105119324]:
_37 = e_1 + 2;
_38 = (unsigned int) e_1;
_39 = 19 - _38;
_40 = _39 / 2;
_41 = (int) _40;
_42 = _41 * 2;
so it's the e_9 replacement that is wrong.
This is chrec_apply, applying the unsigned number of iterations (19 - (unsigned
int) e_31) / 2 to the signed chrec {e_31 + 2, +, 2}_2. This isn't without
overflow when computing the overall increment from INT_MIN to 19 since that
positive number cannot be represented in a signed integer type.
