[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
          Component|middle-end                  |tree-optimization
      Known to work|                            |4.8.3, 4.9.2
   Target Milestone|---                         |5.0
            Summary|request: make               |[5 Regression] request:
                   |-Wstrict-overflow avoid a   |make -Wstrict-overflow
                   |class of false positives    |avoid a class of false
                   |                            |positives

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The warning is senseless for equality compares.  We are trying to transform
(T) x CMP CST to x CMP (typeof x) CST - for equality compares it only matters
whether CST fits in typeof x.  CCing Jeff who added the warning code last year
(making this a regression).  4.9 doesn't warn even if the warning code is
the same, 4.8 doesn't have the warning code.

Index: gcc/tree-vrp.c
===================================================================
--- gcc/tree-vrp.c      (revision 215917)
+++ gcc/tree-vrp.c      (working copy)
@@ -9189,8 +9189,9 @@ simplify_cond_using_ranges (gimple stmt)
              /* If the range overflowed and the user has asked for warnings
                 when strict overflow semantics were used to optimize code,
                 issue an appropriate warning.  */
-             if ((is_negative_overflow_infinity (vr->min)
-                  || is_positive_overflow_infinity (vr->max))
+             if (cond_code != EQ_EXPR && cond_code != NE_EXPR
+                 && (is_negative_overflow_infinity (vr->min)
+                     || is_positive_overflow_infinity (vr->max))
                  && issue_strict_overflow_warning
(WARN_STRICT_OVERFLOW_CONDITIONAL))
                {
                  location_t location;

_6 has [1, +INF(OVF)] beause of Erics new code handling symbolic ranges better
(CCing Eric):

Found new range for j_9: [i_15 + 1, +INF]

Visiting statement:
_6 = j_9 - i_15;
Found new range for _6: [1, +INF(OVF)]

i_15 could be negative and thus j_9 - i_15 could well overflow the input
range at the +INF side.  (i_15 is [-INF, j_5(D) + -1])

I believe we are just better in propagating the ranges here and 4.9
computed _6 as VARYING (and thus not applying the optimization).