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
