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

Open
YueMengGu opened this issue Jul 6, 2022 · 7 comments
Open

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

YueMengGu opened this issue Jul 6, 2022 · 7 comments
Labels
compiler/runtime NeedsFix
Milestone

Comments

@YueMengGu
Copy link

YueMengGu commented Jul 6, 2022

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

ZekeLu commented Jul 6, 2022

This is the commit that introduced the bug: a3bb28e

@YueMengGu
Copy link
Author

YueMengGu commented Jul 6, 2022

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 label Jul 6, 2022
@heschi heschi added this to the Backlog milestone Jul 6, 2022
@gopherbot gopherbot added the compiler/runtime label Jul 13, 2022
@cuonglm cuonglm modified the milestones: Backlog, Go1.20 Aug 12, 2022
@gopherbot
Copy link

gopherbot commented Aug 12, 2022

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

@mdempsky
Copy link
Member

mdempsky commented Aug 12, 2022

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime NeedsFix
Projects
Status: Triage Backlog
Development

No branches or pull requests

6 participants