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 jos...@codesourcery.com
