> compiler started to introduce speculative writes on code pathes where the write did not occur in the source code, and this broke multithreaded programs c.f.

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