sync/atomic: LoadInt64 panics on ARM when uint64 variable is not 64bit aligned

[Hades32]

The following code works fine on Windows x86_64 and fails on Debian Jessie on a Raspberry Pi 2 ARMv7, both go version 1.4:

package main

import (
    "sync/atomic"
    "fmt"
)

type buffer struct {
        id int32 // remove this, or make it int64 and the code will run fine
        done int64
}

func test(buf *buffer) bool {
        if atomic.LoadInt64(&buf.done) == 1 {
                return true
        }

        return false
}
func main() {
        var buf buffer
                buf.done = 1
        fmt.Println("pre-fail")
        res := test(&buf)
        fmt.Println("post-fail", res)
}

Not sure if this is a bug in LoadInt64 or a bug in the go memory layouter...

[cespare]

From the bottom of the sync/atomic docs (the "Bugs" section):

On both ARM and x86-32, it is the caller's responsibility to arrange for 64-bit alignment of 64-bit words accessed atomically. The first word in a global variable or in an allocated struct or slice can be relied upon to be 64-bit aligned.

[Hades32]

Looks like a typical case of RTFM then :)

Although, when it is listed in the docs as bug, why is there no bug in the bug tracker?

[adg]

"Bug" is probably a stronger word than is necessary. "Caveat" is better, but godoc doesn't recognise // CAVEAT: comments.

[minux]

That is not a bug that could be easily fixed without large scale toolchain and runtime changes (e.g. we need 64-bit alignment of SP on 32-bit systems), although the 7g port does lay the foundation for such changes.

[dvyukov]

@minux why is sp alignment required?
we still have not mark atomic ops as noescape, so they are always in heap

[minux]

If you still want to allocate an otherwise unescaped variable on the stack, then the easiest way is to require stronger SP alignment, which is nontrivial but possible.