RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and ALLOW_C_FUNCTION

[Julian Waters]

On Sun, 29 Dec 2024 11:06:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 85:
>> 
>>> 83: #ifdef __clang__
>>> 84: #define FORBID_NORETURN_C_FUNCTION(Signature, Alternative) \
>>> 85:   FORBID_C_FUNCTION(__attribute__((__noreturn__)) Signature, Alternative)
>> 
>> clang isn't the only one that makes a distinction between [[gnu::noreturn]] and [[noreturn]], gcc does too. It's a little strange that gcc doesn't face this same issue
>
> I don't know what `[[gnu::noreturn]]` has to do with this?  And in what way does gcc treat them differently?

[[gnu::noreturn]] is equal to __attribute__((noreturn)), I just referred to it as its scoped attribute form to make it clear that I wasn't talking about the Standard noreturn. There is funnily enough no documentation on how gcc treats them differently, I only learnt that it does while reading through gcc's source code one day


/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
	 but no longer: we have to be able to tell [[noreturn]] and
	 __attribute__((noreturn)) apart.
	 Similarly for C++14 deprecated attribute, we need to emit extra
	 diagnostics for [[deprecated]] compared to [[gnu::deprecated]].  */
      /* C++17 fallthrough attribute is equivalent to GNU's.  */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899281479