https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122483
--- Comment #31 from Richard Sandiford <rsandifo at gcc dot gnu.org> --- (In reply to Alex Coplan from comment #30) > So having looked at this more closely, I think the behaviour we want for > aarch64 is that we don't allow any type attributes to be merged into a > subsequent (otherwise duplicate) decl without attributes if any of the > attributes in the first decl have affects_type_identity set. Yeah, I agree that that seems to be the case FWIW. > In terms of a design for a target hook, it therefore feels tempting to > expose this as (say): > > bool targetm.strong_affects_type_identity_p (); > > which would default to false and aarch64 would set to true. If this returns > true, we would then reject the attribute inheritance in duplicate_decls in > the C FE, if any of the attributes in TYPE_ATTRIBUTES have > affects_type_identity set. > > The other approach is to allow passing down a specific attribute, which > gives the backend more fine-grained control, but I believe isn't actually > necessary for what we want on aarch64, i.e. something like: > > bool targetm.can_inherit_type_attribute_p (const_tree attr); > > It seems somewhat pointless for the FE to query this hook only for the > backend to simply lookup the attribute_spec and check the > affects_type_identity flag (which could have been done in the front-end). Yeah. And since we wouldn't want to allow the new hook to force “strong” type agreement when affects_type_identity is false, the caller would presumably be expected to check that first, which in turn means that the caller would have access to the attribute spec. If we still wanted the hook to have attribute-level control, the question would then be whether the attribute should be identified by the spec, by the tree, or by both. And it's difficult to choose if aarch64 doesn't care. So I agree it seems simpler to pass no arguments in the first instance. That said, perhaps a simpler approach would be define a new return type for TARGET_COMP_TYPE_ATTRIBUTES. E.g. -1 could mean that the type attributes are “strongly” incompatible and mustn't be merged. I can't remember whether that's already been discussed.
