On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in handle_access_attribute (PR 92721) was incomplete and didn't fully resolve the problem (an ICE in the C++ front-end). The attached patch removes the remaining modification that causes the ICE. In addition, the change adjusts checking calls to functions declared with the attribute to scan all its instances.The attached patch was tested on x86_64-linux. I'm puzzled that the ICE only triggers in the C++ front-end and not also in C. The code that issues the internal error is in comptypes() in cp/typeck.c and has this comment: /* The two types are structurally equivalent, but their canonical types were different. This is a failure of the canonical type propagation code.*/ internal_error ("canonical types differ for identical types %qT and %qT", t1, t2); What is "the canonical type propagation code" it refers to?
Generally, code that makes sure that TYPE_CANONICAL equality is equivalent to type identity, not any one specific place.
Is it valid to modify the type in an attribute handler
Only if (flags & ATTR_FLAG_TYPE_IN_PLACE).
If not, and if modifying a type in place is not valid I'd expect decl_attributes to enforce it. I looked for other attribute handlers to see if any also modify the type argument in place (by adding or removing attributes) but couldn't really find any. So if it is invalid I'd like to add such an assertion (probably for GCC 11) but before I do I want to make sure I'm not missing something.
Generally messing with _ATTRIBUTES happens in decl_attributes: changing it directly if it's a DECL or ATTR_FLAG_TYPE_IN_PLACE, otherwise using build_type_attribute_variant. If you need to do it in your handler, you should follow the same pattern.
Jason
