Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:

> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example).  This can
> > magically make -msoft-float work as well everywhere, btw.
> 
> Emulation is one thing, but another one is where are those __float128 or
> quad long double arguments and return values passed.  On power8 le I think
> they are passed in VSX registers, aren't they?
> But are those available everywhere where ppc64 is supported?  For ppc32
> certainly not, I don't remember for ppc64.

As noted in previous discussions, while the current GCC implementation 
requires VSX for _Float128 support, the registers used in the ABI are the 
same as AltiVec registers; it would be possible to implement support for 
_Float128 on all powerpc64 with AltiVec (most but not all 64-bit 
processors), using AltiVec registers in the ABI and being fully compatible 
with the ABI using VSX registers.

> Sure, the ABI could say pass it in e.g. in a pair of integer registers...

You'd need to decide whether you want the 64-bit BE ABI for _Float128 to 
be one that supports the type on all 64-bit processors (so pass in integer 
registers), or one that only supports it on processors with AltiVec but is 
more similar to the LE ABI (passing in AltiVec registers).

And, then, decide the 32-bit ABIs (hard and soft float), if you want to 
support _Float128 there.

And, then, do glibc changes, both to support _Float128 functions at all, 
and to support a different long double format if you wish to support 
changing the long double format for those ABIs.  Note that the symbol 
versioning in glibc assumes that all libm functions either predate 
_Float128 support on all architectures (version of *f128 versions is 
FLOAT128_VERSION) or postdate it on all architectures (versions in 
math/Versions based on whenever that function was added to glibc; various 
*f64x functions, that alias *f128 when appropriate, are also hardcoded as 
GLIBC_2.27).  So if someone adds _Float128 support to any glibc ABI that 
doesn't currently have it, they need to add support for new syntax in 
Versions files such as MAX (FLOAT128_VERSION, GLIBC_2.28), which describes 
the right symbol version for a _Float128 function added in 2.28, in the 
case where some architecture gets _Float128 support later than that.  And 
likewise using LDBL_IBM128_VERSION for __*ieee128 aliases if you add 
support for it being used as a new long double format.  And adding the 
support to glibc means increasing the minimum GCC version for building 
glibc for those ABIs to one that supports _Float128 for those ABIs.

-- 
Joseph S. Myers
joseph@codesourcery.com