http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58605
--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> --- Re initialization: I would think that the usage of "uninitialized state" is a wording issue that should better be clarified by a library issue. I don't think that the reference to C compatibility can be applied to structs with non-trivial constructors, because such beasts don't exist in C. If the library really intents to specify that a non-trivial default constructor should not be called in this, I would strongly suggest to ammend [atomics.types.operations.req] p4 to mention that *never* a constructor will be called. My understanding of the mental model here has always been that it was referring to C- compatible (POD types) where this issue doesn't arise. On the other hand, if my understaidng is correct, I also suggest an improvement of the existing wording to speak of "default-initialization" instead, when this was supposed to be meant. I'll submit an LWG issue for this. Re noexcept: The issue with exception specifications on defaulted constructors had been discussed by the core language group exactly because of atomic<> due to http://cplusplus.github.io/LWG/lwg-active.html#2165 Note that the acceptance of this for atomic<> seems to indicate for me that indeed default-initialization is intended here, otherwise the issue would be NAD. The core language currently suggests to resolve this issue by marking the defaulted constructor as deleted, when the exception specification violates, so there seems no need for magic "no-initialization" in atomic.
