cmd/compile: don't use PPARAMOUT names for temps
The location of VARDEFs is incorrect for PPARAMOUT variables
which are also used as temporary locations. We put in VARDEFs
when setting the variable at return time, but when the location
is also used as a temporary the lifetime values are wrong.
Fix copyelim to update the names map properly. This is a
real name bug fix which, as a result, allows me to
write a reasonable test to trigger the PPARAMOUT bug.
This is kind of a band-aid fix for #14591. A more pricipled
fix (which allows values to be stored in the return variable
earlier than the return point) will be harder.
Fixes #14591
Change-Id: I7df8ae103a982d1f218ed704c080d7b83cdcfdd9
Reviewed-on: https://go-review.googlesource.com/20457
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
diff --git a/test/fixedbugs/issue14591.go b/test/fixedbugs/issue14591.go
new file mode 100644
index 0000000..e4fa80a
--- /dev/null
+++ b/test/fixedbugs/issue14591.go
@@ -0,0 +1,38 @@
+// run
+
+// Copyright 2016 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.
+
+// Test to make sure we don't think values are dead
+// when they are assigned to a PPARAMOUT slot before
+// the last GC safepoint.
+
+package main
+
+import (
+ "fmt"
+ "runtime"
+)
+
+// When a T is deallocated, T[1] is certain to
+// get clobbered (the runtime writes 0xdeaddeaddeaddead there).
+type T [4]int
+
+func f() (r, s *T) {
+ r = &T{0x30, 0x31, 0x32, 0x33}
+ runtime.GC()
+ s = &T{0x40, 0x41, 0x42, 0x43}
+ runtime.GC()
+ return
+}
+
+func main() {
+ r, s := f()
+ if r[1] != 0x31 {
+ fmt.Printf("bad r[1], want 0x31 got %x\n", r[1])
+ }
+ if s[1] != 0x41 {
+ fmt.Printf("bad s[1], want 0x41 got %x\n", s[1])
+ }
+}
