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

[Segher Boessenkool <segher@kernel.crashing.org>]

On Wed, Oct 06, 2021 at 05:13:59PM +0000, Joseph Myers wrote:
> 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.

Good point.  And we can simply require -maltivec for -mfloat128 to work.
We currently require -mvsx, which itself requires -maltivec, so that is
not a restriction.

> > 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).

I vote for the latter: require -maltivec.  Well unless -msoft-float
perhaps, if someone ever cares enough to implement that for QP float :-)

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

Soft float is not described in any formal ABI btw (well, except the
Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
Which does not work over function calls, but that is how it always has
been.

This never was a huge problem afaik.

For 32-bit, maybe we can just require -maltivec as well, to allow
-mfloat128?  Or use what -msoft-float would do for _Float128, if
-mno-altivec, if desired (this does not have to be limited to -m32 of
course).

> 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.

Glibc is outside of my direct influence sphere ;-)  This does sound like
a reasonable plan to me though.


Segher