[Bug c/50082] -Wstrict-overflow mishandles typedef

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.