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/15 21:18, Jason Merrill wrote:
On 05/25/2015 04:55 PM, Nathan Sidwell wrote:

   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.

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?

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. The
 else if (TYPE_CANONICAL (to_type) != to_type)
is false, so the newly created pointer is self-canonical too (and has TRCAA).

If the canonical type should not have TRCAA we need to change the if condition to:
  else if (TYPE_CANONICAL (to_type) != to_type || could_alias_all)

where COULD_ALIAS_ALL is the incoming CAN_ALIAS_ALL value.  Does that make sense?

Making that change does stop the ICE I was seeing, but I've not done a full test yet.

nathan


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