This appears to be a regression from 1.7. The problem doesn't appear with https://play.golang.org/p/iptkp861qM (simple repro case) in the playground. But with 1.8 we get:

package p

var _ = [][]int{
	/*       a, b, c, d, e */
	/* a */
	{0, 0, 0, 0, 0},
	/* b */ {0, 5, 4, 4, 4},
	/* c */ {0, 4, 5, 4, 4},
	/* d */ {0, 4, 4, 5, 4},
	/* e */ {0, 4, 4, 4, 5},
}

Likely related to https://go-review.googlesource.com/#/c/33016/ (need to confirm).

It's probably too late to get this fixed for 1.8 unless there's a trivial mistake. Unrolling the previous change (if it's the culprit) would expose two other issues that it fixed.

@griesemer, you're confident this is sufficiently rare to push off to Go 1.9?

@bradfitz I haven't seen this before and none of the code we regularly gofmt appears to have the problem. That is all I can say at the moment. I will look into the problem today - perhaps there's a safe and easy fix.

Confirming that https://go-review.googlesource.com/#/c/33016/ (commit a0d2e96) is indeed the culprit. The bug is not present before (commit 8cd5561).

@griesemer, you're confident this is sufficiently rare to push off to Go 1.9?

As a data point, this breaks my CI as I perform automated gomft checks on that repo. The failure masks other real failures.

@kortschak Understood. I've started working on this.

@griesemer Thank you

@kortschak Not a completely satisfactory "solution", but a work-around: The following source

var _ = [][]int{ /* a, b, c, d, e */
	/*    a */ {0, 0, 0, 0, 0},
	/*    b */ {0, 5, 4, 4, 4},
	/*    c */ {0, 4, 5, 4, 4},
	/*    d */ {0, 4, 4, 5, 4},
	/*    e */ {0, 4, 4, 4, 5},
}

(first comment on same line as /*) will be preserved. Still trying to see if there's a simple (1.8-acceptable solution).

@kortschak Can you verify that https://go-review.googlesource.com/35811 fixes the problem for you? Thanks.

CL https://golang.org/cl/35811 mentions this issue.

@griesemer Yes, that fixes the problem. Thanks.