[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160209015242.GF9349@brightrain.aerifal.cx>
Date: Mon, 8 Feb 2016 20:52:42 -0500
From: Rich Felker <dalias@...c.org>
To: David Edelsohn <dje.gcc@...il.com>, musl@...ts.openwall.com
Subject: Re: Re: musl libc for PPC64
On Tue, Feb 09, 2016 at 02:45:50AM +0100, Szabolcs Nagy wrote:
> * David Edelsohn <dje.gcc@...il.com> [2016-02-08 20:16:25 -0500]:
> > On Mon, Feb 8, 2016 at 8:03 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> > > * Szabolcs Nagy <nsz@...t70.net> [2016-02-09 00:48:31 +0100]:
> > >> * Rich Felker <dalias@...c.org> [2016-02-08 18:29:45 -0500]:
> > >> > On Mon, Feb 08, 2016 at 06:24:27PM -0500, David Edelsohn wrote:
> > >> > > I'm not sure what you mean. The software emulation assumes the
> > >> > > hardware support is not present. It doesn't mirror back the state to
> > >> > > the processor in 64 bit mode. But the emulation is fully IEEE128
> > >> > > compliant.
> > >> >
> > >> > if fesetround(FE_DOWNWARD) succeeds but then long double math still
> > >> > rounds to nearest, that's not IEEE compliant.
> > >> >
> > >> > The big obstacle to having fenv with softfloat on fully-softfloat
> > >> > archs is the lack of register state for the rounding mode and
> > >> > exception flags, so it should be possible to do this right as long as
> > >> > the cpu has status/mode registers for single/double, which the
> > >> > soft-quad code can then access/set. If this isn't done right already
> > >> > we could either try to get it fixed in libgcc or punt and go with
> > >> > ld64.
> > >> >
> > >>
> > >> it seems to be supported
> > >> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/config/rs6000/sfp-machine.h;h=75d5e1a2d522e0a3d3c5b0463fcfe9b054f7c263;hb=HEAD#l107
> > >>
> > >> so we can implement iso c annex f with 128 bit long doubles.
> > >
> > > hm it seems, this is only for the __float128 type
> > > which will be new in gcc-6.
> > >
> > > i don't see how to configure gcc with ieee128 long double.
> > > (other than using the debug option -mabi=ieeelongdouble)
> > >
> > > so if musl goes with ieee128 long double abi then it will
> > > only work with latest gcc.
> >
> > The musl libc dynamic linking support only was added to the latest GCC.
> >
>
> (resend with correct to:)
>
> musl has a gcc wrapper that changes the specs file and then
> it works even with gcc-3 (on x86 and glibc host without c++).
>
> we also have patches for gcc releases going back to gcc-4.7
Indeed. Just patching in the dynamic linker name and a few other
details to make gcc target musl properly is small and can be done for
any gcc version. Patching in ieee quad or ABI changes is non-trivial
though.
> so powerpc64 would be the only arch that depends on features
> from the latest gcc and that is new situation for musl.
> (this is mostly interesting because there are historical
> powerpc64 machines with older toolchains wich might work
> with musl with minor tweaks if we choose 64bit long double)
>
> but if new hw adds ieee128 instructions then i guess that's
> the right choice.
Obviously the powerpc64 musl target is not going to work with any
compiler too old to have the "ELFv2 ABI" so that limits how far back
it's interesting to be compatible with old compilers. What gcc version
added the v2 ABI? Does clang/llvm support it yet? (Compat with clang
is also valuable.)
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.
