Skip to content
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: miscompilation in pointer operations #52953

Closed
ddaa2000 opened this issue May 18, 2022 · 13 comments
Closed

cmd/compile: miscompilation in pointer operations #52953

ddaa2000 opened this issue May 18, 2022 · 13 comments
Labels
NeedsFix
Milestone

Comments

@ddaa2000
Copy link

@ddaa2000 ddaa2000 commented May 18, 2022

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)

@qiulaidongfeng
Copy link

@qiulaidongfeng qiulaidongfeng commented May 18, 2022

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 mengzhuo added the NeedsInvestigation label May 18, 2022
@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented May 18, 2022

cc @randall77

@orian
Copy link

@orian orian commented May 18, 2022

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
Copy link
Member

@bcmills bcmills commented May 18, 2022

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

@gopherbot
Copy link

@gopherbot gopherbot commented May 18, 2022

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
Copy link
Member

@cuonglm cuonglm commented May 18, 2022

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
Copy link

@orian orian commented May 18, 2022

@cuonglm my example has this bug without a return statement

@mengzhuo mengzhuo added NeedsFix and removed NeedsInvestigation labels May 18, 2022
@cherrymui
Copy link
Member

@cherrymui cherrymui commented May 18, 2022

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
Copy link
Member

@cherrymui cherrymui commented May 18, 2022

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
Copy link
Member

@cuonglm cuonglm commented May 18, 2022

@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
Copy link

@gopherbot gopherbot commented May 18, 2022

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

@cherrymui
Copy link
Member

@cherrymui cherrymui commented May 18, 2022

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
Copy link
Contributor

@benhoyt benhoyt commented May 19, 2022

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)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix
Projects
None yet
Development

No branches or pull requests

9 participants