[C++/66270] another may_alias crash
Nathan Sidwell
nathan@acm.org
Wed May 27 21:26:00 GMT 2015
On 05/27/15 12:20, Jason Merrill wrote:
> On 05/26/2015 03:00 PM, Nathan Sidwell wrote:
>> Ok, so IIUC a canonical pointer to a may_alias type should have TRCAA
>> but a canonical can_alias_all pointer to a non-may_alias type should not
>> have TRCAA? (i.e. one where CAN_ALIAS_ALL was passed true). Or are you
>> saying that no canonical pointers should have TRCAA?
>
> The former: A canonical pointer should have TRCAA if and only if the canonical
> referent is may_alias.
>
>>> Hmm, are you seeing a case where TYPE_CANONICAL (to_type) has the
>>> may_alias attribute?
>>
>> Yes. This occurs when the newly created TRCAA pointer is to a
>> self-canonical type.
>
> Hmm, seems like that's another problem with your testcase: the canonical variant
> of __m256 should not have may_alias. But the canonical variant of a class or
> enum type could still have may_alias, so we still need to handle that case.
I was unclear in my description. The canonical pointer type was being created
with TRCAA set because of the incoming true CAN_ALIAS_ALL parameter. That's
fixed by the patch, so we're all good now.
nathan
More information about the Gcc-patches
mailing list