<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/go-git.git, branch go1.16.3</title>
<subtitle>github.com: golang/go
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/'/>
<entry>
<title>[release-branch.go1.16] go1.16.3</title>
<updated>2021-04-01T17:26:20+00:00</updated>
<author>
<name>Dmitri Shuralyov</name>
<email>dmitshur@golang.org</email>
</author>
<published>2021-04-01T15:28:29+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=9baddd3f21230c55f0ad2a10f5f20579dcf0a0bb'/>
<id>9baddd3f21230c55f0ad2a10f5f20579dcf0a0bb</id>
<content type='text'>
Change-Id: Iace7cfec757a6d0bac25f729be5ecb2ae3b59d74
Reviewed-on: https://go-review.googlesource.com/c/go/+/306569
Run-TryBot: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
Run-TryBot: Carlos Amedee &lt;carlos@golang.org&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change-Id: Iace7cfec757a6d0bac25f729be5ecb2ae3b59d74
Reviewed-on: https://go-review.googlesource.com/c/go/+/306569
Run-TryBot: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
Run-TryBot: Carlos Amedee &lt;carlos@golang.org&gt;
Reviewed-by: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
Reviewed-by: David Chase &lt;drchase@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/compile: fix long RMW bit operations on AMD64</title>
<updated>2021-03-31T17:15:59+00:00</updated>
<author>
<name>Pat Gavlin</name>
<email>pgavlin@gmail.com</email>
</author>
<published>2021-03-26T14:46:37+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=96139f25993f3d8122e27a6fec877a4d4f69f83b'/>
<id>96139f25993f3d8122e27a6fec877a4d4f69f83b</id>
<content type='text'>
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:

    func repro(b []byte, addr, bit int32) {
	    _ = b[3]
	    v := uint32(b[0]) | uint32(b[1])&lt;&lt;8 | uint32(b[2])&lt;&lt;16 | uint32(b[3])&lt;&lt;24 | 1&lt;&lt;(bit&amp;31)
	    b[0] = byte(v)
	    b[1] = byte(v &gt;&gt; 8)
	    b[2] = byte(v &gt;&gt; 16)
	    b[3] = byte(v &gt;&gt; 24)
    }

Roughly speaking:

1. The expression `1 &lt;&lt; (bit &amp; 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])&lt;&lt;8 | uint32(b[2])&lt;&lt;16 |
   uint32(b[3])&lt;&lt;24` is rewritten into `(MOVLload &amp;b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v &gt;&gt; 24)` are
   rewritten into `(MOVLstore &amp;b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &amp;b[0]))` is rewritten into
   `(BTSL (MOVLload &amp;b[0]) bit)`. This is a valid transformation because
   the destination is a register: in this case, the bit offset is masked
   by the number of bits in the destination register. This is identical
   to the masking performed by `SHL`.
5. `(MOVLstore &amp;b[0] (BTSL (MOVLload &amp;b[0]) bit))` is rewritten into
   `(BTSLmodify &amp;b[0] bit)`. This is an invalid transformation because
   the destination is memory: in this case, the bit offset is not
   masked, and the chosen instruction may write outside its intended
   32-bit location.

These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &amp;b[0] (ANDLconst [31] bit))` in step (5).

These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.

Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:

file                               before   after    Δ       %
runtime.s                          536464   536412   -52     -0.010%
bytes.s                            32629    32593    -36     -0.110%
strings.s                          44565    44529    -36     -0.081%
os/signal.s                        7967     7959     -8      -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686    81678    -8      -0.010%
math/big.s                         188235   188253   +18     +0.010%
cmd/link/internal/loader.s         89295    89056    -239    -0.268%
cmd/link/internal/ld.s             633551   633232   -319    -0.050%
cmd/link/internal/arm.s            18934    18928    -6      -0.032%
cmd/link/internal/arm64.s          31814    31801    -13     -0.041%
cmd/link/internal/riscv64.s        7347     7345     -2      -0.027%
cmd/compile/internal/ssa.s         4029173  4033066  +3893   +0.097%
total                              21298280 21301472 +3192   +0.015%

Fixes #45253

Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: ab94ede1d097f920a9d1d3da403c8e4a3d8f6d44
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/305069
Trust: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
Run-TryBot: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Keith Randall &lt;khr@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:

    func repro(b []byte, addr, bit int32) {
	    _ = b[3]
	    v := uint32(b[0]) | uint32(b[1])&lt;&lt;8 | uint32(b[2])&lt;&lt;16 | uint32(b[3])&lt;&lt;24 | 1&lt;&lt;(bit&amp;31)
	    b[0] = byte(v)
	    b[1] = byte(v &gt;&gt; 8)
	    b[2] = byte(v &gt;&gt; 16)
	    b[3] = byte(v &gt;&gt; 24)
    }

Roughly speaking:

1. The expression `1 &lt;&lt; (bit &amp; 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])&lt;&lt;8 | uint32(b[2])&lt;&lt;16 |
   uint32(b[3])&lt;&lt;24` is rewritten into `(MOVLload &amp;b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v &gt;&gt; 24)` are
   rewritten into `(MOVLstore &amp;b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &amp;b[0]))` is rewritten into
   `(BTSL (MOVLload &amp;b[0]) bit)`. This is a valid transformation because
   the destination is a register: in this case, the bit offset is masked
   by the number of bits in the destination register. This is identical
   to the masking performed by `SHL`.
5. `(MOVLstore &amp;b[0] (BTSL (MOVLload &amp;b[0]) bit))` is rewritten into
   `(BTSLmodify &amp;b[0] bit)`. This is an invalid transformation because
   the destination is memory: in this case, the bit offset is not
   masked, and the chosen instruction may write outside its intended
   32-bit location.

These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &amp;b[0] (ANDLconst [31] bit))` in step (5).

These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.

Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:

file                               before   after    Δ       %
runtime.s                          536464   536412   -52     -0.010%
bytes.s                            32629    32593    -36     -0.110%
strings.s                          44565    44529    -36     -0.081%
os/signal.s                        7967     7959     -8      -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686    81678    -8      -0.010%
math/big.s                         188235   188253   +18     +0.010%
cmd/link/internal/loader.s         89295    89056    -239    -0.268%
cmd/link/internal/ld.s             633551   633232   -319    -0.050%
cmd/link/internal/arm.s            18934    18928    -6      -0.032%
cmd/link/internal/arm64.s          31814    31801    -13     -0.041%
cmd/link/internal/riscv64.s        7347     7345     -2      -0.027%
cmd/compile/internal/ssa.s         4029173  4033066  +3893   +0.097%
total                              21298280 21301472 +3192   +0.015%

Fixes #45253

Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: ab94ede1d097f920a9d1d3da403c8e4a3d8f6d44
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/305069
Trust: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
Run-TryBot: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Keith Randall &lt;khr@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] runtime: non-strict InlTreeIndex lookup in Frames.Next</title>
<updated>2021-03-31T16:59:18+00:00</updated>
<author>
<name>Michael Pratt</name>
<email>mpratt@google.com</email>
</author>
<published>2021-03-11T17:28:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=887c0d890fd33a72cc1de6316252ba37649145cb'/>
<id>887c0d890fd33a72cc1de6316252ba37649145cb</id>
<content type='text'>
When using cgo, some of the frames can be provided by cgoTraceback, a
cgo-provided function to generate C tracebacks. Unlike Go tracebacks,
cgoTraceback has no particular guarantees that it produces valid
tracebacks.

If one of the (invalid) frames happens to put the PC in the alignment
region at the end of a function (filled with int 3's on amd64), then
Frames.Next will find a valid funcInfo for the PC, but pcdatavalue will
panic because PCDATA doesn't cover this PC.

Tolerate this case by doing a non-strict PCDATA lookup. We'll still show
a bogus frame, but at least avoid throwing.

For #44971
Fixes #45303

Change-Id: I9eed728470d6f264179a7615bd19845c941db78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/301369
Trust: Michael Pratt &lt;mpratt@google.com&gt;
Run-TryBot: Michael Pratt &lt;mpratt@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Cherry Zhang &lt;cherryyz@google.com&gt;
(cherry picked from commit e4a4161f1f3157550846e1b6bd4fe83aae15778e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/305889
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using cgo, some of the frames can be provided by cgoTraceback, a
cgo-provided function to generate C tracebacks. Unlike Go tracebacks,
cgoTraceback has no particular guarantees that it produces valid
tracebacks.

If one of the (invalid) frames happens to put the PC in the alignment
region at the end of a function (filled with int 3's on amd64), then
Frames.Next will find a valid funcInfo for the PC, but pcdatavalue will
panic because PCDATA doesn't cover this PC.

Tolerate this case by doing a non-strict PCDATA lookup. We'll still show
a bogus frame, but at least avoid throwing.

For #44971
Fixes #45303

Change-Id: I9eed728470d6f264179a7615bd19845c941db78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/301369
Trust: Michael Pratt &lt;mpratt@google.com&gt;
Run-TryBot: Michael Pratt &lt;mpratt@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Cherry Zhang &lt;cherryyz@google.com&gt;
(cherry picked from commit e4a4161f1f3157550846e1b6bd4fe83aae15778e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/305889
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/compile: disable shortcircuit optimization for intertwined phi values</title>
<updated>2021-03-31T14:33:46+00:00</updated>
<author>
<name>Keith Randall</name>
<email>khr@golang.org</email>
</author>
<published>2021-03-23T21:48:47+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=3a45c13094e2bf1ac1430ce6af8b8be80bf0938e'/>
<id>3a45c13094e2bf1ac1430ce6af8b8be80bf0938e</id>
<content type='text'>
We need to be careful that when doing value graph surgery, we not
re-substitute a value that has already been substituted. That can lead
to confusing a previous iteration's value with the current iteration's
value.

The simple fix in this CL just aborts the optimization if it detects
intertwined phis (a phi which is the argument to another phi). It
might be possible to keep the optimization with a more complicated
CL, but:
  1) This CL is clearly safe to backport.
  2) There were no instances of this abort triggering in
     all.bash, prior to the test introduced in this CL.

Fixes #45192

Change-Id: I2411dca03948653c053291f6829a76bec0c32330
Reviewed-on: https://go-review.googlesource.com/c/go/+/304251
Trust: Keith Randall &lt;khr@golang.org&gt;
Trust: Josh Bleecher Snyder &lt;josharian@gmail.com&gt;
Run-TryBot: Keith Randall &lt;khr@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Josh Bleecher Snyder &lt;josharian@gmail.com&gt;
(cherry picked from commit 771c57e68ed5ef2bbb0eafc0d48419f59d143932)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304530
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We need to be careful that when doing value graph surgery, we not
re-substitute a value that has already been substituted. That can lead
to confusing a previous iteration's value with the current iteration's
value.

The simple fix in this CL just aborts the optimization if it detects
intertwined phis (a phi which is the argument to another phi). It
might be possible to keep the optimization with a more complicated
CL, but:
  1) This CL is clearly safe to backport.
  2) There were no instances of this abort triggering in
     all.bash, prior to the test introduced in this CL.

Fixes #45192

Change-Id: I2411dca03948653c053291f6829a76bec0c32330
Reviewed-on: https://go-review.googlesource.com/c/go/+/304251
Trust: Keith Randall &lt;khr@golang.org&gt;
Trust: Josh Bleecher Snyder &lt;josharian@gmail.com&gt;
Run-TryBot: Keith Randall &lt;khr@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Josh Bleecher Snyder &lt;josharian@gmail.com&gt;
(cherry picked from commit 771c57e68ed5ef2bbb0eafc0d48419f59d143932)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304530
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/go: allow '+' in package import paths in module mode</title>
<updated>2021-03-31T14:26:53+00:00</updated>
<author>
<name>Bryan C. Mills</name>
<email>bcmills@google.com</email>
</author>
<published>2021-03-09T22:23:04+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=2940614c63ed1351c47038db4ec613a37d1e72fd'/>
<id>2940614c63ed1351c47038db4ec613a37d1e72fd</id>
<content type='text'>
This change upgrades x/mod to pull in the fix from CL 300152.

Updates #44776.
Fixes #44885.

Change-Id: I273f41df2abfff76d91315b7f19fce851c8770d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/300176
Trust: Bryan C. Mills &lt;bcmills@google.com&gt;
Run-TryBot: Bryan C. Mills &lt;bcmills@google.com&gt;
Reviewed-by: Jay Conrod &lt;jayconrod@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
(cherry picked from commit d33e2192a71c33a604af247161ba1d2c1969e4c7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/300153
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change upgrades x/mod to pull in the fix from CL 300152.

Updates #44776.
Fixes #44885.

Change-Id: I273f41df2abfff76d91315b7f19fce851c8770d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/300176
Trust: Bryan C. Mills &lt;bcmills@google.com&gt;
Run-TryBot: Bryan C. Mills &lt;bcmills@google.com&gt;
Reviewed-by: Jay Conrod &lt;jayconrod@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
(cherry picked from commit d33e2192a71c33a604af247161ba1d2c1969e4c7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/300153
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] build: set GOPATH consistently in run.bash, run.bat, run.rc</title>
<updated>2021-03-29T19:16:21+00:00</updated>
<author>
<name>Russ Cox</name>
<email>rsc@golang.org</email>
</author>
<published>2021-01-27T02:14:43+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=1d967ab95c43b6b8810ca53d6a18aff85e59a3b6'/>
<id>1d967ab95c43b6b8810ca53d6a18aff85e59a3b6</id>
<content type='text'>
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).

run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.

run.rc still clears GOPATH.

Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.

For #45238.
Fixes #45240.

Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox &lt;rsc@golang.org&gt;
Trust: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Reviewed-by: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Alex Brainman &lt;alex.brainman@gmail.com&gt;
Reviewed-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
(cherry picked from commit bb6efb96092cc8ae398c29e3b052a0051c746f88)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304772
Run-TryBot: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Alexander Rakoczy &lt;alex@golang.org&gt;
Reviewed-by: Carlos Amedee &lt;carlos@golang.org&gt;
Trust: Carlos Amedee &lt;carlos@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).

run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.

run.rc still clears GOPATH.

Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.

For #45238.
Fixes #45240.

Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox &lt;rsc@golang.org&gt;
Trust: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
Reviewed-by: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Alex Brainman &lt;alex.brainman@gmail.com&gt;
Reviewed-by: Jason A. Donenfeld &lt;Jason@zx2c4.com&gt;
(cherry picked from commit bb6efb96092cc8ae398c29e3b052a0051c746f88)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304772
Run-TryBot: Dmitri Shuralyov &lt;dmitshur@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Alexander Rakoczy &lt;alex@golang.org&gt;
Reviewed-by: Carlos Amedee &lt;carlos@golang.org&gt;
Trust: Carlos Amedee &lt;carlos@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/link: generate trampoline for inter-dependent packages</title>
<updated>2021-03-25T18:34:20+00:00</updated>
<author>
<name>Cherry Zhang</name>
<email>cherryyz@google.com</email>
</author>
<published>2021-02-16T15:20:58+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=9c7463ca903863a0c67b3f76454b37da0a400c13'/>
<id>9c7463ca903863a0c67b3f76454b37da0a400c13</id>
<content type='text'>
Currently, in the trampoline generation pass we expect packages
are laid out in dependency order, so a cross-package jump always
has a known target address so we can check if a trampoline is
needed. With linknames, there can be cycles in the package
dependency graph, making this algorithm no longer work. For them,
as the target address is unkown we conservatively generate a
trampoline. This may generate unnecessary trampolines (if the
packages turn out laid together), but package cycles are extremely
rare so this is fine.

Updates #44639.
Fixes #44640.

Change-Id: I2dc2998edacbda27d726fc79452313a21d07787a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292490
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
(cherry picked from commit 098504c73ff6ece19566a1ac811ceed73be7c81d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/296909
Run-TryBot: Cherry Zhang &lt;cherryyz@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, in the trampoline generation pass we expect packages
are laid out in dependency order, so a cross-package jump always
has a known target address so we can check if a trampoline is
needed. With linknames, there can be cycles in the package
dependency graph, making this algorithm no longer work. For them,
as the target address is unkown we conservatively generate a
trampoline. This may generate unnecessary trampolines (if the
packages turn out laid together), but package cycles are extremely
rare so this is fine.

Updates #44639.
Fixes #44640.

Change-Id: I2dc2998edacbda27d726fc79452313a21d07787a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292490
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
(cherry picked from commit 098504c73ff6ece19566a1ac811ceed73be7c81d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/296909
Run-TryBot: Cherry Zhang &lt;cherryyz@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/compile, cmd/link: dynamically export writable static tmps</title>
<updated>2021-03-25T18:33:03+00:00</updated>
<author>
<name>Cherry Zhang</name>
<email>cherryyz@google.com</email>
</author>
<published>2021-03-13T04:21:09+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=ac59d7abb9ab5ec31cb0fe1eaccbdf3b17edbde0'/>
<id>ac59d7abb9ab5ec31cb0fe1eaccbdf3b17edbde0</id>
<content type='text'>
Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)

Updates #44956.
Fixes #45030.

Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Run-TryBot: Cherry Zhang &lt;cherryyz@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
(cherry picked from commit de012bc095359e1b552d4ea6fb6b2995f3ab04f5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/302449
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)

Updates #44956.
Fixes #45030.

Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Run-TryBot: Cherry Zhang &lt;cherryyz@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
(cherry picked from commit de012bc095359e1b552d4ea6fb6b2995f3ab04f5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/302449
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] cmd/go/internal/modfetch: detect and recover from missing ziphash file</title>
<updated>2021-03-25T18:28:35+00:00</updated>
<author>
<name>Jay Conrod</name>
<email>jayconrod@google.com</email>
</author>
<published>2021-03-03T21:30:22+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=33fb47921f65d941b232da2ab542191c9978b4dc'/>
<id>33fb47921f65d941b232da2ab542191c9978b4dc</id>
<content type='text'>
Previously, if an extracted module directory existed in the module
cache, but the corresponding ziphash file did not, if the sum was
missing from go.sum, we would not verify the sum. This caused 'go get'
not to write missing sums. 'go build' in readonly mode (now the
default) checks for missing sums and doesn't attempt to fetch modules
that can't be verified against go.sum.

With this change, when requesting the module directory with
modfetch.DownloadDir, if the ziphash file is missing, the go command
will re-hash the zip without downloading or re-extracting it again.

Note that the go command creates the ziphash file before the module
directory, but another program could remove it separately, and it
might not be present after a crash.

Fixes #44812

Change-Id: I64551e048a3ba17d069de1ec123d5b8b2757543c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298352
Trust: Jay Conrod &lt;jayconrod@google.com&gt;
Run-TryBot: Jay Conrod &lt;jayconrod@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Bryan C. Mills &lt;bcmills@google.com&gt;
(cherry picked from commit 302a400316319501748c0f034464fa70e7815272)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298851
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, if an extracted module directory existed in the module
cache, but the corresponding ziphash file did not, if the sum was
missing from go.sum, we would not verify the sum. This caused 'go get'
not to write missing sums. 'go build' in readonly mode (now the
default) checks for missing sums and doesn't attempt to fetch modules
that can't be verified against go.sum.

With this change, when requesting the module directory with
modfetch.DownloadDir, if the ziphash file is missing, the go command
will re-hash the zip without downloading or re-extracting it again.

Note that the go command creates the ziphash file before the module
directory, but another program could remove it separately, and it
might not be present after a crash.

Fixes #44812

Change-Id: I64551e048a3ba17d069de1ec123d5b8b2757543c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298352
Trust: Jay Conrod &lt;jayconrod@google.com&gt;
Run-TryBot: Jay Conrod &lt;jayconrod@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Bryan C. Mills &lt;bcmills@google.com&gt;
(cherry picked from commit 302a400316319501748c0f034464fa70e7815272)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298851
</pre>
</div>
</content>
</entry>
<entry>
<title>[release-branch.go1.16] testing: update helperNames just before checking it</title>
<updated>2021-03-24T20:20:01+00:00</updated>
<author>
<name>Tao Qingyun</name>
<email>qingyunha@gmail.com</email>
</author>
<published>2021-03-18T00:10:38+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/go-git.git/commit/?id=902d16e97bffe3faf49f48e67c43f7a0827f862c'/>
<id>902d16e97bffe3faf49f48e67c43f7a0827f862c</id>
<content type='text'>
parent's helperNames has not been set when frameSkip called, moving
helperNames initilazing to frameSkip.

For #44887
Fixes #44888

Change-Id: I5107c5951033e5e47d1ac441eac3ba5344a7bdc0
GitHub-Last-Rev: 44b90b2e2eeca8e2bb4a2084ec6fdd279c88f76d
GitHub-Pull-Request: golang/go#45071
Reviewed-on: https://go-review.googlesource.com/c/go/+/302469
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
(cherry picked from commit 67048432026062a98a3937a865aeb05a398148c5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/303189
Trust: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
parent's helperNames has not been set when frameSkip called, moving
helperNames initilazing to frameSkip.

For #44887
Fixes #44888

Change-Id: I5107c5951033e5e47d1ac441eac3ba5344a7bdc0
GitHub-Last-Rev: 44b90b2e2eeca8e2bb4a2084ec6fdd279c88f76d
GitHub-Pull-Request: golang/go#45071
Reviewed-on: https://go-review.googlesource.com/c/go/+/302469
Trust: Cherry Zhang &lt;cherryyz@google.com&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
(cherry picked from commit 67048432026062a98a3937a865aeb05a398148c5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/303189
Trust: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Emmanuel Odeke &lt;emmanuel@orijtech.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
