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