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

[Jakub Jelinek <jakub@redhat.com>]

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?

	Jakub