Re: [lmi] [lmi-commits] odd/expm1_log1p 59fff893 4/4: Test gcc builtins for certain transcendentals

[Greg Chicares]

On 5/19/22 16:32, Vadim Zeitlin wrote:
> On Thu, 19 May 2022 06:37:38 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
> 
> GC> branch: odd/expm1_log1p
> GC> commit 59fff893554eff66f5dd097477a204f218692d7a
[...]
> GC>     Test gcc builtins for certain transcendentals
[...] 
>  I've tried expm1(1.01) with gcc versions from 8 to 11 under Linux and they
> all output the same value, which is the same one as you obtain
> (which is 3FFBEDFB5475CB01 as raw IEEE-754 64-bit or also 0x1.bedfb5475cb01
> using %a printf() specifier), so it doesn't seem like there is any
> difference between gcc versions,

That is good to know. Thanks.

> but there is indeed a difference of one
> ULP between Linux and MSW. Interestingly, MSVC also returns the same value
> (0x1.bedfb5475cb00) as MinGW, even though, AFAIK, MinGW does _not_ use its
> CRT for the maths functions implementation.

I carefully followed, and sometimes participated in, the development
of MinGW's C99 additions. If they're using code copied from illustrious
specialists of the 1970s, then their implementation may be highly
accurate, and perhaps even more accurate than glibc's. Later development
became less fastidious than I thought appropriate for standard library
implementation.

Here are some people who do seem fastidious:
  https://hal.inria.fr/hal-03141101/document
When they say, for example, that glibc-2.34's expm1(long double) is
accurate within 0.914 ulp, I would be inclined to suspect they're right,
at least if their final paper includes all the code needed to reproduce
their findings.

>  And I can also confirm that, rather disappointingly, __builtin_expm1()
> expands into just a call to expm1() instead of being directly inlined or
> anything like that.

In an ideal world, the silicon would give correctly-rounded results in
all cases, somebody would prove that by exhaustive comparison of all
2^mantissa_bits cases, and then it would be trivial for every compiler
to inline them directly. We just haven't achieved that yet.