An update - the panic isn't specific to go get. I downloaded the code manually and changed a couple imports to get the demo code to be valid (references to nanogui were changed to gui4go). When trying to build I get the same panic:

$ go build github.com/shibukawa/gui4go/sample1/sample.go
# github.com/shibukawa/gui4go
panic: bad store type

goroutine 1 [running]:
cmd/compile/internal/amd64.storeByType(0xd597a0, 0xd738e0, 0xa6a920)
        c:/go/src/cmd/compile/internal/amd64/ssa.go:76 +0xcf
cmd/compile/internal/amd64.ssaGenValue(0xc044226d00, 0xc043474f20)
        c:/go/src/cmd/compile/internal/amd64/ssa.go:699 +0x5aeb
cmd/compile/internal/gc.genssa(0xc0441c3d40, 0xc0420d4238, 0xc0442315e0, 0xc044231650)
        c:/go/src/cmd/compile/internal/gc/ssa.go:4422 +0x265
cmd/compile/internal/gc.compile(0xc042de9320)
        c:/go/src/cmd/compile/internal/gc/pgen.go:443 +0x70e
cmd/compile/internal/gc.funccompile(0xc042de9320)
        c:/go/src/cmd/compile/internal/gc/dcl.go:1292 +0xe3
cmd/compile/internal/gc.Main()
        c:/go/src/cmd/compile/internal/gc/main.go:464 +0x1f0f
main.main()
        c:/go/src/cmd/compile/main.go:50 +0x105

The first post in this thread is likely irrelevant since the issue isn't with go get, but I'll leave it as is rather than confusing things with edits.

Reproduces with tip. Also reproduces with 1.7, so not a regression, so not marking for 1.8.1.

Looks like this happens when the register allocator decides to spill an int128 value, which weren't designed to be spilled. Preventing CSE of int128s appears to fix the problem (near the top of cse.go):

			if v.Type.IsMemory() || v.Type == TypeInt128 {
				continue // memory values and int128s can never cse
			}

Haven't made a test case. Won't look at this again for a day or three, so jotting down what I know to avoid duplicate effort. (If anyone else wants to take this over, feel free.)

cc @randall77

Come to think of it, movoconst should never be spilled, since it is (or ought to be) rematerializable. This might be a regalloc problem. I'm AFK, but cc @cherrymui.

We do have some MOVOload instructions. My hunch is that those are to blame. We might need to back out copying using MOVOload. Or teach the amd64 backend how to spill them.

In this particular case, it is a MOVOconst, so something is not right in regalloc. (Note that both MOVOload and MOVOstore have memory type, and thus will never be CSE'd.) We should indeed probably also teach amd64 how to spill them, which will also require teaching it how to allocate stack space for them correctly.

Getting a minimized test case for this is a major pain.

Marking as HelpWanted for phase one, namely extracting a moderate-sized, standalone reproducer.

https://play.golang.org/p/YuA5LJzM5c is the closest I got to a minimal test case.

A bit more minimal, even: https://play.golang.org/p/7J9qNNXlUY

Thanks, @dominikh, that's fabulous.

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