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

[Thomas Koenig <tkoenig@netcologne.de>]

Hi Jakub,

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

That is quite doable.

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

Yep.

> 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 is not something I would like to have, for purposes of cleanness.
We can always switch at run-time to a different function.  This
branch should be rather well-predicted, and additional execution
will be insignificant compared to the rest of the I/O.

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

Hm, there's a difference.  I meant that we can select this at compile
time for the user, and we should at least consider adding a flag to
the module files if the routine has been compiled for IBM_QP or IEEE_QP.
We should not change the mangling of the routine names themselves,
I agree.

Best regards

	Thomas