Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 8 Aug 2017, Janne Blomqvist wrote:

> On a semi-related note, it seems the recently released glibc 2.26
> contains quad math functions. Does that mean we should change to use
> those in preference to libquadmath when available? I suppose
> libquadmath cannot be deprecated either, since it's still needed for
> non-glibc targets.

My view is:

* GCC should prefer to use the *f128 functions from libc/libm where 
available (and users should similarly be advised to use those instead of 
libquadmath).  Note that glibc implements the TS 18661-3 strfromf128 
instead of having any form of printf support for _Float128.  A glibc 
version number is determined at GCC configure time which could be used for 
that purpose, if host-side code cares about this (target-side code can do 
link-time tests for availability).

* libquadmath should move to an automated process for making the necessary 
substitutions in glibc source files to convert them to source files for 
use in libquadmath, so that updates are easier rather than the code 
keeping falling behind glibc.

* I don't know if libquadmath, when built for a system with the libc/libm 
support, should just make its functions wrap the system libc/libm ones (or 
indeed make the headers redirect calls with asm ("<func>f128") to use 
those functions directly).

> Or to put it another way, what's the point of quad math support in
> glibc, since libquadmath already exists?

glibc is implementing the standard API from TS 18661-3 (with extensions 
for glibc-specific functions such as lgamma_r and clog10), which is likely 
to be included in C2x, with full integration with all the glibc tests for 
libm, support for TS 18661-3 versions of TS 18661-1 functions that aren't 
in libquadmath, and probable future use of those functions as long double 
functions for powerpc64le.  libquadmath has an old, nonstandard API and 
does not include newer functions at all.  libquadmath arises from a 
rejection of such functionality for glibc at a time when there were no 
standard bindings for it to follow.  Since there are now such standard 
bindings, it's natural for glibc to include the functions.

I expect that in future GCC should have built-in function support for all 
the *f128 functions (not added in my initial _FloatN support to avoid any 
startup time etc. issues from adding hundreds of new built-in functions), 
but not for the old libquadmath APIs.

-- 
Joseph S. Myers
joseph@codesourcery.com