Re: [PATCH] Fix optimization regression in constant folder

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

On 10/1/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > Not at all.  I'm thinking in middle-end operations possible on those types.
>
> So am I.  They are used to define the sizes of objects and offsets into
> objects in the middle-end and I agree that it's important to get well-defined
> semantics for them.
>
> > Okay, so overflow can not happen (except in illformed programs, in which
> > case we don't need to care).  That seems to hint to a OVERFLOW_UNDEFINED
> > type.
>
> Somewhat, though I'm trying hard not to define the sizetype semantics in
> the same way we would for a user-visible type since it *isn't* user-visible.
> It would be *close* to that, except that this will suppress critical
> optimizations that must be done for sizetypes.

It sounds like you define sizetypes to have infinite precision.  Which
is the only
way overflow cannot occur.  Of course in this case converting a
unsigned sizetype
to a signed one will never produce a negative value (which we rely on,
for example
with POINTER_PLUS_EXPR which takes a unsigned sizetype argument but
perfectly well handles effective MINUS by using wrapping semantics - or rather,
by effectively assuming signedness.  It's another thing I opposed to,
as it hints
at POINTER_PLUS_EXPR wants the same sort of thing you want - do the
right thing in the right situation, which is not very well defined).

Oh, and did I ask for testcases?

Richard.