Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (2nd patch)

[Jakub Jelinek <jakub@redhat.com>]

On Sat, Oct 30, 2021 at 11:30:29AM +0200, Thomas Koenig wrote:
> - Have a compiler switch which selects between IEEE_QP and IBM_QP.
>   This was a suggestion by Steve Lionel formerly of DEC and Intel,
>   and they did that when they had a few floating point formats on
>   the Alpha to choose from.  We would then have to specially annotate
>   the KIND=16 library routines, and also maybe indicate the different
>   argument types in module files.  Anything else would be user error.
>   They also had the CONVERT options to go with it.
> 
> Question: Which option would we want to pursue?  I actually think the
> fourth one (the suggestion by Steve Lionel) is the best one.

That was the last option I was mentioning in the initial mail
https://gcc.gnu.org/pipermail/gcc/2021-October/237478.html

Copying it here:

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

That solution would most closely match what we do e.g. for C/C++, especially
libstdc++ or glibc, we already have an option to select that -
-mabi=ibmlongdouble vs. -mabi=ieeelongdouble and default selected during
configure.  libgfortran would be ABI compatible with both ABIs, but user
binaries or libraries wouldn't be.  Similarly to C, there is no different
mangling of user symbols.

	Jakub