[glibc] powerpc: Update acosf ulps

[Adhemerval Zanella Netto]

On 02/01/25 09:29, Alexander Monakov wrote:
> 
> On Thu, 2 Jan 2025, Alexander Monakov wrote:
> 
>> Hello Paul,
>>
>> On Thu, 2 Jan 2025, Paul Zimmermann wrote:
>>
>>>        Hi Florian,
>>>
>>>> Isn't the new acosf implementation supposed to be correctly rounded?
>>>
>>> yes, but due to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245,
>>> the new implementation might be miscompiled by gcc < 12.
>>
>> can you kindly point me where the new acosf employs problematic conversions?
> 
> Ah, this is answered in a change that was not carried over from core-math
> to Glibc. It's in 'return (float) pi2;' where pi2 is a 'const double' local.
> 
>> I see a couple of instances where the 'f' suffix is missing, producing a
>> double literal where a float could work as well:
>>
>>  * in as_special there is
>>
>>   const float pih = 0x1.921fb6p+1;
>>
>>  * and in __ieee754_acosf, in 0x1p-25:
>>
>>       if (t == 0x328885a3u)
>>        return 0x1.921fb6p+0f + 0x1p-25;
>>       if (t == 0x39826222u)
>>        return 0x1.920f6ap+0f + 0x1p-25;
>>  
>> but I don't see any instance where a double-precision constant is converted
>> to float such that result depends on rounding mode.
>>
>> I'm guessing the '+ 0x1p-25' trick above is a workaround for this exact bug?
> 
> I should clarify: without the 'f' suffix, the summation happens in 'double'
> and triggers the GCC bug upon conversion to float. But with the 'f' suffix,
> addition of 0x1p-25f is done at runtime, producing the necessary rounding.

Thanks, I will check and sync with CORE-MATH to fix this issue.

> 
>> Also, should the above instances be fixed to use float literals?
>>
>> Thank you.
>> Alexander
>>