go/test/fixedbugs/issue20029.go
Keith Randall e396667ba3 [release-branch.go1.8] cmd/compile: zero ambiguously live variables at VARKILLs
This is a redo of CL 41076 backported to the 1.8 release branch.
There were major conflicts, so I had to basically rewrite it again
from scratch.  The way Progs are allocated changed.  Liveness analysis
and Prog generation got reordered.  Liveness analysis changed from
running on gc.BasicBlock to ssa.Block.  All that makes the logic quite
a bit different.

Please review carefully.

From CL 41076:

At VARKILLs, zero a variable if it is ambiguously live.
After the VARKILL anything this variable references
might be collected. If it were to become live again later,
the GC will see references to already-collected objects.

We don't know a variable is ambiguously live until very
late in compilation (after lowering, register allocation, ...),
so it is hard to generate the code in an arch-independent way.
We also have to be careful not to clobber any registers.
Fortunately, this almost never happens so performance is ~irrelevant.

There are only 2 instances where this triggers in the stdlib.

Fixes #20029

Change-Id: Ibb757eec58ee07f40df5e561b19d315684dc4bda
Reviewed-on: https://go-review.googlesource.com/43998
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2017-05-24 15:23:47 +00:00

33 lines
583 B
Go

// run
// Copyright 2017 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.
// Issue 20029: make sure we zero at VARKILLs of
// ambiguously live variables.
// The ambiguously live variable here is the hiter
// for the inner range loop.
package main
import "runtime"
func f(m map[int]int) {
outer:
for i := 0; i < 10; i++ {
for k := range m {
if k == 5 {
continue outer
}
}
runtime.GC()
break
}
runtime.GC()
}
func main() {
m := map[int]int{1: 2, 2: 3, 3: 4}
f(m)
}