[EXTERNAL] Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282

Nkwocha, Noble N. (IVV-1800) noble.n.nkwocha at nasa.gov
Wed Feb 17 16:34:38 UTC 2021

Is the plan proposed here going to preclude "long double" type implementations in RTEMS 5.1?

What happens to backward-compatibility?

Thank you,

-----Original Message-----
From: users [mailto:users-bounces at rtems.org] On Behalf Of Michael Davidsaver
Sent: Wednesday, February 17, 2021 11:20 AM
To: joel at rtems.org
Cc: rtems-users at rtems.org <users at rtems.org>
Subject: [EXTERNAL] Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282

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 has long long. GCC 
> accepts long long and ll format specifier on printf() but will 
> complain only if you turn on -pedantic.
> You probably should be using C++11 or C++14 (bug fixed C++11).

This is the plan.  When I say "workaround" there is an implied "temporary" as I expect that the underlying issue is fixable.

The worst cases I can imagine are either patching out various "using ::acoshl" lines in the GCC cmath header or injecting some dummy definitions into the newlib math.h header like:

> long double acoshl(long double) __attribute__((error("Not 
> implemented")));
users mailing list
users at rtems.org

More information about the users mailing list