Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)
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
Second GCC 7.2 Release Candidate available from gcc.gnu.org
Due to a fix for PR81766 there is now a second release candidate for GCC 7.2 available from ftp://gcc.gnu.org/pub/gcc/snapshots/7.2-RC-20170808/ and shortly its mirrors. It has been generated from SVN revision 250958. I have so far bootstrapped and tested the release candidate on x86_64-unknown-linux-gnu. Please test it and report any issues to bugzilla. If all goes well I'd like to release 7.2 on Monday, August 14th.
Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)
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
What to do about all the gcc.dg/guality test failures?
I was wondering if something needs to be done about the gcc.dg/guality tests. There are two main issues I see with these tests, one is that they are often not run during testing and so failures do not show up. I looked into this and found that, at least on my ubuntu 16.04 system, the kernel parameter kernel.yama.ptrace_scope is set to 1 by default. This limits the use of ptrace to direct child processes and causes the guality tests to not run on my system. They also don't show up as failures, all you get is a message in the test log that says 'gdb: took too long to attach'. After changing this to 0, the guality tests do get run. The second problem is that many of the tests fail when they are run. For example, looking at some August test runs: x86_64 failures: https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00651.html aarch64 failures: https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00603.html mips64 failures: https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00527.html s390x failures: https://gcc.gnu.org/ml/gcc-testresults/2017-08/msg00509.html These all show many failures in gcc.dg/guality. Most of the failures are related to using the '-O2 -flto' or '-O3' options. If I remove those option runs I get 15 failures involving 5 tests on my aarch64 system: gcc.dg/guality/pr36728-1.c gcc.dg/guality/pr41447-1.c gcc.dg/guality/pr54200.c gcc.dg/guality/pr54693-2.c gcc.dg/guality/vla-1.c So I guess there are number of questions: Are these tests worth runnning? Do they make sense with -O3 and/or -O2 -flto? If they make sense and should be run do we need to fix GCC to clean up the failures? Or should we continue to just ignore them? Steve Ellcey sell...@cavium.com
Re: Future of libquadmath and glibc 2.26 (Re: statically compile in libquadmath)
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)
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)
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
gcc-5-20170808 is now available
Snapshot gcc-5-20170808 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170808/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 250974 You'll find: gcc-5-20170808.tar.xzComplete GCC SHA256=9c494cc2fb3122ce6b72a51ab444761b6adc6a70cd75b205a8becd539bd85be2 SHA1=a7f1ea88d9a53dbf026278440498b52e5b8a315b Diffs from 5-20170801 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
dJqkhS
aXuWtpaAdglWmht JLLghLREjZWVRnjhBGKL
