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
