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

[Joel Sherrill]

On 8/8/2017 12:44 PM, Joseph Myers wrote:
> 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.

This may be a stupid question but with the focus of this
discussionon glibc, what does this all mean for non-glibc
targets?

--joel