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

[Jason Merrill <jason@redhat.com>]

On Fri, Apr 7, 2017 at 11:32 AM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
> On 04/07/17 17:10, Richard Biener wrote:
>> On April 7, 2017 3:37:30 PM GMT+02:00, Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
>>> On 04/07/17 08:54, Richard Biener wrote:
>>>> On Thu, 6 Apr 2017, Bernd Edlinger wrote:
>>>>> I think get_alias_set(t) will return 0 for typeless_storage
>>>>> types, and therefore has_zero_child will be set anyway.
>>>>> I think both mean the same thing in the end, but it depends on
>>>>> what typeless_storage should actually mean, and we have
>>>>> not yet the same idea about it.
>>>>
>>>> But has_zero_child does not do what we like it to because otherwise
>>>> in the PR using the char[] array member would have worked!
>>>>
>>>> has_zero_child doesn't do that on purpose of course, but this means
>>>> returing alias-set zero for the typeless storage _member_ doesn't
>>>> suffice.
>>>>
>>>
>>> I see you have a certain idea how to solve the C++17 issue.
>>> And yes, I apologize, if I tried to pee on your tree :)
>>
>> We do have the need to support this part of the C++ standard.  For other user code may_alias suffices and I see no reason to haste inventing sth new without a single convincing testcase.  GCC/Language extensions should not be added without a good reason.
>>
>> I didn't propose to expose the type flag to users at all.
>>
>> Richard.
>>
>
> Well, actually you did:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671#c100
>
> But I won't argue if you prefer to do it as you like,
> after all TBAA is your area.  So that is fine for me.
>
> Attached is the latest version of my patch, I fixed
> the issue with the type-flag conversion, and it is
> already fully functional.

I agree that we don't want a new attribute.

This should not be limited to C++17 mode; std::aligned_storage is in
C++11 and we might as well have the same behavior in C++98 mode.

Jason