1
0
mirror of https://github.com/golang/go synced 2024-11-17 14:54:44 -07:00
Commit Graph

2 Commits

Author SHA1 Message Date
Ian Lance Taylor
6e5ccce87f misc/cgo/test: fix go vet warnings
Fixes these warnings from go vet:
buildid_linux.go:25: no formatting directive in Fatalf call
callback.go:180: arg pc[i] for printf verb %p of wrong type: uintptr
env.go:34: possible misuse of unsafe.Pointer
issue7665.go:22: possible misuse of unsafe.Pointer

Change-Id: I83811b9c10c617139713a626b4a34ab05564d4fe
Reviewed-on: https://go-review.googlesource.com/15802
Reviewed-by: David Crawshaw <crawshaw@golang.org>
2015-10-13 17:53:20 +00:00
Russ Cox
e5c105033a cmd/gc: disable link-time copying of un-Go-initialized globals
If you write:

        var x = 3

then the compiler arranges for x to be initialized in the linker
with an actual 3 from the data segment, rather than putting
x in the bss and emitting init-time "x = 3" assignment code.

If you write:

        var y = x
        var x = 3

then the compiler is clever and treats this the same as if
the code said 'y = 3': they both end up in the data segment
with no init-time assignments.

If you write

        var y = x
        var x int

then the compiler was treating this the same as if the
code said 'x = 0', making both x and y zero and avoiding
any init-time assignment.

This copying optimization to avoid init-time assignment of y
is incorrect if 'var x int' doesn't mean 'x = 0' but instead means
'x is initialized in C or assembly code'. The program ends up
with 'y = 0' instead of 'y = the value specified for x in that other code'.

Disable the propagation if there is no initializer for x.

This comes up in some uses of cgo, because cgo generates
Go globals that are initialized in accompanying C files.

Fixes #7665.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/93200044
2014-05-09 16:03:44 -04:00