RTEMS 5.1: cmath compiler errors on m68k/uC5282
Joel Sherrill
joel at rtems.org
Wed Feb 17 15:34:47 UTC 2021
On Wed, Feb 17, 2021 at 1:16 AM Michael Davidsaver <mdavidsaver at gmail.com>
wrote:
> 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__)
>
This is the current code and it does have some logic for __math_m68881
but even though this code has changed, the 4.11 math.h includes similar
logic. I checked and _LDBL_EQ_DBL is defined in newlib.h and the setting
is the same for 4.11 and 5 tools.
> 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.
>
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).
Specifying the language version desired explicitly is a good thing.
Otherwise GCC will change its default version and that could impact
you. Which it may have done here.
> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210217/7dc45a39/attachment-0001.html>
More information about the users
mailing list