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

[Andrew MacLeod <amacleod@redhat.com>]

On 11/07/2011 12:32 PM, Hans-Peter Nilsson wrote:
>> From: "Joseph S. Myers"<joseph@codesourcery.com>
>> Date: Mon, 7 Nov 2011 17:24:04 +0100
>> On Mon, 7 Nov 2011, Andrew MacLeod wrote:
>>
>>> 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.
>> For bare-metal targets there should maybe be an option to presume there is
>> just one thread and map all atomic operations to dumb non-atomic versions,
>> which is perfectly valid in such a case.  But that's a new feature; we
>> didn't have it for __sync_* either.
> It'd not be a new feature, that's apparently how it worked until
> it broke now ...unless you mean something different.
>
Libstdc++-v3 use to supply a locked version of class atomic_flag 
(atomic_0.h implemented locked classes)  if there were no lock free 
routines (_GLIBCXX_ATOMIC_BUILTINS_1 was not set to true in configuration):

  /// 29.2 Lock-free Property
#if defined(_GLIBCXX_ATOMIC_BUILTINS_1) && 
defined(_GLIBCXX_ATOMIC_BUILTINS_2) \
&& defined(_GLIBCXX_ATOMIC_BUILTINS_4) && 
defined(_GLIBCXX_ATOMIC_BUILTINS_8)
# define _GLIBCXX_ATOMIC_PROPERTY 2
# define _GLIBCXX_ATOMIC_NAMESPACE __atomic2
#elif defined(_GLIBCXX_ATOMIC_BUILTINS_1)
# define _GLIBCXX_ATOMIC_PROPERTY 1
# define _GLIBCXX_ATOMIC_NAMESPACE __atomic1
#else
# define _GLIBCXX_ATOMIC_PROPERTY 0
# define _GLIBCXX_ATOMIC_NAMESPACE __atomic0
#endif


This meant it would compile and run fine...  That is no longer standard 
compliant, so we cant fall back to that any more.  This is the first 
time we've had to face not being able to supply atomic_flag, so we need 
to decide what to do.

So, what DO we do if there is no basic level of atomic support...  I 
think it is reasonable to have __sync_lock_test_and_set() and 
__sync_lock_release() perform simple loads and stores if we can decide 
how best to communicate to the expanders that we only ever operating in 
a  single threaded environment.  the as-yet unimplemented  
-fmemory-model flag seems like the best bet unless there is something 
else already being set.

Another option would be to have the libstdc++ header files resort to a 
simple load and store rather than calling a __sync routine when they 
know its not present.  Then we aren't tainting the compiler with this 
arguably offbeat requirement.

Andrew