-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: MOVWreg missing sign-extension following a Copy from a floating-point LoadReg #50671
Comments
That argument is enormously large. It seems it should be 0x64. Maybe it is a compiler bug. |
It is supposed to call |
@cherrymui, I made a stab at updating the title based on your diagnosis. Does it look accurate? 😅 |
Thanks. Yeah, it looks right. |
Change https://golang.org/cl/379236 mentions this issue: |
@gopherbot, please backport to Go 1.16 and Go 1.17. This is a compiler bug that causes subtle run-time data corruption; it is hard to predict which code might be affected, and the corrupted paths might not be triggered by tests, but it appears to cause a nonzero rate of failures in the Go builders. The fix is small and MIPS-specific, so backporting it seems low-risk. |
Backport issue(s) opened: #50682 (for 1.16), #50683 (for 1.17). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/379514 mentions this issue: |
Change https://golang.org/cl/379515 mentions this issue: |
…g to FP register on MIPS64 For an extension operation like MOVWreg, if the operand is already extended, we optimize the second extension out. Usually a LoadReg of a proper type would come already extended, as a MOVW/MOVWU etc. instruction does. But for a LoadReg to a floating point register, the instruction does not do the extension. So we cannot elide the extension. Updates #50671. Fixes #50682. Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3 Reviewed-on: https://go-review.googlesource.com/c/go/+/379236 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit d93ff73) Reviewed-on: https://go-review.googlesource.com/c/go/+/379515
…g to FP register on MIPS64 For an extension operation like MOVWreg, if the operand is already extended, we optimize the second extension out. Usually a LoadReg of a proper type would come already extended, as a MOVW/MOVWU etc. instruction does. But for a LoadReg to a floating point register, the instruction does not do the extension. So we cannot elide the extension. Updates #50671. Fixes #50683. Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3 Reviewed-on: https://go-review.googlesource.com/c/go/+/379236 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit d93ff73) Reviewed-on: https://go-review.googlesource.com/c/go/+/379514
For an extension operation like MOWWreg, if the operand is already extended, we optimize the second extension out. Usually a LoadReg of a proper type would come already extended, as a MOVW/MOVWU etc. instruction does. But for a LoadReg to a floating point register, the instruction does not do the extension. So we cannot elide the extension. Fixes golang#50671. Change-Id: Id8991df78d5acdecd3fd6138c558428cbd5f6ba3 Reviewed-on: https://go-review.googlesource.com/c/go/+/379236 Trust: Cherry Mui <cherryyz@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
greplogs --dashboard -md -l -e '(?ms)\Alinux-mips64le-mengzhuo.*runtime: out of memory'
2022-01-18T14:56:19-6944b10-5b3ebc8/linux-mips64le-mengzhuo
This failure looks like memory corruption to me, because the failing allocation is for a “28862184423424-byte block” (26.2 TiB). It's not obvious to me whether the corruption is due to a bug in
x/image/draw
itself, or in the compiler, runtime, and/or platform.(CC @mengzhuo)
The text was updated successfully, but these errors were encountered: