This is the mail archive of the gcc@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: Revisiting the TYPE_IS_SIZETYPE issue


> 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?

-- 
Eric Botcazou


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