This is the mail archive of the gcc-patches@gcc.gnu.org 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] Fix optimization regression in constant folder


Eric Botcazou <ebotcazou@adacore.com> writes:

> > That said, I take your point that TYPE_OVERFLOW_UNDEFINED is not quite
> > right for sizetypes, since it does not permit us to introduce overflow
> > where it was not present (i.e., it does not permit us to reassociate).
> > And TYPE_OVERFLOW_WRAPS is not quite sufficient, since it does not
> > permit canonicalizations.
> >
> > TYPE_OVERFLOW_WRAPS seems clearly correct for sizetypes (if not, why
> > not, and give us an example).
> >
> > So it seems that we should do is separate TYPE_OVERFLOW_UNDEFINED into
> > two different meanings:
> >
> > 1) We can assume that computations in this type will never overflow,
> >    but we should be careful not to introduce overflow where it was not
> >    present.  (TYPE_OVERFLOW_UNDEFINED)
> >
> > 2) We can assume that computations in this type will never overflow,
> >    no matter what we do.  (TYPE_IGNORE_OVERFLOWS)
> 
> Yes, TYPE_IGNORE_OVERFLOWS is what I'm asking for from the very beginning.
> 
> > Then a few places which currently check TYPE_OVERFLOW_WRAPS can check
> > TYPE_IGNORE_OVERFLOWS instead.
> 
> What about places where we check TYPE_OVERFLOW_UNDEFINED?  Or do we keep 
> TYPE_OVERFLOW_UNDEFINED on size types too (it is set for Ada)?

In some of the places where we currently check
TYPE_OVERFLOW_UNDEFINED, we would also check TYPE_IGNORE_OVERFLOWS (or
we introduce yet another flag which is the intersection).  In the
proposal above, it doesn't make sense to me to set
TYPE_OVERFLOW_UNDEFINED for sizetypes.

Ian


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