PATCH COMMITTED: gcc 4.2 support for -Wstrict-overflow/-fstrict-overflow

Richard Guenther richard.guenther@gmail.com
Tue Mar 13 21:42:00 GMT 2007


On 13 Mar 2007 12:13:27 -0700, Ian Lance Taylor <iant@google.com> wrote:
> "Richard Guenther" <richard.guenther@gmail.com> writes:
>
> > > > > Another approach we could use would be a separate bit in the
> > > > > value_range_t structure to indicate whether overflow has occurred.
> > > > > That would permit us to turn -[-INF, X] into [-X, INF](OVF), rather
> > > > > than [-X, INF(OVF)].  That would slightly extend our ability to use
> > > > > the resulting range.
> > > >
> > > > But it doesn't provide more accuracy for the warning.  If you had "both"
> > > > value ranges you can compare the outcome of a transformation you do
> > > > based on either of the value ranges and warn if they differ.  So what
> > > > you would warn for is "warning: optimization result differs if overflow is
> > > > undefined compared to wrapping semantics" or something like that.
> > >
> > > That may be possible but I'm not convinced.  If the overflow bit is
> > > set for a range which we use to fold, then we would warn that we are
> > > relying on undefined signed overflow.  That is what we want to do
> > > anyhow if the range uses INF(OVF) anywhere.  So what is the
> > > difference?
> >
> > The difference would be in the above case where we now do (?) warn
> > at folding a > 10 to 0.  With the proposed scheme we would avoid this
> > because the value range with wrapping semantics is [-INF+9, +9] (if
> > I computed it right, via the sequence ~[-INF+1,0] [-9,+INF-8] [-INF+9,+9]).
> > The stickyness of the overflow bit at the moment also means it doesn't
> > go away again if we "undo" the overflow.
>
> OK, that is true.
>
> Although I guess it's hard for me to get excited about finding some
> relatively dodgy cases where we can avoid issuing the strict overflow
> warning.

I think only exposing the feature to the wild will tell ;)

> > No, my proposal would not require special infinity arithmetic.  But it would
> > require doubling the amount of value ranges we keep track (and doubling
> > the propagation work).  And it requires (the anyway pending in my tree)
> > improvements for how we handle wrapping semantics and anti-ranges.
>
> I think I don't understand this.  Your proposal was to track two value
> ranges, one with wrapping semantics and one with undefined overflow.
> Tracking the undefined overflow range is the infinity arithmetic case.

My proposal is to do (left is the undefined overflow range, right the one
with wrapping semantics)

  if (a < 0)
    {
      a = -a;      // [1, +INF]   ~[-INF+1,0]
      a = a - 1;  // [0, +INF-1]  [0, +INF-1]
      ...

so we take advantage of "undefinedness" of overflow at propagation time.
INF is not sticky, but of course as we do now, we need to fall back to
+INF/-INF as we do now (and before your patch) in for example
vrp_int_const_binop.  Note that further processing of the range with
infinities does not need to care about a "special" INF (because it's
not required to keep it sticky).

> It's true that before my patch VRP didn't use infinity arithmetic.
> But it got away with that because, e.g.,
> extract_range_from_binary_expr would flush to varying when it saw an
> overflow value.  With infinity arithmetic VRP is actually more precise
> in situations involving overflow.

I didn't notice it flushed to varying.  It does so for wrapping semantics
(but I have patches to improve this), not for undefined overflow
semantics.  So I think these cases are unchanged with your patch.

Richard.



More information about the Gcc-patches mailing list