Re: Revisiting More Complete long double Support

[Joel Sherrill <joel@rtems.org>]

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

> On Aug 18 09:49, Joel Sherrill wrote:
> > On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen wrote:
> > > On Aug 17 17:06, Joel Sherrill wrote:
> > > > [...]
> > > > 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.
>
> They might be able to use it, but if so, they are only able to do so
> since 2009.  It was really just a cheap trick to allow calling long
> double functions on targets which don't require a real long double lib.
> As you may remember, it's not the first time we talk about long double
> functions...
>

Yeah. I have been tracking newlib/RTEMS against various FACE
Technical Standard POSIX profiles. fenv was also part of the missing
functionality. The long double math is the bulk of what's left to address.

>
> However, if we have a *real*, generic implementation of all long double
> functions, there's just no need to keep up with the _LDBL_EQ_DBL hackery.
>

Agreed. If the FreeBSD code works when _LDBL_EQ_DBL and when it isn't.
I honestly can't tell by looking at the FreeBSD e_acosl.c,

I'll put it in my todo list to experiment to see what happens just
replacing it.

If someone sees an obvious problem, please speak up.

If it doesn't work, then falling back to the current implementations may be
needed. But we can try to avoid it.

>
> > > > (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?
>
> No worries. It wouldn't matter for i386, but we dropped 32 bit support
> in master anyway.  For x86_64, Cygwin uses the Windows AMD64 calling
> convention, so we can't use the assembler functions using the standard
> calling convention there.
>
> As a side note, I added x86_64 assembler memcpy/memset functions from
> FreeBSD to Cygwin at one point.  The code is untouched, I just added
> wrapper code which reshuffles the arg registers according to the
> different calling conventions.
>
> That could help using the FreeBSD x86_64 long double functions for
> Cygwin, too, using wrapper macros or something like that.  However, the
> Mingw64 long double functions work nicely for a couple of years, so
> there's no reason to force this.  We're sticking to the Mingw64
> functions in Cygwin for the time being.
>
>
> Corinna
>
>