Thanks for the feedback. Nathan Sidwell <nat...@acm.org> writes: > On 7/14/23 11:56, Richard Sandiford wrote: >> Summary: We'd like to be able to specify some attributes using >> keywords, rather than the traditional __attribute__ or [[...]] >> syntax. Would that be OK? >> >> In more detail: >> >> We'd like to add some new target-specific attributes for Arm SME. >> These attributes affect semantics and code generation and so they >> can't simply be ignored. >> >> Traditionally we've done this kind of thing by adding GNU attributes, >> via TARGET_ATTRIBUTE_TABLE in GCC's case. The problem is that both >> GCC and Clang have traditionally only warned about unrecognised GNU >> attributes, rather than raising an error. Older compilers might >> therefore be able to look past some uses of the new attributes and >> still produce object code, even though that object code is almost >> certainly going to be wrong. (The compilers will also emit a default-on >> warning, but that might go unnoticed when building a big project.) >> >> There are some existing attributes that similarly affect semantics >> in ways that cannot be ignored. vector_size is one obvious example. >> But that doesn't make it a good thing. :) >> >> Also, C++ says this for standard [[...]] attributes: >> >> For an attribute-token (including an attribute-scoped-token) >> not specified in this document, the behavior is implementation-defined; >> any such attribute-token that is not recognized by the implementation >> is ignored. >> >> which doubles down on the idea that attributes should not be used >> for necessary semantic information. > > There;s been quite a bit of discussion about the practicalities of that. As > you > say, there are existing, std-specified attributes, [[no_unique_address]] for > instance, that affect user-visible object layout if ignored. > Further, my understanding is that implementation-specific attributes are > permitted to affect program semantics -- they're implementatin extensions. > > IMHO, attributes are the accepted mechanism for what you're describing. > Compilers already have a way of dealing with them -- both parsing and, in > general, representing them. I would be wary of inventing a different > mechanism. > > Have you approached C or C++ std bodies for input?
Not directly, although members of the C++ WG contributed to the discussion on the Clang side. But I'm not sure how much the WG can help. The main constraint here is what existing compilers do, and that can't be changed. Similarly, any future Arm extension that hasn't been invented yet might need new semantic attributes, and those attributes would be ignored by GCC 14, etc. Thanks, Richard
