

Unexpected string to byte casting behavior in Go 1.5 - spenczar5
https://github.com/golang/go/issues/12226

======
schmichael
Ugly bug, but I'm very impressed to see a first time contributor able to fix a
compiler bug in 6 hours! Seems to lend some credence to the assertion that
rewriting everything in Go would make it easier to maintain.

~~~
Maken
It looks to me more like an accomplishment of git-bisect, which let the
contributor isolate the bug to a few lines of code in a single commit.

~~~
4ad
Git-bisect helped a lot, yes, but you can see that the commit in question was
huge, and complex, not "a few lines of code".

------
sleaze
[http://play.golang.org/p/hR7iVDC-Vu](http://play.golang.org/p/hR7iVDC-Vu)

Yes, that is a very nasty bug indeed. I think I'll be sticking with 1.4.2 for
quite some time..

Does anyone else feel like 1.5 was released prematurely before it was honestly
ready to go out the door? At this point Go is more than 5 years old; these
kinds of amateur issues seem unacceptable.

Can anyone comment on what it's like when new versions of Java have been
released throughout the past 20 years? I am curious if regressions and
stability issues are common in that ecosystem.

My experience with Scala has been that things are quite bulletproof by the
time they actually get released for wide-consumption.

~~~
skybrian
It's certainly surprising, particularly since Go has its own extensive test
suites and quite a few people have used the prereleases (including being
deployed within Google and running all those tests as well).

It suggests the error is somehow not that commonly triggered in a visible way,
or lots of tests would have broken. Or alternately it was a last-minute
change.

~~~
pcwalton
Looks like a register allocation bug, which is the kind of thing that can only
trigger in specific circumstances.

It looks like the Go compilers are especially vulnerable to this because
individual AST nodes have to allocate registers, which would not be a problem
if they used a more traditional IR.

~~~
enneff
There's work underway to implement the SSA form for amd64 in 1.6.

------
detaro
I wonder if it makes sense to "black-flag" certain instructions in the output,
like here the comparison of a value with itself, as instructions that should
never be generated and throw an error if that happens?

