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

[Joel Sherrill]

On Wed, Feb 17, 2021 at 10:34 AM Nkwocha, Noble N. (IVV-1800) <
noble.n.nkwocha at 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
currently does not have libm long double methods. There is an RTEMS ticket
to locate and
port them from some BSD.  Only aarch64, i386, riscv, and x86_64 can be
depended on to
have hardware 128-bit float support. On all others (except m68k), long
double is the same
type as double from GCC and newlib has long double libm methods that just
rename the
double one to the long double name..

m68k is a bit odd in that you only have true 128-bit long double support if
the MC68881
FPU support is present which is basically 68020 w/FPU, 68030, 68040, and
68060. The
5282 or other Coldfires do not have hardware 128-bit long double support,
Long double
is the same as double. In this family, it varies by cpu model and when
possible, the static
inline versions from math-68881.h are used.

I **think** this is strictly a matter of a C++ wrapper change. The long
double support
in newlib has been stable for a LONG time.

--joel


>
> What happens to backward-compatibility?
>


>
> Thank you,
> Noble
>
>
>
> -----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
>
> https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.rtems.org%2Fmailman%2Flistinfo%2Fusers&data=04%7C01%7Cnoble.n.nkwocha%40nasa.gov%7Cce534ba45de646800b5d08d8d35ff04f%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C637491756316082153%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=AAyFjKv2KNCaYpCHeMhTQf37eAVcYJIY%2BDrqSoli2JM%3D&reserved=0
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210217/bc774c0b/attachment.html>