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

[DJ Delorie]

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?

> +  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 ;-)

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

Dangerously long line