Fw: [PATCH 3/3] libm: Adjust errno/exception values for gamma/lgamma

[Brian Inglis]

On 2020-08-27 11:55, C Howland via Newlib wrote:
> On Wednesday, August 26, 2020 1:03 PM, Keith Packard wrote:
>> This makes all of gamma/lgamma functions match POSIX (and glibc) for
>> errno and exception values for both gamma and lgamma functions.
>>
>> The big change is to support the exception/errno value differences for
>> tgamma/lgamma for negative integer arguments. tgamma produces
>> EDOM/FE_INVALID while lgamma produces ERANGE/FE_DIVBYZERO.
>>
>> This was done by splitting the lowest level __ieee754_lgamma*_r
>> functions apart. The new lower-level ___ieee754_lgamma*_r functions
>> can now produce exceptions which are correct for either lgamma or
>> tgamma and use the value in the signgamp parameter to select which
>> mode to operate in.
>>
>> All functions now return EDOM/FE_INVALID for -INFINITY, although POSIX
>> doesn't specify this behavior for lgamma. It does match glibc at
>> least.

> I think you're looking at an old GLIBC.  From my RHEL7 lgamma() man  page:
> "       If the result overflows, a range error occurs, and the functions
> return
>        HUGE_VAL, HUGE_VALF, or HUGE_VALL, respectively, with the correct
> math‐
>        ematical sign.
> ...
> BUGS
>        In glibc 2.9 and earlier, when a pole error occurs,  errno  is  set
>  to
>        EDOM;  instead of the POSIX-mandated ERANGE.  Since version 2.10,
> glibc
>        does the right thing."
> POSIX has only pole and range errors listed for lgamma(), both of which
> return ERANGE, so it is definitely improper to return EDOM.  It should be
> range, so ERANGE/FE_OVERFLOW is what it ought to be.

RHEL7 uses an *old glibc* 2.17 from 2012, compared to Fedora Rawhide with latest
glibc release 2.32.

Check out the specs at the tops of the *current glibc* sources of the gamma
functions to be found nearby online under:

	https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/ieee754/dbl-64

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]