RTEMS 5.1: cmath compiler errors on m68k/uC5282
Michael Davidsaver
mdavidsaver at gmail.com
Wed Feb 17 07:16:20 UTC 2021
FYI. Excluding the c++ part shows that acoshl() and friends are never defined.
> $ cat mtest.c
> #include <math.h>
>
> long double x(long double a) { return acoshl(a); }
>From the newlib math.h:
> /* Newlib doesn't fully support long double math functions so far.
> On platforms where long double equals double the long double functions
> simply call the double functions. On Cygwin the long double functions
> are implemented independently from newlib to be able to use optimized
> assembler functions despite using the Microsoft x86_64 ABI. */
> #if defined (_LDBL_EQ_DBL) || defined (__CYGWIN__)
Looking to the GCC cmath header I find.
> #if __cplusplus >= 201103L
>
> #ifdef _GLIBCXX_USE_C99_MATH_TR1
And indeed adding -std=c++98 seems to be a workaround.
The other macro is defined in a target specific header,
which explains why -mcpu= has an effect.
> grep _GLIBCXX_USE_C99_MATH_TR1 .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/*/bits/c++config.h
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5206/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5208/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5307/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5329/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5407/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m5475/bits/c++config.h:#define _GLIBCXX_USE_C99_MATH_TR1 1
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68000/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68040/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/m68060/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/mcpu32/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */
> .../lib/gcc/m68k-rtems5/7.5.0/include/c++/m68k-rtems5/softfp/bits/c++config.h:/* #undef _GLIBCXX_USE_C99_MATH_TR1 */
These lines are preceded by:
> /* Define if C99 functions or macros in <math.h> should be imported in
> <tr1/cmath> in namespace std::tr1. */
I hope this gives someone else a hint.
On 2/16/21 4:18 PM, Joel Sherrill wrote:
>
>
> On Tue, Feb 16, 2021 at 5:50 PM Johnson, Andrew N. <anj at anl.gov <mailto:anj at anl.gov>> wrote:
>
> On Feb 16, 2021, at 5:26 PM, Joel Sherrill <joel at rtems.org <mailto:joel at rtems.org>> wrote:
>>
>> Can you provide a cutdown?
>
> Sure, it’s 1 line of source:
>
>> *tux% *cat m.cpp
>> #include <cmath>
>
>
> 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.
>
> 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).
>
> 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.
>
> [joel at devel cmath]$ /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc -c -mcpu=5282 m.cc
> [joel at devel cmath]$ /home/joel/rtems-cron-411/tools/4.11/bin//m68k-rtems4.11-gcc --version
> m68k-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB 158ad680aed1c4fd00f00d5b0e269391597872ef, Newlib 2.2.0.20150423)
>
> 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.
>
> --joel
>
>
>
>
> which when compiled:
>
>> *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
>> In file included from *m.cpp:1:0*:
>> */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
>> using ::*acoshl*;
>> *^~~~~~*
>> */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
>> using ::*asinhl*;
>> *^~~~~~*
> *
> *
> Long list of errors truncated as before.
>
>> 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
>
> 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.
>
> - Andrew
>
>
>> On Tue, Feb 16, 2021, 4:42 PM Gedare Bloom <gedare at rtems.org <mailto:gedare at rtems.org>> wrote:
>>
>> Hi Andrew,
>>
>> On Tue, Feb 16, 2021 at 1:16 PM Johnson, Andrew N. <anj at anl.gov <mailto:anj at anl.gov>> wrote:
>> >
>> > 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):
>> >
>> > > /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
>>
>> I don't see -lm not sure if that is an issue or not, but it seems
>> suspect. can you snip out the compiler command line to compare with
>> the pc686 build?
>>
>> > > 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,
>> > > from ../cxxTemplates/resourceLib.h:38,
>> > > from ../cxxTemplates/resourceLib.cpp:15:
>> > > /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
>> > > using ::acoshl;
>> > > ^~~~~~
>> > > /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
>> > > using ::asinhl;
>> > > ^~~~~~
>> > > /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
>> > > using ::atanhl;
>> > > ^~~~~~
>> > >
>> > > ... many similar errors snipped ...
>> > >
>> > > /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
>> > > using ::tgammal;
>> > > ^~~~~~~
>> > > /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
>> > > using ::truncl;
>> > > ^~~~~~
>> >
>> > 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:
>> >
>> > > tux% cat config/5/bsps/uC5282.bset
>> > > %define mail_single_report 1
>> > >
>> > > %define with_rtems_bsp uC5282
>> > > %define rtems_target m68k-rtems5
>> > > %define rtems_host %{rtems_target}
>> > >
>> > > 5/rtems-m68k
>> > > 5/rtems-kernel
>> > > 5/rtems-libbsd
>> >
>> >
>> > The libbsd line there might be wrong, but I wouldn’t expect that to affect the availability of <cmath> functions to the C++ compiler.
>> >
>> > Any suggestions?
>> >
>> > Thanks,
>> >
>> > - Andrew
>> >
>> > --
>> > Complexity comes for free, simplicity you have to work for.
>> >
>> > _______________________________________________
>> > users mailing list
>> > users at rtems.org <mailto:users at rtems.org>
>> > http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>
>> _______________________________________________
>> users mailing list
>> users at rtems.org <mailto:users at rtems.org>
>> http://lists.rtems.org/mailman/listinfo/users <http://lists.rtems.org/mailman/listinfo/users>
>>
>
> --
> Complexity comes for free, simplicity you have to work for.
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
More information about the users
mailing list