cmd/compile: miscompilation in pointer operations #52953

ddaa2000 · 2022-05-18T05:29:50Z

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

$ go version
go version go1.18.1 windows/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\ddaa\AppData\Local\go-build
set GOENV=C:\Users\ddaa\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\ddaa\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\ddaa\go
set GOPRIVATE=
set GOPROXY=https://goproxy.cn,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.18.1
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=D:\programing\go\bugReview\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ddaa\AppData\Local\Temp\go-build2453048728=/tmp/go-build -gno-rec
ord-gcc-switches

What did you do?

https://go.dev/play/p/yxl_PHRHUyf

What did you expect to see?

The program print true.

What did you see instead?

The program print false.
(This bug can be found in go1.17.9, but not in go1.16.15 and before)

The text was updated successfully, but these errors were encountered:

qiulaidongfeng · 2022-05-18T08:39:08Z

The go compiler compiles func UF6 () (V16 T13) do:

TEXT main.UF6(SB) E:/go语言文件/自由练习/37/main.go
func UF6() (V16 T13) {
  0x48b2e0		4883ec10		SUBQ $0x10, SP		
  0x48b2e4		48896c2408		MOVQ BP, 0x8(SP)	
  0x48b2e9		488d6c2408		LEAQ 0x8(SP), BP	
  0x48b2ee		c644240700		MOVB $0x0, 0x7(SP)	
	V16.Field1 = true
  0x48b2f3		c644240701		MOVB $0x1, 0x7(SP)	
	return T13{Field1: *V20}
  0x48b2f8		c644240700		MOVB $0x0, 0x7(SP)	
  0x48b2fd		c644240700		MOVB $0x0, 0x7(SP)	
  0x48b302		0fb6442407		MOVZX 0x7(SP), AX	
  0x48b307		488b6c2408		MOVQ 0x8(SP), BP	
  0x48b30c		4883c410		ADDQ $0x10, SP		
  0x48b310		c3			RET

The go compiler seems to eliminated var V20 * bool = & V16 field1

mengzhuo · 2022-05-18T08:44:41Z

cc @randall77

orian · 2022-05-18T10:06:01Z

Allowed myself to do some renaming in example: https://go.dev/play/p/qFeFB85-o9H (old https://go.dev/play/p/y2tKrbrW8Bg)

//Seed :1636136934
package main

import "fmt"

type T struct {
	Field1 bool
}

func main() {
	var ret T
	ret.Field1 = true
	var v *bool = &ret.Field1
	ret = T{Field1: *v}
	fmt.Println(ret.Field1)
}

bcmills · 2022-05-18T12:33:25Z

@gopherbot, please backport to Go 1.17 and 1.18. This bug causes miscompilation of otherwise-correct Go programs.

gopherbot · 2022-05-18T12:33:38Z

Backport issue(s) opened: #52960 (for 1.17), #52961 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

cuonglm · 2022-05-18T13:04:34Z

It seems to me this is a bug in ascompatee, since when it only happens with named return.

IIRC, ascompatee was optimized/refactored during 1.17 cycle.

Will take a deeper look later if no one beat me then.

cc @mdempsky

orian · 2022-05-18T13:21:49Z

@cuonglm my example has this bug without a return statement

cherrymui · 2022-05-18T15:24:56Z

It looks to me that the AST is fine, but the initial SSA isn't quite right. It generates a wrong value for the assignment ret = T{Field1: *v}

cherrymui · 2022-05-18T15:34:01Z

Okay, maybe the AST is indeed not quite right. ret = T{Field: *v} is compiled to

. BLOCK-init
. . AS tc(1) # x.go:12:6
. . . NAME-main.ret esc(no) Class:PAUTO Offset:0 Addrtaken OnStack Used main.T tc(1) # x.go:9:6
. . BLOCK tc(1) # x.go:12:16
. . BLOCK-List
. . . AS tc(1) # x.go:12:16
. . . . DOT main.Field1 bool tc(1) # x.go:12:16
. . . . . NAME-main.ret esc(no) Class:PAUTO Offset:0 Addrtaken OnStack Used main.T tc(1) # x.go:9:6
. . . . DEREF bool tc(1) # x.go:12:18
. . . . . NAME-main.v esc(no) Class:PAUTO Offset:0 OnStack PTR-*bool tc(1) # x.go:11:6

which is effectively

ret = T{}
ret.Field1 = *v

This is not equivalent to the original code as the value of *v changes after the first assignment (ret=T{}).

Perhaps we need to evaluate the RHS (*v) before rewriting the assignment.

cuonglm · 2022-05-18T16:16:51Z

@cuonglm my example has this bug without a return statement

Thanks for better reproducible program. Sounds like the problem was introduced long time ago, at least go1.16 also print false.

gopherbot · 2022-05-18T16:17:17Z

Change https://go.dev/cl/407014 mentions this issue: cmd/compile: do not use special literal assignment if LHS is address-taken

cherrymui · 2022-05-18T16:38:19Z

Yeah, @orian 's example #52953 (comment) prints false since at least Go 1.11 (maybe even earlier, I didn't try), whereas the original example starts to fail only since Go 1.17...

benhoyt · 2022-05-19T01:43:19Z

FWIW, @orian's example happens as far back as Go 1.3. With such a simple repro, it's surprising this hasn't been run into (or at least reported) earlier!

$ go1.3rc2 run t.go
false
$ go1.4rc2 run t.go
false
$ go1.5.4 run t.go
false
$ go1.6.4 run t.go
false
$ go1.7.6 run t.go
false
$ go1.8.7 run t.go
false
$ go1.9.7 run t.go
false
$ go1.10.8 run t.go
false
$ go1.11.13 run t.go
false
$ go1.12.17 run t.go
false
$ go1.13.15 run t.go
false
$ go1.14.15 run t.go
false
$ go1.15.15 run t.go
false
$ go1.16.15 run t.go
false
$ go1.17.10 run t.go
false
$ go version
go version go1.18.1 linux/amd64
$ go run t.go
false
$ gotip version
go version devel go1.19-c087121daf Wed May 18 19:52:53 2022 +0000 linux/amd64
$ gotip run t.go
true
$ cat t.go
package main

import "fmt"

type T struct {
	Field1 bool
}

func main() {
	var ret T
	ret.Field1 = true
	var v *bool = &ret.Field1
	ret = T{Field1: *v}
	fmt.Println(ret.Field1)
}

gopherbot · 2022-07-25T23:33:36Z

Change https://go.dev/cl/419450 mentions this issue: [release-branch.go1.18] cmd/compile: do not use special literal assignment if LHS is address-taken

gopherbot · 2022-07-25T23:35:27Z

Change https://go.dev/cl/419451 mentions this issue: [release-branch.go1.17] cmd/compile: do not use special literal assignment if LHS is address-taken

…nment if LHS is address-taken A composite literal assignment x = T{field: v} may be compiled to x = T{} x.field = v We already do not use this form is RHS uses LHS. If LHS is address-taken, RHS may uses LHS implicitly, e.g. v = &x.field x = T{field: *v} The lowering above would change the value of RHS (*v). Updates #52953. Fixes #52961. Change-Id: I3f798e00598aaa550b8c17182c7472fef440d483 Reviewed-on: https://go-review.googlesource.com/c/go/+/407014 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 1c77137) Reviewed-on: https://go-review.googlesource.com/c/go/+/419450 Reviewed-by: Matthew Dempsky <mdempsky@google.com>

…nment if LHS is address-taken A composite literal assignment x = T{field: v} may be compiled to x = T{} x.field = v We already do not use this form is RHS uses LHS. If LHS is address-taken, RHS may uses LHS implicitly, e.g. v = &x.field x = T{field: *v} The lowering above would change the value of RHS (*v). Updates #52953. Fixes #52960. Change-Id: I3f798e00598aaa550b8c17182c7472fef440d483 Reviewed-on: https://go-review.googlesource.com/c/go/+/407014 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 1c77137) Reviewed-on: https://go-review.googlesource.com/c/go/+/419451 Reviewed-by: Matthew Dempsky <mdempsky@google.com>

ddaa2000 mentioned this issue May 18, 2022

cmd/compile: miscompilation in pointer operations #52957

Closed

mengzhuo added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 18, 2022

bcmills added this to the Go1.19 milestone May 18, 2022

This was referenced May 18, 2022

cmd/compile: miscompilation in pointer operations [1.17 backport] #52960

Closed

cmd/compile: miscompilation in pointer operations [1.18 backport] #52961

Closed

mengzhuo added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 18, 2022

gopherbot closed this as completed in 1c77137 May 18, 2022

golang locked and limited conversation to collaborators Jul 25, 2023

gopherbot added the FrozenDueToAge label Jul 25, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/compile: miscompilation in pointer operations #52953

cmd/compile: miscompilation in pointer operations #52953

ddaa2000 commented May 18, 2022

qiulaidongfeng commented May 18, 2022

mengzhuo commented May 18, 2022

orian commented May 18, 2022 •

edited

bcmills commented May 18, 2022

gopherbot commented May 18, 2022

cuonglm commented May 18, 2022

orian commented May 18, 2022

cherrymui commented May 18, 2022

cherrymui commented May 18, 2022

cuonglm commented May 18, 2022

gopherbot commented May 18, 2022

cherrymui commented May 18, 2022 •

edited

benhoyt commented May 19, 2022 •

edited

gopherbot commented Jul 25, 2022

gopherbot commented Jul 25, 2022

cmd/compile: miscompilation in pointer operations #52953

cmd/compile: miscompilation in pointer operations #52953

Comments

ddaa2000 commented May 18, 2022

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

qiulaidongfeng commented May 18, 2022

mengzhuo commented May 18, 2022

orian commented May 18, 2022 • edited

bcmills commented May 18, 2022

gopherbot commented May 18, 2022

cuonglm commented May 18, 2022

orian commented May 18, 2022

cherrymui commented May 18, 2022

cherrymui commented May 18, 2022

cuonglm commented May 18, 2022

gopherbot commented May 18, 2022

cherrymui commented May 18, 2022 • edited

benhoyt commented May 19, 2022 • edited

gopherbot commented Jul 25, 2022

gopherbot commented Jul 25, 2022

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

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

orian commented May 18, 2022 •

edited

cherrymui commented May 18, 2022 •

edited

benhoyt commented May 19, 2022 •

edited