Re: round() on arm vs aarch64

Joel Sherrill <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <CAF9ehCVNR8bP0TReoyLe4hBU7YCT1i-jm4-XQsRtmMYrBPCPvA@mail.gmail.com>
On Tue, Nov 15, 2022 at 9:58 AM Stephanos Ioannidis <[email protected]>
wrote:

> On Tue, 2022-11-15 at 09:38 -0600, Joel Sherrill wrote:
> > Digging a bit, I noticed a huge block of <cmath> is ifdef'ed out for
> > aarch64.
> > I found the file c++config.h which is different between the two.
> >
> > Based on the diff of the arm and aarch64 versions, arm has
> >  _GLIBCXX_USE_C99_MATH_TR1 defined but aarch64 does not.
> >
> > I have no idea where the settings in this file come from but this
> > appears to be the key difference.
> >
> > More insight appreciated.
>
> Funny how I came across a similar issue today. The following link might
> be of help in understanding what is going on:
>
>
> https://github.com/zephyrproject-rtos/sdk-ng/issues/566#issuecomment-1315165640


Thanks for the quick reply. It is a shame that the lack of long double
methods
prevents the entire TR1 from being there. Wouldn't it be ok to just have the
prototypes and let the user get a link error?

Anyway, I have been very very slowly picking at newlib long double support
but haven't gotten a complete patch set that is acceptable. See
https://sourceware.org/newlib/ for the discussion. I am happy to share
my work in process.

As I recall, one of the sticking points is that the FreeBSD code has
long double support for architectures which have true long double but
nothing as far as I can tell for architectures where double == long double.
I was proposing a configure time selection of the current code for when
long double == double and use the imported FreeBSD code when there
is true long double support.

Making libstdc++'s configure probe more forgiving would be a nice step
but long term having complete long double support would be better.

How to progress?

--joel


>
> Regards,
>
> Stephanos
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.