[Bug libquadmath/114623] sqrtq and std::numeric_limits<__float128>::max()

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623

--- Comment #8 from GCC 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:481ba4fb5fce8257f5dbeb994dac2748c0237fa2

commit r14-9853-g481ba4fb5fce8257f5dbeb994dac2748c0237fa2
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Apr 9 08:17:25 2024 +0200

    libquadmath: Use soft-fp for sqrtq finite positive arguments [PR114623]

    sqrt should be 0.5ulp precise, but the current implementation is less
    precise than that.
    The following patch uses the soft-fp code (like e.g. glibc for x86) for it
    if possible.  I didn't want to replicate the libgcc infrastructure for
    choosing the right sfp-machine.h, so the patch just uses a single generic
    implementation.  As the code is used solely for the finite positive
arguments,
    it shouldn't generate NaNs (so the exact form of canonical QNaN/SNaN is
    irrelevant), and sqrt for these shouldn't produce underflows/overflows
either,
    for < 1.0 arguments it always returns larger values than the argument and
for
    > 1.0 smaller values than the argument.

    2024-04-09  Jakub Jelinek  <jakub@redhat.com>

            PR libquadmath/114623
            * sfp-machine.h: New file.
            * math/sqrtq.c: Include from libgcc/soft-fp also soft-fp.h and
quad.h
            if possible.
            (USE_SOFT_FP): Define in that case.
            (sqrtq): Use soft-fp based implementation for the finite positive
            arguments if possible.