https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122483
--- Comment #30 from Alex Coplan <acoplan at gcc dot gnu.org> --- 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. 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). So I'm leaning towards the first option, but I'm happy to be persuaded either way; thoughts? Otherwise I will work on the first approach for now.
