I don't think this is a release blocker.

I disagree mildly. Some time recently the tests were weakened, and they should be restored to the strength they had in prior releases.

I spoke to Rob earlier. He was remembering the fact that there used to be a golden x.out next to each x.s in the testdata directory; the x.out contained the output from 'asm -S x.s'. These proved too annoying to keep in sync, so in https://golang.org/cl/18823 I changed the test to require instead that, by default, each line found in the assembly is reprinted with exactly the same syntax. That is, the result of the parse is tested and must reprint as the original input exactly. When there are multiple equivalent forms, so that the result of parse+reprint may vary, a comment in the testdata file specifies the desired printed form. For example:

arm.s:167:	STREX.S	(R2), R3 // STREX.S (R2), R3, R3

The middle operand is omitted in the input but defaults to the final one, so that's what is printed and what is expected by the test (due to the comment).

In a followup CL, https://golang.org/cl/18844 and https://golang.org/cl/18850, I added support for an optional comment giving the hex instruction encoding too, formerly not tested at all:

amd64enc.s:10560:	XORB $7, AL                             // 3407
amd64enc.s:10561:	XORW $61731, AX                         // 663523f1
amd64enc.s:10562:	XORL $4045620583, AX                    // 35674523f1
amd64enc.s:10563:	XORQ $-249346713, AX                    // 4835674523f1
amd64enc.s:10564:	XORW $61731, (BX)                       // 66813323f1
amd64enc.s:10565:	XORW $61731, (R11)                      // 6641813323f1

The two can be combined if needed, as in // printed syntax // hexbytes. That said, there appear to be no such combinations in the testdata directory that are correct. (There are some in s390x but they look wrong. I will file a separate issue.)

It is true the tests are too weak: there should be hex instruction encoding tests for all architectures, not just amd64 and s390x. But this work is unplanned.

On a related note, is there a test that verifies the correct pc-line info for assembly output? If not, that would also be nice to have.

@griesemer We have some indirect tests. For example test/nilptr3.go tests (among other things) that line numbers are right, at least up to the nil pointer removal compiler phase.

After CL 45996 is merged, I thought I have made a relative full encoding test for ARM32. Some corner cases are not tested, since they use the constant pool, which is hard to calculate their offset by hand.