mirror of
https://github.com/golang/go
synced 2024-11-18 14:54:40 -07:00
e5c105033a
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
26 lines
531 B
Go
26 lines
531 B
Go
// Copyright 2013 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 cgotest
|
|
|
|
import (
|
|
"testing"
|
|
"unsafe"
|
|
)
|
|
|
|
// extern void f7665(void);
|
|
import "C"
|
|
|
|
//export f7665
|
|
func f7665() {}
|
|
|
|
var bad7665 unsafe.Pointer = C.f7665
|
|
var good7665 uintptr = uintptr(C.f7665)
|
|
|
|
func test7665(t *testing.T) {
|
|
if bad7665 == nil || bad7665 != unsafe.Pointer(good7665) {
|
|
t.Errorf("ptrs = %p, %#x, want same non-nil pointer", bad7665, good7665)
|
|
}
|
|
}
|