Compilers may restrict the permissible precision of constants. Per the spec http://tip.golang.org/ref/spec#Constants:

"Implementation restriction: Although numeric constants have arbitrary precision in the language, a compiler may implement them using an internal representation with limited precision. ..."

That said, right shifts should never be a problem: for x >> s where x is not constant, any value s >= 64 can be replaced with 64 (trivial fix); and (optimization) the result of x >> s can be replaced with 0 if we know that x is untyped and s >= 64. For x >> s where both x and s are constant, we can do the analogous once the shift count is over x's bit length.

FWIW, quoting @rsc from #9120 (comment):

I have always assumed [the restriction on channel element size] was something like the "stupid shift"
errors, where if you have that big an element size you are probably doing something
wrong. The fact that it took this long for someone to report a problem suggests he was
right.

And this report came from a fuzzer, not a real program (I presume). Given all of that, I'm switching the milestone to Unplanned. Feel free to switch back if you feel strongly.

I assigned the bug to myself and gave it a Go1.5Maybe because I think it's a trivial fix. Unplanned is fine, too, but I don't think it matters.

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

The fix for this bug is trivial: it's deleting some unnecessary code. The math/big package can handle this case just fine. See my comments on https://golang.org/cl/13777 .