You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
cmd/compile: loong64 spills a byte-sized inlined result with an 8-byte MOVD, clobbering adjacent stack slots [1.27 backport] #81147
changed the title [-]cmd/compile: loong64 spills a byte-sized inlined result with an 8-byte MOVD, clobbering adjacent stack slots (go1.27.0) [1.27 backport][/-][+]cmd/compile: loong64 spills a byte-sized inlined result with an 8-byte MOVD, clobbering adjacent stack slots [1.27 backport][/+]on Sep 1, 2026
@abner-chenc since #81000 somehow has 200+ messages, could you confirm the CL to be backported, whether this impacts 1.26 and 1.27, and what the impact is (arbitrary memory corruption on the stack?).
@abner-chenc since #81000 somehow has 200+ messages, could you confirm the CL to be backported, whether this impacts 1.26 and 1.27, and what the impact is (arbitrary memory corruption on the stack?).
Thanks!
Needs backporting to Go 1.26 and Go 1.27, otherwise the MOVD instruction could corrupt the stack. I have submitted a regression test case for this issue in CL 828625。
The input operands for Cvt{32,64}to{32,64}F are integer registers, and the output operands are floating-point registers. However, the corresponding Op implementations on loong64 require both the input and output operands to be floating-point registers. Therefore, we need to move the input operand to a floating-point register on loong64.
Similarly, the input operands for Cvt{32,64}Fto{32,64} are floating-point registers, and the output operands are integer registers. Since the loong64 Op implementations require both operands to be floating-point registers, we need to move the output operand to an integer register on loong64.
Here the test case for this bug. It fails when running on the Go 1.27 branch.
./bin/go version
go version go1.27.2 linux/loong64
./bin/go run issue81000.go
panic: issue81000: {L:0.7222675830801158 A:-0.9031940815103348 B:1.301887514238097} = [184 0 255], want [0 0 0]
goroutine 1 [running]:
main.main()
/home/chenguoqi/golang/go-upstream/issue81000.go:46 +0x460
exit status 2
Activity
[-]cmd/compile: loong64 spills a byte-sized inlined result with an 8-byte MOVD, clobbering adjacent stack slots (go1.27.0) [1.27 backport][/-][+]cmd/compile: loong64 spills a byte-sized inlined result with an 8-byte MOVD, clobbering adjacent stack slots [1.27 backport][/+]prattmic commentedon Sep 1, 2026
@abner-chenc since #81000 somehow has 200+ messages, could you confirm the CL to be backported, whether this impacts 1.26 and 1.27, and what the impact is (arbitrary memory corruption on the stack?).
abner-chenc commentedon Sep 7, 2026
Thanks!
Needs backporting to Go 1.26 and Go 1.27, otherwise the MOVD instruction could corrupt the stack. I have submitted a regression test case for this issue in CL 828625。
Here is the original error message:
gopherbot commentedon Sep 7, 2026
Change https://go.dev/cl/828625 mentions this issue:
test: add regression test for go.dev/issue/81000test: add regression test for go.dev/issue/81000
ci: pin Go 1.27.1 instead of `stable`, and say so in go.mod (#284)
ci: pin Go 1.27.1 instead of `stable`, and say so in go.mod (#306)
go.mod: require 1.27.1, the toolchain CI already pinned (#145)
280 remaining items
build: raise the Go floor to 1.27.1 (#7)
build: raise the Go floor to 1.27.1 (#8)
build: raise the Go floor to 1.27.1 (#6)
build: raise the Go floor to 1.27.1 (#11)
build: raise the Go floor to 1.27.1 (#12)
build: raise the Go floor to 1.27.1 (#14)
build: raise the Go floor to 1.27.1 (#8)
build: raise the Go floor to 1.27.1 (#11)
build: raise the Go floor to 1.27.1 (#11)
build: raise the Go floor to 1.27.1 (#14)
build: raise the Go floor to 1.27.1 (#15)
build: raise the Go floor to 1.27.1 (#12)
build: raise the Go floor to 1.27.1 (#12)
build: raise the Go floor to 1.27.1 (#12)
abner-chenc commentedon Oct 12, 2026
@dmitshur
The input operands for Cvt{32,64}to{32,64}F are integer registers, and the output operands are floating-point registers. However, the corresponding Op implementations on loong64 require both the input and output operands to be floating-point registers. Therefore, we need to move the input operand to a floating-point register on loong64.
Similarly, the input operands for Cvt{32,64}Fto{32,64} are floating-point registers, and the output operands are integer registers. Since the loong64 Op implementations require both operands to be floating-point registers, we need to move the output operand to an integer register on loong64.
Here the test case for this bug. It fails when running on the Go 1.27 branch.
Thanks!