Re: [PATCHv2 3/7] ldbl-128ibm-compat: Add tests for IBM long double functions

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 17 Feb 2020, Paul E. Murphy wrote:

> The reason for the awkward __LONG_DOUBLE_USES_FLOAT128 test is that GCC 7
> compilers can (and do via later patchsets) get invoked with
> "-mabi=ieeelongdouble" and without "-mfloat128".  GCC 7 treats this
> as not having _Float128 and thereby __HAVE_DISTINCT_FLOAT128 == 0.

Why are you building without -mfloat128?

Normally, code built with GCC 7 can expect that, if long double has the 
binary128 format, _Float128 is also available.  Having powerpc64le (only) 
break that invariant seems a bad idea.  I think you should make sure that 
__HAVE_FLOAT128 and __HAVE_DISTINCT_FLOAT128 both are defined to 1 (that 
you compile with options causing them to be defined to 1) when building 
any parts of glibc that use binary128, rather than working around them 
being defined to 0.

> -#if FLT128_MANT_DIG == LDBL_MANT_DIG
> +/* __LONG_DOUBLE_USES_FLOAT128 is used instead of __HAVE_DISTINCT_FLOAT128
> +   because GCC 7 compilers can support IEEE 128 long double without
> +   outwardly supporting _Float128.  When minimum GCC is raised to 8, this
> +   check can be replaced.  */

Any place where something can be simplified when the minimum GCC version 
is increased should have a conditional using __GNUC_PREREQ, not just a 
free-form comment; that's the only way we can effectively find all such 
places when increasing the minimum GCC version.

> +/* _Float128 unconditionally redirects to lgamma.  Ensure the ULPs do too.  */
> +# define gamma lgamma

Rather than a hack like this, I think you should do one of the following:

* Just all the float128 ulps for gamma to the relevant libm-test-ulps 
file.

* Properly implement ulps sharing in the libm-test machinery for all cases 
where tests of more than one function use the same table of tests, and 
update all libm-test-ulps files accordingly.

-- 
Joseph S. Myers
joseph@codesourcery.com