It looks like go 1.12 hits the same internal compiler error as go 1.13, but with go version devel +3eab754cd0 Thu Feb 13 19:49:45 2020 +0000 darwin/amd64, the program compiles and runs successfully.

Thank you for the report @amarjeetanandsingh and welcome to the Go project! Thank you @mark-rushakoff for the initial investigation.

Indeed, as @mark-rushakoff confirmed, the problem starts with Go1.12 and from my investigation, it seems to have been caused by f062f48 aka CL 165858 (/cc @randall77 @dr2chase) in the short circuiting logic. It then seems to have been fixed by @josharian's 52ae04f aka CL 178197 for Go1.14 aka Go tip so it is already fixed. @amarjeetanandsingh, in the meantime please use Go1.14beta1
https://golang.org/dl/#unstable

go get golang.org/dl/go1.14rc1

Perhaps we might need some backports?

I don't know for sure, but it seems likely to me that CL 178197 might have fixed this particular incident, but that there may yet be similar cases lurking. We should look to see whether there's an independent fix, not least because we shouldn't backport CL 178197.

I'm out of time for the moment, but here's a partially minimized reproduction:

package main

func main() {
	var n, a, b int64
	for i := int64(2); i < 10; i++ {
		for j := i; j < 10; j++ {
			if ((n % (i * j)) == 0) && (j > 1 && (n/(i*j)) == 1) {
				a, b = i, 0
				a = n / (i * j)
			}
		}
	}

	if a != b && a != n {
		println("YES")
	}
}

From my first look, it appears that the problem is with CSEing a Select0. When CSE moves a tuple generator to a new block it is supposed to move all selectors along with it. It did so, but somehow there was still a phi value using the old selector as an arg. The old selector thus doesn't get deadcoded, causing scheduling to fail.

That's as far as I've gotten, and as far as I'm likely to get in the very near term.

cc @cherrymui @randall77

Change https://golang.org/cl/233941 mentions this issue: cmd/compile: add test for issue 37246