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

Reply via email to