[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #11 from GCC Commits --- The releases/gcc-14 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:623aaebc7d755ef8696834bebd14f8eddd88200e commit r14-11713-g623aaebc7d755ef8696834bebd14f8eddd88200e Author: Iain Sandoe Date: Sun Dec 29 23:06:54 2024 + includes, Darwin: Handle modular use for macOS SDKs [PR116827]. Recent changes to the OS SDKs have altered the way in which include guards are used for a number of headers when C++ modules are enabled. Instead of placing the guards in the included header, they are being placed in the including header. This breaks the assumptions in the current GCC stddef.h specifically, that the presence of __PTRDIFF_T and __SIZE_T means that the relevant defs are already made. However in the case of the module-enabled C++ with these SDKs, that is no longer true. stddef.h has a large body of special-cases already, but it seems that the only viable solution here is to add a new one specifically for __APPLE__ and modular code. This fixes around 280 new fails in the modules test-suite; it is needed on all open branches that support modules. PR target/116827 gcc/ChangeLog: * ginclude/stddef.h: Undefine __PTRDIFF_T and __SIZE_T for module- enabled c++ on Darwin/macOS platforms. Signed-off-by: Iain Sandoe (cherry picked from commit 9cf6b52d04df22726d88eef113211b3cc08515de)
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #10 from Iain Sandoe --- fixed on trunk, backports to follow.
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #9 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:9cf6b52d04df22726d88eef113211b3cc08515de commit r15-9499-g9cf6b52d04df22726d88eef113211b3cc08515de Author: Iain Sandoe Date: Sun Dec 29 23:06:54 2024 + includes, Darwin: Handle modular use for macOS SDKs [PR116827]. Recent changes to the OS SDKs have altered the way in which include guards are used for a number of headers when C++ modules are enabled. Instead of placing the guards in the included header, they are being placed in the including header. This breaks the assumptions in the current GCC stddef.h specifically, that the presence of __PTRDIFF_T and __SIZE_T means that the relevant defs are already made. However in the case of the module-enabled C++ with these SDKs, that is no longer true. stddef.h has a large body of special-cases already, but it seems that the only viable solution here is to add a new one specifically for __APPLE__ and modular code. This fixes around 280 new fails in the modules test-suite; it is needed on all open branches that support modules. PR target/116827 gcc/ChangeLog: * ginclude/stddef.h: Undefine __PTRDIFF_T and __SIZE_T for module- enabled c++ on Darwin/macOS platforms. Signed-off-by: Iain Sandoe
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-March/6 ||78908.html Status|NEW |ASSIGNED --- Comment #8 from Iain Sandoe --- patch posted
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #7 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #6) > (In reply to Jonathan Wakely from comment #5) > > > #if defined(__has_feature) && __has_feature(modules) > > > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > > would not compile > > Definitely agree, I had missed that, thanks for highlighting it. Every year > some more examples crop up into the SDKs, and every year I report them. > > Reported the examples in macOS 15.0 SDK as FB15255066 > A copy of that report is available there: > https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > > > It looks like the header now assumes that if __has_feature(modules) is > > true, then they're compiling with Clang. Which is not true because GCC > > supports __has_feature now. > > Before I report this to Apple, I want to have an opinion: Iain, what do you > think is the best fix there? Do we want to suggest Apple not bypass > USE_CLANG_TYPES on GCC? At this point (with no other evidence) it would seem to me to be best if clang-specific stuff used __clang__ in the tests (we do _not_ set that in GCC, whereas testing __GNUC__ needs other checks to disambiguate). We might well want to reconcile or add pp defines to match the clang ones if that is creating problems - but I'd expect the underlying types to be unchanged (since that's going to break ABI otherwise). It's not clear to me yet why the change has been made (sorry this is not probably very helpful)
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #6 from Francois-Xavier Coudert --- (In reply to Jonathan Wakely from comment #5) > > #if defined(__has_feature) && __has_feature(modules) > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > would not compile Definitely agree, I had missed that, thanks for highlighting it. Every year some more examples crop up into the SDKs, and every year I report them. Reported the examples in macOS 15.0 SDK as FB15255066 A copy of that report is available there: https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > It looks like the header now assumes that if __has_feature(modules) is true, > then they're compiling with Clang. Which is not true because GCC supports > __has_feature now. Before I report this to Apple, I want to have an opinion: Iain, what do you think is the best fix there? Do we want to suggest Apple not bypass USE_CLANG_TYPES on GCC?
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #5 from Jonathan Wakely ---
(In reply to Francois-Xavier Coudert from comment #3)
> where that new USE_CLANG_TYPES macro is defined at the top of the file:
>
>
> #if defined(__has_feature) && __has_feature(modules)
This is a bug. If __has_feature is _not_ define, then __has_feature(modules)
would not compile:
hf.c:1:44: error: missing binary operator before token "("
1 | #if defined(__has_feature) && __has_feature(uhoh)
|^
This needs to be reported to Apple. Either they should just assume
__has_feature works and not bother checking if it's defined, or check for it
properly.
> #define USE_CLANG_TYPES 1
> #else
> #define USE_CLANG_TYPES 0
> #endif
It looks like the header now assumes that if __has_feature(modules) is true,
then they're compiling with Clang. Which is not true because GCC supports
__has_feature now.
So I think this needs a fixincludes change for GCC to be able to use these new
SDK headers.
> I'm thoroughly confused by this series of includes, especially as
> __need_ptrdiff_t is never used anywhere in the SDK.
GCC's stddef.h uses it.
[Bug target/116827] New C++ failures in macOS 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827 --- Comment #4 from Francois-Xavier Coudert --- Simple reproducer without any libstdc++ indeed: $ cat a.cpp #include $ g++ a.cpp -fmodule-header
