[PATCH] Fix optimization regression in constant folder
Michael Matz
matz@suse.de
Thu Oct 11 16:25:00 GMT 2007
Hi,
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.
Ciao,
Michael.
More information about the Gcc-patches
mailing list