Re: Revisiting the TYPE_IS_SIZETYPE issue

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

On Tue, May 27, 2008 at 11:07 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> Well, this goes back to the question what TYPE_IS_SIZETYPE semantics
>> are ;)  I guess it would be a sort-of "sticky" 'does not overflow'
>> flag?  That is even after any possible re-association no operation does
>> overflow?
>
> Yes.
>
>> What happens if you re-associate  (A +/o B) +/s C  (the first +/o might
>> overflow, the second +/s is the "sticky" one)?
>
> I presume that the FE should make sure this cannot happen, but /s should trump
> anything else in the end.
>
>> From the past discussion we are still waiting for a testcase where the
>> reassoication in question (the one that initially provoked all these
>> discussions) matters.
>
> Well, if you think that the transformation at stake in fold-const.c is totally
> useless, why not simply get rid of the entire code?

You chose to not reply to

"
Re-association is always possible with my idea - you just need to drop from
'does not overflow' to 'may overflow' operations (thus in C speak, from
signed overflow semantics to unsigned overflow semantics) for the
expression in question.  IMHO this should allow all optimizations you
want from TYPE_IS_SIZETYPE types without actually having them.
"

So do you agree with that?

Richard.