go/pointer: fix panic due to bogus constraint from value,ok receive operation.

See regression test for explanation.

I audited the code for similar issues and found none.

Many thanks to Daniel Morsing for providing a small
reproducible test case, a rarity for PTA bugs!

Fixes golang/go#9002

LGTM=crawshaw
R=crawshaw
CC=daniel.morsing, golang-codereviews
https://golang.org/cl/163350043

go/pointer/gen.go

@@ -936,7 +936,8 @@ func (a *analysis) genInstr(cgn *cgnode, instr ssa.Instruction) {
 		case token.ARROW: // <-x
 			// We can ignore instr.CommaOk because the node we're
 			// altering is always at zero offset relative to instr
-			a.genLoad(cgn, a.valueNode(instr), instr.X, 0, a.sizeof(instr.Type()))
+			tElem := instr.X.Type().Underlying().(*types.Chan).Elem()
+			a.genLoad(cgn, a.valueNode(instr), instr.X, 0, a.sizeof(tElem))
 
 		case token.MUL: // *x
 			a.genLoad(cgn, a.valueNode(instr), instr.X, 0, a.sizeof(instr.Type()))

go/pointer/pointer_test.go

@@ -46,6 +46,7 @@ var inputs = []string{
 	"testdata/funcreflect.go",
 	"testdata/hello.go", // NB: causes spurious failure of HVN cross-check
 	"testdata/interfaces.go",
+	"testdata/issue9002.go",
 	"testdata/mapreflect.go",
 	"testdata/maps.go",
 	"testdata/panic.go",

go/pointer/testdata/issue9002.go

@@ -0,0 +1,17 @@
+package main
+
+func main() {
+	// Regression test for golang issue 9002.
+	//
+	// The two-result "value,ok" receive operation generated a
+	// too-wide constraint loading (value int, ok bool), not bool,
+	// from the channel.
+	//
+	// This bug manifested itself in an out-of-bounds array access
+	// when the makechan object was the highest-numbered node, as in
+	// this program.
+	//
+	// In more realistic programs it silently resulted in bogus
+	// constraints.
+	_, _ = <-make(chan int)
+}