[PATCH] Update powerpc libm-test-ulps

[Matheus Castanho]

On 8/20/20 6:25 PM, Carlos O'Donell wrote:
> On 8/20/20 3:44 PM, Tulio Magno Quites Machado Filho wrote:
>> 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;
> 
> Thanks. I didn't know that.
> 
>>>
>>> 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.
> 
> If the loss of precision is due to the implementation then it seems like using
> an XFAIL is not an accurate representation of the state.
> 
>> 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
>  
> Interesting patch, it looks similar to what we do in glibc for some of the
> libm functions.
> 

What do you think we should do in this case? Looks like with the libgcc
patch Tulio mentioned we can actually calculate the correct ULPs for
ibm128, but we would not be able to get that same precision when
building with a regular GCC, which would still cause issues.

So should we:
1. Use max precision ULPs calculated with the patched libgcc?
	This would probably require adding xfail-rounding:ibm128-libgcc to
several entries in auto-libm-test-in to guarantee tests pass with
regular GCC.

2. Do (1) only for entries that have ULPs higher than a threshold (say,
9 or 16)?

3. Apply the patch as-is?

4. Other?

--
Matheus Castanho