need to decide on how to support FLOAT*16 for Fortran.

[iains]

Unfortunately, the current arm64 iOS/macOS long double is 64 bit - we need to figure out some reasonable way to give users access to a larger version.

immediate options:

• support IEEE754-128 somehow (soft/hard as possible). This might be a bit painful performance-wise, TBD.
• if performance is an issue, there's always "ibm128 - double double".

[fxcoudert]

From the Fortran point of view: if we have access to binary32 and binary64 floating-point types, not having larger types is not a show-stopper, because:

• There are Fortran codes out there that use 80-bit extended-precision floating-point types, but they are not portable anyway, and compilers have traditionally not been consistent w.r.t. access to such a type.
• Support for binary128 is nice (I am not going to say otherwise, as I was among those who introduced libquadmath and Fortran support for binary128), but… here again, codes using it are the exception, rather than the norm — because not all compilers support it anyway.

[fxcoudert]

Here is the current situation confirmed with a build of 6363793:

• there are 5 integer (and logical) kinds, which I believe is correct: 8, 16, 32, 64 and 128-bit integer types
• there are only 2 real (and complex) kinds: 32 and 64-bit floating-point types

Both the front-end and libgfortran correctly detect and build for those kinds. From my point of view, this is standard-conforming under the Fortran standard.

I note that we could in theory expose _Float16 as a Fortran real and complex kind, but we don't do it on other ARM targets and I do not think there is a real need. And we would need to have math functions for it.

[rhdtownsend]

From the Fortran point of view: if we have access to binary32 and binary64 floating-point types, not having larger types is not a show-stopper, because:

* There are Fortran codes out there that use 80-bit extended-precision floating-point types, but they are not portable anyway, and compilers have traditionally not been consistent w.r.t. access to such a type.

* Support for binary128 is nice (I am not going to say otherwise, as I was among those who introduced libquadmath and Fortran support for binary128), but… here again, codes using it are the exception, rather than the norm — because not all compilers support it anyway.

Given that gcc on x86_64/linux and aarch64/linux supports 128-bit floats, I think it would be very important to offer them on aarch64/darwin. Plus, there are a couple of big codes that I use/develop that rely on quad precision at certain points in the execution path.

[iains]

(as a writer of scientific and signal processing code) I am inclined to agree, there are times when intermediates for a double calc are easier to handle as quads than some numerical gymnastic.

(As a toolchain developer) I have to point out that this is not just something that requires us to write a bit of library code and/or support in the compiler.

Adding a different-size type requires ABI changes, C++ mangling, C++ library support and (in some way) libc support [think, printf]. GCC's Fortran is part of a suite of compilers, that share much common infrastructure.

While we could adopt the [128b long double] ABI as per AAPCS (the aarch64 'official' ABI) .. in fact, Darwin/macOS has a different ABI (darwinpcs) that specifies 64b long double. It would be prudent, at least, to discuss the way forward with the Apple folks.

[stephentyrone]

I'll talk to some folks within Apple and see if we can add an explicit C ABI for _Float128 in the darwinpcs. Speaking personally, double-double is something that no language should foist on users unless they explicitly say they want it. Binding it to FLOAT*16 would be quite unfortunate.

[iains]

(some of) the Apple folks are already aware of the interest.

what would be great is to minimise any additional divergence between the AAPCS and darwinpcs - every such difference is a maintenance burden (my guess is that's equally true for those responsible for maintaining the aarch64 LLVM backend).

At least in terms of CC and type mangling etc that's very highly desirable (of course, if already have [64] libc++ symbols mangled as 'long double' then we will be obliged to use a different mangling for __float128, _Float128 (however it is eventually spelt).

The transition from mlong-double-64 => mlong-double-128 was handled once before at the OS level with libc symbols with $LDBL128 appended. That worked (and continues to work) well on powerpc-darwin (the fact that the underlying implementation of the 128b version is double-double there is academic to the overall presentation of an API).

[iains]

note that if one did use double-double as a stop-gap, it would be mangled __ibm128 for compatibility - so would not actually tread on the toes of a final solution.

It might be instructive to look at how fortran handles the two possible 128 long doubles for powerpc ...

(there are more pressing code-gen issues on my agenda before this one tho, sadly).

[fxcoudert]

Given that aarch64-linux gcc supports TFmode (which it calls long double, as I understand), we should ideally use the same ABI as that (except in our case it would be called _float128).

Nobody wants double-double/ibm128.

[utf]

Hi all. Are there any updates on this issue?

[iains]

no, the priority at the moment is on getting the base port ready for inclusion in gcc-12
We would not be able to do this "unilaterally" anyway - the ABI owner is Apple, so we might make a suggestion (or offer a design) - but they would have to initiate the changes, and I'd imagine that would require a clang implementation as well.

[utf]

Ok, thanks for the update. All your work on this port is very much appreciated.

[jeffhammond]

Is it possible to an a configure option to tell GCC to use int128 as the ABI for binary128? What doesn't work in that scenario?

[fxcoudert]

Is it possible to an a configure option to tell GCC to use int128 as the ABI for binary128? What doesn't work in that scenario?

I think the limitation is not “what do we chose” but “how do we make sure the choices made are consistent”. In a way, Apple “owns” this ABI and we probably cannot decide without them.

[jeffhammond]

Given that Apple doesn't have a Fortran compiler, I don't see how GCC could be inconsistent with their REAL*16 ABI. I also think 15 months is more than enough opportunity for Apple to have contributed here, and their failure to contribute means that the open-source community should be able to solve the problem themselves. Perhaps seeing the ecosystem move on without them will inspire Apple to do something here. It's not like they lack the resources.

[iains]

In a way, Apple “owns” this ABI and we probably cannot decide without them.

• I think this is the critical factor, if there's a demand for 128b float (I would expect that to come at some point), then raising radars with Apple is a good starting point (since the absence affects C-family as well and we would need a coherent change to allow c-bindings to work)
• For my 0.02GBP it would be sad if the chosen ABI diverged more from the AAPCS than we already have, so engaging in the discussion with the Apple ABI folks will also be on my agenda.
• It also needs support from libSystem (libc) for printing etc. and a sensible migration path (e.g. as for the case when PPC migrated from long-double-64 => long-double-128 - we have to attach some discriminator to the builtins and libc calls).

[jeffhammond]

Can we at least converge on the idea that REAL*16 must be equivalent to REAL(kind=REAL128) and this must be binary128, ie that neither long double nor double double is relevant? That means we can connect directly to C/C++ float128.

I think we're mostly here but I figure it's good to be unambiguous.

[iains]

" C/C++ float128 " is defined where and with what ABI?

The version of the darwinpcs I am working from has no 128b float (C long double is 64 bits).

Iff the port transitions to having a 128b float type, then I would expect C long double to be using that ( at least selectively with -mlong-double-128 as is done elsewhere ) .. at some point one would also expect that to become the default and then -mlong-double-64 would be provided as a legacy option.

This is the kind of mechanism that has been used in the past.

It seems that no-one is interested in using double-double, so that is a moot point (although as can be seen with the current PPC64 work, there are strategies for supporting both that and IEEE128 in the same toolchain)

[jeffhammond]

I'm not saying Apple has a C/C++ float128 ABI, I'm merely saying that mapping REAL*16 to that simplifies the problem and gives Apple more of a reason to care.

I don't think long double is worth thinking about. It's a garbage feature of C that exists to expose x87 80-bit floats, and is beyond useless in any other context, because it's not even a platform stable ABI (Linux yes, but not always).

[fxcoudert]

My own take on this:

• No-one wants double-double. Even on PPC64, where this exists, the transition to IEEE128 is painful
• IEEE128 exists, it's there, it's become a real standard, let's use it
• libSystem support is something I would not expect, and that is not relevant for Fortran: we provide our own libraries for printing and math (libquadmath)
• On Intel, there was never any system support for __float128, and people still used it :) so having it on ARM would allow us to reach feature ARM/Intel feature parity, at least

---

Iff the port transitions to having a 128b float type, then I would expect C long double to be using that ( at least selectively with -mlong-double-128 as is done elsewhere )

I disagree with that. On most targets, C long double is equal to double, at least with default options. We should keep it that way, as there may be code that expects it. In fact, I think we have to keep double = long double != __float128, to retain compatibility with ABI and system clang, which treats long double as the same size as double:

$ cat u.c
#include <math.h>
#include <stdio.h>

int main (void) {
  long double x = 2;
  printf("%20.17Lg\n", sqrtl(x));
  printf("%zi\n", sizeof x);
}
$ clang u.c -W -Wall && ./a.out 
  1.4142135623730951
8

Edit, to add clarification on that sqrtl example above: also, I don't think we should or can switch long double to something other than Apple's choice (long double = double), because then the library functions would not match anymore, and that's a nightmare (it happened on powerpc-darwin at some point, and created lot of trouble.

[iains]

Well, I understand that your focus is on Fortran - but some of us transitioned away from Fortran around the same time the VAX 11/785 was retired (not a co-incidence sometimes one has no choice on employer's decisions). We carried on writing numerical analysis, signal processing and simulation code (just now in C) .. if Fortran users have a requirement for 128b float, then so do c-family users ;)

.. clearly, most of the use of aarch64 darwin has been under iOS and therefore has not seen any such desires(?) - but I'd think to move forward, the platform would have to adopt an 128b float type and agree ABI before we could plug it into fortran.

That would mean that clang and the relevant parts of the system would be updated to deal with this; FWIW (despite that you recall pain associated) the approach used for PPC is solid and functional to this day (completely independent of what the 128bits represent).

[iains]

clarification: none of what I've said implies switching from Apple's choice - rather, my thesis is that we have to adhere to Apple's choice - if they elect not to adopt a 128b float (officially) then we might think again - but in the first instance, the right solution is to lobby for an official 128b float type on the platform.

I do not think it significant that no Apple comments have been made on this thread (there is no reason for anyone from Apple to read it).

[jeffhammond]

Well, I understand that your focus is on Fortran

It's my focus here because it's in the title of the issue, and I came here as a result of not being about to build Fortran applications on my Apple M1 laptop.

[jeffhammond]

I do not think it significant that no Apple comments have been made on this thread (there is no reason for anyone from Apple to read it).

That's not correct (#5 (comment)), although I know Steve isn't speaking with institutional authority here.

[iains]

I fear there is an amount of "talking past" going on here...

• Fortran does not exist independently of the rest of the system (even if it is the only thing one uses)

• If we unilaterally adopt some 128b float format, and invent our own ABI (or use that of AAPCS), that might not be what is eventually chosen by Apple - ergo the first step should be to lobby for an official 128b format.

• My preference is strongly for using the same as specified in AAPCS (and with the same ABI) - that means there is least for us to maintain that is "different" for Darwin/Mach-O.

• speaking purely for myself (in c-family), it is a nuisance when long double does not offer any more precision than double quite a lot of code assumes the contrary .. but I guess in the end if it's spelt ___float128 that's just mechanical editing.

[jeffhammond]

If we unilaterally adopt some 128b float format, and invent our own ABI (or use that of AAPCS), that might not be what is eventually chosen by Apple - ergo the first step should be to lobby for an official 128b format.

If Apple declines to respond, does that mean we can never fix this issue for users? I contend that Apple has had their chance to respond, and they have not, so GCC should do the right thing for its users and solve the problem using the best available option. I agree with your arguments that the best non-Apple solution is AAPCS.

I also believe that the only reasonable choice here is REAL*16 = REAL(kind=REAL128) = __float128 = binary128, all with 16 bytes of storage and 16-byte alignment, so I don't see a huge risk of picking this without Apple's involvement. Do we think they are doing to choose something else? What other reasonable options are there?

speaking purely for myself (in c-family), it is a nuisance when long double does not offer any more precision than double quite a lot of code assumes the contrary .. but I guess in the end if it's spelt ___float128 that's just mechanical editing.

On the long double tangent, if I want something well-defined that's wider than binary64, I use binary128, via __float128. I've never seen any evidence for long double to exist except to support x87.

[stephentyrone]

I also believe that the only reasonable choice here is REAL*16 = REAL(kind=REAL128) = __float128 = binary128, all with 16 bytes of storage and 16-byte alignment, so I don't see a huge risk of picking this without Apple's involvement.

This is correct. Furthermore, Tim Northover correctly observed in an email correspondence:

The [Darwin] PCS is pretty much covered by falling back to the ARM AAPCS for anything that's not explicitly mentioned as a difference. The relevant parts are worded in terms of "quad precision floating-point type" rather than "long double".

Similarly, the Itanium ABI provides a mangling for __float128 (it's 'g'). If and when support gets added for C++ it's very unlikely we'd diverge from that.

So there's no need to "invent our own ABI (or use that of AAPCS)"; since the Darwin PCS document does not say anything about quad, the behavior is defined by AAPCS.

[fxcoudert]

it is a nuisance when long double does not offer any more precision than double

@iains unless I misunderstand something, I think that ship has sailed, anyway. Apple's ABI (https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms) explicitly states:

The long double type is a double precision IEEE754 binary floating-point type, which makes it identical to the double type.

[iains]

which is what we implement .. (and does not make any difference to me as a toolchain maintainer)

the comment was from me as a "user" of c-family : I do not see long double as an X87 thing, but then most of my DSP and numerical analysis coding was/is not on X86 platforms, it's still a nuisance to have to edit the source to use a different type for the extra precision. Anyway, we can agree to differ on this ..

• Is there a current working port of libquadmath?

• the priority for me is to get the main port in (so "patches welcome" for this for now).

[jeffhammond]

I don't see why the long double ABI matters here. REAL128 is not long double on most systems. It's certainly not on an x86 or ARM ones.

If Apple has no ABI for binary128 then we fall back on AAPCS.

[fxcoudert]

Is there a current working port of libquadmath?

The libquadmath in GCC is designed to provide quad-precision math and I/O routines on targets for which __float128 is implemented (and is a IEEE binary128 floating-point type).

the priority for me is to get the main port in (so "patches welcome" for this for now).

I'll try to come up with something.

[stephentyrone]

I have discussed this with the relevant folks, and the following is an official statement:

1. long double will continue to bind double (IEEE binary64) in the Darwin ABI for ARM64.
2. if we were to add IEEE binary128 support for C or C++ in Apple's toolchains, it would follow the AAPCS layout and calling conventions for quad-precision floating-point, and the Itanium name mangling.

We're going to look into where it makes the most sense to document this other than a random post on a GitHub issue. I'll add a reference to that once it's available.

[iains]

thanks very much for the info!

we are currently looking into (with some success mostly down to FX) in implementing __float128 (which automatically enables C's _Float128 in GCC)

this is currently following the existing aarch64 backend ABI (which is AAPCS64).

It might be necessary to document how we deal with variadic calls, since there are significant differences between darwinpcs and AAPCS64 there.

[stephentyrone]

Ok. If you need further clarification on variadic conventions, please let us know.

[iains]

I think we should be in a position to close this issue now (technically, the decision is made, and practically the latest sources support __float128 in c-family and IEEE QP in libgfortran).

I am sure that there are wrinkles - but those can be dealt with separately.

Ok. If you need further clarification on variadic conventions, please let us know.

My intention is that the technical content of the README.md will be added to the GCC port directory as documentation for how the Darwin sub-port differs from AAPCS64.

• so yes, there might be questions (ISTR that when comparing the two ABIs there were a few things I had to make assumptions about) - but that can be moved to a different issue or topic.

• We (GCC-side) should also document (in the same place) the additions that we've made that are not covered by the darwinpcs.

Unless anyone else has questions or additions I will close this in 24h or so.

[iains]

we have an implementation on the branch now.