[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