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).
