Re: accuracy of mathematical functions

On Fri, Feb 5, 2021 at 5:01 PM Brian Inglis <[email protected]>
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.


>
> 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. :)

--joel


> --
> 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.]
>
> [Shame your CORE-Math proposal was rejected: desperately needed these
> days, as
> I've never been a math natural but often seemed more comfortable than
> other
> programmers doing related work.
> Maybe have to comb the literature on reproducible builds, need for
> verification
> no backdoors or vulnerabilities have been introduced, and testing results
> produced are identical across platforms; maybe comb Risks or contact PGN
> for
> math horror stories as references and justifications for resubmission.]
>