Dealing with alignment on atomic operations.

[Andrew MacLeod <amacleod at redhat dot com>]

I punted on determinig what to do with alignment issues when 
implementing atomics for 4.7.  The time has come however to address what 
is to be done.  I've put together a wiki page and discussed its contents 
with a few people to get this cut.  Hopefully it seems reasonably sane. :-)

I've added a link to the page from the primary memory model page, and it 
can be found here: http://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy

in a nutshell:
  - gcc will provide an atomic type attribute (like const and volatile) 
which will also cause any required alignment for a target to utilize its 
lock free instructions.  C11 atomic types will use this, as wil the 
C++11 atomic template class.  This could cause an ABI breakage between 
4.7 and 4.8 C++11 on a few targets, but the C++11 ABI is still not 
finalized, so this would be the time to get it right.
 - When using memory in an atomic built-in function which does not have 
this attribute, the __atomic_{is,always}_lock_free routines will check 
the known alignment of object , and if this matches what is required, 
lock free instructions will still be generated.
 - Anything GCC emits other than calls into libatomic *cannot* use 
locks.  Calls into an OS for lock-free operations are permitted.
- libatomic is integrated into the build now, so any customizations 
beyond the basic implementation of lockfree instruction sequences should 
go there.


The main thing which seems contentious is a new configuration options 
--disable-atomic-resize  which turns off the ability of the 'atomic' 
type attribute to resize the underlying type to achive a lock free 
implementation.  My theory was that if some port found memory to be more 
important than the speed and would sacrifice lockfree sequences in 
favour of locks utilziing less memory, this would provide an easy way to 
do it.

Perhaps it is not needed... thoughts?  Its a configuration option rather 
than a compiler flag because it is a potential ABI breakage.

Any thoughts on the rest of it? brain farts or simplifications?

Andrew