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: internal compiler error: (...) value ~R0 (v85) incorrectly live at entry #62211

Closed
aarzilli opened this issue Aug 22, 2023 · 4 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@aarzilli
Copy link
Contributor

$ go version
go version devel go1.22-63ab68ddc5 Tue Aug 22 12:05:36 2023 +0000 linux/amd64

Building this reproduction program https://go.dev/play/p/DF9uLw2Vrs9?v=gotip results in this internal compiler error:

# command-line-arguments
./repro.go:16:6: internal compiler error: 'checkCertCmd': value ~R0 (v85) incorrectly live at entry

goroutine 17 [running]:
runtime/debug.Stack()
        /usr/local/go-tip/src/runtime/debug/stack.go:24 +0x5e
cmd/compile/internal/base.FatalfAt({0x66b368?, 0xc0?}, {0xc000670000, 0x2d}, {0xc0006426c0, 0x3, 0x3})
        /usr/local/go-tip/src/cmd/compile/internal/base/print.go:230 +0x1d7
cmd/compile/internal/base.Fatalf(...)
        /usr/local/go-tip/src/cmd/compile/internal/base/print.go:199
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0x0?, {0x5?, 0x0?}, {0xd85d53, 0x27}, {0xc0006460e0, 0x2, 0xc00066b401?})
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/ssa.go:8012 +0x16a
cmd/compile/internal/ssagen.(*state).Fatalf(0xce2380?, {0xd85d53?, 0xc00059d430?}, {0xc0006460e0?, 0xebf9e8?, 0xc00065a210?})
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/ssa.go:935 +0x67
cmd/compile/internal/ssagen.(*simplePhiState).insertPhis(0xc00066b900)
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/phi.go:486 +0x2a5
cmd/compile/internal/ssagen.(*state).insertPhis(...)
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/phi.go:45
cmd/compile/internal/ssagen.buildssa(0xc000403e40, 0x2)
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/ssa.go:571 +0x2b6b
cmd/compile/internal/ssagen.Compile(0xc000403e40, 0x0?)
        /usr/local/go-tip/src/cmd/compile/internal/ssagen/pgen.go:216 +0x45
cmd/compile/internal/gc.compileFunctions.func5.1(0x0?)
        /usr/local/go-tip/src/cmd/compile/internal/gc/compile.go:186 +0x34
cmd/compile/internal/gc.compileFunctions.func3.1()
        /usr/local/go-tip/src/cmd/compile/internal/gc/compile.go:168 +0x30
created by cmd/compile/internal/gc.compileFunctions.func3 in goroutine 8
        /usr/local/go-tip/src/cmd/compile/internal/gc/compile.go:167 +0x23a
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 22, 2023
@aarzilli
Copy link
Contributor Author

@mdempsky mdempsky self-assigned this Aug 22, 2023
@mdempsky
Copy link
Member

Thanks for the report.

@mdempsky
Copy link
Member

Simplified test case: https://go.dev/play/p/SPdDcqGaA9C?v=gotip

The issue is the new deadcode elimination identifies x || true is always true, and so it prunes:

func f() bool {
  if x || true {
    return true
  }
  return true
}

into just:

func f() bool {
  if x || true {
    return true
  }
  // no return!
}

This then causes the inliner to trigger special optimizations for functions with a single "return" statement, which then seems to cause confusion for phi insertion during ssagen, because the result parameter (internally named ~R0) never gets initialized in the "no return" path, and it can't tell yet that that path isn't actually reachable.

@gopherbot
Copy link

Change https://go.dev/cl/522096 mentions this issue: cmd/compile/internal/noder: emit static branches as blocks

cellularmitosis pushed a commit to cellularmitosis/go that referenced this issue Aug 24, 2023
In go.dev/cl/517775, I moved the frontend's deadcode elimination pass
into unified IR. But I also made a small enhancement: a branch like
"if x || true" is now detected as always taken, so the else branch can
be eliminated.

However, the inliner also has an optimization for delaying the
introduction of the result temporary variables when there's a single
return statement (added in go.dev/cl/266199). Consequently, the
inliner turns "if x || true { return true }; return true" into:

	if x || true {
		~R0 := true
		goto .i0
	}
	.i0:
	// code that uses ~R0

In turn, this confuses phi insertion, because it doesn't recognize
that the "if" statement is always taken, and so ~R0 will always be
initialized.

With this CL, after inlining we instead produce:

	_ = x || true
	~R0 := true
	goto .i0
	.i0:

Fixes golang#62211.

Change-Id: Ic8a12c9eb85833ee4e5d114f60e6c47817fce538
Reviewed-on: https://go-review.googlesource.com/c/go/+/522096
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: 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 Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

3 participants