This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]