Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

[Joseph Myers <joseph@codesourcery.com>]

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