Simpler example that reproduces the problem:

package main

func fn() (arr [1e9]bool) {
    for range arr {
    }
    return
}

func main() {
    fn()
}

Without the loop it's fine.

The following example:

package main

func fn() (arr [1e10]bool) {
    for range arr {
    }
    return
}

func main() {
    fn()
}

fails to compile with "stack frame too large (>2GB)" error. It looks like compiler and runtime disagree about the maximum stack frame size.

incorrect example deleted

cc @randall77 as fun tests to add to the ssa branch too

Sorry, ignore my last comment. I didn't test it properly ;)

Did you know that for range arr makes a copy of the array
(onto stack)?

Per the Go ABI, the return value will be passed on stack,
even if we have fixed the for range memory blowup, the
program will still overflow the stack because fn/sieve needs
almost 1GB on stack for their return values.

@minux, for range arr (and for i := range arr) doesn't make a copy of the array onto stack. But for _, v := range arr does.

Simpler repro:

package main

//go:noinline
func fn() (arr [1e9]bool) {
    return
}

func main() {
    fn()
}

Discussion about the for loop is a red herring. It just prevented inlining.

The issue seems to be that when we're warning about stack frames that are >1GB, we're failing to include the space reserved for calling other functions. In the example above, main needs to allocate 1GB of stack space for fn's return values, but we're not including that space in the test.

We’ve fixed a bunch of similar bugs recently. I’m AFK for a while but I’d wager this is now fixed, if someone wants to double-check.

They still fail like they did in 1.11.4.
I tested with
go version devel +5073bf3886 Thu Jan 3 22:51:08 2019 +0000 linux/amd64