This makes it easier to identify which functions are used for memory
allocation by looking for functions that start with mallocgc. The Size
suffix is added so that the isSpecializedMalloc function in
cmd/compile/internal/ssa can distinguish between the generated functions
and the mallocgcTiny function called by mallocgc, similar to the SC
suffixes for the mallocgcSmallNoScanSC* and mallocgcSmallScanNoHeaderSC*
functons.
Change-Id: I6ad7f15617bf6f18ae5d1bfa2a0b94e86a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/735780
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Calls to dupSocket may fail, but the error is not properly handled
because the surrounding code incorrectly checks for nil error instead
of non-nil error.
I'm not aware of any code paths that would trigger this error, and
I haven't been able to create a test case that does so, but this
change fixes the error handling to correctly propagate any errors
from dupSocket.
Change-Id: I5ffd3cbe8ed58a83634f3b97c0878a7c73e0505e
Reviewed-on: https://go-review.googlesource.com/c/go/+/734821
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
- introduce subtitles to make various sub-sections easier to find
- split rules for struct literals into two groups (literals without
and with keys)
- move section on syntax ambiguity up as it pertains to the syntax
introduced at the start
- move prose specific to map literals into its own section
No language changes.
Change-Id: If8895b869138693179ca6e4d8b1c6ebdc705eccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/734322
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
We manipulate the dependencies of the build action when adding the
non-test variant of the package being tested as a dependency for the
test, so the set of deps of the build package doesn't correctly
represent the dependencies of the package that have been built. Restrict
the set of dependencies we use to populate the vet data to the actual
build dependencies depended on by the check cache action so we don't
check an action that we don't actually depend on (and which may not have
completed yet!)
Fixes#75380
Change-Id: I029080d00b3b10a837abcfb7039e00206a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734961
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently the Broadcast128/256/512 methods broadcast the lowest
element of the input vector to a vector of the corresponding width.
There are also variations of broadcast operations that broadcast
the whole (128- or 256-bit) vector to a larger vector, which we
don't yet support. Our current naming is unclear which version it
is, though. Rename the current ones to Broadcast1ToN, to be clear
that they broadcast one element. The vector version probably will
be named BoradcastAllToN (not included in this CL).
Change-Id: I47a21e367f948ec0b578d63706a40d20f5a9f46d
Reviewed-on: https://go-review.googlesource.com/c/go/+/734840
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Exposition is also added to outline a difference between syntax which
can / cannot produce values of incomplete types.
For us to enforce non-nilness of type RHS and remove the pending type
mechanism, I suspect we would need to add completeness guards to
the syntax which *can*.
Enforcing non-nilness of type RHS currently breaks the below test
cases, but I suspect that is simply an implementation artifact.
In other words, they just call Underlying at a bad time.
- T0
- T3
- T6 / T7
- T10
- T12
If we also remove pendingType, all of these test cases break; again,
we would need guards in the appropriate syntax logic.
Change-Id: Ibe22042232e542de1d38b923dd1d5cc50dce08cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/734600
TryBot-Bypass: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
To allow this, we also increase the size of the pool to allow the
minimum number for each action, with an extra 2*GOMAXPROCS number of
tokens to boost -c when there are fewer concurrently running actions.
That means the pool will now have the size 6*GOMAXPROCS instead of the
previous 4*GOMAXPROCS.
The goal is to maintain the boosting behavior added by the pool, while
guarding from starving compiles when there are too few tokens left, so
that the value of -c is always at least min(4,GOMAXPROCS), which is what
it was set to before Go 1.26.
Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64_c4as16-perf_vs_parent,gotip-linux-arm64_c4ah72-perf_vs_parent,gotip-linux-amd64_c3h88-perf_vs_parent,gotip-linux-amd64_c2s16-perf_vs_parent
Change-Id: I113a38584514a6c025d3d1bc727ff8d86a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734040
Commit-Queue: Michael Matloob <matloob@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Bypass: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
This fixes a bug where we only incremented concurrentProcesses but never
decremented it, causing us to run out of tokens and give all compiles
-c=1 after a point.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64_c2s16-perf_vs_parent,gotip-linux-amd64_c3h88-perf_vs_parent,gotip-linux-arm64_c4ah72-perf_vs_parent,gotip-linux-arm64_c4as16-perf_vs_parent
Change-Id: I41f4c1edb77004cbc1772d6d672045946a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/734260
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
TryBot-Bypass: Michael Matloob <matloob@google.com>
Pull in the following x/tools changes:
- CL 732260: go/analysis/passes/modernize: disable BLoop analyzer
- CL 733340: gopls/internal/analysis/modernize: mapsloop: undefined loop-var
For #74967.
For #77008.
[git-generate]
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=internal-branch.go1.26-vendor
Change-Id: Ic0c10569a4a3a292aec9164e6dd034e55d052904
Reviewed-on: https://go-review.googlesource.com/c/go/+/733780
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
An atomic.Bool isn't necessary here since, unless otherwise
specified, the methods of an object are not concurrency-safe
w.r.t. each other. Using an atomic causes the copylocks vet
check to warn about copying of Cmd, which is not wrong, because
one shouldn't be copying opaque complex structs from other
packages, but it is a nuisance in the absence of any safe way
to copy a Cmd.
If and when we add a Clone method to Cmd (see #77075) then
it would be appropriate to revert this change so that we get
the benefit of the static check (though ideally we would make
a more explicit tool-readable declaration of the "do not copy"
attribute than merely happening to use an atomic.Bool).
For #77075
Change-Id: I982d4e86623ca165a3e76bbf648fd44041d5f6bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/734200
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
VPMOVMSKB, VMOVMSKPS, and VMOVMSKPD moves AVX1/2-style masks to
integer registers, similar to VPMOV[BWDQ]2M (which moves to mask
registers). The former is available on AVX1/2, the latter requires
AVX512. So use the former if it is supported, i.e. for 128- and
256-bit vectors with 8-, 32-, and 64-bit elements (16-bit elements
always require AVX512).
Change-Id: I972195116617ed2faaf95cee5cd6b250e671496c
Reviewed-on: https://go-review.googlesource.com/c/go/+/734060
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Currently, the IsNan API is defined as x.IsNan(y), which returns
a mask to represent, for each element, either x or y is NaN.
Albeit closer to the machine instruction, this is weird API, as
IsNaN is a unary operation. This CL changes it to unary, x.IsNaN().
It compiles to VCMPPS $3, x, x (or VCMPPD). For the two-operand
version, we can optimize x.IsNaN().Or(y.IsNaN()) to VCMPPS $3, x,
y (not done in this CL).
While here, change the name to IsNaN (uppercase both Ns), which
matches math.IsNaN.
Tests in the next CL.
Change-Id: Ib6e7afc2635e6c3c606db5ea16420ee673a6c6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/733660
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
adonovan pointed out this bug in the review of CL 733320 and this seems
to be the cause of all those list_empty_importpath flakes. It makes
sense that something nondeterministic would be tied up with the module
index because the state of the cache could depend on the order tests are
run in.
Also remove the parts of the test that accept the flaky behavior so we
can verify the issue has been resolved.
For #73976
Change-Id: Ib64ce6b8eed1dc8d327b7c5e842c1e716a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/733321
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
Fix a pattern in test/codegen/comparisons.go to use whitespace instead
of a tab. The test needs a whitespace to properly fail if the regalloc
change from CL686655 would be missing (in that case we would have a
spill immediately after call to memequal, which is supposed to be
captured by this pattern).
Change-Id: I5b6fb5e861b9327c7f071660592b8ffa265e0030
Reviewed-on: https://go-review.googlesource.com/c/go/+/727620
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The rangefunc rewrite pass implements defer using deferrangefunc and
deferproccat. The loop body is rewritten into a closure, it cannot be
inlined due to defer call. But the outer function may still be inlined
in certain scenarios (e.g., with PGO), leading to the defer executing
at the wrong time.
Fixes#77033
Change-Id: I4649fad5cd1b65891832523522002d9352711123
Reviewed-on: https://go-review.googlesource.com/c/go/+/732140
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
