As far as I can tell, there is no public documentation on this topic,
which cost me several days of debugging.
I am possibly unusual in that I run binaries in production with the
race detector turned on, but I think that others who do the same may
want to be aware of the risk.
Updates #26813.
Updates #37233.
Change-Id: I1f8111bd01d0000596e6057b7cb5ed017d5dc655
Reviewed-on: https://go-review.googlesource.com/c/go/+/220586
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
It was needed for the old softfloat implementation, which has
long gone.
Change-Id: Ib8d53689209a3b003d62f84c7c6047d8ec5df859
Reviewed-on: https://go-review.googlesource.com/c/go/+/220719
Reviewed-by: Than McIntosh <thanm@google.com>
Add support to the asimd instruction rev16 which reverses elements in
16-bit halfwords.
syntax:
VREV16 <Vn>.<T>, <Vd>.<T>
<T> should be either B8 or B16.
Change-Id: I7a7b8e772589c51ca9eb6dca98bab1aac863c6c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/213738
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Provide an assembly implementation of mulWW - for now all others run the
Go code.
Change-Id: Icb594c31048255f131bdea8d64f56784fc9db4d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/220919
Reviewed-by: Robert Griesemer <gri@golang.org>
Also, explicitly zero AuxInt in some ops (like Div),
to make it clear why they do not use an ellipsis.
Passes toolstash-check -all.
Change-Id: Iefd8891fca5d7be8aa1bb91eb1fe2c99c8bf9c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/217011
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts CL 213477.
Reason for revert: tests are failing on linux-mips*-rtrk builders.
Change-Id: I8168f7450890233f1bd7e53930b73693c26d4dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/220897
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts CL 220722.
Reason for revert: rolling forward with fix.
Fixes#37392
Change-Id: Iba8b0c645267777fbb7019976292d691a10b906a
Reviewed-on: https://go-review.googlesource.com/c/go/+/220898
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When internal linking was broken buildmode PIE is set to external
linking. Now internal linking is fixed, -buildmode=pie can default to
internal linking again.
Fixes#35545
Change-Id: Iaf86b3047eb76babebc1545a79125586a7a3980e
Reviewed-on: https://go-review.googlesource.com/c/go/+/207877
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When converting from float32->float64->float32, any signal NaNs
get converted to quiet NaNs. Avoid that so using reflect.Value.Convert
between two float32 types keeps the signal bit of NaNs.
Update #36400
Change-Id: Ic4dd04c4be7189d2171d12b7e4e8f7cf2fb22bb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/213497
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We store 32-bit floating point constants in a 64-bit field, by
converting that 32-bit float to 64-bit float to store it, and convert
it back to use it.
That works for *almost* all floating-point constants. The exception is
signaling NaNs. The round trip described above means we can't represent
a 32-bit signaling NaN, because conversions strip the signaling bit.
To fix this issue, just forbid NaNs as floating-point constants in SSA
form. This shouldn't affect any real-world code, as people seldom
constant-propagate NaNs (except in test code).
Additionally, NaNs are somewhat underspecified (which of the many NaNs
do you get when dividing 0/0?), so when cross-compiling there's a
danger of using the compiler machine's NaN regime for some math, and
the target machine's NaN regime for other math. Better to use the
target machine's NaN regime always.
This has been a bug since 1.10, and there's an easy workaround
(declare a global varaible containing the signaling NaN pattern, and
use that as the argument to math.Float32frombits) so we'll fix it in
1.15.
Fixes#36400
Update #36399
Change-Id: Icf155e743281560eda2eed953d19a829552ccfda
Reviewed-on: https://go-review.googlesource.com/c/go/+/213477
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
In CL 210180 we detect gaps between PT_LOAD segments and subtract
them from size calculation. The code there only works when
PT_LOAD segments are next to each other. But it is possible that
there are other segments in between (e.g. a GNU_RELRO segment).
Relax the gap detection to count gaps between PT_LOAD segments
regardless of whether they are next to each other.
Updates #36023.
Updates #35545.
Change-Id: I8b94506359fa649a4478acc742d86d4b16022dbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/220654
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Builds upon the changes from #32000 which supported sourcing environment
variables for a new process from the environment of a Windows user token
when supplied.
But due to the logic of os/exec, the Env field of a process was
always non-nil when it reached that change.
This change moves the logic up to os/exec, specifically when
os.ProcAttr is being built for the os.StartProcess call, this
ensures that if a user token has been supplied and no Env slice has
been provided on the command it will be sourced from the user's
environment.
If no token is provided, or the program is compiled for any other
platform than Windows, the default environment will be sourced from
syscall.Environ().
Fixes#35314
Change-Id: I4c1722e90b91945eb6980d5c5928183269b50487
GitHub-Last-Rev: 32216b7291
GitHub-Pull-Request: golang/go#37402
Reviewed-on: https://go-review.googlesource.com/c/go/+/220587
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This found its way in accidentally.
Change-Id: I830f1e3ec4852a213901a679ad20094a6958cb07
Reviewed-on: https://go-review.googlesource.com/c/go/+/220680
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also, explicitly zero AuxInt in some ops (like Div),
to make it clear why they do not use an ellipsis.
Passes toolstash-check -all.
Change-Id: I47b4ed745196ed734927dbb5923edec33ce286da
Reviewed-on: https://go-review.googlesource.com/c/go/+/217013
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Also, explicitly zero AuxInt in some ops (like Div),
to make it clear why they do not use an ellipsis.
Passes toolstash-check -all.
Change-Id: I2e234e7b779422f7577037813f277e7586061880
Reviewed-on: https://go-review.googlesource.com/c/go/+/217012
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also, explicitly zero AuxInt in some ops (like Div),
to make it clear why they do not use an ellipsis.
Passes toolstash-check -all.
Change-Id: I2294d10e47d904d03e489e6ca43d46679323f75d
Reviewed-on: https://go-review.googlesource.com/c/go/+/217009
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also, explicitly zero AuxInt in some ops (like Div),
to make it clear why they do not use an ellipsis.
Passes toolstash-check -all.
Change-Id: Iea0e807949f0899c43d2d21b9551a2cf00a829b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/217006
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The address calculations in the example end up doing x << 4 + y + 0.
Before this CL we use a SHLQ+LEAQ. Since the constant offset is 0,
we can use SHLQ+ADDQ instead.
Change-Id: Ia048c4fdbb3a42121c7e1ab707961062e8247fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/209959
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The wrapper takes a pointer to the argument, not the argument itself.
Fixes#36705
Change-Id: I566d4457d00bf5b84e4a8315a26516975f0d7e10
Reviewed-on: https://go-review.googlesource.com/c/go/+/215942
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If GOBIN is set in the GOENV file, then merely unsetting it in the
process environment is not sufficient. We can instead either set GOBIN
explicitly, or disable GOENV explicitly. For now, we (semi-arbitrary)
choose the former.
Fixes#37390
Change-Id: Iec54532c804b70546d695105cd89e9169eac5dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/220652
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We should panic in this situation. Rewriting to a SSA op just leads
to a compiler panic.
Fixes#36259
Change-Id: I6e0bccbed7dd0fdac7ebae76b98a211947947386
Reviewed-on: https://go-review.googlesource.com/c/go/+/212405
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Fixes the declaration line reported in the DW_AT_decl_line for
variables captured in a closure.
Fixes#36542
Change-Id: I228d32b57121fd62c4615c2ef71a6e8da616a1e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/214637
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Use consistent indentation for one of the paragraphs.
Include issue number in the visible text, so it is easier to read.
Fixes#36878
Change-Id: Iab857b26b1d27b0137e981126207089db108d530
Reviewed-on: https://go-review.googlesource.com/c/go/+/220646
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This function is apparently unused since CL 204917.
Updates #35290
Updates #37397
Change-Id: Id7f5f5d5176fdbd1c5c6227e81d0854ceafc3f12
Reviewed-on: https://go-review.googlesource.com/c/go/+/220640
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Change Checker.index to return the type and constant index value
rather than just a boolean valid flag and the constant value.
While at it, rename some variables and simplify the control flow.
Adjust all uses of Checker.index to new signature. In code for
make() built-in, collect type information for signature reporting.
Fixes#37393.
Change-Id: Id70196faa9539ed5a0d6b59e0f3ea05e05f2f6a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/220585
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Having an mcache field in both m and p is confusing, so remove it from m.
Always use mcache field from p. Use new variable mcache0 during bootstrap.
Change-Id: If2cba9f8bb131d911d512b61fd883a86cf62cc98
Reviewed-on: https://go-review.googlesource.com/c/go/+/205239
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The runtime implementation of select has an upper limit on the number of
select cases that are supported in order to maintain low stack memory
usage. Rather than support an arbitrary number of select cases, we've
opted to panic early with a useful message pointing the user directly
at the problem.
Fixes#37350
Change-Id: Id129ba281ae120387e681ef96be8adcf89725840
Reviewed-on: https://go-review.googlesource.com/c/go/+/220583
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
• Inline check function because it's more readable.
• Delete toolPath because it was unused.
• Use strings.TrimPrefix because it's simpler.
• Remove out variable because its value was unused.
• Rename serr to err because it's more consistent.
Change-Id: I084fb4f8b399578834d5eea29a673c386cf3a357
Reviewed-on: https://go-review.googlesource.com/c/go/+/218701
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Hajime Hoshi <hajimehoshi@gmail.com>
This constant is only used on libc-based platforms (aix, darwin,
solaris).
Change-Id: Ic57d1fe3b1501c5b552eddb9aba11f1e02510082
Reviewed-on: https://go-review.googlesource.com/c/go/+/220421
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Limit the maximum nesting depth when parsing to protect against stack
overflow, permitted by https://tools.ietf.org/html/rfc7159#section-9
A nesting depth limit of 10,000 was chosen to be a conservative
balance between avoiding stack overflow and avoiding impacting
legitimate JSON documents.
10,000 is less than 1% of the experimental stack depth limit
with the default stack size:
* On 64-bit systems, the default stack limit is 1GB,
which allows ~2,800,000 frames of recursive parsing
* On 32-bit systems, the default stack limit is 250MB,
which allows ~1,100,000 frames of recursive parsing
Fixes#31789
Change-Id: I4f5a90e89dcb4ab1a957ad9d02e1fa0efafaccf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/199837
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Always shadow or modify the original parameter name. With code like:
func index(item reflect.Value, ... {
v := indirectInterface(item)
It was possible to incorrectly use 'item' and 'v' later in the function,
which could result in subtle bugs. This is precisely the kind of mistake
that led to #36199.
Instead, don't keep both the old and new reflect.Value variables in
scope. Always shadow or modify the original variable.
While at it, simplify the signature of 'length', to receive a
reflect.Value directly and save a few redundant lines.
Change-Id: I01416636a9d49f81246d28b91aca6413b1ba1aa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/212117
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Roberto Clapis <robclap8@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
