On Fri, Aug 26, 2022 at 10:05 AM Corinna Vinschen <vinschen@redhat.com>
wrote:

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

So don't preserve the FreeBSD files as close to a direct copy
as possible?

Maybe I am overestimating it. I just don't see the single _fpmath.h
to rule them all with confidence like you do. I am not seeing the
set of parameters in my head which makes this generic with
some macros.

I'd appreciate help on this.


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

+1

I also have come across there needs to be a way to pick between ld80
and ld128 headers and implementation files. FreeBSD has them in
separate directories. Apparently their build system builds common
plus an architecture specific _fpmath.h and a choice of ld80/ld128
which adds at least two other header files

--joel

>
>
> Thanks,
> Corinna
>
>