This is the mail archive of the gcc-patches@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: [PATCH] Fix PR32628, bogus overflow flag on sizetype consts


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

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.

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

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


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