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
