Re: max_align_t mess on i386

[Daniel Kolesa <daniel@octaforge.org>]

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
>