[PATCH 0/5] Atomic type qualifier

[Andrew MacLeod <amacleod@redhat.com>]

On 07/26/2013 01:15 PM, Andrew MacLeod wrote:
> This patch adds an atomic type qualifier to GCC.   It can be accessed 
> via __attribute__((atomic)) or in C11 mode via the _Atomic keyword.
>
> What it does:
>  *  All the __atomic builtins now expect an atomic qualified value for 
> the atomic variable.  Non-atomic values can still be passed in, but 
> they are not guaranteed to work if the original type is not compatible 
> with the atomic type  No fears.  At the moment, every target's atomic 
> types line up with the unsigned type of the same size, so like magic, 
> its all good for existing code.
>  *  There is a new target hook "atomic_align_for_mode" which a target 
> can use to override the default alignment when the atomic variation 
> requires something different.   There may be other attributes 
> eventually, but for now alignment is the only thing supported.  I 
> considered size, but the effort to do that is what drove me to the 
> re-architecture project :-P  At least the mechanism is now in place 
> for overrides when atomic requirements aren't just the default it use 
> to be.    (I introduced atomicQI_type_node, atomicHI_type_node,  
> atomicSI_type_node, atomicDI_type_node, atomicTI_type_node, ).  I 
> tested this by aligning all shorts to 32 byte boundaries and 
> bootstrapping/running all the tests.
>  * I went through the front ends trying to treat  atomic qualifier 
> mostly like a volatile, since thats is the basic behaviour one 
> expects.  In the backend, it sets the TREE_IS_VOLATILE bit so 
> behaviour ought to be the same as before, plus they are/will be always 
> used in __atomic_built-in functions.
>  * I changed the libstdc++ atomic implementation so that all the 
> atomic classes use __attribute__((atomic)) on their data members, 
> ensuring that if anyone overrides the atomic type, it should work fine 
> with C++ atomics.   It also served as a good test that I had the type 
> set up properly... getting TYPE_CANONICAL() correct throughout the C++ 
> compiler was, well..., lets just say painful.
> * I changed 2 of the atomic test sets, one uses 
> __attribute__((atomic)) to ensure the attribute compiles ok, and the 
> other uses _Atomic and --std=c11 to ensure that compiles OK.
>
> What it doesn't do:
>   * It doesn't implement the C11 expression expansion into atomic 
> built-ins.  ie, you can't write:
> _Atomic int x;
>  x = 0;
>       and have the result be an atomic operation calling 
> __atomic_store (&x, 0).   That will be in a  follow on patch. So none 
> of the expression expansion from C11 is included yet. This just 
> enables that.
>  * It doesn't do a full set of checks when _Atomic is used in invalid 
> ways.  I don't know the standard nor the front end well enough.. Im 
> hoping someone else will pitch in with that eventually, assuming 
> someone cares enough :-)  There are a couple of errors issued, but 
> that is it.
>
> This bootstraps on x86_64, and passes all the testsuites with no new 
> regressions.  I didnt split it up any more than this because most of 
> it is inter-related... plus this is already split out from a much 
> larger set of changes :-) I did try to at least organize the ordering, 
> all the long boring stuff is at the end :-)
>
> Both front end and back end stuff in here.  I think I caught it all, 
> but have a look. There is time to find any remaining issues I may have 
> missed.
>
> Andrew
>
I split the original patch into some smaller hunks, and cleaned up a few 
bit and pieces here and there... following: