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