<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021 at 10:34 AM Nkwocha, Noble N. (IVV-1800) <<a href="mailto:noble.n.nkwocha@nasa.gov">noble.n.nkwocha@nasa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Is the plan proposed here going to preclude "long double" type implementations in RTEMS 5.1?<br></blockquote><div><br></div><div>On some architectures, the hardware really supports 128-bit floating point. For those, newlib </div><div>currently does not have libm long double methods. There is an RTEMS ticket to locate and </div><div>port them from some BSD. Only aarch64, i386, riscv, and x86_64 can be depended on to</div><div>have hardware 128-bit float support. On all others (except m68k), long double is the same </div><div>type as double from GCC and newlib has long double libm methods that just rename the</div><div>double one to the long double name..</div><div><br></div><div>m68k is a bit odd in that you only have true 128-bit long double support if the MC68881 </div><div>FPU support is present which is basically 68020 w/FPU, 68030, 68040, and 68060. The </div><div>5282 or other Coldfires do not have hardware 128-bit long double support, Long double </div><div>is the same as double. In this family, it varies by cpu model and when possible, the static </div><div>inline versions from math-68881.h are used.</div><div><br></div><div>I **think** this is strictly a matter of a C++ wrapper change. The long double support</div><div>in newlib has been stable for a LONG time.</div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What happens to backward-compatibility?<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thank you,<br>
Noble<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: users [mailto:<a href="mailto:users-bounces@rtems.org" target="_blank">users-bounces@rtems.org</a>] On Behalf Of Michael Davidsaver<br>
Sent: Wednesday, February 17, 2021 11:20 AM<br>
To: <a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a><br>
Cc: <a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
Subject: [EXTERNAL] Re: RTEMS 5.1: cmath compiler errors on m68k/uC5282<br>
<br>
On 2/17/21 7:34 AM, Joel Sherrill wrote:<br>
> And indeed adding -std=c++98 seems to be a workaround.<br>
> <br>
> <br>
> EPICS most likely should use a newer C++ standard than that. C++03 is<br>
> C++98 with corrections. But it does not have long long because C++98<br>
> definition predated C99 finalization and C99 has long long. GCC <br>
> accepts long long and ll format specifier on printf() but will <br>
> complain only if you turn on -pedantic.<br>
> <br>
> You probably should be using C++11 or C++14 (bug fixed C++11).<br>
<br>
This is the plan. When I say "workaround" there is an implied "temporary" as I expect that the underlying issue is fixable.<br>
<br>
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:<br>
<br>
> long double acoshl(long double) __attribute__((error("Not <br>
> implemented")));<br>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="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" rel="noreferrer" target="_blank">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</a><br>
</blockquote></div></div>