GCC 4.7.0 and C++ atomics

[Joel Sherrill]

On 03/07/2012 12:44 PM, Andrew MacLeod wrote:
> On 03/07/2012 10:11 AM, Sebastian Huber wrote:
>> Hello,
>>
>> I run the GCC testsuite for GCC 4.7.0 20120307
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg00782.html
>>
>> I got a lot of errors like this:
>>
>> FAIL: g++.dg/simulate-thread/atomics-1.C  -O0 -g  (test for excess
>> errors)
>> 148796 Excess errors:
>> 148797
>> /home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:458:
>> undefined reference to `__sync_synchronize'
>> 148798
>> /home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:458:
>> undefined reference to `__sync_synchronize'
>> 148799
>> /home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:458:
>> undefined reference to `__sync_synchronize'
>> 148800
>> /home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:458:
>> undefined reference to `__sync_synchronize'
>> 148801
>> /home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:438:
>> undefined reference to `__sync_synchronize'
>> 148802
>> /tmp/ccgSyPe7.o:/home/sh/rtems-testing/gcc/b-arm-gcc/arm-rtemseabi4.11/libstdc++-v3/include/bits/atomic_base.h:438:
>> more undefined references to `__sync_synchronize' follow
>>
>> Who is supposed to provide this function? expand_mem_thread_fence
>>
> Looks like it is defaulting to emitting the synchronize_libfunc call,
> which is suppose to be provided by libgcc I think...
>
> rth, you are familiar with how this part is suppose to hook up properly...
>
> I traced the code in expand_mem_thread_fence, and the sync_synchronize
> is being emiited by:
>
> else if (synchronize_libfunc != NULL_RTX)
>           emit_library_call (synchronize_libfunc, LCT_NORMAL, VOIDmode, 0);
>
> presumably something just isn't being linked to the executable?  or
> maybe not being built into libgcc?
I haven't looked into this specific case but often it is a case of
a multilib variant not being covered by the existing code.
> Andrew
>
> Andrew
>
>


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985