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: compile failed with "Value live at entry" #53702

Closed
YueMengGu opened this issue Jul 6, 2022 · 13 comments
Closed

cmd/compile: compile failed with "Value live at entry" #53702

YueMengGu opened this issue Jul 6, 2022 · 13 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@YueMengGu
Copy link

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

$ go version
go version go1.18.3 darwin/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
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/xxx/.cache/go-build"
GOENV="/Users/xxx/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/xxx/Coding/go/pkg/mod"
GONOPROXY="*.everphoto.cn,git.smartisan.com"
GONOSUMDB="*.everphoto.cn,git.smartisan.com"
GOOS="darwin"
GOPATH="/Users/xxx/Coding/go"
GOPRIVATE="*.everphoto.cn,git.smartisan.com"
GOPROXY="https://goproxy.cn,https://proxy.golang.org,direct"
GOROOT="/Users/xxx/Coding/github/go"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/Users/xxx/Coding/github/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18.3"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/77/qcdftwkd6jb6945_b2k6n60h0000gp/T/go-build1272012810=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

package main

type Elem struct {}
func  (*Elem) Wait(callback func()) {}

type Base struct {
  elem [8]*Elem
}

var g_val = 1
func (s *Base) Do() *int {
  resp := &g_val
  for _, e := range s.elem {
    e.Wait(func() {
      *resp = 0
    })
  }
  return resp
}

type Sub struct {
  *Base
}

func main() {
  a := Sub{}
  a.Do()
}

What did you expect to see?

go build test.go

compile with no error

What did you see instead?

command-line-arguments

./diversity_wrap.go:15:7: internal compiler error: 'Sub.Do.func1': Value live at entry. It shouldn't be. func Sub.Do.func1, node resp, value nil

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

it's ok with go1.16 and go1.17

I have tried patch which didn't work:

@ZekeLu
Copy link
Contributor

ZekeLu commented Jul 6, 2022

This is the commit that introduced the bug: a3bb28e

@YueMengGu
Copy link
Author

This is the commit that introduced the bug: a3bb28e

I tried to change the loop from range to by step,just like

  func (s *Base) Do() *int {
    resp := &g_val
    for i := 0; i < 8; i++ {
    //for _, e := range s.elem {
      s.elem[i].Wait(func() {
        *resp = 0
      })
    }
    return resp
  }

Compiled with go build -gcflags="-m=2" test.go

Without the change, compiled with go1.17 we got

./diversity_wrap.go:11:6: cannot inline (*Base).Do: unhandled op RANGE

And with the change, compiled with go1.17 we got

./diversity_wrap.go:11:6: can inline (*Base).Do with cost 46 as: method(*Base) func() *int { resp := &g_val; for loop; return resp }

The range is missing, and then compiled with go1.18.3 we got

./diversity_wrap.go:11:6: can inline (*Base).Do with cost 46 as: method(*Base) func() *int { resp := &g_val; for loop; return resp }
./diversity_wrap.go:16:7: internal compiler error: 'Sub.Do.func1': Value live at entry. It shouldn't be. func Sub.Do.func1, node resp, value nil

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

So the bug maybe introduced not only a3bb28e

@cuonglm
Copy link
Member

cuonglm commented Jul 6, 2022

Writing Base.Do as:

func (s *Base) Do() *int {
	resp := &g_val
	for *resp != 0 {
		s.elem[0].Wait(func() { *resp = 0 })
	}
	return resp
}

is enough to trigger the bug.

@cuonglm
Copy link
Member

cuonglm commented Jul 6, 2022

git bisect points to https://go-review.googlesource.com/c/go/+/327871 cc @mdempsky

Unified IR does not have this bug, because it generates its own wrapper instead of relying on reflectdata.

@heschi heschi added the NeedsFix The path to resolution is known, but the work has not been done. label Jul 6, 2022
@heschi heschi added this to the Backlog milestone Jul 6, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
@cuonglm cuonglm modified the milestones: Backlog, Go1.20 Aug 12, 2022
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/423434 mentions this issue: test: add test case for issue 53702

@mdempsky
Copy link
Contributor

git bisect points to https://go-review.googlesource.com/c/go/+/327871 cc @mdempsky

That's surprising. That commit should have only affect devirtualizationed, but the test case doesn't have any interface types.

If we revert just the typecheck.NeedITab stuff, does it fix the issue? (We shouldn't need it for unified IR, but maybe it was important to !unified mode.)

@cuonglm
Copy link
Member

cuonglm commented Aug 13, 2022

That's surprising. That commit should have only affect devirtualizationed, but the test case doesn't have any interface types.

I think the problem comes from generating method wrapper, not interface types. After CL 327871, we now always do inlining for method wrapper after global escape analysis. Note that disable inlining will make it compiled in non-unified.

If we revert just the typecheck.NeedITab stuff, does it fix the issue?

No.

gopherbot pushed a commit that referenced this issue Aug 14, 2022
The issue is expected to be fixed when Unified IR is enabled by default,
so adding a test to make sure thing works correctly.

Updates #53702

Change-Id: Id9d7d7ca4506103df0d10785ed5ee170d69988ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/423434
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/423834 mentions this issue: test: fix issue53702.go for noopt builder

gopherbot pushed a commit that referenced this issue Aug 15, 2022
The test requires inlining happens.

Updates #53702

Change-Id: I0d93b5e29e271ace4098307b74c40c0e06d975e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/423834
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
@cuonglm
Copy link
Member

cuonglm commented Aug 27, 2022

This is now fixed at tip, could we close? @mdempsky

@mdempsky
Copy link
Contributor

@cuonglm The issue is reportedly still a regression from Go 1.17. It's also not specifically a generics issue, so I think we should try to backport fixes for Go 1.18/1.19.

@gopherbot
Copy link
Contributor

Change https://go.dev/cl/426334 mentions this issue: cmd/compile: only inline method wrapper if method don't contain closures

@cuonglm
Copy link
Member

cuonglm commented Aug 29, 2022

@gopherbot please backport this issue to go1.18 and go1.19

@gopherbot
Copy link
Contributor

Backport issue(s) opened: #54725 (for 1.18), #54726 (for 1.19).

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants