cxx-mem-model merge [6 of 9] - libstdc++-v3

[Andrew MacLeod]

>> On 11/06/2011 07:38 PM, Hans-Peter Nilsson wrote:
>>> This (formally a change in the range 181027:181034) got me three
>>> libstdc++ regressions for cris-elf, which has no "atomic"
>>> support whatsoever (well, not the version represented in
>>> "cris-elf"), so something is amiss at the bottom of the default
>>> path:
>> yes, I have a final pending patch which didn't make it to the branch
>> before the merge.  It changes the behaviour of atomic_flag on targets
>> with no compare_and_swap.  I *think* it will resolve your problem.
>>
>> I've attached the early version of the patch which you can try. Its
>> missing a documentation change I was going to add tomorrow before
>> submitting, but we can see if it resolves your problem.  Give it a shot
>> and let me know.
> Sorry, no it didn't help.  No additional regressions either
> though, but the undef'd reference changed to two:
>
> Excess errors:
> /tmp/atreg1/gccobj/cris-elf/libstdc++-v3/include/bits/atomic_base.h:273: undefined reference to `std::atomic_thread_fence(std::memory_order)'
> /tmp/atreg1/gccobj/cris-elf/libstdc++-v3/include/bits/atomic_base.h:274: undefined reference to `__sync_lock_test_and_set_1'
> collect2: error: ld returned 1 exit status
>

Actually, this target has no lock free support whatsoever?  ie, no 
compare_and_swap instruction, nor an implementation of 
sync_lock_test_and_set and sync_lock_release?

I think the libstdc++ standard now requires the class atomic_flag to be 
lock free in order to conform (n3242 29.7.2)

So I guess this is the situation which all the atomic tests are not even 
suppose to be run since they aren't supported.  My guess is that in the 
previous releases the c++ header files probably provided a locked 
implementation of test_and_set, and so the tests would run.

bkoz:  I guess what we need is a way to disable all atomic support for 
targets which do not have an implementable atomic_flag class?

Thats why we're getting the unresolved external 
__sync_lock_test_and_set_1 ,  in order to get his far, we assume that 
minimal level of support...

rth: __sync_lock_test_and_set_1  could be provided by libgcc if the OS 
has hooks in it to provide functionality...  How can we tell when 
compiling a C++ program whether that is going to be an unresolved 
external or whether libgcc is going to provide it? I know you have a 
pending patch for libgcc support fo the __atomics, but Im unsure how we 
check this from the compiler

I should also change it so that the compiler issues an error if 
atomic_thread_fence doesn't resolve to a something since that implies 
there is no __sync_sychronize() either, which is also minimally expected 
at this point.  It should never become  an external reference.

Andrew