https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #23 from baoshan <pangbw at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #22)
> (In reply to baoshan from comment #21)
> > Don't you think the range value is strange? how it is possible the range
> > value is so big according the code?
>
> j = i - 1 is actually j = i + 4294967295 because of unsigned.
>
> Thus the problematic ranges:
>
> [test.c:9:13] # RANGE [4294967291, 4294967295]
> _51 = i_2 + 4294967290;
>
> are actually:
>
> [test.c:9:13] # RANGE [-5, -1]
> _51 = i_2 - 6;
>
> but this code should have not been generated. Those ranges do seem
> suspicious. Finding out how that block ends up with those ranges would be
> helpful. You probably need to debug vrp or (using -fopt-info) the point
> where gcc gives:
>
> test.c:7:3: note: loop turned into non-loop; it never loops.
> test.c:7:3: note: loop with 5 iterations completely unrolled
I have seen two places that would convert "A-1" to "A+(-1)", and due the type
is unsigned int, it would be converted to "A+4294967295". This looks not right
to me.
The two places are:
1. fold-const.c:10626
/* A - B -> A + (-B) if B is easily negatable. */
if (negate_expr_p (arg1)
&& !TYPE_OVERFLOW_SANITIZED (type)
&& ((FLOAT_TYPE_P (type)
/* Avoid this transformation if B is a positive REAL_CST. */
&& (TREE_CODE (arg1) != REAL_CST
|| REAL_VALUE_NEGATIVE (TREE_REAL_CST (arg1))))
|| INTEGRAL_TYPE_P (type)))
=> return fold_build2_loc (loc, PLUS_EXPR, type,
fold_convert_loc (loc, type, arg0),
fold_convert_loc (loc, type,
negate_expr (arg1)));
2. c-common.c:4574
if (resultcode == MINUS_EXPR)
intop = fold_build1_loc (loc, NEGATE_EXPR, sizetype, intop);
