[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Nov 2018 14:00:36 -0400
From: David Edelsohn <dje.gcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] PPC64 IEEE128 bit FP support
IEEE binary64 still will be available for long double.
Current musl libc has not been compatible with the ABI and with
current GLIBC because it did not implement IBM double-double format.
Musl libc can call it an ABI break, but musl libc has not been compatible.
And the new configuration in GCC, LLVM and GLIBC allow both IBM
double-double and IEEE 754 binary128 to co-exist. Changing the musl
libc dynamic linker name doesn't fix that and actually makes musl libc
even less compatible with the rest of the PPC64LE Linux Ecosystem.
Thanks, David
On Fri, Nov 2, 2018 at 1:55 PM Szabolcs Nagy <nsz@...t70.net> wrote:
>
> * David Edelsohn <dje.gcc@...il.com> [2018-11-02 13:32:55 -0400]:
> > I don't know if it would be necessary for musl libc long double to be
> > selectable for backward compatibility or one can implement a "flag
> > day" where a musl libc release switches to only 128 bit quad precision
> > long double.
>
> since currently long double is ieee-binary64 in musl,
> if we want it to be ieee-binary128 then that's a new
> abi and in musl new abi means a new dynamic linker name:
> current toolchain uses /lib/ld-musl-powerpc64le.so.1, a new
> toolchain would use e.g. /lib/ld-musl-powerpc64le_f128.so.1
>
> i think even if the 64bit long double is deprecated and not
> selectable in gcc anymore, we would use a new dynamic
> linker name (but i think in musl we can easily keep supporting
> two long double variants, the difficulty is in the gcc config
> machinery and ux issues if there are no abi markers for
> relocatable objects to detect abi mismatch at link time).
>
> >
> > Thanks, David
> > On Fri, Nov 2, 2018 at 12:13 PM Rich Felker <dalias@...c.org> wrote:
> > >
> > > On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> > > > * Markus Wichmann <nullplan@....net> [2018-10-26 06:28:29 +0200]:
> > > > > Now you just need to look through all the maths code to find all the
> > > > > places that need changing. __floatscan() comes to mind immediately. And
> > > > > I don't know if any of the libm functions needs adjustment for this new
> > > > > format.
> > > >
> > > > generic c code in musl should work for all supported
> > > > floating-point formats, which includes ieee binary128
> > > > for long double.
> > > >
> > > > only float.h needs to be set up according to the abi.
> > > >
> > > > some long double math functions don't have high quality
> > > > implementations for ieee binary128 format though.
> > >
> > > Yes. Assuming there aren't other problems revealed by my questions
> > > about argument passing and ISA levels, I think the only blocking issue
> > > here is naming the ABI. I forgot to mention but that should also
> > > involve a gcc patch that we can put in mcm and eventually upstream.
> > >
> > > QoI issues for IEEE-quad-based [sub]archs can be improved later;
> > > aarch64 and s390x are already affected IIRC.
> > >
> > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
