PATCH COMMITTED: gcc 4.2 support for -Wstrict-overflow/-fstrict-overflow
Tue Mar 13 21:42:00 GMT 2007
On 13 Mar 2007 12:13:27 -0700, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> "Richard Guenther" <email@example.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
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.
More information about the Gcc-patches