Comment 1:

Seems to be regression in 1.4. 1.3 works fine.

Comment 2 by szamcsi@google.com:

Sorry, I should have added that it was failing in 1.4rc1 and it was working with 1.3.3

Comment 3:

Most likely write barriers altered evaluation order in race mode; and now we call
racewrite(&a[i]) after assigning to a.
I somewhat afraid of touching that code before release.

The racewalk gets this as its input

BLOCK
. CALLFUNC writebarrierstring
. a[len(a)-1] = ""
. a = a[:len(a)-1]

Because the first op in the block is a CALLFUNC, the racewalk code assumes that it's a multi-valued return and puts the instrumentation after the block in order to not clobber the stack.

What if we explicitly mark OBLOCKs that copy out return values of a call with a special flag. And then specially handle only these blocks in racewalk rather than try to guess OBLOCK type by looking at the first node.
The offending blocks seem to be created only by ascompatte during walk. Maybe there are few other functions, but they must be findable by calls to arch.nodarg.

How about using rlist on the CALL* nodes? It's not used and it would remove the semantic conflation that the BLOCK node has right now.

This sounds equally good to me. The root cause of the issue is that OBLOCK guessing in racewalk. And your proposal also removes it.

See issue #8102. The handling of OBLOCK is just wrong in general. This is the second time. This needs to be fixed correctly. Again, see my comments on issue #8102.

Rewriting racewalk as SSA pass should fix this.

That's not a fix for Go 1.5. It needs to be fixed for Go 1.5.

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