[PATCH 19/25] math: Use lgamma from CORE-MATH

[Adhemerval Zanella Netto]

On 10/09/25 17:52, DJ Delorie wrote:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
>> diff --git a/math/Makefile b/math/Makefile
>> index aecbf8cc80..f03a368064 100644
>> --- a/math/Makefile
>> +++ b/math/Makefile
>> @@ -206,8 +206,6 @@ libm-calls = \
>>    e_sqrtF \
>>    gamma_productF \
>>    k_tanF \
>> -  lgamma_negF \
>> -  lgamma_productF \
>>    s_asinhF \
>>    s_atanF \
>>    s_cbrtF \
>> @@ -346,6 +344,8 @@ type-ldouble-routines := \
>>    k_cosl \
>>    k_sincosl \
>>    k_sinl \
>> +  lgamma_negl \
>> +  lgamma_productl \
>>    s_iscanonicall \
>>    t_sincosl \
>>    # type-ldouble-routines
>> @@ -389,6 +389,8 @@ type-float128-routines := \
>>    k_cosf128 \
>>    k_sincosf128 \
>>    k_sinf128 \
>> +  lgamma_negf128 \
>> +  lgamma_productf128 \
>>    t_sincosf128 \
>>    # type-float128-routines
>>  type-float128-yes := float128
> 
> If I compare libm.a before/after this patch set, the after one is
> missing some functions:
> 
> __lgamma_neg
> __lgamma_product
> 
> The libm.so lists are the same, though.  libm.a's weak symbols didn't
> change either.  Is this change intentional?
> 
> Has the ABI been checked on a float-96 target?

Did you make from a clean build? If you are doing an incremental build,
where you build glibc, apply the patch, and rebuild; I think our make
rules will not regenerate the intermediaries files and will add lingering
files on the resulting libm.a.

On x86_64 the libm.a should only have:

$ objdump -t math/libm.a | grep __lgamma_neg
0000000000000000         *UND*  0000000000000000 __lgamma_negf128
0000000000000000         *UND*  0000000000000000 __lgamma_negl
0000000000000000 g     F .text  00000000000009c2 __lgamma_negf128
0000000000000000 g     F .text  000000000000077f __lgamma_negl

Which represents the required helper function to ldbl-96 and float-128
on x86.

> 
>> +  if (fabs (fh) < 0x1.8p-2)
>> +    {
>> +      if (fabs (fh) < 0x1.74p-4 && sx > -2.61 && sx < -2)
> 
> Does it matter that -2.61 isn't perfectly describable in IEEE?  Should a
> 0xFOOpB be used here?  It doesn't look like it, but checking anyway.
> 
>> +      else if (fabs (fh) < 0x1.168p-4 && sx > -3 && sx < -2.61)
> 
> And here ;-)

Ack, current practices for math code is to use hexadecimal float constants.
I will change it.


> 
>> +      double zh = 1.0 / xh, dz = *xl * zh, zl = (fma (zh, -xh, 1.0) - dz) * zh;
> 
> Dangerously long line
> 

Ack.