Is the plan proposed here going to preclude "long double" type implementations
in RTEMS 5.1?
What happens to backward-compatibility?
Thank you,
Noble
-Original Message-
From: users [mailto:users-boun...@rtems.org] On Behalf Of Michael Davidsaver
Sent: Wednesday, February 17, 2021 11
On Wed, Feb 17, 2021 at 10:34 AM Nkwocha, Noble N. (IVV-1800) <
noble.n.nkwo...@nasa.gov> wrote:
>
> Is the plan proposed here going to preclude "long double" type
> implementations in RTEMS 5.1?
>
On some architectures, the hardware really supports 128-bit floating point.
For those, newlib
curre
On 2/17/21 7:34 AM, Joel Sherrill wrote:
> And indeed adding -std=c++98 seems to be a workaround.
>
>
> EPICS most likely should use a newer C++ standard than that. C++03 is
> C++98 with corrections. But it does not have long long because C++98
> definition predated C99 finalization and C99
On Wed, Feb 17, 2021 at 1:16 AM Michael Davidsaver
wrote:
> FYI. Excluding the c++ part shows that acoshl() and friends are never
> defined.
>
> > $ cat mtest.c
> > #include
> >
> > long double x(long double a) { return acoshl(a); }
>
> From the newlib math.h:
>
> > /* Newlib doesn't fully supp
