On Mon, 4 Oct 2021, 15:14 Jakub Jelinek via Gcc, <gcc@gcc.gnu.org> wrote:
> 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?
All the new ieee128 support in libstdc++ is dependent on being built
against a new glibc. If you don't have a new glibc, you wish don't get any
C++ library support for ieee128. The SONAME doesn't change, but there are
additional symbols versions (and symbols) present in libstdc++.so.6 if
built against a new glibc.
>
>
