Re: [PATCH] Add a new type attribute always_alias (PR79671)

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Apr 05, 2017 at 05:17:24PM -0600, Sandra Loosemore wrote:
> > > Yes, exactly.  I really want to reach the deadline for gcc-7.
> > > Fixing the name is certainly the most important first step,
> > > and if everybody agrees on "typeless_storage", for the name
> > > I can start with adjusting the name, and look into how
> > > to use a spare type-flag that should be a mechanical change.
> > > 
> > 
> > Jakub, I just renamed the attribute and reworked the patch
> > as you suggested, reg-testing is not yet completed, but
> > it looks good so far.  I also added a few more tests.
> > 
> > I have changed the documentation as Richi suggested, but
> > I am not too sure what to say here.
> > 
> 
> > Index: gcc/doc/extend.texi
> > ===================================================================
> > --- gcc/doc/extend.texi	(revision 246678)
> > +++ gcc/doc/extend.texi	(working copy)
> > @@ -6656,6 +6656,11 @@ declaration, the above program would abort when co
> >  @option{-fstrict-aliasing}, which is on by default at @option{-O2} or
> >  above.
> > 
> > +@item typeless_storage
> > +@cindex @code{typeless_storage} type attribute
> > +An object declared with a type with this attribute behaves like a
> > +character type with respect to aliasing semantics.
> > +
> >  @item packed
> >  @cindex @code{packed} type attribute
> >  This attribute, attached to @code{struct} or @code{union} type
> 
> 
> "An object ....  behaves like a character type"?  I think you mean "as if it
> had character type".  Or maybe something simpler like "A type declared with
> this attribute has the same aliasing semantics as @code{char} type."

Well, that wording doesn't make much sense, because the problem is exactly
that alias semantics of the char type does not do what C++ needs from
unsigned char [N] or std::byte [N] arrays.  char type inside of a structure
no longer means you can put anything in there.  If you have effective type
of char and access it through lvalue of some type incompatible with it (see
the C99 6.5/7 rules), then it is still invalid, only if you access object
of any effective type through lvalue of char type, then it is valid.
Now, for objects with type with typeless_storage or for C++ unsigned char
or std::byte arrays, we basically want to say that accessing them through
lvalue of any type is well defined.  I'd probably document it just for
typeless_storage attribute, because for the unsigned char and std::byte
arrays it is C++17 that defines the exact rules and they are probably
less strict than that, so it would be good if we leave it open to refine
the unsigned char/std::byte array behavior later on to better match what
C++ requires.  Not sure if we want to document anything about accesses
through lvalue of type with typeless_storage attribute, whether that also
implies it is like accesses through lvalue of type char.  If yes, that
would be may_alias attribute behavior extended, so that it is not just
accesses through pointers/references to type with may_alias attribute
that are treated that way, but any accesses through lvalue with type
with typeless_storage attribute.

	Jakub