commit 1984ee00048b63eacd2155cd6d74a2d13e998272 [browse]
Author: Alexander Rakoczy
Date: 2020-10-14 13:45:23 -04:00

[release-branch.go1.15] go1.15.3

Change-Id: I8a45870039d0d3f210d883c464a7fed2abd9e28b
Reviewed-on: https://go-review.googlesource.com/c/go/+/262337
Run-TryBot: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>

commit 7863f742c4e8427a7169325b024c2d8a970e0134 [browse]
Author: Keith Randall
Date: 2020-10-01 09:57:52 -07:00

[release-branch.go1.15] cmd/compile: fix left shift constant folding rule

The 32-bit left shift constant folding rule should keep its result
properly sign extended.

Fixes #41720
Fixes #41711

Change-Id: I0fc74444d444274e911952e1725dab0b7737a846
Reviewed-on: https://go-review.googlesource.com/c/go/+/258817
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>

commit 8b224e9951438283ae53ae35dc2a50a56fccc404 [browse]
Author: Austin Clements
Date: 2020-10-03 16:44:22 -04:00

[release-branch.go1.15] runtime: correct signature of call16

The signature of call16 is currently missing the "typ" parameter. This
CL fixes this. This wasn't caught by vet because call16 is defined by
macro expansion (see #17544), and we didn't notice the mismatch with
the other call* functions because call16 is defined only on 32-bit
architectures and lives alone in stubs32.go.

Unfortunately, this means its GC signature is also wrong: the "arg"
parameter is treated as a scalar rather than a pointer, so GC won't
trace it and stack copying won't adjust it. This turns out to matter
in exactly one case right now: on 32-bit architectures (which are the
only architectures where call16 is defined), a stack-allocated defer
of a function with a 16-byte or smaller argument frame including a
non-empty result area can corrupt memory if the deferred function
grows the stack and is invoked during a panic. Whew. All other current
uses of reflectcall pass a heap-allocated "arg" frame (which happens
to be reachable from other stack roots, so tracing isn't a problem).

Curiously, in 2016, the signatures of all call* functions were wrong
in exactly this way. CL 31654 fixed all of them in stubs.go, but
missed the one in stubs32.go.

Updates #41795.
Fixes #41797.

Change-Id: I31e3c0df201f79ee5707eeb8dc4ff0d13fc10ada
Reviewed-on: https://go-review.googlesource.com/c/go/+/259338
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/259598

commit 76a2c87a2c4e78f40f0f70bda3da93c773630179 [browse]
Author: Keith Randall
Date: 2020-10-02 16:04:12 -07:00

[release-branch.go1.15] cmd/compile: export notinheap annotation to object file

In the rare case when a cgo type makes it into an object file, we need
the go:notinheap annotation to go with it.

Fixes #41432.

Change-Id: Ie2ef241ee49661792e0d8c8c46c51b2fe5c6fa7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/259300
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

commit cfeb16ddec5b2134198dcc029cdd501ed11a7c01 [browse]
Author: Keith Randall
Date: 2020-09-17 09:55:23 -07:00

[release-branch.go1.15] cmd/compile: propagate go:notinheap implicitly

//go:notinheap
type T int

type U T

We already correctly propagate the notinheap-ness of T to U.  But we
have an assertion in the typechecker that if there's no explicit
//go:notinheap associated with U, then report an error. Get rid of
that error so that implicit propagation is allowed.

Adjust the tests so that we make sure that uses of types like U
do correctly report an error when U is used in a context that might
cause a Go heap allocation.

Update #41432

Change-Id: I1692bc7cceff21ebb3f557f3748812a40887118d
Reviewed-on: https://go-review.googlesource.com/c/go/+/255637
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 22053790fa2c0944df53ea95df476ad2f855424f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/255697
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>