https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111445
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- And I think its a SCEV/tree-affine issue. We have <bb 6> [local count: 236223200]: # e_15 = PHI <0(10), e_21(5)> _9 = (unsigned char) d_26; _10 = _9 + 1; _11 = (int) _10; _12 = (int) e_15; _13 = _11 + _12; if (_13 <= 1) goto <bb 5>; [50.00%] else goto <bb 7>; [50.00%] <bb 5> [local count: 118111600]: b.6_7 = b; _8 = (int) b.6_7; check (_8); e_21 = e_15 + 1; goto <bb 6>; (get_scalar_evolution (scalar = e_15) (scalar_evolution = {0, +, 1}_2)) that's OK if the niter bound is correct (get_scalar_evolution (scalar = _12) (scalar_evolution = {0, +, 1}_2)) likewise (get_scalar_evolution (scalar = _13) (scalar_evolution = {(int) ((unsigned char) d_26 + 1), +, 1}_2)) also OK. But from that we get IV struct: SSA_NAME: _13 Type: int Base: d_26 + 1 Step: 1 Biv: N Overflowness wrto loop niter: No-overflow That's because simple_iv_with_niters does, getting the correct iv->base (int) ((unsigned char) d_26 + 1) /* Try to simplify iv base: (signed T) ((unsigned T)base + step) ;; TREE_TYPE (base) == signed T == (signed T)(unsigned T)base + step == base + step If we can prove operation (base + step) doesn't overflow or underflow. Specifically, we try to prove below conditions are satisfied: base <= UPPER_BOUND (type) - step ;;step > 0 base >= LOWER_BOUND (type) - step ;;step < 0 This is done by proving the reverse conditions are false using loop's initial conditions. The is necessary to make loop niter, or iv overflow analysis easier for below example: int foo (int *a, signed char s, signed char l) { signed char i; for (i = s; i < l; i++) a[i] = 0; return 0; } Note variable I is firstly converted to type unsigned char, incremented, then converted back to type signed char. */ where we end up querying d_26 > 2147483646 but the comment also doesn't match us skipping a narrowing conversion here (besides failing to use the limit based on the narrowed type).