On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote:
> I am currently working on implementing the IEEE 128-bit floating
> on POWER. One of the things to decide is what to call the
> math functions for the library calls.
>
> Example: libgfortran/generated/bessel_r16.c currently has
>
> #if defined(GFC_REAL_16_IS_FLOAT128)
> #define MATHFUNC(funcname) funcname ## q
> #else
> #define MATHFUNC(funcname) funcname ## l
> #endif
>
> (This is actually generated from an m4 file).
>
> For the BesselJ functions, for example, either the library functions jnq
> or jnl will be called.
I think it depends.
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
&& defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define MATHFUNC(funcname) __ ## funcname ## ieee128
(i.e. use the functions that will be used when one uses e.g.
sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
if those need to be declared by libgfortran or math.h declares them).
Otherwise (when libgfortran is compiled against glibc older than 2.32)
it should use
#define MATHFUNC(funcname) funcname ## q
i.e. use the libquadmath APIs).
Now, when compiler itself actually emits calls like sinl etc. itself,
IMHO it should use solely those __ ## funcname ## ieee128 functions,
because that means either user uses explicit -mabi=ieeelongdouble
and at that point he needs to make sure he has glibc 2.32 or later,
or the compiler is configured to default to -mabi=ieeelongdouble and
user doesn't use -mabi=ibmlongdouble (then presumably again user has to
make sure glibc 2.32 or later is used).
The reason to use libquadmath as fallback inside of libgfortran is so that
one can build gcc against older glibc and keep the libgfortran ABI,
and then use the compiler against newer glibc (or the older glibc assuming
ibmlongdouble is used).
Jakub
