[PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h
Joseph Myers
joseph@codesourcery.com
Mon Sep 6 16:31:12 GMT 2021
On Sun, 5 Sep 2021, Sandra Loosemore wrote:
> Unless the aarch64 maintainers think it is a bug that __float128 is not
> supported, I think the right solution here is the one I was thinking of
> previously, to fix the Fortran front end to tie the C_FLOAT128 kind to
> _Float128 rather than __float128, and fix the runtime support and test cases
> accordingly. Then there should be no need to depend on quadmath.h at all.
> C_FLOAT128 is a GNU extension and _Float128 is supported on a superset of
> targets that __float128 is, so there should be no issue with backward
> compatibility.
gfc_build_intrinsic_lib_fndecls (at least) knows about the "q" function
naming in libquadmath, and I think will result in gfortran generating
calls to *q functions in some cases.
I think there are at least three cases involved:
(a) long double has the IEEE binary128 format. In that case, the *l
functions from libm can be used, with no need for libquadmath to be
involved at all. (It's still necessary to allow for the long double libm
functions possibly having a different assembler name, for the powerpc64le
case, but if the front end goes via built-in functions then it may not
need further code to handle that specifically; see
rs6000_mangle_decl_assembler_name.)
(b) long double does not have the IEEE binary128 format, but glibc
includes support for _Float128 functions (*f128) in libm for this target.
Whether that support is included depends on the architecture and glibc
version (glibc 2.26 or later needed; supported for
x86_64/x86/ia64/powerpc64le). If the glibc support is present (could be
tested using GCC_GLIBC_VERSION_GTE_IFELSE in configure to work properly
when bootstrapping a cross compiler), it would make sense for the Fortran
front end to use *f128 functions directly and so not depend on
libquadmath. But I don't think the Fortran front end actually has any
support for using *f128 functions at present.
It's possible some non-glibc libraries also support *f128 or will do so in
future (those are the standard names in TS 18661-3 / C23). However, you
can't do configure tests of compiling/linking with target libraries when
configuring front ends, only grep headers or use information about the
configured target triplet or configure options (which is more or less what
GCC_GLIBC_VERSION_GTE_IFELSE does), so I don't think there's anything that
could readily be done to allow using *f128 from non-glibc libm
automatically if such libm gains support for those functions in future.
(c) __float128 is supported, different format from long double, but glibc
does not have _Float128 functions (too old) or a non-glibc libm is in use.
This is the only case where libquadmath is actually relevant.
(libquadmath code is based on glibc, with some support
(update-quadmath.py) for updating parts of that code from glibc sources
automatically (most of the parts based on glibc libm, but not the string
conversion parts). In practice, it's likely that changes to
update-quadmath.py would be needed as part of such an update.)
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Gcc-patches
mailing list