http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50082
Richard Guenther <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011-08-15 CC| |iant at google dot com Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-15 11:04:12 UTC --- > The diagnostic is bogus, since GCC can clearly deduce that signed > overflow is impossible here: 'i' must be nonnegative at the point of > the complaint, and 'i - 1' cannot possibly overflow. well, the warning machinery does not use ranges (ha, surprise!). And you probably just fool some coalescing with the typedef which hides the issue. Yep, in the int case we fold the comparison to i <= gap_start very early (and do not warn), while in the typedef case we have if ((foo) ((int) i + -1) < gap_start) so there seem to be some STRIP_NOPS missing during early folding. Index: gcc/fold-const.c =================================================================== --- gcc/fold-const.c (revision 177757) +++ gcc/fold-const.c (working copy) @@ -8935,7 +8935,7 @@ fold_comparison (location_t loc, enum tr return fold_build2_loc (loc, cmp_code, type, variable1, const2); } - tem = maybe_canonicalize_comparison (loc, code, type, op0, op1); + tem = maybe_canonicalize_comparison (loc, code, type, arg0, arg1); if (tem) return tem; "fixes" it. Even though we apply overflow knowledge with that folding, we only warn then with -Wstrict-overflow=5 (as documented). Ian - it seems the defering of overflow warnings in forwprop and then undefering does not apply the same restrictions as warning directly? Or rather we should in most of the cases pass 0 instead of some warning-code to fold_undefer_overflow_warnings? I think you added that argument to tree-ssa-forwprop.c - do you remember why? I'm testing the above patch anyway.