patch - __sync_lock_test_and_set, __sync_lock_release fallback expansion

[Andrew MacLeod <amacleod at redhat dot com>]

Originally I had __atomic_exchange falling back to 
__sync_lock_test_and_set, and __atomic_store falling back to 
__sync_lock_release whenever the _atomic variation wasn't specified.

On some limited targets, functionality of these two operations can be 
restrictedt.  rth had already removed the store fallback to 
__sync_lock_release, but another side effect of that was that 
__sync_lock_release now always falls back to just storing 0, which I 
don't think is quite right either.

the test_and_set case is worse. On some targets, a 1 can be stored, but 
thats it.  In those cases, and integer store of 1 would result in a lock 
free call, but calues other than 1 may not happen, or be changed to a 
one. This would be unacceptable.

This patch allows expansion of those 2 __sync routines to utilize their 
pattern *if* the expand_builtin call originates with a __sync builtin.  
So this means those two __sync calls first try to utilize the new 
__atomic pattern if they can, but *will* try to fallback to the sync 
pattern next.  This fallback will NOT happen if the expansion originates 
with an __atomic builtin.

Both C1x and C++11 define that the atomic_flag object *must* be lock 
free in order to be standard compliant.  The issue shows up on limited 
targets which only support a test_and_set and release operations, but 
nothing else.  The existing code results in an external call to 
__atomic_exchange_1 which is unsatisfactory.  The atomic_flag 
implementation needs to fall back to these 2 __sync's if there is no 
other support, so thats the libstdc++-v3 changes.  Plus the oversight 
where the fence routines don't actually call the fence builtins.

This patch bootstraps and produces no new testsuite regressions  on  
x86_64-unknown-linux-gnu.

Andrew

Attachment: TAS2.diff
Description: Text document