[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17b0b2d0-caad-c64a-03b3-023ab2c39652@octaforge.org>
Date: Sat, 14 Dec 2019 19:53:06 +0100
From: Daniel Kolesa <daniel@...aforge.org>
To: Rich Felker <dalias@...c.org>, musl@...ts.openwall.com
Subject: Re: max_align_t mess on i386
On 12/14/19 7:17 PM, Rich Felker wrote:
> On Sat, Dec 14, 2019 at 06:51:50PM +0100, Florian Weimer wrote:
>> * Rich Felker:
>>
>>> However, whatever we do with i386, the option of using 8-byte
>>> granularity remains open for all the other 32-bit archs, most of which
>>> tend to be used with machines far more memory-constrained than i386.
>> Note that powerpc has a similar issue, but with long double:
>>
>> <https://sourceware.org/bugzilla/show_bug.cgi?id=6527>
>>
>> But perhaps musl follows the old powerpc ABI, where double and long
>> double are both binary64 (I have not checked, sorry).
> We use the ld64 powerpc ABI. musl doesn't support non-IEEE-semantics
> floating point types (stuff like IBM double-double) and quad was not
> an option at the time, and if it's even supported now it's messy and
> requires very recent tooling.
>
> BTW I know someone from our community doing both musl and glibc stuff
> on powerpc is actually interested in continuing to use the ld64 ABI
> (with the old compat symbols) on glibc due to problems with
> double-double support in applications.
Yes, that would be me. I've been looking into making my distribution use
the old ld64 ABI for ppc (64le, 64, 32) but without much success.
Technically, I did get it working for most part, thanks to glibc doing
asm redirection, but there is still the edge case of people declaring
math prototypes manually (which is allowed), which would result in the
incorrect symbol being used, unless explicitly linked with
-lnldbl_nonshared. So I put this effort on hold for the time being.
As far as I know, glibc is going to add support for IEEE754 binary128
format (which distros like Fedora plan to use), which would require
introduction of new symbol versions for stuff like math when built in
that kind of configuration. However, this is only going to be available
on platforms that support VSX (i.e. when built for POWER7 or better).
I've been wondering if, while doing that, it would be possible to
reintroduce support for the ld64 ABI in glibc, as in, the binary64
symbols would have the same version as the binary128 ones.
Perhaps my thinking is wrong, but as I see it, it would mean no
compatibility breakage then. Configurations using the IBM long double
ABI would keep using their older versions, and configurations built to
use the IEEE754 long double would use the newer versions, either
binary128 (for VSX platforms) or binary64 (for the others). And that's
what I would do as well; switch ppc64le+glibc to IEEE754 binary128, and
have all musl variants plus ppc64 and ppc stick with binary64.
Florian, since you seem to be familiar with this, would you mind telling
me if I'm wrong and if I am, why? And is there any chance of upstream
glibc potentially accepting such change?
Daniel
>
> 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.
