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 jos...@codesourcery.com