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 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-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
