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