Revisiting More Complete long double Support

[Joel Sherrill]

On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

> On Aug 17 17:06, Joel Sherrill wrote:
> > Hi
> >
> > I'm looking at newlib long double support again when sizeof(long double)
> !=
> > sizeof(double).
> >
> > (1) Merged FreeBSD C code for long double math
> >
> > FreeBSD has C code for long double math routines as default
> implementation:
> >
> > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/src
> >
> > I **THINK** those will work if LDBL != DBL so that code might need the
> > ifdef for LDBL_EQ_DBL to pick the current newlib common implementation of
> > the method which just calls the normal version of the method.  I code
> even
> > add the files as XXX_freebsd.c and only add
> >
> > ifdef _LDBL_EQ_DBL
> > long double
> > acosl (long double x)
> > {
> >   return acos(x);
> > }
> > #else
> > #include "acosl_freebsd.c"
> > #endif
> >
> > which would definitely avoid edits to the FreeBSD source.
>
> Question is, do we really still need this?
>
> These #ifdef have been added just as a cheap workaround for small
> targets, because nobody provided the actual long double implementations,
> yet.  If we merge the actual long double implementations from FreeBSD,
> there's no need for this anymore and we can probably drop the
> _LDBL_EQ_DBL flag entirely.
>

I think that's hopeful thinking although I like the idea of importing the
FreeBSD code. I have attached a slightly updated version of the script
I used to probe which targets were  _LDBL_EQ_DBL. Two yes'es means
that _LDBL_EQ_DBL implementation is used. Two no's means that
it needs a real long double implementation -- if my script and probe program
are correct.

has_long_double]$ sh j
     TARGET       in lib ldbl=dbl
================= ====== ========
   aarch64-rtems6     no     no
       arm-rtems6    yes    yes
      bfin-rtems6    yes    yes
      i386-rtems6     no     no
      lm32-rtems6    yes    yes
      m68k-rtems6     no     no
microblaze-rtems6    yes    yes
      mips-rtems6    yes    yes
     moxie-rtems6    yes    yes
     nios2-rtems6    yes    yes
      or1k-rtems6    yes    yes
   powerpc-rtems6    yes    yes
     riscv-rtems6     no     no
        sh-rtems6    yes    yes
   sparc64-rtems6     no     no
     sparc-rtems6    yes    yes
      v850-rtems6    yes    yes
    x86_64-rtems6     no     no

Hopefully that aligns ok on your side. Most of the targets seem to be able
to legitimately use the current _LDBL_EQ_DBL implementations.

What about two directories of long double implementations. One
is for _LDBL_EQ_DBL and the other is the FreeBSD code. I think
libm/Makefile.inc already has an example of picking one of two
directories based on an automake flag. Adding one for to reflect
_LDBL_EQ_DBL and picking either one of the two long double
math implementation directories should work.

Names are always an issue. I have no ideas for good names for
the directories. Something somewhat horrible like
common/ldbl_eq_double and common/ldbl are the best I have.


> If we just merge the long double code from FreeBSD's lib/msun/src
> into our libm/common dir...
>

Maybe a subdirectory or parallel directory so we can keep the
_LDBL_EQ_DBL where it is needed.

>
> > (2) More i386 assembly versions
> >
> > Then there appears to be some long double methods for the i386/87 here
> > which newlib doesn't currently have:
> >
> > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/i387
> >
> > Thoughts on adding this long double code from FreeBSD?
>
> ...and merge the occasional CPU-specific assembler code from
> FreeBSD's lib/msun/<cpu> into our libm/machine/<cpu> dir, that
> should work nicely.
>

:)

I think you've said in the past that Cygwin has these but the
calling conventions are different. Is that something that has to
be taken into account in newlib?

--joel

>
>
> Corinna
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: has_long_double.tar.xz
Type: application/octet-stream
Size: 1548 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220818/91518310/attachment.obj>