http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- Thanks for the testcase. At this point I think we need Andrew MacLeod or Torvald Riegel to review it and assess what should happen where to fix this (both for direct uses of the atomic built-in functions, and for _Atomic / std::atomic). Since the original bug report it has come to my attention that there are known ambiguities in how the C11/C++11 memory model is mapped to processor operations on some architectures, which will need to be addressed in platform ABIs for interoperation between implementations (when one thread is built with one implementation and the other thread with another implementation, for example). http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html (It is not clear to me if research in this area is sufficiently advanced to provide a good way for ABIs to specify this that is unambiguous and does not inhibit optimizations within a single implementation.) It will also of course be necessary for ABIs to specify such things as alignment for C11 _Atomic for that to interoperate between implementations (for GCC at present, if the size of the type is 8 / 16 / 32 / 64/ 128 bits, the alignment gets increased to match that of the corresponding core type). But first it may take a while for things to work reliably within single implementations.