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: pierrec/lz4#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