Issues with API_AVAILABLE macro (Error: attributes are not allowed on a function-definition)

[saschasc]

I am trying to upgrade gRPC on macOS (aarch64 and Intel). Currently, I am using Sonoma and the newest available gcc 14.2.0 version from Homebrew.

I am using the XCode Command Line Tools (CLT) 15.3. I read somewhere that it is crucial that the fixes have to match the CLT version which was used to build it which also makes sense since the fixes need to match. So I am not sure how to find out, if CLT 15.3 is the right one to take.

I also tried CLT 16.0 with the Homebrew version, but when reading other issues, I assume I would need to wait for an updated Homebrew version or compile one by myself. Looking forward for CLT 16.0 support. I appreciate all the work you invest to support gcc! ❤️

I read somewhere that the fixes for availability handling were removed. But now I am unsure what the issue could be and looking for support. At least for me the error messages look related.

Here an excerpt from the build log:

In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/Availability.h:177,
                 from /Users/user/.conan/data/grpc/1.65.0/_/_/build/07bef171607f761fa75f583232d92bcc7c48b3d3/src/include/grpc/support/port_platform.h:266,
                 from /Users/user/.conan/data/grpc/1.65.0/_/_/build/07bef171607f761fa75f583232d92bcc7c48b3d3/src/src/core/lib/event_engine/cf_engine/cf_engine.cc:15:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:70: error: attributes are not allowed on a function-definition
  126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:70: error: attributes are not allowed on a function-definition
  127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (16 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:69: error: attributes are not allowed on a function-definition
  128 | CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(n << 24));}
      |                                                                     ^~~~~~~~~~~~~

[iains]

I am trying to upgrade gRPC on macOS (aarch64 and Intel). Currently, I am using Sonoma and the newest available gcc 14.2.0 version from Homebrew.

I am using the XCode Command Line Tools (CLT) 15.3. I read somewhere that it is crucial that the fixes have to match the CLT version which was used to build it which also makes sense since the fixes need to match. So I am not sure how to find out, if CLT 15.3 is the right one to take.

I also tried CLT 16.0 with the Homebrew version, but when reading other issues, I assume I would need to wait for an updated Homebrew version or compile one by myself. Looking forward for CLT 16.0 support. I appreciate all the work you invest to support gcc! ❤️

I cannot really comment on the exact situation with HB - you would probably be better to ask a question there.

I read somewhere that the fixes for availability handling were removed. But now I am unsure what the issue could be and looking for support. At least for me the error messages look related.

Yes, they do look related; but certainly the fixincludes for that were removed in b50a053 which corresponds to gcc-14.2-darwin-r1 (but I do not know the exact designation for HB)

Here an excerpt from the build log:

In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/Availability.h:177,
                 from /Users/user/.conan/data/grpc/1.65.0/_/_/build/07bef171607f761fa75f583232d92bcc7c48b3d3/src/include/grpc/support/port_platform.h:266,
                 from /Users/user/.conan/data/grpc/1.65.0/_/_/build/07bef171607f761fa75f583232d92bcc7c48b3d3/src/src/core/lib/event_engine/cf_engine/cf_engine.cc:15:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:70: error: attributes are not allowed on a function-definition
  126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:70: error: attributes are not allowed on a function-definition
  127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (16 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:69: error: attributes are not allowed on a function-definition
  128 | CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(n << 24));}
      |                                                                     ^~~~~~~~~~~~~

[saschasc]

OK, fair enough. I thought you would be in close contact with the Homebrew maintainers and/or even contributing directly there.

Can I see somehow which CLT were used to create a specific gcc HB version if not compiled by myself?

Yes, they do look related; but certainly the fixincludes for that were removed in https://github.com/iains/gcc-14-branch/commit/b50a0534fd2b8abfa298501f90cc019e797cbf59 which corresponds to gcc-14.2-darwin-r1 (but I do not know the exact designation for HB)

In other words you would not expect such errors when using gcc-14.2-darwin-r1 or gcc-14.2-darwin?

As far as I can see the changes from https://github.com/iains/gcc-14-branch/commit/b50a0534fd2b8abfa298501f90cc019e797cbf59 are also applied to the HB version (https://raw.githubusercontent.com/Homebrew/formula-patches/d5dcb918a951b2dcf2d7702db75eb29ef144f614/gcc/gcc-14.2.0.diff).

[iains]

OK, fair enough. I thought you would be in close contact with the Homebrew maintainers and/or even contributing directly there.

We are on close contact :) @fxcoudert is closely involved with the branches here - but what is done by the various "downstream" distributions is their call.

Can I see somehow which CLT were used to create a specific gcc HB version if not compiled by myself?

For any GCC you can see the configured sysroot with gcc --print-sysroot

Unfortunately, if that is /Library/Developer/CommandLineTools/SDKs/MacOS.sdk that does not actually tell you the version - and you need to ask the distribution folks.

Yes, they do look related; but certainly the fixincludes for that were removed in b50a053 which corresponds to gcc-14.2-darwin-r1 (but I do not know the exact designation for HB)

In other words you would not expect such errors when using gcc-14.2-darwin-r1 or gcc-14.2-darwin?

As far as I can see the changes from b50a053 are also applied to the HB version (https://raw.githubusercontent.com/Homebrew/formula-patches/d5dcb918a951b2dcf2d7702db75eb29ef144f614/gcc/gcc-14.2.0.diff).

Well .. I cannot be 100% certain without more checking - but what you showed looked pretty much like the same symptom - and, yes, I was under the impression that particular issue was resolved.

You might double-check your CLT installation and make sure that all the symlinks point to somewhere expected?

[saschasc]

Regarding ...

gcc --print-sysroot

It shows the /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk but the minor is missing. @fxcoudert Would it be possible to include this information on homebrew as text and also use a more specific sysroot when building with the CI?

You might double-check your CLT installation and make sure that all the symlinks point to somewhere expected? Yes, symlinks etc. should all be fine.

@iains Could you verify if this minimal as possible sample works on your side with the newest patches? CoreFoundation is included in several important projects (e.g. gRPC).

% cat test.cpp
#include <CoreFoundation/CFUserNotification.h>

int main() {
    return 0;
}

g++-14 test.cpp

In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/Availability.h:177,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFAvailability.h:20,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:21,
                 from /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:13,
                 from test.cpp:1:
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:70: error: attributes are not allowed on a function-definition
  126 | CF_INLINE CFOptionFlags CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:70: error: attributes are not allowed on a function-definition
  127 | CF_INLINE CFOptionFlags CFUserNotificationSecureTextField(CFIndex i) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (16 + i)));}
      |                                                                      ^~~~~~~~~~~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:69: error: attributes are not allowed on a function-definition
  128 | CF_INLINE CFOptionFlags CFUserNotificationPopUpSelection(CFIndex n) API_AVAILABLE(macos(10.0)) API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(n << 24));}

And the MacOSX14.sdk is linking to the MacOSX14.4.sdk (/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -> MacOSX14.4.sdk). The one I used to build gcc from source. I didn't succeed in building your branch. But I assume that the r1 patches should be included in the Homebrew recipe. @fxcoudert Is somewhere documented how you create the diff file for the Homebrew gcc recipe. It seems only to have a subset of the changes from iains branch.

[iains]

Regarding ...

gcc --print-sysroot

It shows the /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk but the minor is missing. @fxcoudert Would it be possible to include this information on homebrew as text and also use a more specific sysroot when building with the CI?

FWIW, I do not think that should be necessary - we ought to have compatibility within a major version ..

@iains Could you verify if this minimal as possible sample works on your side with the newest patches? CoreFoundation is included in several important projects (e.g. gRPC).

% cat test.cpp
#include <CoreFoundation/CFUserNotification.h>

int main() {
    return 0;
}

No. this fails for me too - because it's a genuine complaint :(

In GCC, attributes are not allowed in that position on a function definition (IIRC, you can put them before the type - but no later). This is an incompatibility between what clang accepts and what GCC accepts (and TBH clang is supposed to be implementing compatible GNU attributes).

As usual, we are between a rock and a hard place ..

• without 'attribute((availability...))` support we cannot parse some of the SDK ..
• with it we now have an error where the SDK misplaces an attribute.

At the moment, I have no work-around .... let me think some more.

[iains]

re...

.@fxcoudert Is somewhere documented how you create the diff file for the Homebrew gcc recipe. It seems only to have a subset of the changes from iains branch.

NOTE: there are new patches on this branch that are under test (and we have not yet released 14.2-darwin-r2 because more testing is needed .. so it's quite likely that any patch after 14.2-darwin-r1 will not yet be in HB).

[iains]

@iains Could you verify if this minimal as possible sample works on your side with the newest patches? CoreFoundation is included in several important projects (e.g. gRPC).

% cat test.cpp
#include <CoreFoundation/CFUserNotification.h>

int main() {
    return 0;
}

No. this fails for me too - because it's a genuine complaint :(

In GCC, attributes are not allowed in that position on a function definition (IIRC, you can put them before the type - but no later). This is an incompatibility between what clang accepts and what GCC accepts (and TBH clang is supposed to be implementing compatible GNU attributes).

As usual, we are between a rock and a hard place ..

• without 'attribute((availability...))` support we cannot parse some of the SDK ..
• with it we now have an error where the SDK misplaces an attribute.

At the moment, I have no work-around .... let me think some more.

I am testing an extension to allow us to accept attributes in this position NOTE this is likely to remain a macOS/Darwin-specific fix indefinitely, since the general feeling is that the handling of GNU attributes is already complex - and the replacement [[]] syntax has better-defined properties.

[saschasc]

re...

.@fxcoudert Is somewhere documented how you create the diff file for the Homebrew gcc recipe. It seems only to have a subset of the changes from iains branch.

NOTE: there are new patches on this branch that are under test (and we have not yet released 14.2-darwin-r2 because more testing is needed .. so it's quite likely that any patch after 14.2-darwin-r1 will not yet be in HB).

Yes, Homebrew seems to be r1. As mentioned above I don't know how @fxcoudert creates the patch, therefore it's a little bit diffiult to verify 100%.

[saschasc]

@iains Could you verify if this minimal as possible sample works on your side with the newest patches? CoreFoundation is included in several important projects (e.g. gRPC).

% cat test.cpp
#include <CoreFoundation/CFUserNotification.h>

int main() {
    return 0;
}

No. this fails for me too - because it's a genuine complaint :( In GCC, attributes are not allowed in that position on a function definition (IIRC, you can put them before the type - but no later). This is an incompatibility between what clang accepts and what GCC accepts (and TBH clang is supposed to be implementing compatible GNU attributes). As usual, we are between a rock and a hard place ..

• without 'attribute((availability...))` support we cannot parse some of the SDK ..
• with it we now have an error where the SDK misplaces an attribute.

At the moment, I have no work-around .... let me think some more.

I am testing an extension to allow us to accept attributes in this position NOTE this is likely to remain a macOS/Darwin-specific fix indefinitely, since the general feeling is that the handling of GNU attributes is already complex - and the replacement [[]] syntax has better-defined properties.

Thank you for investigating and providing the explanations. At least I could reduce it to a minimal example!

I understand the challenges we’re facing. My application supports multiple platforms, using LLVM Clang and GNU GCC on Linux and macOS, and it has many third-party dependencies. So sooner or later CoreFoundation is pulled in.

It would be fantastic to find a solution. I’m also open to a macOS/Darwin-specific fix if that’s feasible. Just let me know if there’s anything you’d like me to test!

• without 'attribute((availability...))` support we cannot parse some of the SDK .. Could this be configured somewhere during compilation of gcc? Like this I could give it at try.

Thanks again for your support. Much appreciated!

[iains]

As usual, we are between a rock and a hard place ..

• without 'attribute((availability...))` support we cannot parse some of the SDK ..
• with it we now have an error where the SDK misplaces an attribute.

I am testing an extension to allow us to accept attributes in this position NOTE this is likely to remain a macOS/Darwin-specific fix indefinitely, since the general feeling is that the handling of GNU attributes is already complex - and the replacement [[]] syntax has better-defined properties.

It would be fantastic to find a solution. I’m also open to a macOS/Darwin-specific fix if that’s feasible. Just let me know if there’s anything you’d like me to test!

• without 'attribute((availability...))` support we cannot parse some of the SDK .. Could this be configured somewhere during compilation of gcc? Like this I could give it at try.

Well - the SDK has to be parsed by the compiler at compile-time - so both the cases need to be handled; we can "fix" some incompatibilities when they are in /usr/include using 'fixincludes' - but that does not work for content in frameworks (and actually brings its own set of issues in making the compiler dependent on the SDK versions)

[iains]

i have just pushed a change that adds a new flag "-fallow-extended-attribute-placement" that is defaulted to 'on' for macOS/Darwin. To implement this means changes to both the C and C++ parsers - so that I think it should be tested as widely as possible (I have tested on i686-darwin17, x86_64-darwin17, x86_64-darwin23, aarch64-darwin21, 23 so far).

Together the the other fixes and back ports, this would be what I propose to make gcc-14.2-darwin-r2...

Please test in your environment. @fxcoudert - likewise, if possible.

[saschasc]

Wow, that sounds awesome! I'm currently a little limited in terms of hardware, as I'm on the road. I am happy to help with testing. Currently only with Intel CPU. I'll get back to you as soon as I've found the time.

[saschasc]

I've tested x86_64-darwin23 with CLT 15.3 (MacOSX14.4.sdk) and I have compiled a whole bunch of libraries like catch2, freeimage, freetype, grpc, gtest, libjpeg-turbo, libpng, libwebp, libzip, onetbb, openjpeg, openssl, protobuf, zlib, ...

I was able to compile gRPC 1.65.0 now without any issues. Hooray 🎉! Also all other libraries compiled like a charm.

libcurl 8.2.1 on the other hand made some issues. As referenced above they have implemented a workaroud in newer version. See here the build log. libcurl.txt

[iains]

I've tested x86_64-darwin23 with CLT 15.3 (MacOSX14.4.sdk) and I have compiled a whole bunch of libraries like catch2, freeimage, freetype, grpc, gtest, libjpeg-turbo, libpng, libwebp, libzip, onetbb, openjpeg, openssl, protobuf, zlib, ...

I was able to compile gRPC 1.65.0 now without any issues. Hooray 🎉! Also all other libraries compiled like a charm.

great!

libcurl 8.2.1 on the other hand made some issues. As referenced above they have implemented a workaroud in newer version. See here the build log. libcurl.txt

I kinda wish folks would report the issue instead of hacking around it (unless there's no other option) - the problem with disabling functionality in one place is it breaks in another...

[iains]

OK so it looks like clang accepts GNU attributes in several places that GCC does not. I will need to find out where in the parser this is handled .. it could take a little while.

[saschasc]

It seems to be integrated into the Parser.cpp. At least there is mentioned [[attrib in one comment. It seems to be rather complex though.

https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/Parser.cpp

[iains]

OK so it looks like clang accepts GNU attributes in several places that GCC does not. I will need to find out where in the parser this is handled .. it could take a little while.

but... this does not actually seem to be the problem ...

I cannot see a definition of __AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15 in the SDK .

. if I provide a -D__AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15=__attribute\(\(availability\(macosx,introduced=10.2,deprecated=10.15\)\)\) on the compile line then it works ..

perhaps the definition is supposed to be built from token concatenation.. I will have to look through the headers to figure that out.

[iains]

@fxcoudert do you have any reports about this?

[iains]

summary for the libcurl issue:

with XC 15.3 / MacOSX14.4.sdk XC 16.1b2 / MacOSX14.5.sdk or MacOSX15.sdk

Fails to compile:

/opt/iains/x86_64-apple-darwin23/gcc-14-2Dr2/bin/gcc /XC/16.1b2/CommandLineTools/SDKs/MacOSX14.5.sdk/System/Library/Frameworks/Security.framework/Headers/SecProtocolTypes.h -isysroot /XC/16.1b2/CommandLineTools/SDKs/MacOSX14.5.sdk  -save-temps -o t.gch 

with ...ocolTypes.h:156:24: error: expected ‘,’ or ‘}’ before ‘__AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15’

Adding:

-D__AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15=__attribute\(\(availability\(macosx,introduced=10.2,deprecated=10.15\)\)\)

makes it succeed.... grepping the SDK for __AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15 finds nothing (at least for me)

[iains]

OK. I think I got to the bottom of this - two things interacting.

1. Although most places in the SDK do not check __has_feature(availability_......) there are some that do
2. We have support for attribute_availability_with_version_underscores but we do not currently advertise the feature (the __has_feature() code is generic .. I can temporarily add to that, but need to find a way to add target-specific entries)

So clang (a) has attribute_availability_with_version_underscores and (b) advertises it. This causes CFAvailability.h to expand a macro to use version underscores.

GCC has the feature, but does not currently advertise it which causes CFAvailability.h to expand a macro to a version that needs __AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15

Perhaps the SDK was not checked with a compiler without the feature, anyway it seems that the fallback #define for __AVAILABILITY_INTERNAL__MAC_10_2_DEP__MAC_10_15 has been omitted - which causes the fail.

Perhaps we should raise a Feedback for the missing #define .. but in the meantime I will arrange to advertise the features we support.

[iains]

I think that the two issues raised here should be resolved now - please test and report back - we can then go ahead with the R2 release...

thanks.

[saschasc]

I tried the first time to compile it with XCLT 16.0, but there are new problems that seem to occur. I will create a new issue for this and retest with XCLT 15.x.

[iains]

I tried the first time to compile it with XCLT 16.0, but there are new problems that seem to occur.

It is always possible that we fix one case - and then that exposes the next...

I will create a new issue for this and retest with XCLT 15.x.

thanks.

(I am testing the current branch across OS versions - but not including XC16 or macOS 15 - however XC15 + macOS 14 are included)

[saschasc]

I think it is independent of the attributes issue. For more infos see issue https://github.com/iains/gcc-14-branch/issues/14

[saschasc]

I will try to test it again with XCLT 15.3 and report back later.

[iains]

fixed in gcc-14.2-darwin-r2

[saschasc]

I think that the two issues raised here should be resolved now - please test and report back - we can then go ahead with the R2 release...

I need to check again, but I think that the older libcurl version still has some problems. Since the main issue has been resolved I would create a new issue for it since only partially related to the original issue with the Availability.h include.

Thank you for the great support. Much appreciated!

[iains]

I think that the two issues raised here should be resolved now - please test and report back - we can then go ahead with the R2 release...

I need to check again, but I think that the older libcurl version still has some problems. Since the main issue has been resolved I would create a new issue for it since only partially related to the original issue with the Availability.h include.

yes, please - it's good to keep issues separate

[saschasc]

In the meantime, I have been able to successfully test the project with Sonoma and CLT14 and Sequoia and CLT15. Since it has quite some dependencies in it, I just wanted to report it back. Everything works perfectly! Thanks again for the great support ❤️!

The project also compiles on macOS with clang (19.x) and libstdc++ from gcc 14.2. I still have linker problems, but only on Apple Silicon with TLS despite using emulated-tls. But I'm still not sure what the problem is and if it is more related to clang or gcc/libstdc++ on Apple Silicon. If it is OK, I would open a new issue if I see that it could somehow be related to gcc.

[iains]

TLS on Arm64 is Issue #1 :) .. it's a question of having some time to implement it...

[cjones051073]

I guess you mean this issue instead https://github.com/iains/gcc-darwin-arm64/issues/1

[iains]

I guess you mean this issue instead iains/gcc-darwin-arm64#1

I do - not sure why the auto-link failed there...

[saschasc]

Thanks for the link. Sure that this would also be related to emulated TLS? Still need to get things sorted and try to create a minimal example.

[iains]

Thanks for the link. Sure that this would also be related to emulated TLS? Still need to get things sorted and try to create a minimal example.

Well you cannot expect to mix native and emulated TLS for the same variable (all TUs that use a given var have to agree on using one mechanism or the other). Otherwise, the two implementations should be independent.

[m-a-v]

For completeness sake. This should have been the same issue: https://stackoverflow.com/questions/78452523/g-works-but-g-14-produces-a-lot-of-errors-on-macos

[m-a-v]

@iains This seems also to be the same issue. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880

Not sure if this has been backported to other GCC versions as well. I let you answer this ;-). At least GCC 14.2 should resolve this issue as well.