This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Revisiting the TYPE_IS_SIZETYPE issue
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?
Sure, why not. But getting rid of these recursive foldings (also like
extract_muldiv and friends) requires to open-code the two or three
useful flat transformations - those that are useful if you combine
two gimple expressions.
Did you even try my initial suggestion from the last discussion to
make TYPE_IS_SIZETYPEs TYPE_OVERFLOW_WRAPs? As
said in the previous discussion you run into the (optimization) differences
compared to C because your sizetype is signed (and thus
TYPE_OVERFLOW_UNDEFINED).
And we still didn't get a testcase, so rely on you to even try what we
suggest.
Richard.