public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* powerpc64le ieee128 transition path
@ 2021-01-31 22:51 Daniel Kolesa
  0 siblings, 0 replies; only message in thread
From: Daniel Kolesa @ 2021-01-31 22:51 UTC (permalink / raw)
  To: libc-help

Hello,

I recently got curious about the transition path from ibm128 long doubles to ieee128 long doubles. Particularly, Fedora has wanted to this for a while; I'm a maintainer at Void Linux and we'd like to do the same. I have not been able to get much information from the Fedora maintainer I have access to, so I thought I'd raise a thread to clear up my concerns.

So, glibc 2.32 introduced the long double redirects. This is conceptually identical to the already existing redirects for 64-bit long double, and will work automagically (via __asm__ redirection) for programs that include the appropriate libc headers. So far so good.

What I am curious about - is there any plan to address the actual defaults? There is a particular curious breakage that will happen if they are not addressed - particularly two cases:

1) program declares a libc symbol manually without going through a header; this is not allowed for most libc symbols, but it is allowed for libm symbols (as far as I can tell); it will grab the symbol with the default version, which is currently the 128-bit IBM one
2) program attempts to use a libc symbol through other means, such as dlopen/dlsym - this will get the unversioned symbol, which is, as far as i can tell, the oldest version available (on powerpc64 BE, this is likely already broken, since the oldest symbol will be pre-ibm128 64-bit one, on LE this will just be the ibm128 symbol)

As far as I can tell, 1) is not addressable without also breaking compile-time support for the 128-bit IBM long double, as it would require changing the default symbol version to a newer one, which would use IEEE binary128 long double; at runtime things would continue to work as existing binaries would be tied to the older symbols 2) may not be addressable without breaking existing binaries at all, as it would require changing what the unversioned symbol is an alias of.

So, is glibc simply planning to keep these edge cases unhandled? Or is there a plan in place? I'd also like a relevant Fedora person to pitch in here, but I'm not sure who's dealing with this, or whether they are reading this list.

While at it, I have another concern. We are also shipping big endian
versions of the distro, for 64-bit and 32-bit. I would like to
transition them to use 64-bit long doubles, since the IBM long double
format has been a pet peeve of mine for a while now (it breaks
constexpr in gcc since gcc can't constant-fold it, it's not contiguous,
various software does not support it, etc; additionally, we also have
ports with the musl libc, which uses 64-bit universally, and this would
bring the two targets together and allow things such as gcompat to work
reliably) and binary128 actually requires VSX in gcc (which is much
newer than the hardware we cover; the 32-bit port doesn't even need any
vector support at all). I was investigating the transition before and
came to the conclusion I would not do it at the time because of those
exact two edge cases above. Our toolchain obviously supports asm
redirection, but I feared the two edge cases where redirection does not
kick in would be problematic.

However - since there is the option of transitioning the little endian target now, and it might be suffering from those two same edge cases already, I figured we could just do it for BE as well, just to 64-bit instead of 128-bit ldbl, but using the same redirection concept. The concerns are identical, and if we possibly have to deal with it for LE already, might as well do it all at once. But before going ahead with anything, I would like to clear up the situation here on the mailing list.

Of course, the chance of actual breakage is fairly low. It requires both the already rare case of declaring own symbols and/or using dlopen on the standard library (which is sketchy and non-portable by itself), and using the specific symbols related to long double (and long double usage is rare even on its own).

Lastly, while at it, is the 128-bit long double support in glibc considered "ready" at this point? I haven't been able to find much, other than Fedora's outdated transition page, some little details on GCC wiki, and commits/changelog in glibc itself.

Thank you,

Daniel

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-01-31 22:51 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-31 22:51 powerpc64le ieee128 transition path Daniel Kolesa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).