Go version

go version >=1.24

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='0'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/tazjin/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/tazjin/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build67497218=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/tazjin/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/tazjin/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/nix/store/mdn9hnvf0qmxywbrpbywmxww2adxdn5v-go-1.24.4/share/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/tazjin/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/nix/store/mdn9hnvf0qmxywbrpbywmxww2adxdn5v-go-1.24.4/share/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

We upgraded Go from 1.23 to 1.24, and saw a behaviour change in the pierrec/lz4 compression library which is causing some unit tests to fail on some CPUs.

git bisect on Go itself tracked this down to https://go-review.googlesource.com/c/go/+/580735 which added ERMS support to memmove on supporting CPUs.

What did you see happen?

The lz4 library's blockwise encoder is failing to decode data that could previously be decoded, failing with a generic error message. A detailed description is available in the issue we filed in the library: https://github.com/pierrec/lz4/issues/233

It's important to note that the library implements block decoding in Go assembler, and the calls to runtime.memmove around which ~something goes wrong are in there: https://github.com/pierrec/lz4/blob/v4/internal/lz4block/decode_amd64.s

We haven't tracked down the root issue yet (the reproducer in the linked issue currently still uses a lot of surrounding code, unfortunately), so it is entirely possible that some documented condition is violated in this assembler. However, I didn't find a policy on reporting potential regressions / issues of this kind, so decided to file a bug with you just in case this counts as a problem with Go itself.

What did you expect to see?

We expected no change in behaviour after upgrading to Go 1.24

Comment From: gabyhelp

Related Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: randall77

I can reproduce this, but I don't know what is going on yet. Turning the memmove tests in the runtime up to 11 doesn't reveal anything.

The assembly calling memmove looks ok, I don't think there is a problem there.

Maybe the memmove assembly does a CLD (clear direction)` in more situations now, and the lz4 assembly depends on the direction flag somehow? I don't see anything obviously wrong with the lz4 assembly, but maybe worth double-checking.