Golang cmd/compile: internal compiler error too many arguments to function call

Go version

go version go1.25rc1 linux/amd64

Output of `go env` in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/mauclair/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/mauclair/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/home/mauclair/tmp/go-build1738312256=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/home/mauclair/go2/src/github.com/DevotedHealth/core/go.mod'
GOMODCACHE='/home/mauclair/go2/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/mauclair/go2'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/mauclair/go2/pkg/mod/golang.org/toolchain@v0.0.1-go1.25rc1.linux-amd64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/mauclair/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/mauclair/go2/pkg/mod/golang.org/toolchain@v0.0.1-go1.25rc1.linux-amd64/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.25rc1'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I'm attempting to build our main binary with go 1.25rc1, and I'm getting an ICE when building a couple packages that both use another of our packages spanutil for managing date spans (EffectiveSpan here). The error is pointing to the population of aSlice on the last line in the following snippet

func IntersectEffectiveSpans[
  P1 EffectiveSpan,
  P2 EffectiveSpan,
](a []P1, b []P2) []P1 {
  bSlice := SortEffectiveSpans(b, ASC)
  aSlice := SortEffectiveSpans(a, ASC)

and seems to only occur on the generic type that matches the return type (no error points to the population of bSlice). I'm working on building a replication case here, but wanted to fill out this issue before I lost all the context here. Replicating is difficult because this code is full of types generated from protobuf files, etc so it might take me a bit to build that replication case without having to pull in a large chunk of our codebase.

I'm running go test against a package with no tests here because it was the fastest feedback loop I could find in our codebase that replicated the issue. I'm seeing this same issue in our CI pipelines that run the same code on linux / arm64.

What did you see happen?

$ go test -gcflags=all=-h
# <path to package a>
../../../spanutil/spanutil.go:748:30: internal compiler error: too many arguments to function call

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new
panic: -h [recovered, repanicked]

goroutine 1 [running]:
cmd/compile/internal/gc.handlePanic()
        cmd/compile/internal/gc/main.go:52 +0xa5
panic({0xe3a100?, 0x1085990?})
        runtime/panic.go:783 +0x132
cmd/compile/internal/base.hcrash()
        cmd/compile/internal/base/print.go:267 +0x45
cmd/compile/internal/base.FatalfAt({0x5336c80?, 0xc0?}, {0xf15096, 0x18}, {0xc0030b40c0, 0x1, 0x1})
        cmd/compile/internal/base/print.go:235 +0x22a
cmd/compile/internal/base.Fatalf(...)
        cmd/compile/internal/base/print.go:195
cmd/compile/internal/typecheck.typecheckaste(0x1d, {0x10970b8?, 0xc0052d7180?}, 0xb8?, {0xc0052a50f8?, 0x696954?, 0x1098cd8?}, {0xc005181770, 0x3, 0x3}, ...)
        cmd/compile/internal/typecheck/typecheck.go:1058 +0x26d
cmd/compile/internal/typecheck.tcCall(0xc005331680, 0x3)
        cmd/compile/internal/typecheck/func.go:258 +0xb9a
cmd/compile/internal/typecheck.typecheck1({0x1097248?, 0xc005331680?}, 0x3)
        cmd/compile/internal/typecheck/typecheck.go:390 +0x865
cmd/compile/internal/typecheck.typecheck({0x1097248, 0xc005331680}, 0x3)
        cmd/compile/internal/typecheck/typecheck.go:179 +0x1ad
cmd/compile/internal/typecheck.Call(...)
        cmd/compile/internal/typecheck/typecheck.go:28
cmd/compile/internal/noder.(*reader).expr(0xc005336c80)
        cmd/compile/internal/noder/reader.go:2414 +0x1dc5
cmd/compile/internal/noder.(*reader).expr(0xc005336c80)
        cmd/compile/internal/noder/reader.go:2475 +0x296c
cmd/compile/internal/noder.(*reader).multiExpr(0xc005336c80)
        cmd/compile/internal/noder/reader.go:2999 +0x1e7
cmd/compile/internal/noder.(*reader).stmt1(0xc005336c80, 0xc00533c230?, 0xc0030b5520)
        cmd/compile/internal/noder/reader.go:1712 +0x95c
cmd/compile/internal/noder.(*reader).stmts(0xc005336c80)
        cmd/compile/internal/noder/reader.go:1691 +0xb0
cmd/compile/internal/noder.(*reader).funcBody.func1()
        cmd/compile/internal/noder/reader.go:1344 +0x66
cmd/compile/internal/ir.WithFunc(0x77aa0707a745?, 0x570?)
        cmd/compile/internal/ir/func.go:405 +0x86
cmd/compile/internal/noder.(*reader).funcBody(0xc005336c80, 0xc0052f3180)
        cmd/compile/internal/noder/reader.go:1333 +0xd2
cmd/compile/internal/noder.pkgReaderIndex.funcBody({0xc00070d770, 0x1f, 0xc0052e2a90, 0x0, 0x0}, 0xc0052f3180)
        cmd/compile/internal/noder/reader.go:1321 +0x4f
cmd/compile/internal/noder.readBodies(0xc0001e2000, 0x0)
        cmd/compile/internal/noder/unified.go:265 +0x17a
cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0xc0001c0930?, 0xe242e0?, 0xc00020f928?})
        cmd/compile/internal/noder/unified.go:205 +0x1ab
cmd/compile/internal/noder.LoadPackage({0xc0001c4130, 0x3, 0x3})
        cmd/compile/internal/noder/noder.go:77 +0x450
cmd/compile/internal/gc.Main(0xf3f420)
        cmd/compile/internal/gc/main.go:208 +0xcc5
main.main()
        cmd/compile/main.go:57 +0xf9
# <path to package b>
../../../spanutil/spanutil.go:748:30: internal compiler error: too many arguments to function call

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new
panic: -h [recovered, repanicked]

goroutine 1 [running]:
cmd/compile/internal/gc.handlePanic()
        cmd/compile/internal/gc/main.go:52 +0xa5
panic({0xe3a100?, 0x1085990?})
        runtime/panic.go:783 +0x132
cmd/compile/internal/base.hcrash()
        cmd/compile/internal/base/print.go:267 +0x45
cmd/compile/internal/base.FatalfAt({0x366aa980?, 0x71f4?}, {0xf15096, 0x18}, {0xc005d8e0c0, 0x1, 0x1})
        cmd/compile/internal/base/print.go:235 +0x22a
cmd/compile/internal/base.Fatalf(...)
        cmd/compile/internal/base/print.go:195
cmd/compile/internal/typecheck.typecheckaste(0x1d, {0x10970b8?, 0xc000946b40?}, 0xb8?, {0xc0008ef458?, 0x696954?, 0x1098cd8?}, {0xc0033d3b00, 0x3, 0x3}, ...)
        cmd/compile/internal/typecheck/typecheck.go:1058 +0x26d
cmd/compile/internal/typecheck.tcCall(0xc00097ab40, 0x3)
        cmd/compile/internal/typecheck/func.go:258 +0xb9a
cmd/compile/internal/typecheck.typecheck1({0x1097248?, 0xc00097ab40?}, 0x3)
        cmd/compile/internal/typecheck/typecheck.go:390 +0x865
cmd/compile/internal/typecheck.typecheck({0x1097248, 0xc00097ab40}, 0x3)
        cmd/compile/internal/typecheck/typecheck.go:179 +0x1ad
cmd/compile/internal/typecheck.Call(...)
        cmd/compile/internal/typecheck/typecheck.go:28
cmd/compile/internal/noder.(*reader).expr(0xc0051b92c0)
        cmd/compile/internal/noder/reader.go:2414 +0x1dc5
cmd/compile/internal/noder.(*reader).expr(0xc0051b92c0)
        cmd/compile/internal/noder/reader.go:2475 +0x296c
cmd/compile/internal/noder.(*reader).multiExpr(0xc0051b92c0)
        cmd/compile/internal/noder/reader.go:2999 +0x1e7
cmd/compile/internal/noder.(*reader).stmt1(0xc0051b92c0, 0xc000978f50?, 0xc005d8f520)
        cmd/compile/internal/noder/reader.go:1712 +0x95c
cmd/compile/internal/noder.(*reader).stmts(0xc0051b92c0)
        cmd/compile/internal/noder/reader.go:1691 +0xb0
cmd/compile/internal/noder.(*reader).funcBody.func1()
        cmd/compile/internal/noder/reader.go:1344 +0x66
cmd/compile/internal/ir.WithFunc(0x71f4358ec745?, 0x570?)
        cmd/compile/internal/ir/func.go:405 +0x86
cmd/compile/internal/noder.(*reader).funcBody(0xc0051b92c0, 0xc005196a00)
        cmd/compile/internal/noder/reader.go:1333 +0xd2
cmd/compile/internal/noder.pkgReaderIndex.funcBody({0xc003accff0, 0x1f, 0xc0057ceb60, 0x0, 0x0}, 0xc005196a00)
        cmd/compile/internal/noder/reader.go:1321 +0x4f
cmd/compile/internal/noder.readBodies(0xc00021c000, 0x0)
        cmd/compile/internal/noder/unified.go:265 +0x17a
cmd/compile/internal/noder.unified({0x0?, {0x0?, 0x0?}}, {0xc0004c7a40?, 0xe242e0?, 0xc00023b928?})
        cmd/compile/internal/noder/unified.go:205 +0x1ab
cmd/compile/internal/noder.LoadPackage({0xc000003b70, 0x9, 0x9})
        cmd/compile/internal/noder/noder.go:77 +0x450
cmd/compile/internal/gc.Main(0xf3f420)
        cmd/compile/internal/gc/main.go:208 +0xcc5
main.main()
        cmd/compile/main.go:57 +0xf9
FAIL    <path>/invocation [build failed]

What did you expect to see?

$ go test -gcflags=all=-h
?       github.com/DevotedHealth/core/backend/services/providers/invocation     [no test files]

Comment From: gabyhelp

Related Issues

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: griesemer

Thanks for this report. - Presumably this is a new issue (with 1.25), and the code worked fine with 1.24. Is that correct? (in which case this would be a regression.) - A simple reproducer would really help here; otherwise it's difficult to make much progress on this one.

Comment From: mikeauclair

Thanks for this report.

Presumably this is a new issue (with 1.25), and the code worked fine with 1.24. Is that correct? (in which case this would be a regression.)

Yeah, this is new with 1.25 and this code is working fine with 1.24.4

A simple reproducer would really help here; otherwise it's difficult to make much progress on this one.

Yep, totally understandable - this one has been tough to reproduce, and I'm working both down from the complexity of our real code and up from an exemplar that I'm trying to build out to replicate (but not there yet on). I'll keep working on that, and totally understand that it'll be tough to pin this one down until I can nail that down.

Comment From: mikeauclair

Also, I'm thinking that the issue is caller-specific (or maybe specific to the types being passed by the callers), because I'm not getting the error on other packages that call the erroring function, so I'll keep poking at that idea as I try to replicate

Comment From: mikeauclair

Still working on replicating this, but I managed to solve the acute issue in our codebase - changing from

func IntersectEffectiveSpans[
  P1 EffectiveSpan,
  P2 EffectiveSpan,
](a []P1, b []P2) []P1 {

func IntersectEffectiveSpans[
  T any,
  P1 EffectiveSpanPtr[T],
  S any,
  P2 EffectiveSpanPtr[S],
](a []P1, b []P2) []P1 {

where EffectiveSpanPtr is

type EffectiveSpanPtr[T any] interface {
  EffectiveSpan
  *T
}

caused the error to go away.

Comment From: cuonglm

@mikeauclair Could you please try current gotip and see if the ICE still happen?

Comment From: mikeauclair

@mikeauclair Could you please try current gotip and see if the ICE still happen?

Unfortunately it still fails with the same trace

Comment From: shenwei356

I meet the same error when compiling for linux-arm64 with go1.25.1, and go1.24.7 works. And it costs > 300 GB RAM before occurring the error.

Golang cmd/compile: internal compiler error too many arguments to function call

Go version

Output of go env in your module/workspace:

What did you do?

What did you see happen?

What did you expect to see?

Output of `go env` in your module/workspace: