[RFC] Appropriate portable data type for IEEE half-precision on C/C++

[Jonathan Wakely]

On Fri, 12 Mar 2021 at 09:10, Kito Cheng via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi:
>
> It's Kito, a RISC-V folks, recently RISC-V has an ISA extension draft
> for IEEE half-precision operations [4], including arithmetic,
> conversion, comparison...a full set of support for IEEE
> half-precision.
>
> So we are seeking the data type for IEEE half-precision, and then we
> have few candidates for that:
> 1. _Float16
> 2. __fp16 (Same as ACLE)
> 3. Other type names maybe __float16_t
>
> _Float16 was the best candidate since it kind of standard types from
> ISO/IEC TS 18661-3, and it already supported by both clang and gcc,
> however the issue is GCC don't support that on C++ mode and seems like
> [1-2] it not intend to support that due to the decimal floating point
> issue,

I am not aware of any motivation in the C++ committee for using class
types for new floating-point types. I don't think the C++ decimal
floating-point TR is considered a success.

> C++ also has another proposal for extended floating-point types
> (https://wg21.link/p1467), which included half-precision types, so in
> my understanding, _Float16 won't be a portable typen between C/C++.

Why not just make _Float16 available in C++ as a GCC extension?

P1467 specifically says:
"The C++ implementation could use _Float16, _Float32, etc. as the
names of the extended floating-point types behind the std:: type
aliases, allowing the use of the C names in both languages."

If/when P1467 (or something like it) gets into the C++ standard we can
add std::float16 to libstdc++ as a typedef for _Float16, but even
before then we can start to add support to std::to_chars,
std::is_floating_point, std::complex, std::abs etc.

> And the second candidate __fp16, which is the typename come from ACLE,
> it has no C/C++ portable issue due to its target specific type, the

This isn't a standard name, so to use it would mean relying on
GCC-specific extensions, so I don't see why it would be better than
relying on "_Float16" as a GCC extension for C++ (and standard for C).

Similarly for __float16_t.