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:20 AM To: j...@rtems.org Cc: rtems-us...@rtems.org <users@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@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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
