mirror of
https://github.com/golang/go
synced 2025-04-12 00:29:42 +00:00
2b8026f025
For aggregate-typed arguments passed to a call, expandCalls decomposed them into parts in the same block where the value was created. This is not necessarily the call block, and in the case where stores are involved, can change the memory leaving that block, and getting that right is problematic. Instead, do all the expanding in the same block as the call, which avoids the problems of (1) not being able to reorder loads/stores across a block boundary to conform to memory order and (2) (incorrectly, not) exposing the new memory to consumers in other blocks. Putting it all in the same block as the call allows reordering, and the call creates its own new memory (which is already dealt with correctly). Fixes #62057. Updates #61992. Change-Id: Icc7918f0d2dd3c480cc7f496cdcd78edeca7f297 Reviewed-on: https://go-review.googlesource.com/c/go/+/519276 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit e72ecc6a6becab9ca895c0108047db4723394296) Reviewed-on: https://go-review.googlesource.com/c/go/+/520058
27 lines
439 B
Go
27 lines
439 B
Go
// compile
|
|
|
|
// Copyright 2023 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 61992, inconsistent 'mem' juggling in expandCalls
|
|
|
|
package p
|
|
|
|
type S1 struct {
|
|
a, b, c []int
|
|
i int
|
|
}
|
|
|
|
type S2 struct {
|
|
a, b []int
|
|
m map[int]int
|
|
}
|
|
|
|
func F(i int, f func(S1, S2, int) int) int {
|
|
return f(
|
|
S1{},
|
|
S2{m: map[int]int{}},
|
|
1<<i)
|
|
}
|