Re: [WIP RFC] Add support for keyword-based attributes

[Richard Sandiford <richard.sandiford@arm.com>]

Jakub Jelinek <jakub@redhat.com> writes:
> On Fri, Jul 14, 2023 at 04:56:18PM +0100, Richard Sandiford via Gcc-patches 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?
>
> Will defer to C/C++ maintainers, but as you mentioned, there are many
> attributes which really can't be ignored and change behavior significantly.
> vector_size is one of those, mode attribute another,
> no_unique_address another one (changes ABI in various cases),
> the OpenMP attributes (omp::directive, omp::sequence) can change
> behavior if -fopenmp, etc.
> One can easily error with
> #ifdef __has_cpp_attribute
> #if !__has_cpp_attribute (arm::whatever)
> #error arm::whatever attribute unsupported
> #endif
> #else
> #error __has_cpp_attribute unsupported
> #endif

Yeah.  It's easy to detect whether a particular ACLE feature is supported,
since there are predefined macros for each one.  But IMO it's a failing
if we have to recommend that any compilation that uses arm::foo should
also have:

#ifndef __ARM_FEATURE_FOO
#error arm::foo not supported
#endif

It ought to be the compiler's job to diagnose its limitations, rather
than the user's.

The feature macros are more for conditional usage of features, where
there's a fallback available.

I suppose we could say that users have to include a particular header
file before using an attribute, and use a pragma in that header file to
tell the compiler to enable the attribute.  But then there would need to
be a separate header file for each distinct set of attributes (in terms
of historical timeline), which would get ugly.  I'm not sure that it's
better than using keywords, or even whether it's better than predefining
the "keyword" as a macro that expands to a compiler-internal attribute.

Thanks,
Richard