[PATCH] pr51038 atomic_flag on targets with no atomic support.

[Andrew MacLeod <amacleod at redhat dot com>]

The issue here is no atomic support whatsoever.  The standard now 
*requires* that atomic_flag be implementable in a lock free manner for 
compliance.  That means they must resolve to something, and not an 
external library call.

In order to support atomic_flag in a lock free manner on a target, we 
need at a minimum the legacy __sync_lock_test_and_set and 
__sync_lock_release to be implemented.

Previous to this release, if atomic_flag couldn't be implemented lock 
free, it was implemented with locks.  libstdc++-v3 no longer supports 
any locked implementations.

We'll have the same problem with C1x next release as well, so I bit the 
bullet and added __atomic_test_and_set and __atomic_clear as built-ins.  
These routines will first try to use lock free exchange and store.  
Failing that, legacy __sync_lock_test_and_set and __sync_lock_release 
are tried.  If those fail as well, then we simply default to performing 
a load and/or store as is required.

Currently I don't issue any warnings because we don't have a good way of 
saying we are running in a single threaded model.  When we add the 
"-fmemory-model=single" flag (probably next release) I think we should 
issue a warning that atomics with no support are being used in a 
non-single threaded environment.

this boostraps and no new regressions on x86_64-unknown-linux-gnu.  I 
also built a cris-elf compiler and looked at the output from 
atomic-flag.c, and there were no external calls in it, so hopefully it 
resolves the issue there...

care to give it a try and verify?

Andrew

Attachment: pr51038.patch
Description: Text document