[clang] missing support for _Float128 (C23)

[nickdesaulniers]

_Float128 x;

<source>:1:1: error: unknown type name '_Float128'
    1 | _Float128 x;
      | ^

"Annex H (normative) IEC 60559 interchange and extended types" subsection "H.2.1 Interchange floating types" talks about:

Types designated: _FloatN where N is 16, 32, 64, or ≥ 128 and a multiple of 32

Looks like clang does not support this type. The extension type __float128 seems supported, but only on x86_64 (or rather, at least not on aarch64 where instead long double seems to be 128b). After first class compiler support is enabled for these types on all supported targets, there's some preprocessor defines that should be defined by clang as well.

An implementation that defines STDC_IEC_60559_BFP and STDC_IEC_60559_TYPES shall provide _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively. If the implementation’s long double type supports an IEC 60559 interchange format of width N > 64, then the implementation shall also provide the type _FloatN as an interchange floating type with the same representation and alignment requirements as long double.

Otherwise libraries that seek to provide support for functions that have _Float128 return or parameter types need to result to compiler version detection (rather than feature detection) and type alias to compiler extensions (or long double :nauseated_face: :vomiting_face: ).

In particular, porting code making excessive use of long double on x86_64 to aarch64 has been quite painful. _Float128 will help, but clang is currently missing pieces that may help make code more platform-portable easier.

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Nick Desaulniers (nickdesaulniers)

```c _Float128 x; ``` ``` <source>:1:1: error: unknown type name '_Float128' 1 | _Float128 x; | ^ ``` "Annex H (normative) IEC 60559 interchange and extended types" subsection "H.2.1 Interchange floating types" talks about: > Types designated: _FloatN where N is 16, 32, 64, or ≥ 128 and a multiple of 32 Looks like clang does not support this type. The extension type `__float128` seems supported, but only on x86_64 (or rather, at least not on aarch64). After first class compiler support is enabled for these types on all supported targets, there's some preprocessor defines that should be defined by clang as well. > An implementation that defines __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_TYPES__ shall provide _Float32 and _Float64 as interchange floating types with the same representation and alignment requirements as float and double, respectively. If the implementation’s long double type supports an IEC 60559 interchange format of width N > 64, then the implementation shall also provide the type _FloatN as an interchange floating type with the same representation and alignment requirements as long double. Otherwise libraries that seek to provide support for functions that have `_Float128` return or parameter types need to result to compiler version detection (rather than feature detection) and type alias to compiler extensions. In particular, porting code making excessive use of `long double` on x86_64 to aarch64 has been quite painful. `_Float128` will help, but clang is currently missing pieces that may help make code more platform-portable easier.

[pinskia]

Note _Float128 could be easily supported for aarch64-linux-gnu as long double there is the same. For Darwin/Mac OS IIRC long double is the same as double.

Note also _Float128 support was addded in GCC 7+ for aarch64-- (darwin is not supported in GCC yet).

[tgross35]

GNU GCC 13 supports both __float128 and _Float128 on MacOS aarch64, unsure about x86.

Is there any reason not to make _Float128 available on all platforms, at least 64-bit? LLVM makes this possible already via fp128.

[tgross35]

Note that there seem to be some ABI bugs on 32-bit platforms, see the garbage output at https://gcc.godbolt.org/z/avxEGPoz9. Also:

• https://github.com/llvm/llvm-project/issues/77401
• https://github.com/llvm/llvm-project/issues/41838