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