Sorry about that, looking into it. (FWIW, I did actually test go build crypto/x509 after patching in that CL, but I didn't think to testing running the resulting binary.)

Smaller repro:

package main

import (
	"crypto/elliptic"
	"math/big"
)

func main() {
	elliptic.P224()

	var z big.Int
	elliptic.P256().IsOnCurve(&z, &z)
}

Smaller repro:

package main

import (
	"crypto/elliptic"
	"math/big"
)

func main() {
	elliptic.P224()

	var z big.Int
	elliptic.P256().IsOnCurve(&z, &z)
}

Hmm, I can't reproduce the bug with this program, using GOEXPERIMENT=unified go run main.go

@cuonglm Did you patch in CLs 315273 and 360015?

@cuonglm Did you patch in CLs 315273 and 360015?

Ops, I did checkout CL 360015 using git fetch https://go.googlesource.com/go refs/changes/15/360015/6 && git checkout -b change-360015 FETCH_HEAD, but run go build instead of go run. That's why the bug is not triggered.

The issue seems sensitive to the use of the -p flag, which makes it difficult to repro in the $GOROOT/test framework.

This is the simplest repro I've come up with so far:

$ cat elliptic.go
package elliptic

type Curve interface{ IsOnCurve() }

type nistCurve[Point any] struct{}

func (curve *nistCurve[Point]) IsOnCurve() {}

var RawP224 = &nistCurve[int]{}
var P224 = Curve(RawP224)

$ cat main.go
package main

import "elliptic"

func main() {
	_ = elliptic.Curve(elliptic.RawP224)
	elliptic.P224.IsOnCurve()
}

$ mkdir pkg
$ GOEXPERIMENT=unified go tool compile -I pkg -p elliptic -o pkg/elliptic.a elliptic.go
$ GOEXPERIMENT=unified go tool compile -I pkg -p main -o pkg/main.a main.go
$ GOEXPERIMENT=unified go tool link -L pkg pkg/main.a
$ ./a.out
fatal error: unreachable method called. linker bug?
[...]

@cherrymui suggests looking at cmd/link -dumpdep output. Here's a diff between bad and good output:

$ diff -u bad good
--- bad	2022-03-08 12:09:51.022029489 -0800
+++ good	2022-03-08 12:09:42.933858359 -0800
@@ -4709,12 +4709,12 @@
 example/elliptic.P224 -> example/elliptic..stmp_0
 go.itab.*example/elliptic.nistCurve[int],example/elliptic.Curve -> type.example/elliptic.Curve
 go.itab.*example/elliptic.nistCurve[int],example/elliptic.Curve -> type.*example/elliptic.nistCurve[int] <UsedInIface>
-type.*example/elliptic.nistCurve[int] <UsedInIface> -> type..namedata.*elliptic.nistCurve[int]-
-type.*example/elliptic.nistCurve[int] <UsedInIface> -> type.example/elliptic.nistCurve[int] <UsedInIface>
-type.*example/elliptic.nistCurve[int] <UsedInIface> -> type..importpath.example/elliptic.
-type.*example/elliptic.nistCurve[int] <UsedInIface> -> type..namedata.IsOnCurve.
 type.example/elliptic.Curve -> type..namedata.*elliptic.Curve.
 type.example/elliptic.Curve -> type.*example/elliptic.Curve
+type.example/elliptic.Curve -> type..importpath.example/elliptic.
+type.example/elliptic.Curve -> type..namedata.IsOnCurve.
+type.*example/elliptic.nistCurve[int] <UsedInIface> -> type..namedata.*elliptic.nistCurve[int]-
+type.*example/elliptic.nistCurve[int] <UsedInIface> -> type.example/elliptic.nistCurve[int] <UsedInIface>
 runtime.getpid -> runtime.getpid.args_stackmap
 runtime.getpid -> runtime.getpid.arginfo0
 runtime.tgkill -> runtime.tgkill.args_stackmap

"bad" here means the test case as presented above. "good" is with the blank assignment in main.main commented out (which doesn't trigger the runtime panic).

@cherrymui Are you able to help make sense of the above diff?

For the diff above, it looks like the RHS of the arrows are the same set of symbols? So it looks like the set of symbols marked live are the same.

It looks like the failing call is example/elliptic.(*nistCurve[int]).IsOnCurve ? It looks like the itab go.itab.*example/elliptic.nistCurve[int],example/elliptic.Curve doesn't point to that method, instead, it points to unreachableMethod. Maybe we build the itab incorrectly? But I don't see why.

It looks to me that under unified IR mode, when both the main package and the elliptic package defines the function example/elliptic.(*nistCurve[int]).IsOnCurve, and it is NOT marked as dupOK. When the blank assignment is present, it triggers the itab generation, so both packages contains the itab, and it is dupOK. At link time, they are two symbols of the method, and one symbol of the itab (as the linker dedup them). The itab (happens to) point to the method that is not marked. Another copy of the method symbol is marked, but isn't referenced by the itab.

When unified IR mode is not used, they are also defined in both packages but marked as dupOK so the linker can dedup them.

I think the method symbol should be marked at dupOK in unified mode as well.

@cherrymui Thanks! Marking the instantiated functions as DUPOK seems to fix it.

Change https://go.dev/cl/390956 mentions this issue: cmd/compile: mark instantiated generic functions as DUPOK