[Bug tree-optimization/49234] [4.5/4.6/4.7/4.8 Regression] -Wstrict-overflow gives obviously unwarranted warning

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> 2013-03-04 09:57:40 UTC ---
On Fri, 1 Mar 2013, aldyh at redhat dot com wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49234
> 
> --- Comment #12 from Aldy Hernandez <aldyh at redhat dot com> 2013-03-01 19:17:32 UTC ---
> > --- Comment #11 from Ian Lance Taylor <ian at airs dot com> 2013-03-01 14:52:53 UTC ---
> > I suspect we can handle this case by observing that all the incoming values to
> > the PHI node are constants.
> 
> Ian.
> 
> They're not all constants.  In this particular case we have phis like this:
> 
> state_2 = PHI <0(6), state_3(12), 2(5)>
> 
> I suppose we could chase the SSA def chain and if all the phi arguments 
> are either constants, or known to point to an SSA that has been 
> previously analyzed as constant, then we can avoid generating an 
> overflow.  But we'd have to keep track of states across calls to 
> vrp_visit_phi_node.  Is this what you had in mind, or am I 
> misunderstanding something?
> 
> Obviously, Richi's idea is much simpler :).  With his suggestion we 
> could probably do with:
> 
> @@ -8111,11 +8109,9 @@ vrp_visit_phi_node (gimple phi)
>         if (cmp_max < 0 || cmp_max > 0)
>          {
>            if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))
> -             || !vrp_var_may_overflow (lhs, phi))
> +             || !vrp_var_may_overflow (lhs, phi)
> +             || supports_overflow_infinity (TREE_TYPE (vr_result.max)))
>              vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
> -         else if (supports_overflow_infinity (TREE_TYPE (vr_result.max)))
> -           vr_result.max =
> -               positive_overflow_infinity (TREE_TYPE (vr_result.max));
>          }
> 
> And similarly for MIN.  In the above, supports_overflow_infinity is just 
> there to make sure we have a CONSTANT_CLASS_P.  If that's not needed, we 
> could even do:
> 
>     if (cmp_max < 0 || cmp_max > 0)
>       vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max));
> 
> and be done with it.

That's what I was suggesting.

As for strict-overflow warnings in VRP my suggestion was that we
want to warn only when a folding result _changes_.  Thus, propagate
-fwrapv and -fno-wrapv in "parallel" using two lattices and compare
the final result.  That's way less prone to false positives.

Richard.