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, 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.) -- Joseph S. Myers jos...@codesourcery.com
