This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, richard dot guenther at gmail dot com, gcc-patches at gcc dot gnu dot org, matz at suse dot de
- Date: Wed, 3 Oct 2007 08:43:15 +0200
- Subject: Re: [PATCH] Fix optimization regression in constant folder
- References: <200709171539.26653.ebotcazou@adacore.com> <10710011319.AA12088@vlsi1.ultra.nyu.edu> <m3ve9q207p.fsf@localhost.localdomain>
> 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)?
--
Eric Botcazou