This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add a new type attribute always_alias (PR79671)
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Jakub Jelinek <jakub at redhat dot com>, "GCC Patches" <gcc-patches at gcc dot gnu dot org>, Marc Glisse <marc dot glisse at inria dot fr>, Jonathan Wakely <jwakely at redhat dot com>, Jeff Law <law at redhat dot com>
- Date: Wed, 5 Apr 2017 20:46:27 +0000
- Subject: Re: [PATCH] Add a new type attribute always_alias (PR79671)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de;
- References: <AM4PR0701MB216292327A207737064C3CA3E40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <20170405132832.GS17461@tucnak> <E33F8D97-47E5-4836-8633-D44406BDF10A@suse.de> <AM4PR0701MB21627566C67EB9B4CB0F501FE40A0@AM4PR0701MB2162.eurprd07.prod.outlook.com> <CADzB+2kGSL=yLDARcrXW2cAafEZC2Q84kTd0tjyALrLiRpqTRg@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 04/05/17 22:17, 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?
>
This is how I always thought it worked, until Jakub pointed out that
it is documented differently:
@item may_alias
@cindex @code{may_alias} type attribute
Accesses through pointers to types with this attribute are not subject
to type-based alias analysis, but are instead assumed to be able to
alias any other type of objects.
In the context of section 6.5 paragraph 7 of the C99 standard,
an lvalue expression dereferencing such a pointer is treated like
having a character type.
=> So nobody said anything about accesses without pointers.
>> 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, that is only as close as I can get in the moment.
It does the same as may_alias but additionally objects
declared with that type have alias set 0, I just don't
know if I have yet found the right words so that it can
be understood. Based on the feedback I have now written:
+@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.
Bernd.