This is the mail archive of the 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


On Thu, 11 Oct 2007, Richard Guenther wrote:

> The only reason to have sizetype is that there may be no language defined
> integral type of the required precision (which is the precision of
> pointers AFAIK).

I'm not argueing against the existence of a type-tree stored in a global 
variable named 's?sizetype'.  I'm arguing against that type-tree being an 
integer type with strange semantics like the current ill-defined 
TYPE_IS_SIZETYPE property.  It unfortunately doesn't help that the strange 
properties are called "sizetype" and the variable is called "sizetype" and 
the expected semantics and use-case also is best conveyed with the single 
word "sizetype".

Actually I'm arguing for that type-tree being an unsigned integer type 
of the same width as pointers, without a name, throughout the whole 
compiler, and be done with this.

> So it does make sense to have this special sizetype (you could call it
> intptr_t of course), and it might also make sense to treat overflow of
> the signed
> variant as wrapping (though I'd argue we should match overflow behavior of
> pointers as we mainly use sizetypes to offset pointers or compute differences
> of them - which would make overflow of sizetypes undefined and not wrapping).

The difference is, that we don't calculate with pointers (so it's okay 
that overflow is undefined, as this simply can't happen), but we do have 
to calculate with sizetype and offsettype (I'm making up the latter), and 
the kind of arithmetics we do on them (e.g. what Mark has shown) argues 
for wrapping on overflow, even on the conceptually signed offsettype.


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