This was a bastard to diagnose. To summarise:

1. Under windows the floating-point registers XMM6 to XMM15 are categorised as "non-volatile" across function calls (https://msdn.microsoft.com/en-us/library/9z1stfyw.aspx)
2. memmove_amd64.s clobbers these registers in some cases without restoring their original values (specifically the 65 through 256 byte cases)

For pure go code this is perhaps a non-issue. In my case I have a long-lived C thread (spawned by portaudio) repeatedly calling back into go. After two days debugging it has become apparent that gcc is using XMM6 for a certain floating-point calculation, and is expecting the register to remain unmodified after executing the callback (which seems to be within its rights according to the MSDN link).

However my go code calls the builtin copy. At some stage it tries to copy 66 bytes, causing memmove to clobber XMM6. Once the callback returns the C code keeps referring to XMM6 in further floating point operations, producing garbage.

This particular set of circumstances has left me unable to create a simple reproducer (my workspace is currently full of debugging hacks at every level), but I am entirely satisfied with this explanation. I've observed XMM6 being clobbered after the callback via gcc, and any of the following changes cause the symptom to disappear:

1. Restructure the code so that every call to copy is of the same size (2,304 bytes)
2. Avoid the 66-byte copy invocation
3. Comment out the JBE move_65through128 and JBE move_129through256 lines in memmove_amd64.s
4. Add a conditional printf to the C function (even if the condition is never met at runtime - presumably gcc decides storing the value in a register is no longer worth it?)

gdb's register info before the callback:

xmm6           {..., v2_int64 = {0x40caafb7a95d3d0e, 0x0}, ...}
xmm7           {..., v2_int64 = {0x3fe0000000000000, 0x0}, ...}

ie. float64(xmm6) = 13663.434856085598 which is inline with previous timings reported by my program:

Adc Time:                0, Current:  13663.414530729, Dac:  13663.498625786
Adc Time:                0, Current:  13663.424691487, Dac:  13663.511714507

After the callback does its 66-byte memmove, gdb says:

xmm6           {..., v2_int64 = {0x7bf99add7ce993ee, 0x79bbab5b7ae9a2b2}, ...}
xmm7           {..., v2_int64 = {0x7701bed9786db4c5, 0x73d0d4a57578c981}, ...}

After accounting for endianness this exactly matches the last 32 bytes in the buffer I passed to copy. So there is little doubt left as to what is happening - the only remaining question is whether gcc is in error for expecting the register to remain unchanged, or go is in error for not restoring the register's value. As I said earlier it looks like go's fault, but I am not an expert in this area and a single MSDN article is perhaps not entirely authoritative.

I'm going to take a break from this problem now and enjoy the rest of my weekend, but happy to provide further information/prepare a minimal-as-possible reproducer as desired.

For completeness, my environment details:

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

go version go1.3.3 windows/amd64
go version go1.6 windows/amd64

(I've mainly been using 1.3.3 but have confirmed the problem still exists in 1.6)

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

$ go env
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:/code/go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

$ gcc --version
gcc.exe (rev5, Built by MinGW-W64 project) 4.8.1