Re: accuracy of mathematical functions

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

On 2021-02-05 16:46, Joel Sherrill wrote:
> On Fri, Feb 5, 2021 at 5:01 PM Brian Inglis wrote:
>> On 2021-02-05 03:43, Paul Zimmermann wrote:
>>> I have updated my comparison with the newly released 2.33 version.
>>> No big difference with the previous version, except that I included
>>> the "long double" format (aka ldbl-96), which is not supported by Newlib.
>>>
>>> https://members.loria.fr/PZimmermann/papers/#accuracy
>>
>> Thanks for doing this work and making it available is greatly appreciated.
>>
>> While newlib is mainly targeted to smaller platforms, the Cygwin port math
>> library supports gcc __FLT64X_...__/__FLT128_...__ under
>> .../newlib-cygwin/winsup/cygwin/math/ and related includes.

> Any thoughts on what's required to have long double support on the targets 
> where long double != double? Someone was recently cleaning up the warnings 
> from the RTEMS tests which check that the headers match POSIX's man page and
> I generated this list of architectures from the RTEMS tools and which have 
> long double support in libm.a
> 
> no  aarch64-rtems6
> yes arm-rtems6
> yes bfin-rtems6
> no  i386-rtems6
> yes lm32-rtems6
> no  m68k-rtems6
> yes microblaze-rtems6
> yes mips-rtems6
> yes moxie-rtems6
> yes nios2-rtems6
> yes or1k-rtems6
> yes powerpc-rtems6
> no  riscv-rtems6
> yes sh-rtems6
> no  sparc64-rtems6
> yes sparc-rtems6
> yes v850-rtems6
> no  x86_64-rtems6
> 
> It probably is a decent GSoC project if upstream sources for long double on
> some of those architectures can be identified for potential incorporation.
ARM aarch64 probably have c and S sources available, maybe recent PowerPC.

Cygwin sources appear to be from mingw-w64 and are PD, ZPL, or unspecified:

$cd ~/src/newlib-cygwin/winsup/cygwin/math/
$ egrep -c 'Zope|PD' *l.* | pr -4th ""
acoshl.c:1        complex_internal. floorl.S:1        nearbyintl.S:1
acosl.c:1         conjl.c:1         fmal.c:1          nextafterl.c:1
asinhl.c:1        copysignl.S:1     fmaxl.c:1         pow10l.c:0
asinl.c:1         coshl.c:1         fminl.c:1         powil.c:1
atan2l.c:1        cosl.c:1          fmodl.c:1         powl.c:1
atanhl.c:1        cosl_internal.S:1 frexpl.S:1        remainderl.S:1
atanl.c:1         cpowl.c:1         ilogbl.S:1        remquol.S:1
cabsl.c:1         cprojl.c:1        internal_logl.S:1 rintl.c:1
cacosl.c:1        creal.def.h:1     ldexpl.c:1        roundl.c:1
cargl.c:1         creall.c:1        lgammal.c:1       scalbl.S:1
casinl.c:1        csinl.c:1         llrintl.c:1       scalbnl.S:1
catanl.c:1        csqrtl.c:1        llroundl.c:1      sinhl.c:1
cbrtl.c:1         ctanl.c:1         log10l.S:1        sinl.c:1
ccosl.c:1         erfl.c:1          log1pl.S:1        sinl_internal.S:1
ceil.S:1          exp10l.c:0        log2l.S:1         sqrtl.c:1
ceill.S:1         exp2l.S:1         logbl.c:1         tanhl.c:1
cexpl.c:1         expl.c:1          logl.c:1          tanl.S:1
cimagl.c:1        expm1l.c:1        lrintl.c:1        tgammal.c:1
clog10l.c:1       fabsl.c:1         lroundl.c:1       truncl.c:1
clogl.c:1         fdiml.c:1         modfl.c:1
$ head ???10l.c
==> exp10l.c <==
#undef exp10l
#include <math.h>

long double
exp10l (long double x)
{
   return powl (10.0L, x);
}

==> pow10l.c <==
#undef pow10l
#include <math.h>

long double
pow10l (long double x)
{
   return powl (10.0L, x);
}

>> As you may already be aware, clang and gcc have added support for ARM 
>> __FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C 
>> https://en.wikipedia.org/wiki/F16C, and more compiler and library support 
>> are likely to follow, as they are already used in graphics and GPGPU
>> areas.
> 
> What would this require from newlib, if anything?  He asks ignorantly. :)

More of a comment to the OP for future exhaustive testing.

Indication of demand or need; arch and compiler support; adopt/adapt software 
library?

-- 
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 binary units and prefixes, physical quantities in SI.]