gcc-12.4 targeting arm64 bootstrap with Xcode 16 (macOS 15): “error: ‘_Float16’ does not name a type” #24
Comments
|
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? |
|
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). |
|
(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) |
|
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. |
Not sure why that is - although x86 did get the float16 support first. |
|
My previous comment got partially chewed up. Here’s what it should read:
|
"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. |
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: I can also do a little arithmetic and then (after converting to |
|
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). |
|
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. |
Interesting. linux-arm64 behaves the same way: C knows the type, and C++ does not. This is https://github.com/gcc-mirror/gcc/commits/releases/gcc-12/ at gcc-mirror/gcc@917b6c6. |
|
Ah, here we go! gcc-mirror/gcc b04208895fed gcc/c-family/c-common.cc, in 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. |
|
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 Instead, markmentovai/gcc@8708938 shows a fixincludes hack to wrap the uses of In this case, I’ve limited it to 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 |
|
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. |
|
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... |
|
plus I am assuming that the same thing will happen on GCC-11, which is needed as the bootstrap for D. |
|
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. |
|
Your thought process mimics my own. At #24 (comment), I thought it best to just make
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
Yeah, this is the problem. gcc-mirror/gcc@b042088 does a bunch more than just |
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. |
|
I think that this is now OK with what's currently pushed |
@iains , I actually ran into this today trying to build off this commit:
13.3 seems to work fine at any rate. |
you do not need what is this $SYSROOT/usr/include is the default include path - so you might well just be confusing the configure process. I'd suggest re-trying with that removed... Putting in non-standard configuration options can be necessary - but unless there's a good (preferably documented) reason - it's usually more harmful than helpful.
... if that still does not work, please post the error output so that I can repeat/debug, thanks |
It seemed to be necessary in an old gcc config when I was cross-compiling so I've been including it by default, but indeed, it doesn't seem necessary. That being said: Let me know if I'm missing anything. |
Ehm .. that is not correct - I added the comment to the wrong Issue, sorry. It looks like we still need to find a solution here (I really want to avoid adding more fixincludes, since SDK changes tend to break them - and that has been a pain point recently). |
|
Understood. I just saw your comment and wanted to note it was still occurring. (In my case, I was just experimenting with the 12 branch, but since the 13 one seems to work, I can work just fine with that) |
|
OK; (one issue for me is limited arm64 hardware, so it has to multiplex between development and testing) update: So this branch bootstraps fine on x86_64-darwin24 (macOS Sequoia) using SDK 15 (Xcode CLT 16.1) #include <cmath>
int main ()
{
_Float16 f = 0.0;
}
.. so the provisions made by x86_64 (without back-porting the large patch mentioned earlier) seem to be enough. I confirm that the issue is still present on Arm64, let's investigate making the same provisions as x86_64. We really need to have 11.5 bootstrapping too - since that is the last version that can build D without an existing D compiler ... so whatever we do here, I will likely also apply to 11.5 (and maybe 10.5). |
|
please try 99533d9 and let me know if you still see issues. @markmentovai - I prefer this solution over fixincludes because we are now trying (very) hard to reduce the number of fixincludes - because of the difficulties we face with incompatibilities between fixes in different SDK versions. This patch is local to macOS and self-contained in the arm64 backend (it follows the same basic idea as x86_64 which has been in use for sometime - upstream too). |
|
I will be testing this on 11.5-darwin too (but will comment there when that's done). If this work for you folks - I'd like to issue a 12.4-darwin-r1 rolling up the changes to support macOS 15 / Xcode 16. |
|
It's enough to get gcc to accept the Using it is a different story. If I remember, the reason I didn't do this (expose #24 (comment) was the relevant part of the conversation. |
It's what's required to make the _Float16 type name available - the actual type HFtype has been available for some time - we are just publishing a user-visible type name for it.
What do you mean "different semantics"?
It must not break ABI - since the [Apple] darwinpcs specifies that the float format for 16 bit floats is IEEE754 (a.k.a. _Float16/__fp16) - we already have all this on GCC-13, 14 and trunk... [M3/4 also support bfloat16, but that's not the subject of this change]. Of course, one has to make sure that the mangling matches with what was agreed between GCC and clang (which this patch does). There's also strategy: fixing issues that might arise with supporting _Float16 on gcc-12/11 - can be done once .. fixing issues with SDK changes is a forever problem. FWIW: I compared a couple of small (scalar code) examples with the code generated by clang and the output was essentially the same.
We do not want to merge the larger patch, for sure, it is not needed (at least not at this point - and so far Apple have not used a longer float type than 64b). We are between a rock and a hard place here - we can expect more changes of this nature in the SDKs .. and we still need to support an early enough GCC to bootstrap D (which is essentially GCC-11). |
|
(and don't forget that you have been able to use this same _Float16 from C for some time - including making any libc calls relevant - we're not inventing something new - the ABI lowering code works on HFmode, not on the user-visible type names ). |
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:
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
_Float16in C mode:but not in C++ mode:
@iains
The text was updated successfully, but these errors were encountered: