libstdc++ support for m68k

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Sep 13 06:23:24 UTC 2016 

Actually its a bit more complicated. The libstdc++ configure script 
performs this:

[...]
     cat > conftest.$ac_ext << EOF
#line 15391 "configure"
int main()
{
   typedef bool atomic_type;
   atomic_type c1;
   atomic_type c2;
   atomic_type c3(0);
   // N.B. __atomic_fetch_add is not supported for bool.
   __atomic_compare_exchange_n(&c1, &c2, c3, true, __ATOMIC_ACQ_REL,
                   __ATOMIC_RELAXED);
   __atomic_test_and_set(&c1, __ATOMIC_RELAXED);
   __atomic_load_n(&c1, __ATOMIC_RELAXED);

   return 0;
}
EOF

     { $as_echo "$as_me:${as_lineno-$LINENO}: checking for atomic 
builtins for bool" >&5
$as_echo_n "checking for atomic builtins for bool... " >&6; }
     if { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: 
\"$ac_compile\""; } >&5
   (eval $ac_compile) 2>&5
   ac_status=$?
   $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
   test $ac_status = 0; }; then
       if grep __atomic_ conftest.s >/dev/null 2>&1 ; then
     glibcxx_cv_atomic_bool=no
       else
     glibcxx_cv_atomic_bool=yes
       fi
     fi
[...]

So, it compiles a test using atomic operations. If it finds references 
to external __atomic* functions, then it assumes the atomic operations 
are not supported.

Later we have:

[...]
   # Set atomicity_dir to builtins if all but the long long test above 
passes.
   if test "$glibcxx_cv_atomic_bool" = yes \
      && test "$glibcxx_cv_atomic_short" = yes \
      && test "$glibcxx_cv_atomic_int" = yes; then

$as_echo "#define _GLIBCXX_ATOMIC_BUILTINS 1" >>confdefs.h

     atomicity_dir=cpu/generic/atomicity_builtins
   fi
[...]

So, the fall back is chosen for most m68k multilibs:

/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/mcpu32/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/softfp/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m68040/softfp/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m68040/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m68060/softfp/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m68060/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5206/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5208/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m68000/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5307/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5329/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5407/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/bits/c++config.h:#define 
_GLIBCXX_ATOMIC_BUILTINS 1
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5475/softfp/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */
/opt/rtems-4.12/lib64/gcc/m68k-rtems4.12/6.2.1/include/c++/m68k-rtems4.12/m5475/bits/c++config.h:/* 
#undef _GLIBCXX_ATOMIC_BUILTINS */

On 12/09/16 13:39, Sebastian Huber wrote:
> It seems that the libstdc++ configure script already detects that for 
> RTEMS the generic atomic built-ins are available and doesn't select 
> the CPU-specific header file. So, this stuff in 
> libstdc++-v3/config/cpu/m68k/atomicity.h looks like dead code.
>
> On 09/09/16 21:54, Joel Sherrill wrote:
>> I am OK with using what the default is as long as there is some 
>> implementation
>> for all the multilibs. That covers a lot of CPU models with no 
>> concept of
>> atomic operations and some with just test and set.
>>
>> --joel
>>
>> On Fri, Sep 9, 2016 at 4:13 AM, Sebastian Huber 
>> <sebastian.huber at embedded-brains.de 
>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>
>>     Hello,
>>
>>     I was a bit surprised to find this special case for RTEMS in
>>     libstdc++ on m68k:
>>
>>     https://gcc.gnu.org/ml/libstdc++/2016-09/msg00017.html
>> <https://gcc.gnu.org/ml/libstdc++/2016-09/msg00017.html>
>>
>>     Any objections to eliminate this special case and simply use the
>>     generic implementation? We have to check if the atomic operations
>>     for our m68k (or ColdFire) targets really work and if the
>>     libatomic is used appropriately.
>>
>>     --     Sebastian Huber, embedded brains GmbH
>>
>>     Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>     Phone   : +49 89 189 47 41-16 <tel:%2B49%2089%20189%2047%2041-16>
>>     Fax     : +49 89 189 47 41-09 <tel:%2B49%2089%20189%2047%2041-09>
>>     E-Mail  : sebastian.huber at embedded-brains.de
>>     <mailto:sebastian.huber at embedded-brains.de>
>>     PGP     : Public key available on request.
>>
>>     Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des 
>> EHUG.
>>
>>     _______________________________________________
>>     devel mailing list
>>     devel at rtems.org <mailto:devel at rtems.org>
>>     http://lists.rtems.org/mailman/listinfo/devel
>>     <http://lists.rtems.org/mailman/listinfo/devel>
>>
>>
>

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list