cmd/compile: crash in make running generic code [1.18 backport]

[mier85]

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

go version go1.18 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mier85/.cache/go-build"
GOENV="/home/mier85/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mier85/go/pkg/mod"
GONOPROXY=
GONOSUMDB=
GOOS="linux"
GOPATH="/home/mier85/go"
GOPRIVATE=
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
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 -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2488678595=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://go.dev/play/p/ys1JxRrYwce

What did you expect to see?

=== RUN   TestRunner
=== RUN   TestRunner/#00
[]string{"blubb"}--- PASS: TestRunner (0.00s)
    --- PASS: TestRunner/#00 (0.00s)
PASS

What did you see instead?

=== RUN   TestRunner
=== RUN   TestRunner/#00
--- FAIL: TestRunner (0.00s)
    --- FAIL: TestRunner/#00 (0.00s)
panic: runtime error: makeslice: cap out of range [recovered]
	panic: runtime error: makeslice: cap out of range

goroutine 19 [running]:
testing.tRunner.func1.2({0x4bf6a0, 0x4f7f00})
	/usr/local/go-faketime/src/testing/testing.go:1389 +0x24e
testing.tRunner.func1()
	/usr/local/go-faketime/src/testing/testing.go:1392 +0x39f
panic({0x4bf6a0, 0x4f7f00})
	/usr/local/go-faketime/src/runtime/panic.go:838 +0x207
strconv.appendQuotedWith({0xc0000a2c98, 0x0, 0x45b5d9?}, {0x2e676e6974736574, 0x72656e6e755274}, 0x22, 0x85?, 0x50?)
	/usr/local/go-faketime/src/strconv/quote.go:35 +0x86
strconv.AppendQuote(...)
	/usr/local/go-faketime/src/strconv/quote.go:135
fmt.(*fmt).fmtQ(0xc0000a2c70, {0x2e676e6974736574, 0x4bba80?})
	/usr/local/go-faketime/src/fmt/format.go:457 +0xe8
fmt.(*pp).fmtString(0x4bba80?, {0x2e676e6974736574?, 0x0?}, 0x0?)
	/usr/local/go-faketime/src/fmt/print.go:441 +0x7b
fmt.(*pp).printValue(0xc0000a2c30, {0x4bba80?, 0x508561?, 0x0?}, 0x76, 0x1)
	/usr/local/go-faketime/src/fmt/print.go:757 +0xf32
fmt.(*pp).printValue(0xc0000a2c30, {0x4ba400?, 0xc0000ac0a8?, 0x4aba33?}, 0x76, 0x0)
	/usr/local/go-faketime/src/fmt/print.go:856 +0x1615
fmt.(*pp).printArg(0xc0000a2c30, {0x4ba400?, 0xc0000ac0a8}, 0x76)
	/usr/local/go-faketime/src/fmt/print.go:712 +0x74c
fmt.(*pp).doPrintf(0xc0000a2c30, {0x4d2be5, 0x3}, {0xc000093f08?, 0x1, 0x1})
	/usr/local/go-faketime/src/fmt/print.go:1026 +0x288
fmt.Fprintf({0x4f8308, 0xc0000b2008}, {0x4d2be5, 0x3}, {0xc000038708, 0x1, 0x1})
	/usr/local/go-faketime/src/fmt/print.go:204 +0x75
fmt.Printf(...)
	/usr/local/go-faketime/src/fmt/print.go:213
main.Fixture.Run(...)
	/tmp/sandbox3516507230/prog.go:34
testing.tRunner(0xc000083040, 0xc0000ac078)
	/usr/local/go-faketime/src/testing/testing.go:1439 +0x102
created by testing.(*T).Run
	/usr/local/go-faketime/src/testing/testing.go:1486 +0x35f

[ianlancetaylor]

This test works on tip, fails on Go 1.18 branch. A git bisect suggests that it was fixed by https://go.dev/cl/395594 which reverted https://go.dev/cl/378178. I'm not sure whether we should backport 395594 to the 1.18 branch.

CC @randall77

[ianlancetaylor]

Since this is fixed on tip, I'm marking this as a cherry pick candidate for 1.18.

[heschi]

cc @mdempsky @randall77

[toothrot]

Any updates on this issue? @randall77

[gopherbot]

Change https://go.dev/cl/411120 mentions this issue: [release-branch.go1.18] Revert "cmd/compile: stop interface conversions for generic method calls from allocating"

[cherrymui]

CL 395594 doesn't apply cleanly to the 1.18 branch, but the edit is small. I made https://go-review.googlesource.com/c/go/+/411120 , which does seem to fix the issue.

@randall77 what do you think? Should we backport the reverting CL? Thanks.