cmd/compile: 1-sized array's pointer typed element set to nil, after received from channel and print in a loop

[helinwang]

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

go version go1.9.2 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/helin/env/gopath"
GORACE=""
GOROOT="/home/helin/env/go"
GOTOOLDIR="/home/helin/env/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build809756853=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

package main

import (
	"fmt"
)

const arraySize = 1

// comment above and uncomment below, will work as expected.
// const arraySize = 2

type foo struct {
	bar [arraySize]*int
}

func main() {
	ch := make(chan foo, 2)
	var a int
	var b [arraySize]*int
	b[0] = &a
	ch <- foo{bar: b}
	close(ch)

	for v := range ch {
		// uncomment below, will work as expected.
		// fmt.Println(v.bar[0])
		for i := 0; i < 1; i++ {
			fmt.Println(v.bar[0], b[0])
		}
	}
}

What did you expect to see?

// Output:
// 0x10410020 0x10410020

What did you see instead?

// Output:
// <nil> 0x10410020

Playground link:

https://play.golang.org/p/Qd8fDy-ls3

[as]

I dont understand the issue. Why are you closing the channel and then attempting to recieve on that closed channel?

[helinwang]

@as receiving from the closed channel is safe, it will read all the remaining values.
In this case I just don't want the for ... range to block forever.

[robpike]

Given that there are no explicit goroutines and that printing a value changes the behavior, I think this is a compiler bug or perhaps a runtime bug.

[bradfitz]

/cc @mdempsky @dr2chase @aclements

[mdempsky]

I can repro this with Go 1.9, but it seems to work as expected at master.

[dr2chase]

Array-of-size-1 is a special case in the SSA code, too.

[randall77]

This is the buggy rule:

(ArraySelect [0] (Load ptr mem)) -> (Load ptr mem)

It allows the load to move blocks. It needs an @v.Block modifier, I think.

[randall77]

The bad rule was removed at tip during https://go-review.googlesource.com/c/go/+/71731 . Seems coincidental that it was removed, but that's why tip is ok.

[bradfitz]

Add test + candidate for backport?

[gopherbot]

Change https://golang.org/cl/77331 mentions this issue: [release-branch.go1.9] cmd/compile: fix decomposition of 1-element arrays

[gopherbot]

Change https://golang.org/cl/77332 mentions this issue: cmd/compile: add test for array decomposition

[dr2chase]

The removal was indeed coincidental; since I was freshening someone else's old patch, I just kept the change. I'm trying to figure out if we need it, given the other make and select rules.

[andybons]

CL 77331 OK for Go 1.9.3.

[gopherbot]

Change https://golang.org/cl/88320 mentions this issue: [release-branch.go1.9] cmd/compile: add test for array decomposition

[andybons]

go1.9.3 has been packaged and includes:

• CL 77331 [release-branch.go1.9] cmd/compile: fix decomposition of 1-element arrays

The release is posted at golang.org/dl.

— golang.org/x/build/cmd/releasebot, Jan 22 21:02:55 UTC