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

[Gabriel Ravier]

On 3/12/21 7:07 PM, Joseph Myers wrote:
> On Fri, 12 Mar 2021, Jonathan Wakely via Gcc wrote:
>
>> Why not just make _Float16 available in C++ as a GCC extension?
> There may be questions about promotions from _Float16 to wider formats for
> arithmetic.
>
> For C, there are no such promotions at the level of types (adding two
> _Float16 values produces a result of type _Float16), but the excess
> precision mechanism is used in some cases to cause a result of _Float16
> arithmetic, although of semantic type _Float16, to be represented with the
> range and precision of _Float32, to reduce the number of conversions of
> intermediate results back to the range and precision of _Float16 that are
> needed on hardware that doesn't have arithmetic operating directly on
> _Float16.  Specifically, on AArch64, the excess precision mechanism is
> used before ARMv8.2-A; v8.2-A adds direct arithmetic on _Float16 so no
> excess precision is used from then on (see aarch64_excess_precision).
>
> As we don't have excess precision support in the C++ front end,

Couldn't that just be made into shared code between the C and C++ 
frontends ?

> supporting
> _Float16 for C++ will require a decision about how to handle _Float16
> arithmetic on hardware where there aren't actual _Float16 arithmetic
> operations.
>
> (The RISC-V document linked to suggests that won't be an issue for RISC-V
> with hardware _Float16 support, though obviously it's still necessary to
> decide what to do when using _Float16 on RISC-V systems without the
> hardware support, if that is allowed at all.)
>