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

[Segher Boessenkool]

Hi Joseph,

On Mon, Oct 04, 2021 at 07:24:31PM +, Joseph Myers wrote:
> On Mon, 4 Oct 2021, Segher Boessenkool wrote:
> > Some current Power GCC targets support neither.  Some support only
> > double-double.  Making IEEE QP float work on those (that is, those that
> > are < power8) will require some work still: it should use libquadmath or
> > similar, but that needs to be put into the ABIs, to define how parameter
> > passing works for those types.  Just treating it like a struct or an
> > array of ints will work fine, but it needs to be written down.  This is
> > more than just Fortran.
> 
> Is the 64-bit BE (ELFv1) ABI maintained somewhere?  (The 32-bit ABI, 
> covering both hard float and soft float, is 
>  - no activity lately, but I think 
> Ryan said he'd given write access to someone still involved with Power.)

The last release (version 1.9) was in 2004.  If there is interest in
making updates to it that coulde be done of course, it is GFDL, there is
no red tape getting in the way.

Maybe this could be maintained in the same repository even?


Segher

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

[Thomas Koenig via Gcc]

On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:

Based on some IRC discussion, yet another option would be bump libgfortran
SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
always IEEE quad (starting with GCC 12) and if wanted add support for
real(kind=15) meaning double double.



Bumping the SONAME for everybody even on architectures which are
not affected (like x86 or ARM) does not really feel right.  We will
probably have to do it sooner or later, at least to get PDTs right
(and for array descriptor reform), but we will then have to
do another SONAME change when we do that (it is certainly not
ready now).

There is also the issue of binary data.  If some user has written
out data in double double and wants to read it in as IEEE quad,
the results are going to be garbage.  Another option for CONVERT
might be the solution to that, or, as you wrote, having a
REAL(KIND=15).  It should be inaccessible via SELECTED_REAL_KIND,
though.

Hmm...

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

[Jonathan Wakely via Gcc]

On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc,  wrote:

> On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek via Gcc wrote:
> > Or the last option would be to try to make libgfortran.so.5 ABI
> compatible
> > with both choices on powerpc64le-linux.  From quick skimming of
> libgfortran,
> > we have lots of generated functions, which use HAVE_GFC_REAL_16 and
> > GFC_REAL_16 etc. macros.  So, we could perhaps arrange for the compiler
> > to use r16i or r17 instead of r16 in the names when real(kind=16) is the
> > IEEE quad on powerpc64le and keep using r16 for the IBM double double.
> > For the *.F90 generated files, one could achieve it by making sure
> > the *r16* files are compiled with -mabi=ibmlongdouble, for
> > *r16i* or *r17* with -mabi=ieeelongdouble and otherwise use kind=16 in
> > those, for *.c generated files the *GFC_* macros could just ensure that
> > it doesn't use long double but __ibm128 or __float128 depending on which
> one
> > is needed.
> > But then I see e.g. the io routines to just pass in kind and so
> > switch (kind) // or len
> >   {
> >   case ...:
> > *(GFC_REAL_*) = ...;
> >   }
> > etc.  Could we just pretend in the compiler to libgfortran ABI that
> > powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> > would actually think it is 17 bytes it uses 16 instead (though, kind=10
> > on x86-64 or i686 also isn't 10 bytes but 16 or 12, right?).
> >
> > Your thoughts on this?
>
> Based on some IRC discussion, yet another option would be bump libgfortran
> SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> always IEEE quad (starting with GCC 12) and if wanted add support for
> real(kind=15) meaning double double.
> libgfortran would then on powerpc64le-linux use -mabi=ieeelongdouble to
> make
> sure that regardless of the long double choice for C/C++ (whether default
> configure time selection or explicit -mabi=*) GFC_REAL_16 is the __float128
> long double.
> One problem with that is that I think IEEE quad long double support relies
> on glibc 2.32 or later, so not sure what exactly would be done if gcc is
> built against older glibc when it needs to call libm routines.  Perhaps
> convert to __ibm128, call the __ibm128 sinl etc. and convert back (big loss
> of precision and range, but at least something).
>
> What does libstdc++ do there?


All the new ieee128 support in libstdc++ is dependent on being built
against a new glibc. If you don't have a new glibc, you wish don't get any
C++ library support for ieee128. The SONAME doesn't change, but there are
additional symbols versions (and symbols) present in libstdc++.so.6 if
built against a new glibc.


>
>

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

[Segher Boessenkool]

Hi!

On Tue, Oct 05, 2021 at 10:16:47PM +0200, Thomas Koenig wrote:
> On 04.10.21 16:14, Jakub Jelinek via Fortran wrote:
> >Based on some IRC discussion, yet another option would be bump libgfortran
> >SONAME (on all arches), make real(kind=16) on powerpc64le-linux mean
> >always IEEE quad (starting with GCC 12) and if wanted add support for
> >real(kind=15) meaning double double.
> 
> Bumping the SONAME for everybody even on architectures which are
> not affected (like x86 or ARM) does not really feel right.  We will
> probably have to do it sooner or later, at least to get PDTs right
> (and for array descriptor reform), but we will then have to
> do another SONAME change when we do that (it is certainly not
> ready now).

You do not have to change soname more than once per release.

You could leave it at the old value for archs not affected.  It is good
for everyone's sanity to keep the same numbers for all archs though, so,
just skip some for some archs.

Everyone who uses -static won't be hurt either way.

> There is also the issue of binary data.  If some user has written
> out data in double double and wants to read it in as IEEE quad,
> the results are going to be garbage.  Another option for CONVERT
> might be the solution to that, or, as you wrote, having a
> REAL(KIND=15).  It should be inaccessible via SELECTED_REAL_KIND,
> though.

That means flipping the default on all PowerPC to no longer be double-
double.  This means that you should have IEEE QP work everywhere, or the
people who do need more than double precision will have no recourse.

It will be great if you can do this at the same time, get all the pain
over with at the same time, have better results for everyone.  Heck, you
only need the "kind=15" for compatibility then.

People who have data stored in the old format will be in a tough spot
no matter what.  Presumably everyone will want to convert to the
standard format at some point.


Segher