cmd/compile: typebits.Set: invalid initial alignment: type Peer has alignment 8, but offset is 4

[stv0g]

This is seems to be a regression of: #54638

What version of Go are you using (go version)?

go version go1.19.1 linux/arm64

Does this issue reproduce with the latest release?

Not, tested.

What operating system and processor architecture are you using (go env)?

go env Output

GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/home/stv0g/.cache/go-build"
GOENV="/home/stv0g/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/stv0g/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/stv0g/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm64"
GOVCS=""
GOVERSION="go1.19.1"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/stv0g/workspace/cunicu2/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3584615060=/tmp/go-build -gno-record-gcc-switches"

What did you do?

git clone github.com/stv0g/cunicu
cd cunicu
GOARCH=arm go build ./cmd/cunicu

What did you expect to see?

A successful build for 32-bit architectures.

What did you see instead?

The following compiler error:

# github.com/stv0g/cunicu/pkg/feat/epdisc
<autogenerated>:1: internal compiler error: typebits.Set: invalid initial alignment: type Peer has alignment 8, but offset is 4

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

This issue has been observed for the following GOARCH=arm, mips and GOOS=linux
64-bit builds (GOOS=arm64, amd64) are successful.

[cuonglm]

It seems to me that CL 425256 only handles local variables. While the problem in this issue is for arguments which are on stack.

[cuonglm]

cc @cherrymui @randall77

[cuonglm]

Minimal reproducer:

package p

import (
	"sync/atomic"
)

type I interface {
	M()
}

type S struct{}

func (S) M() {}

type T struct {
	I
	x atomic.Int64
}

func F() {
	t := T{I: S{}}
	t.M()
}

[cuonglm]

Seems that we can't do the same trick with autotmp, the arguments frame offset is used to write function stack map, so it can't be fake.

[cherrymui]

I haven't looked into this issue. But I think CL 425256 should handle autotmp. I'll see what we missed.

[cuonglm]

I haven't looked into this issue. But I think CL 425256 should handle autotmp. I'll see what we missed.

Yeah, see my comment above.

This issue is about parameters which are on stack, specifically for the reproducer, it's .this receiver of wrapper method.

[randall77]

Seems to be ok for 386, just not arm.
Looks like this is due to the fact that args start at offset 4 from SP. I'm not sure there's anything we can do here, we'd have to change the calling convention which would break existing arm assembly.
We could ignore this error in cases like this, I guess.
Or copy the arg off into an argtmp that is properly aligned in the prolog.
In any case it seems a very strange case. I don't see any reason to pass an atomic thing around as an argument.
Maybe the error could be better though? (Or as above, just make this not an error.)

[cuonglm]

In any case it seems a very strange case. I don't see any reason to pass an atomic thing around as an argument.

To be clear, it's not passing an atomic around, it's the .this receiver, which contains atomic thing:

• T has alignment 8
• arm has fixed frame size 4
• When calculating offset for .this receiver, which has type T, we use its offset minus fixed frame size, which is 8 - 4

Previously, this can't happen because T would have alignment 4, thus frame offset is 4 - 4, which will satisfy the check.

Maybe for typesbits.Set, we should skip the check if T alignment is greater than ptr size?

[stv0g]

Hi there 👋,

is there a chance to work around this bug in my current code?

In any case it seems a very strange case. I don't see any reason to pass an atomic thing around as an argument.

This hints, that passing it around as a pointer would work?