<p dir="auto">The go 1.6 compiler panics on this 2.25 Mbyte source file containing a slice with 13240 elements: <a href="https://drive.google.com/file/d/0B2AF520HhpuzdzZhSVpPZGZkTUU/view" rel="nofollow">https://drive.google.com/file/d/0B2AF520HhpuzdzZhSVpPZGZkTUU/view</a></p>
<p dir="auto">go1.6 linux/amd64<br>
GOARCH="amd64"<br>
GOOS="linux"</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="$ go build buildme.go
# command-line-arguments
panic: runtime error: makeslice: len out of range

goroutine 1 [running]:
panic(0x804f60, 0xc86085dd70)
        /usr/lib/google-golang/src/runtime/panic.go:483 +0x3ef
cmd/compile/internal/gc.newliveness(0xc82018b9e0, 0xc8200a0000, 0xc865c44000, 0x2d416, 0x2e400, 0xc866950000, 0xcee1, 0xf000, 0xc9cda4b11aac74db)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/plive.go:687 +0x161
cmd/compile/internal/gc.liveness(0xc82018b9e0, 0xc8200a0000, 0xc848dee900, 0xc848dee980)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/plive.go:1782 +0x2cf
cmd/compile/internal/gc.compile(0xc82018b9e0)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/pgen.go:541 +0xdf2
cmd/compile/internal/gc.funccompile(0xc82018b9e0)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/dcl.go:1450 +0x1c0
cmd/compile/internal/gc.Main()
        /usr/lib/google-golang/src/cmd/compile/internal/gc/lex.go:472 +0x2116
cmd/compile/internal/amd64.Main()
        /usr/lib/google-golang/src/cmd/compile/internal/amd64/galign.go:127 +0x58d
main.main()
        /usr/lib/google-golang/src/cmd/compile/main.go:32 +0x395"><pre class="notranslate"><code class="notranslate">$ go build buildme.go
# command-line-arguments
panic: runtime error: makeslice: len out of range

goroutine 1 [running]:
panic(0x804f60, 0xc86085dd70)
        /usr/lib/google-golang/src/runtime/panic.go:483 +0x3ef
cmd/compile/internal/gc.newliveness(0xc82018b9e0, 0xc8200a0000, 0xc865c44000, 0x2d416, 0x2e400, 0xc866950000, 0xcee1, 0xf000, 0xc9cda4b11aac74db)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/plive.go:687 +0x161
cmd/compile/internal/gc.liveness(0xc82018b9e0, 0xc8200a0000, 0xc848dee900, 0xc848dee980)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/plive.go:1782 +0x2cf
cmd/compile/internal/gc.compile(0xc82018b9e0)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/pgen.go:541 +0xdf2
cmd/compile/internal/gc.funccompile(0xc82018b9e0)
        /usr/lib/google-golang/src/cmd/compile/internal/gc/dcl.go:1450 +0x1c0
cmd/compile/internal/gc.Main()
        /usr/lib/google-golang/src/cmd/compile/internal/gc/lex.go:472 +0x2116
cmd/compile/internal/amd64.Main()
        /usr/lib/google-golang/src/cmd/compile/internal/amd64/galign.go:127 +0x58d
main.main()
        /usr/lib/google-golang/src/cmd/compile/main.go:32 +0x395
</code></pre></div>
<p dir="auto">We have a lot of packages in the std that uses specialized instructions<br>
that are not always present. Most of the times, the package will detect<br>
the required features by themselves. This is fine but will lead to code<br>
duplication. And as Bryan Chan mentioned on <a href="https://golang.org/cl/22201" rel="nofollow">https://golang.org/cl/22201</a>,<br>
even if the processor provides way to detect certain optional features,<br>
it's still better to use AT_HWCAP from Linux auxv because that also<br>
takes kernel support into account.</p>
<p dir="auto">Only the runtime can access auxv, so it makes sense for the runtime<br>
to query the processor capabilities and provide that to the packages.</p>
<p dir="auto">I propose that we add an internal package <code class="notranslate">internal/cpu</code> that exposes<br>
capability flags for the current processor so that each std packages<br>
could query it directly instead of having a runtime detection routine<br>
that duplicates the work.</p>
<p dir="auto">Another benefit is that, some processors, like ARM, doesn't provide<br>
a way to do runtime capability detection, so we have to rely on the<br>
kernel to provide this information. Different kernels provide different<br>
mechanisms for this (sysctl for BSD and auxv for linux), so providing<br>
a package that abstracts those OS-dependent feature away is also<br>
beneficial.</p>
<p dir="auto">We might promote the package to runtime/cpu if deemed fit, but that's<br>
out of the scope for this proposal.</p>
<p dir="auto">The package could be modeled after the Linux's AT_HWCAP bits,<br>
and it will be processor dependent.</p>