https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114623
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83800#c4
>
> Basically libquadmath should be using sqrt128f if it exist for sqrtq instead
> of doing a version itself ...
That doesn't make any sense.
sqrtf128 is only available in recent glibcs, not in any other C library.
libquadmath by design contains copies of the (old) glibc IEEE754 quad code, so
that
it provides the support independently from the C library. Has been doing that
before
any *f128 support has been added to glibc, and needs to do it even now to
support other C libraries.
The sqrt* case was an exception, the glibc sysdeps/ieee754/ldbl-128/ didn't
contain any sqrt implementation, as arches which supported ldbl-128 as long
double at that point had hw sqrt support, so libquadmath has just an
approximation.
What could be done is use the soft-fp implementation like is done even in glibc
for x86. We have the soft-fp code in gcc, but would need to arrange the right
sfp-machine.h etc.
