The change should not be reverted. Instead the 64-bit atomics on the 32-bit systems should all include alignment checks.

On the 32-bit x86, it may appear that unaligned 64-bit atomics are atomic - they execute at least - but that turns out to be true in practice only when the 64-bit value does not span a cache line boundary. If it does, then the operation is silently non-atomic. The way to make a 64-bit value not span a cache line boundary is to be 64-bit aligned (because so are cache line boundaries).

So all 32-bit systems should actively require in their 64-bit atomic implementations that values to be acted upon are 64-bit aligned in memory.

CL https://golang.org/cl/33159 mentions this issue.

CL https://golang.org/cl/33236 mentions this issue.

CL https://golang.org/cl/33235 mentions this issue.

It turns out I have to add another padding in the runtime (CL https://go-review.googlesource.com/c/33235/). I am not sure this is the best way to do -- it makes the struct unnecessarily one word larger on 64-bit architectures, and it is not future-proofing (if we add/delete/change a field before it, we need to adjust the padding). Maybe we should do something in the compiler? Add a go:align pragma? (but I'm worried about adding too many pragmas...)

I also don't like the current approach.

How about we add a runtime.alignedInt64 type and handle it specially in the
compiler (similar to how runtime.hex is handled by the compiler.)

We can also make runtime/internal/atomic 64-bit atomic operations require
pointer to that type instead of regular *int64.

We can decide whether to add something to the sync package later (for
example, we could add a sync/atomic.Int64 type with accessor methods and
also make the compiler reject any direct access to values of that type.)

If there are interests, I can write up a proposal. But I'm a little
concerned that it might lead to abuse of the sync/atomic package, which, in
general, is very hard to use correctly.

We could potentially add a type for the runtime, but I don't think we could do this in sync.

It still seems to me like a reasonable middle ground is to have a vet check for this (aka #11891).