cmd/compile: calling function that propagates multiple return values, some generic, causes compiler panic

[jiftechnify]

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

$ go version
go version go1.17 linux/amd64

Does this issue reproduce with the latest release?

Yes. (I found this issue in the latest release.)

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jiftechnify/.cache/go-build"
GOENV="/home/jiftechnify/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jiftechnify/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jiftechnify/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jiftechnify/sdk/go1.17"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jiftechnify/sdk/go1.17/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jiftechnify/code_samples/go/generics/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2454853886=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.17 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.17
uname -sr: Linux 5.11.0-27-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.31-0ubuntu9.2) stable release version 2.31.
gdb --version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2

What did you do?

I tried to run the program below.

package main

// multivalued function that one of the results is generic
func aaa[T any]() (T, error) {
	var t T
	return t, nil
}

// returns results of function call directly
func ng[T any]() (T, error) {
	return aaa[T]()
}

// first assigns results of function call to temporary variables, then return them
func ok[T any]() (T, error) {
	t, err := aaa[T]()
	return t, err
}

func main() {
	ng[string]()
	// ok[string]()
}

What did you expect to see?

The program compiles and runs successfully.

What did you see instead?

Compiler panic.

$ go run -gcflags=-G=3 main.go
# command-line-arguments
panic: cannot SetOp XXX on XXX

goroutine 1 [running]:
cmd/compile/internal/ir.(*ConvExpr).SetOp(0xc0000a5bd0, 0x40)
        /usr/local/go/src/cmd/compile/internal/ir/expr.go:279 +0xd9
cmd/compile/internal/ir.NewConvExpr({0xb50a0, 0xc0}, 0x10, 0xc0003ca310, {0xe4d2f8, 0xc0000c8360})
        /usr/local/go/src/cmd/compile/internal/ir/expr.go:267 +0xae
cmd/compile/internal/noder.assignconvfn({0xe4d2f8, 0xc0000c8360}, 0xc0003ca310)
        /usr/local/go/src/cmd/compile/internal/noder/transform.go:421 +0xb3
cmd/compile/internal/noder.typecheckaste(0x18, {0xc0000a59a0, 0xc0000c8360}, 0x0, 0xc000123158, {0xc00009c440, 0x1, 0xc000123158})
        /usr/local/go/src/cmd/compile/internal/noder/transform.go:467 +0x179
cmd/compile/internal/noder.transformReturn(0xc0000a59a0)
        /usr/local/go/src/cmd/compile/internal/noder/transform.go:488 +0xa8
cmd/compile/internal/noder.(*subster).node.func1({0xe4ebf8, 0xc0000a4730})
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:413 +0x7cb
cmd/compile/internal/noder.(*subster).node(0xc0000a58b0, {0xe4ebf8, 0xc0000a4730})
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:548 +0xa5
cmd/compile/internal/noder.(*subster).list(0xc00009c420, {0xc00009c310, 0x1, 0xc00007c5a0})
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:568 +0x8e
cmd/compile/internal/noder.(*irgen).genericSubst(0xc0000c8000, 0xc0000a5860, 0xc0000aeb60, {0xc00009c3b0, 0x1, 0x1}, 0x0)
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:318 +0x7a5
cmd/compile/internal/noder.(*irgen).getInstantiation(0xc0000c8000, 0xc0000aeb60, {0xc00009c3b0, 0x1, 0x1}, 0xf0)
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:191 +0xc9
cmd/compile/internal/noder.(*irgen).getInstantiationForNode(0xc00009b620, 0xc000094ff0)
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:178 +0x9f
cmd/compile/internal/noder.(*irgen).stencil.func1({0xe4d2f8, 0xc0000c8240})
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:89 +0xda
cmd/compile/internal/ir.Visit.func1({0xe4d2f8, 0xc0000c8240})
        /usr/local/go/src/cmd/compile/internal/ir/visit.go:105 +0x30
cmd/compile/internal/ir.doNodes({0xc00009c3d0, 0x1, 0xc0000a6090}, 0xc0000a02a0)
        /usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1440 +0x67
cmd/compile/internal/ir.(*Func).doChildren(0xe4dac8, 0xc00009e6e0)
        /usr/local/go/src/cmd/compile/internal/ir/func.go:151 +0x2e
cmd/compile/internal/ir.DoChildren(...)
        /usr/local/go/src/cmd/compile/internal/ir/visit.go:94
cmd/compile/internal/ir.Visit.func1({0xe4dac8, 0xc00009e6e0})
        /usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.Visit({0xe4dac8, 0xc00009e6e0}, 0xc0000a8a20)
        /usr/local/go/src/cmd/compile/internal/ir/visit.go:108 +0xb8
cmd/compile/internal/noder.(*irgen).stencil(0xc0000c8000)
        /usr/local/go/src/cmd/compile/internal/noder/stencil.go:76 +0x1a5
cmd/compile/internal/noder.(*irgen).generate(0xc0000c8000, {0xc000064820, 0x2, 0xc00009c0b0})
        /usr/local/go/src/cmd/compile/internal/noder/irgen.go:185 +0x25d
cmd/compile/internal/noder.check2({0xc000064820, 0x0, 0x2})
        /usr/local/go/src/cmd/compile/internal/noder/irgen.go:78 +0x5da
cmd/compile/internal/noder.LoadPackage({0xc00001e2a0, 0x2, 0x0})
        /usr/local/go/src/cmd/compile/internal/noder/noder.go:80 +0x30b
cmd/compile/internal/gc.Main(0xd16450)
        /usr/local/go/src/cmd/compile/internal/gc/main.go:192 +0xb2e
main.main()
        /usr/local/go/src/cmd/compile/main.go:55 +0xdd

notes

• The compiler panics only when the problematic function (ng) is actually called. If that call is commented out, the program compiles normally.
• Calling a function that is semantically equal to ng but returns result indirectly (ok in the code above) doesn't cause a compiler panic.
• Type(s) of result(s) other than the generic one (e.g. error in the code above) are irrelevant to this issue.

[ALTree]

I don't think you're supposed to use -G=3 on 1.17. The dev.tyeparams branch was merged into master after the release. -G=3 in 1.17 has a lot of bugs and it's not supposed to be used at all, in general.

If you want to experiment with generics, use -G=3 with tip.

[ALTree]

(That program doesn't crash on tip, btw).

[mknyszek]

@ALTree Thanks for looking into it. If it doesn't crash on tip then there's nothing to do here.

@jiftechnify If you can still reproduce on master, then I'll reopen the issue. Closing for now.

[jiftechnify]

I tried to reproduce on gotip, and everything went well.

@ALTree I'm sorry for misunderstanding about development version of Go, and thank you for information about it.

$ gotip env GOVERSION
devel go1.18-9871726 Thu Aug 19 15:09:47 2021 +0000

$ gotip run -gcflags=-G=3 main.go
# compiles and runs without panic

[ALTree]

@jiftechnify no problem. Thanks for checking.