https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:ba281da28d34f9a78a07f6ee56ad2c754447966e commit r13-3372-gba281da28d34f9a78a07f6ee56ad2c754447966e Author: Jakub Jelinek <ja...@redhat.com> Date: Wed Oct 19 11:25:03 2022 +0200 libstdc++-v3: Implement {,b}float16_t nextafter and some fixes [PR106652] The following patch implements nextafter for std::{,b}float16_t, though right now only without constexpr support, and adds a testcase for it. The testcase unfortunately relevealed I've screwed up testing of my last patch. I've tested earlier version of the patch with --target_board=unix/-std=c++23 but didn't test the final version with that RUNTESTFLAGS, so missed an invalid call to std::sph_neumann (too many arguments) in the test. And, I've made a typo in the guard for numeric_limits (the reason for the guard is I wanted to avoid defining a large macro that nothing will then use because the std::{,b}float*_t types are C++23 only) and so numeric_limits wasn't specialized for the types at all but testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't detect that. In the nextafter implementation I'm calling __builtin_nextafterf to get various required side-effects for nextafter from 0/-0, or from max to inf or from min to largest subnormal to avoid needing to set errno inline, or use inline asm specific for each processor to force math evaluation barriers. Dunno if #ifdef __INT16_TYPE__ using __float16_int_type = __INT16_TYPE__; #else using __float16_int_type = short int; #endif isn't too ugly, perhaps we could just blindly use short int and hope or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t? Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types and all of them have 16-bit short (I think the only target with some other short size is avr with certain command line switches where both short and int are 8-bit, but such mode isn't compatible with C and C++ requirements). 2022-10-19 Jakub Jelinek <ja...@redhat.com> PR c++/106652 * include/std/limits: Fix a typo, 202202L -> 202002L. (numeric_limits::<_Float16>::radix, numeric_limits::<_Float32>::radix, numeric_limits::<_Float64>::radix, numeric_limits::<_Float128>::radix, numeric_limits::<__gnu_cxx::__bfloat16_t>::radix): Use __FLT_RADIX__ macro instead of type specific macros. * include/c_global/cmath (nextafter(_Float16, _Float16)): New overload. (nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)): Likewise. * testsuite/26_numerics/headers/cmath/functions_std_c++23.cc (test_functions): Uncomment nextafter test. Fix up sph_neumann call. * testsuite/26_numerics/headers/cmath/nextafter_c++23.cc: New test.
