/cc @randall77 @cherrymui @dr2chase

I think this is a bug in your code.
You're casting (using unsafe) a pointer to an empty struct to a pointer to a large data structure. This is the fundamental error.

The old legacy backend and the SSA backend differ in how they respond to this bad code.
As part of the expression r.bars[0][0].Offset(), you're getting a nil check on p+65536. The old compiler did a nil check with a compare against 0, which passes. The new compiler does a test load off of that pointer, which fails because it points to the middle of nowhere (way outside the bounds of the original &struct{}{} you allocated).

Understood about the pointer pointing to nowhere. But I never actually dereference the pointer only
compute its offset from the base. Is this still a bug? Not sure I understand the semantics of unsafe
here. FYI the code involves a large memory mapped ASIC and Offset() is used to compute register/memory offsets within the ASIC. With go 1.6 everything works like a charm (as with -ssa=0).

Do I need to find another way to make Offset() work?

The semantics of unsafe are intentionally left vague. Hence the name. That gives us wiggle room to modify how things work under the covers, but it means you can get bitten by assumptions that don't hold from release to release. Sorry about that.

Can you use unsafe.Offsetof? As in

    addr := ASICbase + unsafe.Offsetof(foo_regs{}.bars)

No worries re: unsafe. Just coded up mmap based solution. Works like a charm with ssa.

unsafe.Offsets(r.bars[0][0][0]) is invalid syntax. Bummer. I did try that. Only works for struct.field

I'm cool with the mmap since /dev/zero mapped memory is copy on write via the linux kernel & we never write. so, mmap'ing e.g. 2^N bytes N = #address bits is no problem. Do, let me know if you can think of a better solution.

Hey, and thanks for all the great compiler work... been following along for a while on dev.ssa