Unfortunately this miscompilation probably is within spec, given that the atomic package has no documented ordering.
But it's coming.
But it's coming.
Many concurrent memory models (C++ at least, java very likely) allow coalescing stores to atomic variables as long as there is no other interleaving side effect; this is normally a desirable optimization.
As described by dvyukov, the go compiler seems to be aggressively coalescing all stores till the end of the loop (which never happens).
Store coalescing is desirable, but it is hard to specify completely, for example the C++ standard has non normative wording stating that stores should be visible in a reasonable amount of time exactly to prevent this sort of issues.