gcc-12.4 targeting arm64 bootstrap with Xcode 16 (macOS 15): “error: ‘_Float16’ does not name a type”

[markmentovai]

This is on mac-arm64 running macOS 15.0 24A335 with Xcode 16.0 16A242d. I expect that this would also occur targeting mac-arm64 on macOS 14 as long as Xcode 16 is used.

While bootstrapping gcc-12.4 from iains/gcc-12-branch gcc-12-4-darwin at gcc-12.4-darwin-r0:

libtool: compile:  ${BUILD}/./gcc/xgcc -shared-libgcc -B${BUILD}/./gcc -nostdinc++ -L${BUILD}/aarch64-apple-darwin24/libstdc++-v3/src -L${BUILD}/aarch64-apple-darwin24/libstdc++-v3/src/.libs -L${BUILD}/aarch64-apple-darwin24/libstdc++-v3/libsupc++/.libs -B${PREFIX}/aarch64-apple-darwin24/bin/ -B${PREFIX}/aarch64-apple-darwin24/lib/ -isystem ${PREFIX}/aarch64-apple-darwin24/include -isystem ${PREFIX}/aarch64-apple-darwin24/sys-include -I${SRC}/libstdc++-v3/../libgcc -I${BUILD}/aarch64-apple-darwin24/libstdc++-v3/include/aarch64-apple-darwin24 -I${BUILD}/aarch64-apple-darwin24/libstdc++-v3/include -I${SRC}/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=complex_io.lo -g -O2 -c ../../../../../gcc/libstdc++-v3/src/c++98/complex_io.cc  -fno-common -DPIC -D_GLIBCXX_SHARED -o complex_io.o
In file included from ${BUILD}/aarch64-apple-darwin24/libstdc++-v3/include/cmath:45,
                 from ${BUILD}/aarch64-apple-darwin24/libstdc++-v3/include/complex:44,
                 from ../../../../../gcc/libstdc++-v3/src/c++98/complex_io.cc:2:
${BUILD}/./gcc/include-fixed/math.h:629:8: error: ‘_Float16’ does not name a type
  629 | extern _Float16 __fabsf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:630:8: error: ‘_Float16’ does not name a type
  630 | extern _Float16 __hypotf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:631:8: error: ‘_Float16’ does not name a type
  631 | extern _Float16 __sqrtf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:632:8: error: ‘_Float16’ does not name a type
  632 | extern _Float16 __ceilf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:633:8: error: ‘_Float16’ does not name a type
  633 | extern _Float16 __floorf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:634:8: error: ‘_Float16’ does not name a type
  634 | extern _Float16 __rintf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:635:8: error: ‘_Float16’ does not name a type
  635 | extern _Float16 __roundf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:636:8: error: ‘_Float16’ does not name a type
  636 | extern _Float16 __truncf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:637:8: error: ‘_Float16’ does not name a type
  637 | extern _Float16 __copysignf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:638:8: error: ‘_Float16’ does not name a type
  638 | extern _Float16 __nextafterf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:639:8: error: ‘_Float16’ does not name a type
  639 | extern _Float16 __fmaxf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:640:8: error: ‘_Float16’ does not name a type
  640 | extern _Float16 __fminf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
${BUILD}/./gcc/include-fixed/math.h:641:8: error: ‘_Float16’ does not name a type
  641 | extern _Float16 __fmaf16(_Float16, _Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0));
      |        ^~~~~~~~
make[5]: *** [complex_io.lo] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libstdc++-v3] Error 2
make: *** [all] Error 2

This does not occur when using gcc-12.4 (mainline) targeting x86_64.

This does not occur when using gcc-13.3 or gcc-14.2 (your branches) targeting arm64.

The compiler being built does recognize _Float16 in C mode:

mark@arm-and-hammer zsh% ${BUILD}/./gcc/xgcc -B${BUILD}/./gcc -x c -S -o - - <<< '_Float16 f;'
	.arch armv8.4-a+fp16+sb+ssbs
	.build_version macos,  15, 0
	.text
	.globl _f
	.zerofill __DATA,__common,_f,2,1
	.ident	"GCC: (GNU) 12.4.0"
	.subsections_via_symbols

but not in C++ mode:

mark@arm-and-hammer zsh% ${BUILD}/./gcc/xgcc -B${BUILD}/./gcc -x c++ -S -o - - <<< '_Float16 f;'
	.arch armv8.4-a+fp16+sb+ssbs
	.build_version macos,  15, 0
<stdin>:1:1: error: ‘_Float16’ does not name a type

@iains

[iains]

Perhaps the support was not added upstream at that point (I do not think we make any darwin-specific provisions for _Float16 - only for float 128.)

This will need some archeology to see what's missing - is there a work-around that you are aware of?

[markmentovai]

Still looking for the problem. I think it's very telling that it works for C but not C++.

[iains]

Still looking for the problem. I think it's very telling that it works for C but not C++.

AH.... another clang extension I fear (_Float16 is not a C++ type AFAIK).

[iains]

(as an aside .. I think that one of the causes of these cases is that the SDK headers are "system headers" and so have warnings suppressed - which means that things that might otherwise be flagged to the developers as clang extensions creep in - and then we're stuck with them - because the SDKs are "in the wild" and cannot be changed)

[iains]

confirmed: We support _Float16 (std::float16) from GCC-13 .. if this is a show-stopper, we'll have to see what would need back porting to fix it.

[markmentovai]

#24 (comment):

AH.... another clang extension I fear (_Float16 is not a C++ type AFAIK).

_Float16 works in gcc-12.4 targeting mac-x86_64, though, targeting both C and C++.

Not sure why that is - although x86 did get the float16 support first.

[markmentovai]

My previous comment got partially chewed up. Here’s what it should read:

#24 (comment):

AH.... another clang extension I fear (_Float16 is not a C++ type AFAIK).

_Float16 works in gcc-12.4 targeting mac-x86_64, though, targeting both C and C++.

#24 (comment):

(as an aside .. I think that one of the causes of these cases is that the SDK headers are "system headers" and so have warnings suppressed - which means that things that might otherwise be flagged to the developers as clang extensions creep in - and then we're stuck with them - because the SDKs are "in the wild" and cannot be changed)

‘_Float16’ does not name a type is never a warning, though. This is a hard error if _Float16 isn’t supported, no matter where it appears.

[iains]

My previous comment got partially chewed up. Here’s what it should read:

#24 (comment):

AH.... another clang extension I fear (_Float16 is not a C++ type AFAIK).

_Float16 works in gcc-12.4 targeting mac-x86_64, thoughthough, targeting both C and C++.

"Works" - as in you can use it in a c++ program, or "works" as in the SDK does not require it and so there's no error?

AFAICT we did not add the support until gcc-13.

[markmentovai]

#24 (comment):

"Works" - as in you can use it in a c++ program, or "works" as in the SDK does not require it and so there's no error?

The compiler recognizes the type. This is mac-x86_64 running macOS 14.7, Xcode 16.0, at the HEAD of the releases/gcc-12 branch with a fix for the libunwind symbols that are no longer in the SDK:

mark@thingamajigger zsh% ${PREFIX}/bin/gcc -x c++ -S -o - - <<< '_Float16 f;'
	.build_version macos,  14, 0
	.text
	.globl _f
	.zerofill __DATA,__common,_f,2,1
	.ident	"GCC: (GNU) 12.4.1 20240923"
	.subsections_via_symbols

I can also do a little arithmetic and then (after converting to float) printf it successfully.

[iains]

OK. that's interesting; support for types is arch-dependent (but you mentioned that _Float16 works for Arm64 with C but not C++) .. so that implies the base support is there - I think I will need to do a build on Linux and repeat the experiment there; as noted, we have not (intentionally, at least) made any changes to _Float16 for the darwin port).

[iains]

OK.. I can confirm the observation (without needing xcode16 installed). Now I need to find out if this is an upstream (aarch64) issue or something we've somehow unintentionally introduced.

x86 does do things differently - on macOS (at least on the i5 box I have macOS14.7 on) there's no h/w fp16 support - and so it's done in soft-float for both gcc-12 and 13 (and is the same for c and c++) .. whereas the Arm64 port is using native fp16 inns.

[markmentovai]

#24 (comment):

OK. that's interesting; support for types is arch-dependent (but you mentioned that _Float16 works for Arm64 with C but not C++) .. so that implies the base support is there - I think I will need to do a build on Linux and repeat the experiment there; as noted, we have not (intentionally, at least) made any changes to _Float16 for the darwin port).

Interesting. linux-arm64 behaves the same way: C knows the type, and C++ does not.

mark@adsb zsh% uname -sm
Linux aarch64
mark@adsb zsh% ${PREFIX}/bin/gcc -x c -S -o - - <<< '_Float16 f;'
	.arch armv8-a
	.file	"<stdin>"
	.text
	.global	f
	.bss
	.align	1
	.type	f, %object
	.size	f, 2
f:
	.zero	2
	.ident	"GCC: (GNU) 12.4.1 20240923"
	.section	.note.GNU-stack,"",@progbits
mark@adsb zsh% ${PREFIX}/bin/gcc -x c++ -S -o - - <<< '_Float16 f;'
	.arch armv8-a
	.file	"<stdin>"
<stdin>:1:1: error: '_Float16' does not name a type

This is https://github.com/gcc-mirror/gcc/commits/releases/gcc-12/ at gcc-mirror/gcc@917b6c6.

[markmentovai]

Ah, here we go!

gcc-mirror/gcc b04208895fed gcc/c-family/c-common.cc, in c_common_reswords, moved _Float16’s c_common_resword::disable mask from D_CONLY to 0. That has the effect of enabling _Float16 for C++, effective in gcc-13.

That’s in generic common code. As you point out, x86_64 does its own thing. Here it is even as it exists on the releases/gcc-12 branch.

[markmentovai]

It’d take some effort to backport gcc-mirror/gcc@b042088 to GCC 12, and I’m not sure if there were follow-ups required. It seems ill-advised to introduce generic _Float16 support to C++ in GCC 12, which doesn’t ordinarily provide it.

Instead, markmentovai/gcc@8708938 shows a fixincludes hack to wrap the uses of _Float16 in the macOS 15 SDK’s <math.h> inside #ifndef __cplusplus guards.

In this case, I’ve limited it to *-*-darwin*, because although I’ve noted that GCC 12 targeting x86_64 does offer _Float16 in C++, I’ve also taken note of the “backwards incompatibility at least on x86” verbiage in the commit message at gcc-mirror/gcc@b042088. Nevertheless, it would be defensible to scope this to just aarch64-*-darwin*, or to structure the guards as #if !defined(__cplusplus) || defined(__x86_64__). (I acknowledge that GCC 12 targeting 32-bit x86, with SSE2 enabled, will also make _Float16 available in C++ mode, but don’t deem it necessary to handle this case as the macOS 15 SDK cannot be used to target 32-bit x86.)

With this fix and the fix described at iains/gcc-darwin-arm64#137, I’m able to build iains/gcc-12-branch gcc-12-4-darwin for macOS 15 on arm64; gcc-mirror/gcc@33ccc13 is also necessary for -pipe to work.

[iains]

I totally agree that the _Float16 patch is a big one (I did not yet see how much of it is actually needed)

It is, however, terribly sad to add new fixincludes when we've been trying hard to reduce them as much as possible (since they have caused other issues for downstream, including macports)

@fxcoudert - I'd welcome your input too.

[fxcoudert]

Could we follow the x86_64 route, and define the _Float16 type by hand for the aarch64 target? (I think we were actually doing that in the first version of the ARM support, when Apple Silicon first came out, for _Float128.)

[iains]

Could we follow the x86_64 route, and define the _Float16 type by hand for the aarch64 target? (I think we were actually doing that in the first version of the ARM support, when Apple Silicon first came out, for _Float128.)

If we can make that work (and given that this port will never be upstreamed on GCC-12, so we do not have to convince the Arm maintainers) - that would be nicer than the alternatives. Can we basically clone && update the float128 additions? NOTE; I do not have any time to look at this this week...

[iains]

plus I am assuming that the same thing will happen on GCC-11, which is needed as the bootstrap for D.

[iains]

ah .. maybe that's not the issue here; _Float16 is already enabled - but only for C - the change to allow it for C++ (std::float16) is what the big patch introduced - and the equally big question there is how much of that patch we'd need.

[markmentovai]

Your thought process mimics my own. At #24 (comment), I thought it best to just make _Float16 work for C++. But by #24 (comment), I came to the conclusion that this probably wasn’t a great idea, so I landed on the fixincludes approach that I had initially resisted.

#24 (comment):

plus I am assuming that the same thing will happen on GCC-11, which is needed as the bootstrap for D.

I assumed that gcc-11 was out of support and thus out of scope, but if it’s in fact interesting or relevant, gcc-11 doesn’t have gcc-mirror/gcc@a684121, so when targeting x86_64, it won’t know _Float16 even for C on that branch. The fixincludes approach for gcc-11 would need guards like #if !defined(__x86_64__) && !defined(__cplusplus).

#24 (comment):

ah .. maybe that's not the issue here; _Float16 is already enabled - but only for C - the change to allow it for C++ (std::float16) is what the big patch introduced - and the equally big question there is how much of that patch we'd need.

Yeah, this is the problem. gcc-mirror/gcc@b042088 does a bunch more than just _Float16. I’m not convinced that it’s prudent to backport _Float16 (and potentially more) C++ support to gcc-12 (and possibly gcc-11) just to be able to get the compiler to pass over a handful of declarations in <math.h> that probably nobody’s even expecting to be able to call (if they’re using gcc-12).

[iains]

plus I am assuming that the same thing will happen on GCC-11, which is needed as the bootstrap for D.

I assumed that gcc-11 was out of support and thus out of scope, but if it’s in fact interesting or relevant, gcc-11 doesn’t have gcc-mirror/gcc@a684121, so when targeting x86_64, it won’t know _Float16 even for C on that branch. The fixincludes approach for gcc-11 would need guards like "#if !defined(__x86_64__) && !defined(__cplusplus).

The branch is no longer updated 'upstream' but, like macports and homebrew distros (Linux ones) have 'vendor' branches and tend to ship much older GCC versions as the default (with newer ones as an option).

For Darwin, my intent is to support GCC-10 until we abandon OSX - 10.5..10.8 (since that's the oldest that can be bootstrapped with c++98).

To support the 'D' front end we now need a D compiler, and the last GCC D version that can be built using C++ to start is GCC-11 .. so, even for newer macOS versions, I fear we will be supporting 11.5 for some time.

So - I expect GCC-10.5-darwin and GCC-11.5-darwin to be LTS and will have to have at least the minimum fixes to deal with SDK/XCode issues unless/until we can find a way to cook up our own SDK.