go/test/fixedbugs/issue9604.go
Keith Randall daa64ddfe6 cmd/5g: make sure we normalize after unary ops on small types
We were failing ^uint16(0xffff) == 0, as we computed 0xffff0000 instead.

I could only trigger a failure for the above case, the other two tests
^uint16(0xfffe) == 1 and -uint16(0xffff) == 1 didn't seem to fail
previously.  Somehow they get MOVHUs inserted for other reasons (used
by CMP instead of TST?).  I fixed OMINUS anyway, better safe than
sorry.

Fixes #9604

Change-Id: I4c2d5bdc667742873ac029fdbe3db0cf12893c27
Reviewed-on: https://go-review.googlesource.com/2940
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
2015-01-15 23:50:01 +00:00

29 lines
631 B
Go

// run
// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package main
var x uint16 = 0xffff
var y uint16 = 0xfffe
var a uint16 = 0x7000
var b uint16 = 0x9000
func main() {
// Make sure we truncate to smaller-width types after evaluating expressions.
// This is a problem for arm where there is no 16-bit comparison op.
if ^x != 0 {
panic("^uint16(0xffff) != 0")
}
if ^y != 1 {
panic("^uint16(0xfffe) != 1")
}
if -x != 1 {
panic("-uint16(0xffff) != 1")
}
if a+b != 0 {
panic("0x7000+0x9000 != 0")
}
}