For #36460
Change-Id: I95abff45bb325732a19eb8b9c0d3fc34df08b4d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294293
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
For #36460
Change-Id: I889c4ece0d2caff7528cf437f89f7446dbd83955
Reviewed-on: https://go-review.googlesource.com/c/go/+/294292
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
bug511.dir/b.go:10:14: error: reference to undefined field or method 'M'
Change-Id: I9f96dc5c7254b310bc3e15b0bc588d62718cb4b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292009
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"[-]" is not a valid path.Match pattern.
Fixes#44474
Change-Id: I0932bbf08ffb8ad0c5337d69d0893f53c1ba89ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/294869
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This function has the wrong signature, so return an error when that
actually might lead to unexpected results. Users should switch to
x/sys/windows for the real version of this function.
Updates #44538.
Change-Id: I4d1f3d1e380815733ecfea683f939b1d25dcc32a
Reviewed-on: https://go-review.googlesource.com/c/go/+/296154
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow the implementation used by the other BSDs and account for the
intricacy of having to pass the fds array even though the file
descriptors are returned.
Re-submit of CL 130996 with corrected pipe2 wrapper.
Change-Id: Ie36d8214cba60c4fdb579f18bfc1c1ab3ead3ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/295372
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
math.Float32bits was not being inlined across package boundaries.
Create a private func that can be inlined with -l.
Change-Id: Ic50bf4727dd8ade09d011eb204006b7ee88db34a
Reviewed-on: https://go-review.googlesource.com/c/go/+/295989
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On windows/arm, the abort is given from one byte off of the function
address, perhaps because Windows wants to simulate x86/amd64 modes, or
because it's jumping from thumb mode. This is not the case with
windows/arm64, though.
This prevents a failure in the builders with the TestAbort test:
crash_test.go:727: output contains BAD:
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: BAD: recovered from abort
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x6a5721]
Change-Id: I8939c60611863cc0c325e179a772601acea9fd4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/296153
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This reverts commit dc4698f52b, and then
fixes the memory corruption issue. It also suggests users switch to
x/sys/windows for the proper function.
This requires CL 295174 to be submitted first.
Updates #44538.
Change-Id: I0ee602f1c1d6a89cc585aff426833a4cb3f2be50
Reviewed-on: https://go-review.googlesource.com/c/go/+/296149
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Work in progress.
TODO:
- insert debugging output for all the steps listed below
- emit modified call instructions w/ multiple register inputs
and Result-typed outputs (next CL)
- initially just change output from "mem" to "Result{mem}"
= most places this hits will be future work.
- change OpArg to use registerized variants
- (done) match abi paramresultinfo with particular arg, use Name
- (this CL) push register offsets for "loads" and "stores" into
recursive decomposition.
- hand registerized Result to exit block
For #40724.
Change-Id: Ie5de9d71f8fd4e092f5ee9260b54de35abf91016
Reviewed-on: https://go-review.googlesource.com/c/go/+/293390
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Added a flag '-d=inlfuncswithclosures=1' to allow inlining functions with
closures, and change the default to off for now, until #44370 is fixed.
Updates #44370.
Change-Id: Ic17723aa5c091d91f5f5004d8b63ec7125257acf
Reviewed-on: https://go-review.googlesource.com/c/go/+/296049
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
This fixes a bug in the internal ABI specification that made it not
equivalent to ABI0 even with zero architectural argument registers in
the case of a zero-sized argument with alignment > 1.
In ABI0, even zero-sized arguments cause alignment padding in the
stack frame.
Currently, in the internal ABI, zero-sized arguments get
register-assigned even if there are no registers because they don't
consume any registers. Hence, they don't create alignment padding in
the stack frame.
Fix this by stack-assigning zero-sized arguments.
For #40724.
Change-Id: I1f5a95a94fed8b5313a360e5e76875701ba5f562
Reviewed-on: https://go-review.googlesource.com/c/go/+/295791
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
We've already implemented dedicating R14 as the G register on amd64,
so remove the TODO saying we might want to hold off on this.
For #40724.
Change-Id: I45b24ced03cac862127b53f5e9a4b4bcf6b1f86c
Reviewed-on: https://go-review.googlesource.com/c/go/+/295790
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Florian Weimer pointed out that my justification for using MMX mode
was nonsense and that staying in x87 mode simplifies transitions to
and from C. Hence, switch the spec to say we're always in x87 mode.
For #40724.
Change-Id: Iad916b2c376db41f95614aa6897f6b1184576bb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/295789
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The code generated when storing eight bytes loaded from memory created a
series of small writes instead of a single, large one. The specific
pattern of instructions generated stored 1 byte, then 2 bytes, then 4
bytes, and finally 1 byte.
The new rules match this specific pattern both for amd64 and for s390x,
and convert it into a single instruction to store the 8 bytes. arm64 and
ppc64le already generated the right code, but the new codegen test
covers also those architectures.
Fixes#41663
Change-Id: Ifb9b464be2d59c2ed5034acf7b9c3e473f344030
Reviewed-on: https://go-review.googlesource.com/c/go/+/280456
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add test in which a input Go object file contains a very large number
of relocations (more than 1<<20).
Updates #41621.
Change-Id: If1ebf3c4fefbf55ddec4e05c5299e7c48fc697d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/278493
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
Fixes#44538.
RELNOTES=yes
Change-Id: Idf48d4c712d13da29791e9a460159255f963105b
Reviewed-on: https://go-review.googlesource.com/c/go/+/295371
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Plumb abi information into ssa/ssagen for plain calls
and plain functions (not methods). Does not extend all the
way through the compiler (yet).
One test disabled because it extends far enough to break the test.
Normalized all the compiler's register args TODOs to
// TODO(register args) ...
For #40724.
Change-Id: I0173a4579f032ac3c9db3aef1749d40da5ea01ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/293389
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
OCONVOP doesn't have effect in the compiled code so, it can be safely
excluded from inline cost calculation.
Also make sequence ODEREF OCONVNOP* OADDR cost 1. This is rather common
conversion, such as *(*uint32)(unsafe.Pointer(&x)).
Fixes#42788
Change-Id: I5001f7e89d985c198b6405694cdd5b819cf3f47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/281232
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
When you log after a test has completed,
the testing package panics.
Print the logged line as part of that panic,
to aid in debugging.
Change-Id: I3d6689d1eed57c03e300afe37db0c15b2f4acda4
Reviewed-on: https://go-review.googlesource.com/c/go/+/283972
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use an atomic.Value to hold the done channel.
Conveniently, we have a mutex handy to coordinate writes to it.
name old time/op new time/op delta
ContextCancelDone-8 67.5ns ±10% 2.2ns ±11% -96.74% (p=0.000 n=30+28)
Fixes#42564
Change-Id: I5d72e0e87fb221d4e230209e5fb4698bea4053c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288193
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The fix is to pull in CL 295089 from the x/mod repo.
Fixes#44497
Change-Id: I008b58d0f4bb48c09d4f1e6ed31d11a714f87dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/295150
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
For mips32 currently, we are using FP32, while the gcc may be FPXX,
which may generate .MIPS.abiflags and .gnu.attributes section with
value as FPXX. So the kernel will treat the exe as FPXX, and may
choose to use FR=1 FPU mode for it.
Currently, in Go, we use 2 lwc1 to load both half of a double value
to a pair of even-odd FPR. This behavior can only work with FR=0 mode.
In FR=1 mode, all of 32 FPR are 64bit. If we lwc1 the high-half of a double
value to an odd FPR, and try to use the previous even FPR to compute, the
real high-half of even FPR will be unpredicatable.
We set -mfp32 to force the gcc generate FP32 code and section value.
More details about FP32/FPXX/FP64 are explained in:
https://web.archive.org/web/20180828210612/https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
When GOMIPS/GOMIPS64 is set as softfloat, we should also pass
-msoft-float to gcc.
Here we also add -mno-odd-spreg option, since Loongson's CPU cannot use
odd-number FR in FR=0 mode.
Fixes#39435
Change-Id: I54026ad416a815fe43a9261ebf6d02e5519c3930
Reviewed-on: https://go-review.googlesource.com/c/go/+/237058
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
For #42026Fixes#44311
Change-Id: I3dabcf902d155f95800b4adf1d7578906a194ce6
Reviewed-on: https://go-review.googlesource.com/c/go/+/285378
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
The decodeState type is a large part of the allocated space during Unmarshal.
The errorContext field is infrequently used, and only on error.
Extract it into a pointer and allocate it separate when necessary.
name old time/op new time/op delta
UnmarshalString-8 115ns ± 5% 114ns ± 3% ~ (p=0.170 n=15+15)
UnmarshalFloat64-8 113ns ± 2% 106ns ± 1% -6.42% (p=0.000 n=15+14)
UnmarshalInt64-8 93.3ns ± 1% 86.9ns ± 4% -6.89% (p=0.000 n=14+15)
name old alloc/op new alloc/op delta
UnmarshalString-8 192B ± 0% 160B ± 0% -16.67% (p=0.000 n=15+15)
UnmarshalFloat64-8 180B ± 0% 148B ± 0% -17.78% (p=0.000 n=15+15)
UnmarshalInt64-8 176B ± 0% 144B ± 0% -18.18% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
UnmarshalString-8 2.00 ± 0% 2.00 ± 0% ~ (all equal)
UnmarshalFloat64-8 2.00 ± 0% 2.00 ± 0% ~ (all equal)
UnmarshalInt64-8 1.00 ± 0% 1.00 ± 0% ~ (all equal)
Change-Id: I53f3f468e6c65f77a12e5138a2626455b197012d
Reviewed-on: https://go-review.googlesource.com/c/go/+/271338
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This test contained a data race.
On line 437, db.BeginTx starts a goroutine that runs tx.awaitDone,
which reads tx.keepConnOnRollback.
On line 445, the test writes to tx.keepConnOnRollback.
tx.awaitDone waits on ctx, but because ctx is timeout-based,
there's no ordering guarantee between the write and the read.
The race detector never caught this before
because the context package implementation of Done
contained enough synchronization to make it safe.
That synchronization is not package of the context API or guarantees,
and the first several releases it was not present.
Another commit soon will remove that synchronization,
exposing the latent data race.
To fix the race, emulate a time-based context
using an explicit cancellation-based context.
This gives us enough control to avoid the race.
Change-Id: I103fe9b987b1d4c02e7a20ac3c22a682652128b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288493
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
The changes from the (reviewed) dev.regabi copy of call.go can be seen
by comparing patchset 1 and 4. The actual changes are removing the
"// REVIEW INCOMPLETE" marker, deleting some leftover handling of type
instantiation in Checker.call, and adding a comment that exprOrTypeList
should be refactored.
I started to refactor exprOrTypeList, but thought it best to mark this
code as reviewed before diverging from types2.
Change-Id: Icf7fbff5a8def49c5f1781472fd7ba7b73dd9a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/295531
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: I453d06da2f596eb0b99905aec46a05547d73c62c
Reviewed-on: https://go-review.googlesource.com/c/go/+/290872
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Is and isExcludingLatin did not handle negative runes when dispatching
to is16. TestNegativeRune covers this along with the existing uint32
casts in IsGraphic, etc. (For tests, I picked the smallest non-Latin-1
code point in each range.)
Updates #43254
Change-Id: I17261b91f0d2b5b5125d19219411b45c480df74f
Reviewed-on: https://go-review.googlesource.com/c/go/+/280493
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Change-Id: Ic7701a9e4635fe1a331c9a1df776ed580759eb9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268758
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Rob Pike <r@golang.org>
Change-Id: Ic4fcd67cd9222eae6b72d9e91e37f3b0293b0b8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/295530
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The test does not use Done channel, so fix that.
Change-Id: I795feab2e95de815b8b6ee7a7fd90f19f7af7db1
Reviewed-on: https://go-review.googlesource.com/c/go/+/294749
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Trust: Sameer Ajmani <sameer@golang.org>
Trust: Cody Oss <codyoss@google.com>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Test NoRaceMutexPureHappensBefore in runtime/race/testdata/mutex_test.go
expects the second spawned goroutine to run after the first. The test
attempts to force this scheduling with a 10 millisecond wait. Following
a suggestion by Bryan Mills, we force this scheduling using a shared
variable whose access take place within the existing mutex.
Fixes#35745.
Change-Id: Ib23ec51492ecfeed4752e020401dd25755a669ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/291292
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
See if this clears failure on openbsd-amd64-68 (ahem).
Change-Id: Ifa60ef711a95e5de8ad91433ffa425f75b36c76f
Reviewed-on: https://go-review.googlesource.com/c/go/+/295629
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change-Id: I9a234cc1f04ca762375b51ec8ef009fb264c7ed1
Reviewed-on: https://go-review.googlesource.com/c/go/+/295689
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This template is based on CL 248198 and previous ones like it.
Continue to eagerly include often-used sections, and clarify that
the TODO is about completing the section, or removing if it turns
out not to be needed.
Move the Go 1.16 release notes to x/website, since that's the new
home for past Go release notes as of CL 291711. They're added to
x/website in CL 295249.
'relnote -html' does not report any CLs with RELNOTE annotations
since 2021/02/01.
For #44513.
Updates #40700.
Change-Id: Idd389335500ec4dec2764cbbaa385918cc8a79ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/295209
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
For #44497
Change-Id: Ie5285b9c526506b6b1280a590a5dcbee4074f57b
Reviewed-on: https://go-review.googlesource.com/c/go/+/295149
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
If the race detector were runnable in dynamic linking mode,
then R15 would get clobbered. I don't think it is, so maybe
not a problem, but can't hurt to clean it up.
It also lets CL 283474 pass cleanly when checking the whole stdlib
(together with CL 288452).
Change-Id: I5a5021ecc7e7b8bed1cd3a7067c39b24c09e0783
Reviewed-on: https://go-review.googlesource.com/c/go/+/289270
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When in dynlink mode, reading a global can clobber R15.
Just to be safe, save R15 before checking the AVX state to see
if we need to VZEROUPPER or not.
This could cause a problem in buildmodes that aren't supported yet.
Change-Id: I8fda62d3fbe808584774fa5e8d9810a4612a84e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288452
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
MOV*nop and MOV*reg seem superfluous. They are there to keep type
information around that would otherwise get thrown away. Not sure
what we need it for. I think our compiler needs a normalization of
how types are represented in SSA, especially after lowering.
MOV*nop gets in the way of some optimization rules firing, like for
load combining.
For now, just fold MOV*nop and MOV*const. It's certainly safe to
do that, as the type info on the MOV*const isn't ever useful.
R=go1.17
Change-Id: I3630a80afc2455a8e9cd9fde10c7abe05ddc3767
Reviewed-on: https://go-review.googlesource.com/c/go/+/276792
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
nowdays, in runtime/mgc.go,we can see the comment descrition : The fractional worker is necessary when GOMAXPROCS*gcBackgroundUtilization is not an integer.
but it not true such as GOMAXPROCS=5.
in the implemet of startCycle() , Fractional Mode happend only when
GOMAXPROCS<=3 or GOMAXPROCS=6. so utilization can closest to 25%.
Fixes#44380
Change-Id: Id0dd6d9f37759c2c9231f164a013a014216dd442
GitHub-Last-Rev: 5910e76324
GitHub-Pull-Request: golang/go#44381
Reviewed-on: https://go-review.googlesource.com/c/go/+/293630
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
s/!gccgo/gc/ in files which use gc-syntax assembly.
Change-Id: Ifdadb62edd1210ebc70e7cd415648b752afaf067
Reviewed-on: https://go-review.googlesource.com/c/go/+/269957
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
