This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 11 Mar 2007 09:12:01 -0700, Ian Lance Taylor <> wrote:
"Richard Guenther" <> writes:

> On 02 Mar 2007 12:09:43 -0800, Ian Lance Taylor <> wrote:
> > Ian Lance Taylor <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]