On Fri, Sep 30, 2022 at 06:21:04PM +0000, Joseph Myers wrote: > 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?
No idea. https://eel.is/c++draft/cmath.syn has (since that std::float*_t/std::bfloat16_t paper) constexpr floating-point-type nextafter(floating-point-type x, floating-point-type y); constexpr float nextafterf(float x, float y); constexpr long double nextafterl(long double x, long double y); constexpr floating-point-type nexttoward(floating-point-type x, floating-point-type y); constexpr float nexttowardf(float x, long double y); constexpr long double nexttowardl(long double x, long double y); That is certainly wrong for double, because it is a backwards incompatible change, where constexpr double nexttoward(double x, long double y); is gone and constexpr double nexttoward(double x, double y); is added. IMHO the nexttoward case just shouldn't be changed, so it should remain: constexpr float nexttoward(float x, long double y); constexpr double nexttoward(double x, long double y); constexpr long double nexttoward(long double x, long double y); constexpr float nexttowardf(float x, long double y); constexpr long double nexttowardl(long double x, long double y); Having constexpr floating-point-type nexttoward(floating-point-type x, long double y); would be problematic, because long double might have unordered floating point rank to floating-point-type (say powerpc IBM extended long double vs. std::float128_t), or could have smaller floating point rank (say if it is IEEE double). But like nexttowardl or nexttoward(long double, long double) aren't very useful because they are the same thing as nextafterl or nextafter(long double, long double), introducing other nexttoward overloads doesn't seem useful. Jakub
