The code previously filters out VAES-only instructions, this CL added
them back.
This CL added the VAES feature check following the Intel xed data:
XED_ISA_SET_VAES: vaes.7.0.ecx.9 # avx.1.0.ecx.28
This CL also found out that the old AVX512VAES feature check is not
checking the correct bits, it also fixes it:
XED_ISA_SET_AVX512_VAES_128: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_256: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16 avx512vl.7.0.ebx.31
XED_ISA_SET_AVX512_VAES_512: vaes.7.0.ecx.9 aes.1.0.ecx.25 avx512f.7.0.ebx.16
It restricts to the most strict common set - includes avx512vl for even
512-bits although it doesn't requires it.
Change-Id: I4e2f72b312fd2411589fbc12f9ee5c63c09c2e9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/738500
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When resuming TLS sessions, on the server and client verify that the
chains stored in the session state (verifiedChains) are still acceptable
with regards to the Config by checking for the inclusion of the root in
either ClientCAs (server) or RootCAs (client). This prevents resuming
a session with a certificate chain that would be rejected during a full
handshake due to an untrusted root.
Updates #77113
Updates #77217
Updates CVE-2025-68121
Change-Id: I11fe00909ef1961c24ecf80bf5b97f7b1121d359
Reviewed-on: https://go-review.googlesource.com/c/go/+/737700
Auto-Submit: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Coia Prant <coiaprant@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Instead of adding a typelinks section to a Go binary,
mark the start and end of the typelinked type descriptors.
The runtime can then step through the descriptors to find them all,
rather than relying on the extra linker-generated offset list.
The runtime steps through the type descriptors lazily,
as many Go programs don't need the typelinks list at all.
This reduces the size of cmd/go by 15K bytes, which isn't much
but it's not nothing.
A future CL will change the reflect package to use the type pointers
directly rather than converting to offsets and then back to type pointers.
For #6853
Change-Id: Id0af4ce81c5b1cea899fc92b6ff9d2db8ce4c267
Reviewed-on: https://go-review.googlesource.com/c/go/+/724261
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
WaitDelay only handles writes to Stdin and reads from Stdout/Stderr.
If Stdin is set to a blocking Reader, or Stdout/Stderr are set to
a blocking Writer, Wait can hang indefinitely. I don't see any way to
fix this with the current API, as there is no general way that the
os/exec package can interrupt the blocking Read or Write.
This CL documents the limitation and points people toward the
workaround of using StdinPipe/StdoutPipe/StderrPipe and arranging
for their own way to interrupt the blocking Read or Write.
Fixes#77227
Change-Id: I3150ae7af89dccf8d859b41eb43eaf0bbbb55fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/739422
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently this is a raw symbol name with no package component, which is
confusing when seen in profilers or similar tools.
This function does not follow a Go ABI, and thus should not have a Go
function declaration. go vet requires declaration for standard assembly
functions.
CL 176100 removed the package name as part of making vet pass on package
runtime, but simply making the function static via the <> suffix is
sufficient, there is no need to shorten the symbol name.
Change-Id: I6a6a636c6030f1c9a4b8bb330978733bb336b08e
Reviewed-on: https://go-review.googlesource.com/c/go/+/738521
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This change establishes the invariant that Underlying() cannot observe
a nil RHS for a defined type, unless that type was created by go/types
with an explicitly nil underlying type.
It does so using isComplete, which is a guard to check that a type has
an underlying type. This guard is needed whenever we could produce a
value of a defined type or access some property of a defined type.
Examples include T{}, *x (where x has type *T), T.x, etc. (see CL
734600 for more).
The pendingType mechanism to deeply traverse values of a defined type
is moved to hasVarSize, since this is only truly needed at the site
of a built-in such as unsafe.Sizeof.
This ties cycle detection across value context directly to the syntax,
which seems like the right direction.
Change-Id: Ic47862a2038fb2ba3ae6621e9907265ccbd86ea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/734980
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
On RISC-V the JAL and JALR instructions provide Return Address
Stack(RAS) prediction hints based on the registers used (as per section
2.5.1 of the RISC-V ISA manual). When a JALR instruction uses X1 or X5
as the source register, it hints that a pop should occur.
When making a function call, avoid the use of X5 as a source register
since this results in the RAS performing a pop-then-push instead of a
push, breaking call/return pairing and significantly degrading front-end
branch prediction performance.
Based on test result of golang.org/x/benchmarks/json on SpacemiT K1, fix
version has a performance improvement of about 7%
Fixes#76654
Change-Id: I867c8d7cfb54f5decbe176f3ab3bb3d78af1cf64
Reviewed-on: https://go-review.googlesource.com/c/go/+/726760
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Write down a few more things relevant to the process of maintaining
the vendor directory for the std and cmd modules. This includes the
import path of the package containing a tree consistency check, and
some considerations regarding the Go release cycle.
Also mention the updatestd command with enough context so that it's
clear that it is okay to either use it to update everything at once,
or instead update specific modules with individual 'go get' calls,
whichever is a better fit for the task at hand.
For #31806.
For #36905.
Change-Id: I37d391c557d6cf6ebf2751d71ab9c8f7c10d922d
Reviewed-on: https://go-review.googlesource.com/c/go/+/739301
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Alexander <jitsu@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
During the parallel section of compilation, we limit the amount of
parallelism to prevent scheduler churn. We do this with a worker
scheduler, but it does not have insight on when a compilation is blocked
due to lock contention.
The symbol table was protected with a lock. While most lookups were
quick lock->read->unlock affairs, sometimes there would be
initialization logic involved. This caused every lookup to stall,
waiting for init. Since our worker scheduler couldn't see this, it would
not launch new goroutine to "cover" the gap.
Fix by splitting the symbol lock into 2 cases, initialization and
lookup. If symbols need initialization simultaneously, they will wait
for each other, but the common case of looking up a symbol will be
handled by a syncmap. In practice, I have yet to see this lock being
blocked on.
Additionally, get rid of the scheduler goroutine and have each
compilation goroutine grab work from a central queue. When multiple
compilations finished at the same time, the work scheduler would
sometime not get run immediately. This ended up starving the system of
work.
These 2 changes together cuts -1.37% off the build time of typescriptgo
on systems with a lot of cores (specifically, the c3h88 perf builder).
Updates #73044.
Change-Id: I6d4b3be56fd00a4fdd4df132bcbd52e4b2a3e91f
Reviewed-on: https://go-review.googlesource.com/c/go/+/724623
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Instead of generating an equality function for each type that
needs it, generate one per "signature". A "signature" is a
summary of the comparisons needed to check a type for equality.
For instance, the type
type S struct {
i int32
j uint32
s string
e error
}
Will have the signature "M8SI".
M8 = 8 bytes of regular memory
S = string
I = nonempty interface
This way, potentially many types that have the same signature
can share the same equality function.
The number of generated equality functions in the go binary
is reduced from 634 to 286. The go binary is ~1% smaller.
The generation of equality functions gets simpler (particularly, how
we do inlining of sub-types, unrolling, etc.) and the generated code
is probably a bit more efficient.
The new function names are kind of weird, but will seldom show up
for users. They will appear in cpu profiles, and in tracebacks in the
situation where comparisons panic because an interface somewhere in
the type being compared contains an uncomparable type (e.g. a slice).
Note that this CL only affects generated comparison functions. It does
not generally affect generated code for == (except when that code decides
to call a comparison function as a subtask). Maybe a TODO for the future.
Update #6853
Change-Id: I202bd6424cb6bf7c745a62c9603d4f01dc1a1fc8
Reviewed-on: https://go-review.googlesource.com/c/go/+/725380
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
The Go loop variable semantics changed in Go 1.22: loop variables are now
created per-iteration instead of per-loop. The compiler decides which
semantics to use based on the Go version in go.mod.
When go.mod specifies go 1.21 and the code is built with a Go 1.22+
compiler, the per-loop(compatible behavior) semantics should be used.
However, when a line directive is present in the source file,
go.mod 1.21 and go1.22+ compiler outputs a per-iteration semantics.
For example, the file below wants output 333 but got 012.
-- go.mod --
module test
go 1.21
-- main.go --
//line main.go:1
func main() {
var fns []func()
for i := 0; i < 3; i++ {
fns = append(fns, func() { fmt.Print(i) })
}
for _, fn := range fns {
fn()
}
}
The distinctVars function uses stmt.Pos().Base() to look up the file
version in FileVersions. Base() returns the file name after line
directives are applied (e.g., "main.go" for "//line main.go:1"), not
the actual source file path. This causes the version lookup to fail
for files with line directives.
This CL fixes the bug by using stmt.Pos().FileBase() instead. FileBase()
returns the actual file path before line directives are applied, ensuring
the correct version information is retrieved from the original source file.
Fixes: #77248
Change-Id: Idacc0816d112ee393089262468a02acfe40e4b72
Reviewed-on: https://go-review.googlesource.com/c/go/+/737820
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The current cheaprand performs 128-bit multiplication on 64-bit numbers
and truncate the result to 32 bits, which is inefficient.
A 32-bit specific implementation is more performant because it performs
64-bit multiplication on 32-bit numbers instead.
The current cheaprand64 involves two cheaprand calls.
Implementing it as 64-bit wyrand is significantly faster.
Since cheaprand64 discards one bit, I have preserved this behavior.
The underlying uint64 function is made available as cheaprandu64.
│ old │ new │
│ sec/op │ sec/op vs base │
Cheaprand-8 1.358n ± 0% 1.218n ± 0% -10.31% (n=100)
Cheaprand64-8 2.424n ± 0% 1.391n ± 0% -42.62% (n=100)
Blocksampled-8 8.347n ± 0% 2.022n ± 0% -75.78% (n=100)
Fixes#77149
Change-Id: Ib0b5da4a642cd34d0401b03c1d343041f8230d11
GitHub-Last-Rev: 549d8d407e
GitHub-Pull-Request: golang/go#77150
Reviewed-on: https://go-review.googlesource.com/c/go/+/735480
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
