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

[Joel Sherrill]

On 8/8/2017 4:17 PM, Joseph Myers wrote:

On Tue, 8 Aug 2017, Joel Sherrill wrote:


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


Well, Jakub recently updated parts of libquadmath from glibc (only the
functions coming from the ldbl-128 directory, and excluding a few of those
that were more complicated; not the complex arithmetic functions or
string/numeric conversions) so it's not quite so out-of-date and buggy.
If updates are automated in future that would help in keeping it working
and up-to-date for targets that have a use for it.

I'd expect more libm implementations to add *f128 functions in future now
the standard names are assigned in TS 18661-3, which is quite likely to
become an optional feature of C2x (most of the parts of TS 18661 are being
proposed for inclusion as optional features in C2x).  I'm not suggesting
removing libquadmath, but I'd expect it to be de-emphasised on targets
that have the *f128 functions in their own libm.



Thanks. I guess I am more concerned specifically about newlib
for Cygwin and RTEMS. I expect we would like to rely on gcc
providing the implementation.

It feels strange to see C2x. :)

--joel

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

[Joseph Myers]

On Tue, 8 Aug 2017, Joel Sherrill wrote:

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

Well, Jakub recently updated parts of libquadmath from glibc (only the 
functions coming from the ldbl-128 directory, and excluding a few of those 
that were more complicated; not the complex arithmetic functions or 
string/numeric conversions) so it's not quite so out-of-date and buggy.  
If updates are automated in future that would help in keeping it working 
and up-to-date for targets that have a use for it.

I'd expect more libm implementations to add *f128 functions in future now 
the standard names are assigned in TS 18661-3, which is quite likely to 
become an optional feature of C2x (most of the parts of TS 18661 are being 
proposed for inclusion as optional features in C2x).  I'm not suggesting 
removing libquadmath, but I'd expect it to be de-emphasised on targets 
that have the *f128 functions in their own libm.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: 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 ("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

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

[Joseph Myers]

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 ("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
jos...@codesourcery.com

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

[Janne Blomqvist]

On Tue, Aug 8, 2017 at 3:10 PM, Manfred Schwarb  wrote:
> Am 27.07.2017 um 15:24 schrieb Manfred Schwarb:
>> Hi,
>>
>> there is the long standing annoyance that it is very hard to
>> statically compile in libquadmath.
>> See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539 and
>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00375.html.
>>
>> Unfortunately, the patch from FX went nowhere, and the
>> second suggestion of Tobias (gfortran -specs=myspecfile) does not work.
>>
>> There remain two working options:
>> 1) compile with gcc:
>># gcc -static-libgcc -Wl,-Bstatic -lgfortran -lquadmath -Wl,-Bdynamic -lm
>> 2) modify /lib*/libgfortran.spec of the compiler itself
>>
>> It crossed my mind that one could do the second option in a conditional way:
>>
>> --- libgfortran.spec.old 2017-05-29 15:55:24.939239222 +
>> +++ libgfortran.spec2017-07-27 12:55:05.006518676 +
>> @@ -5,4 +5,4 @@
>>  #
>>
>>  %rename lib liborig
>> -*lib: %{static-libgfortran:--as-needed} -lquadmath 
>> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
>> +*lib: %{static-libgfortran:--as-needed} %{static-libgfortran:-Bstatic} 
>> -lquadmath %{static-libgfortran:-Bdynamic} 
>> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
>>
>
> Well, --as-needed and -Bstatic together makes not really much sense.
> And, according to my experiences, somehow --as-needed does not work at all in 
> this context,
> libquadmath will always be linked in, even when there is no use of quad 
> precision.
>
> So the following would make more sense:
>
> --- libgfortran.spec.old2017-05-29 21:46:01.036867084 +
> +++ libgfortran.spec2017-08-08 12:04:01.500558409 +
> @@ -5,4 +5,4 @@
>  #
>
>  %rename lib liborig
> -*lib: %{static-libgfortran:--as-needed} -lquadmath 
> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
> +*lib: %{static-libgfortran:-Bstatic} -lquadmath 
> %{static-libgfortran:-Bdynamic} -lm %(libgcc) %(liborig)

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.

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


-- 
Janne Blomqvist