Re: [PATCH] Fix PR32628, bogus overflow flag on sizetype consts

[Richard Guenther <rguenther at suse dot de>]

On Wed, 16 Jan 2008, Richard Kenner wrote:

> > > It seems wrong, however, to have sizetype be that user-visible.
> > 
> > It is as user-visible as using sizetype for sizes of VLA types.
> 
> It's used *internally* as the size and offsets for such types, but does
> not correspond to any language-visible type.  When you specify the size
> of an array, you use whatever language-visible type you want (usually
> "int") and the value gets converted to sizetype by the middle-end.

If you add an offset to a pointer, you use whatever language-visible
type you want (usually "int") and the value gets converted to sizetype
by the middle-end.

I see no difference here ;)

> Conversely, when you use something like sizeof, the middle-end converts
> the value of sizetype into a value of size_t type.  size_t and sizetype
> are NOT meant to be the same type!
> 
> > I know this looks weird and I have complained about this in the past.
> 
> I think that's the core of this bug.

Maybe.

> > sign-extension means that the representation of INTEGER_CSTs of
> > that type (the pair of two HOST_WIDE_INTs) which always has a precision
> > of 2*BITS_PER_HOST_WIDE_INT is sign-extended (that is, the most 
> > significant bit of the constant is interpreted as a sign-bit which is
> > then copied to the excess precision parts).
> 
> If the type is unsigned, then there's no sign bit, so this seems quite wrong.

It's been this way since day one of GCC in version control.  I tried
to get rid of this "feature", but interesting things happen if you do ;)

sizetypes are scary and weird.  But I think I have expressed this opinion
many times ;)

> > > > As written, (char *)0 + ~0ULL is the address of the last byte of the
> > > > virtual address space.
> > > 
> > > And the C standard defines it this way?
> > 
> > The C standard surely does not speak about virtual address space.  But
> > why is the C standard relevant in this discussion?  It's about the
> > middle-end.
> 
> No, it's about how to interpret things specified by a language in the
> middle-end.  In order to do that, we first have to know the proper official
> language interpretation.  And I don't know C nearly well enough to know
> that in the above case.

The official language representation is that (T *)x + a is pointing
to the n+i-th element of an array with element type T if x points
to the n-th element of this array.  [very much more language lawyer
stuff is there, of course]

Apart from this, it specifies that the result type of an addition if
one operand has pointer type and one operand has integer type is
the pointer type.

Richard.