Maybe it is not a code bug. If

var struct3_1 struct{a, b, c int}

is changed to

var struct3_1 = struct{a, b, c int}{3, 2, 1}

, then the result is constantly about

Benchmark_CopyStruct_3_fields-4   	  118312	      9430 ns/op
Benchmark_xxx-4                   	1000000000	         0.3946 ns/op
Benchmark_yyy-4                   	1000000000	         0.4007 ns/op

So it looks like a cpu cache related problem.

I don't know whether or not some improvements should be applied to the testing package (I hope it could handle the problem). If not, feel free to close this issue.

Its not uncommon to see benchmarks improve or regress in performance when unrelated code is added or removed. ANy code change e.g. compiler or linker or user code can effect this.

This can be due to caching, branch alignment or if the loop fits into the internal loop buffer of the cpu. There are all kinds of constraints e.g. how many branches are within a specific cacheline window. Maybe there is something that be done to harden benchmarks better (even higher alignment?).

To figure out what happens in this case a hardware profile could be made and seeing if any cpu internal stats like branch predictions or cache misses change majorly.

Another might-similar benchmark: https://github.com/go101/go101/wiki/Remove-benchmark-surprises-(2) (not valid)

As @martisch points out, benchmarks with tight loops like this can end up being very sensitive to instruction caching and alignment. I'm not sure it's worth dwelling on this too much. Like @martisch says though, if you're interested, you can probably figure out exactly what's wrong with hardware performance counters. The easiest way to do this on Linux is with Linux's perf tool.

Given that everything's fine on tip and the nature of these kinds of benchmarks, I'm going to close this issue unless there's a more clear indication that something went wrong with the code the compiler produced.