Re: PATCH RFC: Use explicit representation of infinity in VRP

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 11 Mar 2007 09:12:01 -0700, Ian Lance Taylor <iant@google.com> wrote:
> "Richard Guenther" <richard.guenther@gmail.com> writes:
>
> > On 02 Mar 2007 12:09:43 -0800, Ian Lance Taylor <iant@google.com> wrote:
> > > Ian Lance Taylor <iant@google.com> writes:
> > >
> > > > This patch is a lengthy prelude to adding full support for
> > > > -fstrict-overflow and -Wstrict-overflow to tree-vrp.c.  It changes VRP
> > > > to use an explicit representation of signed infinity when there is a
> > > > signed overflow.
> > >
> > > Committed as follows.
> >
> > This patch causes optimization regressions because it preserves "overflow"
> > even if -fstrict-overflow is in effect or -Wstrict-overflow is not in effect.
> > See PR31130.  I believe needs_overflow_infinity () should return false
> > for -fstrict-overflow.
>
> That would not be the right fix.  It would cause -Wstrict-overflow to
> become ineffective for VRP, which would put us right back where we
> were when I started the whole series of patches: user code would act
> in unexpected ways with no warning.  And simply adding
> -Wstrict-overflow should not, of course, change code generation.
>
> I know that some people are uneasy with the whole idea of this series
> of patches.  But the fact is, real users were prepared to turn on
> -fwrapv for all code which uses autoconf, which is a good fraction of
> uses of gcc.  I think that my patch does considerably less harm than
> that.  I am always open to other suggestions, and I have asked for
> them consistently during this series of patches.

I don't want to re-start all the discussion, but I still believe that those
(few) people will still be unhappy that the "optimizations in question
happen anyhow".  So my opinion is that we made gcc worse for the
sake of a few people that were loudly complaining and probably
still will turn on -fwrapv.

I do believe that -Wstrict-overflow is a good addition, but I didn't expect
the addition of a warning possibilty to affect the set of optimizations done.
That sounds as backward as generating different code of -Wstrict-overflow
is in effect.

Richard.