public inbox for
 help / color / mirror / Atom feed
From: Corinna Vinschen <>
To: Joel Sherrill <>, Jeff Johnston <>
Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions
Date: Fri, 26 Aug 2022 17:05:12 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Aug 24 08:40, Joel Sherrill wrote:
> On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen <>
> 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.


  parent reply	other threads:[~2022-08-26 15:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 22:50 Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 1/4] Add infrastructure for incorporating FreeBSD long double methods Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 2/4] and configure: Regenerated Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 3/4] Split libm/common/frexpl.c into LDBL_EQ_DBL and long double versions Joel Sherrill
2022-08-22 22:50 ` [PATCH newlib v1 4/4] Regenerated Joel Sherrill
2022-08-24  9:26 ` [PATCH newlib v1 0/4] Add FreeBSD long double functions Corinna Vinschen
2022-08-24 13:40   ` Joel Sherrill
2022-08-24 13:40     ` Joel Sherrill
2022-08-26 15:05     ` Corinna Vinschen [this message]
2022-08-26 15:45       ` Joel Sherrill
2022-08-26 15:45         ` Joel Sherrill
2022-08-26 17:45         ` Corinna Vinschen
2022-08-26 20:45           ` Jeff Johnston
2022-08-26 20:45             ` Jeff Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).