[PATCH] Update powerpc libm-test-ulps

[Tulio Magno Quites Machado Filho]

Adhemerval Zanella via Libc-alpha <libc-alpha@sourceware.org> writes:

> On 20/08/2020 15:39, Carlos O'Donell wrote:
>> On 8/20/20 2:37 PM, Matheus Castanho via Libc-alpha wrote:
>>> Before this patch, the following tests were failing:
>>>
>>> ppc and ppc64:
>>>     FAIL: math/test-ldouble-j0
>>>
>>> ppc64le:
>>>     FAIL: math/test-ibm128-j0
>>> ---
>>>  sysdeps/powerpc/fpu/libm-test-ulps | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/sysdeps/powerpc/fpu/libm-test-ulps b/sysdeps/powerpc/fpu/libm-test-ulps
>>> index cd2a5fed45..0b82c3f107 100644
>>> --- a/sysdeps/powerpc/fpu/libm-test-ulps
>>> +++ b/sysdeps/powerpc/fpu/libm-test-ulps
>>> @@ -1317,13 +1317,13 @@ Function: "j0_downward":
>>>  double: 2
>>>  float: 4
>>>  float128: 4
>>> -ldouble: 11
>>> +ldouble: 12
>>>  
>>>  Function: "j0_towardzero":
>>>  double: 5
>>>  float: 6
>>>  float128: 2
>>> -ldouble: 8
>>> +ldouble: 16
>> 
>> We should not have ULPs higher than 9.
>> 
>> I see Adhemerval added some 11 ULPs here for cexp.
>> 
>> We should be able to achieve <= 9 ULPs on these algorithms, otherwise there are
>> compiler problems that need fixing?
>
> We are more forgiving for IBM long double due its inherent precision issues:
>
> math/libm-test-support.c
>
>  228   if (testing_ibm128)
>  229     /* The documented accuracy of IBM long double division is 3ulp
>  230        (see libgcc/config/rs6000/ibm-ldouble-format), so do not
>  231        require better accuracy for libm functions that are exactly
>  232        defined for other formats.  */
>  233     max_valid_error = exact ? 3 : 16;
>  234   else
>  235     max_valid_error = exact ? 0 : 9;
>
> And jN implementation also has low precision for some inputs.  With both constraints
> I think 16ulps should be ok.

There is also a loss of precision with different rounding modes in libgcc.

There are currently 30 entries for ibm128 with ULP between 10 and 16 (without
counting this patch).  Maybe some of these should actually be marked as
xfail-rounding:ibm128-libgcc instead.

The only way to validate this is by compiling glibc with a libgcc that has a
patch from Joseph.  I have an up-to-date version of that patch in
https://github.com/tuliom/gcc/commit/ca42479cae3c2b56651c3e97bb5eeaf24ca4bb61

-- 
Tulio Magno