https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |jsm28 at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If not copying over the attribute is intentional when it isn't builtin, we
could still copy over just the single attribute, like:
--- gcc/c/c-decl.c.jj 2021-03-16 00:21:29.464233163 +0100
+++ gcc/c/c-decl.c 2021-04-08 18:19:24.762093841 +0200
@@ -3268,6 +3268,17 @@ pushdecl (tree x)
thistype
= build_type_attribute_variant (thistype,
TYPE_ATTRIBUTES (b->u.type));
+ else if (!lookup_attribute ("access", TYPE_ATTRIBUTES (thistype)))
+ if (tree access = lookup_attribute ("access",
+ TYPE_ATTRIBUTES (b->u.type)))
+ {
+ /* Otherwise, copy over the access attribute. */
+ tree attr = tree_cons (TREE_PURPOSE (access),
+ TREE_VALUE (access),
+ TYPE_ATTRIBUTES (thistype));
+ thistype
+ = build_type_attribute_variant (thistype, attr);
+ }
TREE_TYPE (b->decl) = thistype;
bind (name, b->decl, scope, /*invisible=*/false, /*nested=*/true,
locus);
Except that the access attribute unfortunately seems to mean a lot of different
things, it is a user attribute with some arguments that is later rewritten into
a different form and that other form is reused also for the array parameters
and the -Warray-parameter stuff using that.
So, if both decls of f1 should have different attributes, then doing the above
is undesirable because it would also result in user's access attributes being
copied over, or that for user access attribute on the second declaration would
result in it not being copied.
Perhaps we can copy the attribute under a different attribute name (something
with space in it so that it isn't user accessible) and use that for
-Warray-parameter purposes in preference over "access"?
Also, I'd argue that the rewritten "access" attribute shouldn't be called
"access" but with some internal name.
