Re: Revisiting More Complete long double Support

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

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.

> > > (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