Re: [C++/66270] another may_alias crash

[Jason Merrill <jason@redhat.com>]

On 05/25/2015 04:55 PM, Nathan Sidwell wrote:
> This patch addresses 66270, another case where may_alias disrupted the
> canonical type system.  We ICE as TYPE_CANONICALs differ, but comptypes
> think they are the same.
>
> There seems to be a bit of confusion as to whether pointers that differ
> only in TYPE_REF_CAN_ALIAS_ALL are the same canonical type or not.
>
> Firstly, in tree.c build_pointer_type_for_mode, when the pointed-to type
> is not its own canonical type, that means the newly constructed pointer
> type is (possibly) not canonical either.  So we explicitly build a
> canonical type with:
>
>    else if (TYPE_CANONICAL (to_type) != to_type)
>      TYPE_CANONICAL (t)
>        = build_reference_type_for_mode (TYPE_CANONICAL (to_type),
>                         mode, false);
>
> But we're passing 'false' in as 'can_alias_all', rather than pass the
> value passed into us.

Yes, I actually just changed that a month ago because we were hitting 
this same ICE from a different direction (bug 50800).  Since 
TYPE_CANONICAL (to_type) doesn't have the may_alias attribute, the 
canonical pointer shouldn't have TRCAA.

> That'll make a difference if the caller passed in
> true and to_type doesn't have may_alias set.   This is inconsistent at
> least, because we could sometimes end up with canonical types with
> T_R_C_A_A set (to-type is canonical) and sometimes with it not set.  It
> seems the right solution is to consider T_R_C_A_A as a distinguisher,
> thus we should pass can_alias_all to the canonical type builder.  Note
> that it is ok to pass the possibly modified can_alias_all in, and not
> the incoming value, because we only ever modify it to make it true --
> and in that case the same behavior would happen in the canonical type
> builder because to_type and TYPE_CANONICAL (to_type) should have the
> same may_alias attribute.

Hmm, are you seeing a case where TYPE_CANONICAL (to_type) has the 
may_alias attribute?

> Anyway, that's a bit of collateral confusion I fell over investigating.
> With that out of the way, we have  to teach comptypes that T_R_C_A_A
> affects pointer type equality.  Hence add such a check to POINTER_TYPE
> case there.

Similarly, I removed this check for bug 50800.

Jason