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

[Ian Lance Taylor <iant at google dot com>]

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


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

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.

Ian