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

Richard Biener rguenther@suse.de
Thu Apr 6 07:23:00 GMT 2017


On Wed, 5 Apr 2017, Jason Merrill wrote:

> On Wed, Apr 5, 2017 at 1:41 PM, Bernd Edlinger
> <bernd.edlinger@hotmail.de> wrote:
> > On 04/05/17 17:20, Richard Biener wrote:
> >>> Also, wonder if you need to mark all types containing such arrays,
> >>> if you couldn't just set that flag in C++ on unsigned char/std::byte
> >>> arrays (and on anything with that attribute), have that imply alias set
> >>> 0 on it and then let the rest of alias machinery handle aggregate types
> >>> containing such fields.
> >>
> >> Yes, I expected it to work like this (didn't look at the patch yet).
> 
> My impression is that this is how GCC 6 worked, but GCC 7 decides to
> ignore alias set 0 members.  Is that right?

Yes, in GCC 6 an access via an aggregate type that had an alias-set zero
member was using alias-set zero.

So we'd re-instantiate that behavior for aggregates containing
a type marked with the proposed new flag.

> > I want to allow *only* what the C++ standard requires or what Jason says
> > of course :), and not a single bit more, because it suppresses otherwise
> > correct optimizations.
> >
> > So a struct with a std::byte member is not alias_set 0,
> > only the std::byte itself is, but an array of std::byte
> > is itself typeless_storage, and makes the whole structure
> > also typeless_storage
> 
> Well, only the array member, not the whole structure, but it may make
> sense for GCC to treat the whole structure as such internally.

Yes, it's the easiest way to implement the required behavior.  But
I wouldn't document it that way but clearly state that only the
marked member behaves so but that for the purpose of accesses via
a container type the standards access rules apply as if the member
is accessed with a character type.

Richard.



More information about the Gcc-patches mailing list