Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support

[Joseph Myers <joseph@codesourcery.com>]

On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote:

> What isn't in the patch but I think we'll need to also change are some
> minimal set of __builtin_*bf16 builtins.  Seems for _Float16, GCC provides
> all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is
> no glibc support for any of that, so builtins that are expanded by the
> compiler are fine, but what should be fall back to libm won't work.
> Maybe at least for now it is acceptable to implement most <cmath> and
> <complex> std::float16_t and std::bfloat16_t overloads with using
> __builtin_*f and explicitly narrow down, but I think at least nextafter
> (and apparently nexttoward as an alias for it for extended floating
> point types) needs to be specific for the particular floating point format.

C doesn't have nexttoward (the function whose second argument is always 
long double, independent of the type of the first argument) for any of the 
_FloatN or _FloatNx types; why does C++ have in (but with second argument 
the same type as the first?) for those types?

(C2x also doesn't have fmax or fmin for the _FloatN or _FloatNx types, but 
that's because the operations those are bound to are replaced in IEEE 
754-2019 by different max/min operations with different corresponding 
functions; glibc still provides the fmax and fmin operations for _FloatN 
and _FloatNx, as in TS 18661-3, as extensions.)

Providing a full set of _Float16 operations in glibc would be reasonable 
(modulo the issues with implications for the minimum GCC version for 
building glibc for a given architecture).  It's rather less clear that 
__bf16 operations would be appropriate.

There may also be double rounding considerations for implementing some 
functions (that are required to be correctly rounded) via operations on 
float; at least for fma (if the result of fmaf is half way between two 
representable values of the narrower type, but not exactly equal to the 
value of a*b+c).

-- 
Joseph S. Myers
joseph@codesourcery.com