https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796
--- Comment #14 from Bruno Haible <bruno at clisp dot org> --- (In reply to Joseph S. Myers from comment #13) > Everything available with __attribute__ is also available with [[]]; > __attribute__((foo)) is [[gnu::foo]]. Indeed, according to https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Attribute-Syntax.html that's a new feature of GCC 14. It is not mentioned in https://gcc.gnu.org/gcc-14/changes.html, though. Can it still be added to that page, or is it too late for that? > You *do* need to ensure that the > [[gnu::foo]] is placed in the right syntactic position for the entity > appertained to, because laxity in positioning only ever applies with > __attribute__ syntax, not with [[]] syntax. The documentation says "Refer to the relevant language standards for exact details on the placement of ‘[[]]’ attributes within your code". And the problem here is that this placement depends on the language: [[__deprecated__]] extern int a, b, c; is valid in C but [[__deprecated__]] extern "C" int a, b, c; is a syntax error in C++. Whereas extern [[__deprecated__]] int a, b, c; is a syntax error in C but extern "C" [[__deprecated__]] int a, b, c; is valid in C++. Similarly for function declarations and 'static inline' function definitions. How did the standards authors imagine that we write .h files that can be used from C and C++, without #if nor macros?
