[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181102175515.GC2032@port70.net>
Date: Fri, 2 Nov 2018 18:55:16 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] PPC64 IEEE128 bit FP support
* 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.
