<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 1:16 AM Michael Davidsaver <<a href="mailto:mdavidsaver@gmail.com">mdavidsaver@gmail.com</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">FYI.  Excluding the c++ part shows that acoshl() and friends are never defined.<br>
<br>
> $ cat mtest.c <br>
> #include <math.h><br>
> <br>
> long double x(long double a) { return acoshl(a); }<br>
<br>
>From the newlib math.h:<br>
<br>
> /* Newlib doesn't fully support long double math functions so far.<br>
>    On platforms where long double equals double the long double functions<br>
>    simply call the double functions.  On Cygwin the long double functions<br>
>    are implemented independently from newlib to be able to use optimized<br>
>    assembler functions despite using the Microsoft x86_64 ABI. */<br>
> #if defined (_LDBL_EQ_DBL) || defined (__CYGWIN__)<br></blockquote><div><br></div><div>This is the current code and it does have some logic for __math_m68881 </div><div>but even though this code has changed, the 4.11 math.h includes similar </div><div>logic. I checked and _LDBL_EQ_DBL is defined in newlib.h and the setting </div><div>is the same for 4.11 and 5 tools.</div><div><br></div><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>
Looking to the GCC cmath header I find.<br>
<br>
> #if __cplusplus >= 201103L<br>
> <br>
> #ifdef _GLIBCXX_USE_C99_MATH_TR1<br>
<br>
And indeed adding -std=c++98 seems to be a workaround.<br></blockquote><div><br></div><div>EPICS most likely should use a newer C++ standard than that. C++03 is </div><div>C++98 with corrections. But it does not have long long because C++98</div><div>definition predated C99 finalization and C99 has long long. GCC accepts</div><div>long long and ll format specifier on printf() but will complain only if you </div><div>turn on -pedantic.</div><div><br></div><div>You probably should be using C++11 or C++14 (bug fixed C++11).</div><div><br></div><div>Specifying the language version desired explicitly is a good thing. </div><div>Otherwise GCC will change its default version and that could impact</div><div>you. Which it may have done here.</div><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>
The other macro is defined in a target specific header,<br>
which explains why -mcpu= has an effect.<br>
<br>
> grep _GLIBCXX_USE_C99_MATH_TR1 .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/*/bits/c++config.h<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5206/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5208/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5307/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5329/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5407/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5475/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68000/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68040/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68060/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/mcpu32/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */<br>
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/softfp/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */<br>
<br>
These lines are preceded by:<br>
<br>
> /* Define if C99 functions or macros in <math.h> should be imported in<br>
>    <tr1/cmath> in namespace std::tr1. */<br>
<br>
I hope this gives someone else a hint.<br>
<br>
<br>
On 2/16/21 4:18 PM, Joel Sherrill wrote:<br>
> <br>
> <br>
> On Tue, Feb 16, 2021 at 5:50 PM Johnson, Andrew N. <<a href="mailto:anj@anl.gov" target="_blank">anj@anl.gov</a> <mailto:<a href="mailto:anj@anl.gov" target="_blank">anj@anl.gov</a>>> wrote:<br>
> <br>
>     On Feb 16, 2021, at 5:26 PM, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a> <mailto:<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>>> wrote:<br>
>><br>
>>     Can you provide a cutdown? <br>
> <br>
>     Sure, it’s 1 line of source:<br>
> <br>
>>     *tux% *cat m.cpp <br>
>>     #include <cmath><br>
> <br>
> <br>
> I can confirm this one-liner compilers on every rtems 5 and 6 gcc target including m68k but when you add mcpu=5282 to either the rtems 5 or 6 gcc it does not compile. <br>
> <br>
> The next step would be to look at the multilib directories selected by that. Something must be different about that vs the default (m68020 w/FPU).<br>
> <br>
> Luckily I had 4.11 tools laying around and I can report it works with the 4.11 GCC. Bad news, is that it is gcc 4.9.3 versus gcc 7. I suspect an examination of what that compiler did versus the new one will highlight the issue. Then we have to look at the config/m68k/t-* files RTEMS uses for changes.<br>
> <br>
> [joel@devel cmath]$ /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc -c  -mcpu=5282  m.cc<br>
> [joel@devel cmath]$ /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc --version<br>
> m68k-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB 158ad680aed1c4fd00f00d5b0e269391597872ef, Newlib 2.2.0.20150423)<br>
> <br>
> I'm afraid I did the quick part since I had the tools. Gedare.. can you do some version comparison and gcc git archeology? Just chat me and we can run this down.<br>
> <br>
> --joel<br>
> <br>
>   <br>
> <br>
> <br>
>     which when compiled:<br>
> <br>
>>     *tux% */local/anj/RTEMS-5.1/rtems-5.1/bin/m68k-rtems5-g++ -B/local/anj/RTEMS-5.1/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs -qrtems -mcpu=5282 -Wall -c m.cpp<br>
>>     In file included from *m.cpp:1:0*:<br>
>>     */local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1086:11:* *error: *'*::acoshl*' has not been declared<br>
>>        using ::*acoshl*;<br>
>>                *^~~~~~*<br>
>>     */local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1090:11:* *error: *'*::asinhl*' has not been declared<br>
>>        using ::*asinhl*;<br>
>>                *^~~~~~*<br>
>     *<br>
>     *<br>
>     Long list of errors truncated as before.<br>
> <br>
>>     And any idea what those using statements are referring to? I know the methods in libm but so not understand what it means in the context of using<br>
> <br>
>     I think that's how you ask C++ to import symbols into the current namespace (they are all inside a namespace std {...} block), but I’m not a C++ expert. In any case they come from gcc. EPICS probably doesn’t need any of the missing functions which look to have been added by C99, but we do need to be able to pull in math.h and/or cmath from C++ code.<br>
> <br>
>     - Andrew<br>
> <br>
> <br>
>>     On Tue, Feb 16, 2021, 4:42 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
>><br>
>>         Hi Andrew,<br>
>><br>
>>         On Tue, Feb 16, 2021 at 1:16 PM Johnson, Andrew N. <<a href="mailto:anj@anl.gov" target="_blank">anj@anl.gov</a> <mailto:<a href="mailto:anj@anl.gov" target="_blank">anj@anl.gov</a>>> wrote:<br>
>>         ><br>
>>         > I tried to build the in-progress port of EPICS for the uC5282 BSP last night against a release build of RTEMS-5.1 with tools and BSP built using RSB. It looks like the g++ cmath routines haven't been configured properly for this target. It failed at the first C++ source file includes math.h (other BSPs such as the beatnik and qoriq_e500 get further than this, and only the pc686 build completely succeeds right now):<br>
>>         ><br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/bin/m68k-rtems5-g++ -B/local/anj/RTEMS-5.1/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs -qrtems     -mcpu=5282       -D_GNU_SOURCE -D_DEFAULT_SOURCE            -DUNIX      -O2 -g -ffunction-sections -fdata-sections   -Wall       -DMY_DO_BOOTP=NULL    -D__LINUX_ERRNO_EXTENSIONS__ -DHAVE_SOCKADDR_SA_LEN=1  -I. -I../O.Common -I. -I../osi/compiler/gcc -I../osi/compiler/default -I. -I../osi/os/RTEMS-posix -I../osi/os/RTEMS -I../osi/os/posix -I../osi/os/default -I.. -I../as -I../bucketLib -I../calc -I../cvtFast -I../cppStd -I../cxxTemplates -I../dbmf -I../ellLib -I../env -I../error -I../fdmgr -I../flex -I../freeList -I../gpHash -I../iocsh -I../log -I../macLib -I../misc -I../osi -I../pool -I../ring -I../taskwd -I../timer -I../yacc -I../yacc -I../yajl -I../../../../include/compiler/gcc -I../../../../include/os/RTEMS -I../../../../include         -c ../cxxTemplates/resourceLib.cpp<br>
>><br>
>>         I don't see -lm not sure if that is an issue or not, but it seems<br>
>>         suspect. can you snip out the compiler command line to compare with<br>
>>         the pc686 build?<br>
>><br>
>>         > > In file included from /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/math.h:36:0,<br>
>>         > >                  from ../cxxTemplates/resourceLib.h:38,<br>
>>         > >                  from ../cxxTemplates/resourceLib.cpp:15:<br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1086:11: error: '::acoshl' has not been declared<br>
>>         > >    using ::acoshl;<br>
>>         > >            ^~~~~~<br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1090:11: error: '::asinhl' has not been declared<br>
>>         > >    using ::asinhl;<br>
>>         > >            ^~~~~~<br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1094:11: error: '::atanhl' has not been declared<br>
>>         > >    using ::atanhl;<br>
>>         > >            ^~~~~~<br>
>>         > ><br>
>>         > > ... many similar errors snipped ...<br>
>>         > ><br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1220:11: error: '::tgammal' has not been declared<br>
>>         > >    using ::tgammal;<br>
>>         > >            ^~~~~~~<br>
>>         > > /local/anj/RTEMS-5.1/rtems-5.1/lib/gcc/m68k-rtems5/7.5.0/include/c++/cmath:1224:11: error: '::truncl' has not been declared<br>
>>         > >    using ::truncl;<br>
>>         > >            ^~~~~~<br>
>>         ><br>
>>         > There could very well have been errors building the BSP on my part as I had to hand-create a uC5282.bset file for RSB to build it:<br>
>>         ><br>
>>         > > tux% cat config/5/bsps/uC5282.bset<br>
>>         > > %define mail_single_report 1<br>
>>         > ><br>
>>         > > %define with_rtems_bsp uC5282<br>
>>         > > %define rtems_target   m68k-rtems5<br>
>>         > > %define rtems_host     %{rtems_target}<br>
>>         > ><br>
>>         > > 5/rtems-m68k<br>
>>         > > 5/rtems-kernel<br>
>>         > > 5/rtems-libbsd<br>
>>         ><br>
>>         ><br>
>>         > The libbsd line there might be wrong, but I wouldn’t expect that to affect the availability of <cmath> functions to the C++ compiler.<br>
>>         ><br>
>>         > Any suggestions?<br>
>>         ><br>
>>         > Thanks,<br>
>>         ><br>
>>         > - Andrew<br>
>>         ><br>
>>         > --<br>
>>         > Complexity comes for free, simplicity you have to work for.<br>
>>         ><br>
>>         > _______________________________________________<br>
>>         > users mailing list<br>
>>         > <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>>         > <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a> <<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a>><br>
>>         _______________________________________________<br>
>>         users mailing list<br>
>>         <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a> <mailto:<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a>><br>
>>         <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a> <<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a>><br>
>><br>
> <br>
>     -- <br>
>     Complexity comes for free, simplicity you have to work for.<br>
> <br>
> <br>
> _______________________________________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br>
> <br>
<br>
</blockquote></div></div>