[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:ba281da28d34f9a78a07f6ee56ad2c754447966e

commit r13-3372-gba281da28d34f9a78a07f6ee56ad2c754447966e
Author: Jakub Jelinek <jakub@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  <jakub@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.