Diagnose GNU-style attribute differences with GCC

[AaronBallman]

GCC was the initial implementer of the __attribute__(()) extension, which Clang has copied. However, over the years, Clang has diverged from GCC in terms of where we accept the attribute syntactically (we've also diverged in terms of specific attribute implementations, but this issue is specific to the syntax of __attribute__). It would be nice to issue a diagnostic telling users about those divergences, under the -Wgcc-compat warning (or a new warning grouped under that one).

e.g.,

[[]] __attribute__(()) void func1(); // Both accept
__attribute__(()) [[]] void func2(); // Clang accepts, GCC rejects

struct [[]] __attribute__(()) S1 { // Both accept
};
struct __attribute__(()) [[]] S2 { // Clang accepts, GCC rejects
};

https://godbolt.org/z/oq5T55jfE

(We should try to be exhaustive at finding all the places we've diverged, more may exist than what's listed here.)

[pinskia]

Note for GCC, there is a difference between the C and C++ front-ends here. GCC's C++ front-end accepts all of the example here. And there is a GCC bug against the C FE not accepting mixing the 2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796

[AaronBallman]

Note for GCC, there is a difference between the C and C++ front-ends here. GCC's C++ front-end accepts all of the example here. And there is a GCC bug against the C FE not accepting mixing the 2: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108796

Thank you for the reminder about the GCC issue! I had thought that bug was going to be closed because of Joseph's comment about it being intentional behavior. If GCC considers this a bug (which seems plausible given the issue is open), then we should hold off on this diagnostic in Clang.