[PATCH newlib v1 0/4] Add FreeBSD long double functions

[Corinna Vinschen]

On Aug 24 08:40, Joel Sherrill wrote:
> On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen <vinschen@redhat.com>
> wrote:
> > > [...]
> > >   if architecture has _fpmath.h
> > >      use FreeBSD long double code in libm/common/ldbl
> > >   else
> > >      use existing long double code
> >
> > Erm... Did you actually read my last reply?
> 
> 
> Yes. If we do that, we end up with long double support on 8
> architectures and lose it immediately on all others. On the
> 18 RTEMS target architectures,
> 
> + Current: long double support on 12
> + Proposed: long double support on all
> + Delete ldbl=dbl implementation: 8 would have long double
> 
> 
> We should really not add YA
> > code path.  Merging the FreeBSD long double functions should work for
> > basically all supported arches.  We only have to create our own
> > _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it?
> >
> 
> It should if someone creates all the _fpmath.h headers.

No, I wrote, create a *single* _fpmath.h file with the massive amount
of definitions (*all* seven) based on LDBL_MANT_DIG.

There are very few special targets, like x86/x86_64 which need a tweak
in the macros, most of the time the macros should be the same.

Instead of having 61 files, only have one.  In theory there should be
only two definitions for targets with LDBL_MANT_DIG == DBL_MANT_DIG
to support little and big endian, more shouldn't be required.

For all others, we already have *ieee*.h files with matching definitions
which can be used as role models for the various (but few) definitions of
union IEEEl2bits.  See, for instance, newlib/libc/include/machine/ieee.h.

> There are 61
> directories under libc/machine. That leaves 53 _fpmath.h headers to
> complete and most are likely ldbl==dbl. That is up to 53 target
> architectures
> which would lose the long double math APIs in libm.a.
> 
> Honestly, I don't mind long term planning to delete them but I was
> thinking this approach improves the current situation a lot since it will
> support the targets which really have long double support. It leaves
> in place support for where ldbl==dbl with no change in available APIs.
> It is a net win for users.
> 
> If there is a target with long double which doesn't have a FreeBSD
> _fpmath.h file, then there is value in creating it.  Honestly, unless
> someone
> can script writing the missing 50+ _fpmath.h files, I am not comfortable
> or eager to dive in. Ignoring the lack of time to so.
> 
> This approach works and doesn't abandon the targets which the
> ldbl==dbl method works for.

I never said to abandon these targets, but fwiw, I think you're
overestimating the complexity to generate a single _fpmath.h
file with matching definitions for these targes as well.  The
information is basically already present in newlib.

Jeff, ping?  Your POV would be much appreciated here.


Thanks,
Corinna