&gt; compiler started to introduce speculative writes on code pathes where the write did not occur in the source code, and this broke multithreaded programs<p>c.f. <a href="http:&#x2F;&#x2F;www.di.ens.fr&#x2F;~zappa&#x2F;readings&#x2F;c11comp.pdf" rel="nofollow">http:&#x2F;&#x2F;www.di.ens.fr&#x2F;~zappa&#x2F;readings&#x2F;c11comp.pdf</a><p>&gt; the position of &quot;all the standard, nothing but the standard&quot; is utter bullshit<p>I&#x27;m pretty sure that wasn&#x27;t the point.<p>&gt; the current published atomic specification is subtly unsound<p>Details? Batty has a few nits for C around memcpy, consume isn&#x27;t implemented, out-of-thin-air is a theoretical problem, and forward progress guarantees will be added &quot;soon&quot;. OTOH I can&#x27;t think of anything else, but I&#x27;m sure I&#x27;m forgetting some. IMO none of these are interesting enough to be in the talk, but would make fine references.<p>&gt; Do compiler authors do the right thing instead of trying to implement the broken spec, while waiting for the spec to be fixed?<p>Compiler authors are also fixing the spec.<p>&gt; without proving this really improves performance like crazy to justify taking that kind of risk<p>That&#x27;s untrue in most cases, especially when optimizing atomics.