This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]