Add support for fine-grained memory ordering flags in the RISC-V FENCE
instruction to the assembler. This implements instruction validation and
encoding for predecessor and successor flags (I, O, R, W) rather than
always falling back to a full memory barrier. This allows more precise
memory barriers like FENCE R, RW or FENCE W, W.
Additionally, this adds assembly support for the FENCE.TSO, which is
encoded as FENCE RW, RW with the fm field set to 1000.
Change-Id: Ie9c6c8cd24b38b08013032972bd54515eaedd637
Reviewed-on: https://go-review.googlesource.com/c/go/+/758000
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mangling produces shaped qualified identifiers using a dictionary. It's
important for determining the stenciled type to use for a given
instantiation.
Since generic methods have qualified identifiers, they need mangling.
Suppose a generic method like T[P].m[Q] and a shaped dictionary like:
{
implicits: 0
receivers: 1
targs: [go.shape.int, go.shape.int]
}
This would be shaped to T[go.shape.int].m[go.shape.int].
Change-Id: Idc4c825f77a4e9209da65b5b0acb74b9f845bde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/761340
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This change adds pointers in the documentation for go tool to point to
go get -tool, and vice versa, and documents the rules for when aliases
can be used for tools and what those aliases are.
It also modifies go tool with no arguments so that it prints the alias
for any tools for which aliases can be provided, such as:
$ go tool
asm
cgo
[...]
bar (foo.com/full/package/path/bar)
For #71663
Change-Id: Id008cffbb02863692a18d4e1c1458b5b6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/761100
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When processing SETTINGS frame, Transport currently only checks if the
frame is valid for SETTINGS_ENABLE_CONNECT_PROTOCOL. As a result, a
SETTINGS_MAX_FRAME_SIZE with the invalid value of 0 is erroneously
accepted. This will then result in Transport being stuck in an infinite
loop writing CONTINUATION frames.
This CL fixes the issue by ensuring that SETTINGS frame are always
validated, regardless of the SETTINGS parameter.
Thanks to Marwan Atia (marwansamir688@gmail.com) for reporting this
issue.
Fixes#78476
Fixes CVE-2026-33814
Change-Id: I8b6219431e87454d34bca738fbcb59b66a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/761581
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Nicholas Husin <husin@google.com>
Generic methods will be hoisted to objects so that they can get their
own dictionaries. We need to avoid name collisions, so within a
package, we qualify generic methods using their defining type.
We don't differentiate method identifiers by whether they have a pointer
or value receiver for simplicity.
Change-Id: Ied06c5e4a4c5a6f8de8027358ddbe38fc40ae452
Reviewed-on: https://go-review.googlesource.com/c/go/+/761263
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change permits shaping method expressions for generic methods.
The API is slightly different for generic and non-generic methods,
as explained in code comments.
Using OMETHEXPR minimizes the necessary changes, but forces us to
split / rejoin the linker symbol for generic methods. While a bit
odd, it seems sound.
Change-Id: Iff28b9b11b9e83f450225aba0873644633f20633
Reviewed-on: https://go-review.googlesource.com/c/go/+/761220
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
A curious bug was reported to kubernetes[1] and runc[2] recently:
sometimes runc init reports exit status of 2.
Turns out, Go runtime assumes that on any UNIX system signals such as
SIGTERM (or any other that has _sigKill flag set in sigtable) with no
signal handler set up, will result in kernel terminating the program.
This is true, except for PID 1 which gets a custom treatment from the
kernel.
As a result, when a Go program that runs as PID 1 (which is easy to
achieve in Linux by using a new PID namespace) receives such a signal,
Go runtime calls dieFromSignal which falls through all the way to
exit(2), which is very confusing to a user.
This issue can be worked around by the program by adding custom handlers
for SIGTERM/SIGINT/SIGHUP, but that requires a goroutine to handle those
signals, which, in case of runc, unnecessarily raises its NPROC/pid.max
requirement (see discussion at [2]).
Since practically exit(2) in dieFromSignal can only happen when the
process is running as PID 1, replace it with exit(128+sig) to mimic
the shell convention when a child is terminated by a signal.
Add a test case which demonstrates the issue and validates the fix
(albeit only on Linux).
[An earlier version of this patch used to do nothing in dieFromSignal
for PID 1 case, but such behavior might be a breaking change for a Go
program running in a Linux container as PID 1.]
Fixes#78442
[1]: https://github.com/kubernetes/kubernetes/issues/135713
[2]: https://github.com/opencontainers/runc/pull/5189
Change-Id: I196e09e4b5ce84ce2c747a0c2d1fc6e9cf3a6131
Reviewed-on: https://go-review.googlesource.com/c/go/+/759040
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
We've been using go/build to load packages, and that doesn't
always do the right thing, because it doesn't have the same
context and settings that the go command uses to load packages.
Use the go command's loader to load packages.
This CL doesn't remove the logic for searching for matching
packages in dirs.go. A next step would be to remove that so
all the matching is also done with the go command's logic.
Fixes#75976
Change-Id: I3c76d9a54dc88648bb7c76a17afad8cb6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/733200
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sean Liao <sean@liao.dev>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
A bunch of tests had broken yet undetected syntax errors
in their assembly output regexps. Things like mismatched quotes,
using ^ instead of - for negation, etc.
In addition, since CL 716060 using commas as separators between
regexps doesn't work, and ends up just silently dropping every
regexp after the comma.
Fix all these things, and add a test to make sure that we're not
silently dropping regexps on the floor.
After this CL I will do some cleanup to align with CL 716060, like
replacing commas and \s with spaces (which was the point of that CL,
but wasn't consistently rewritten everywhere).
Change-Id: I54f226120a311ead0c6c62eaf5d152ceed106034
Reviewed-on: https://go-review.googlesource.com/c/go/+/760521
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Paul Murphy <paumurph@redhat.com>
Auto-Submit: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We were depending on runtime.etypes immediately following the itabs.
However, on AIX, runtime.etypes, as a zero-sized symbol, can float
when using external linking. It won't necessarily stay right at the
end of the itabs. Rather than worry about this, just record the size
of the itab data.
In practice it almost always works on AIX, but it fails the runtime
test TestSchedPauseMetrics/runtime/debug.WriteHeapDump,
which fails when iterating over all the itabs.
Tested on AIX. This should fix AIX on the build dashboard.
Change-Id: Id3a113b75b93fa8440c047e92f764ab81423df48
Reviewed-on: https://go-review.googlesource.com/c/go/+/760203
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
During the rangefunc rewrite, the compiler must correctly identify
the target of branch statements. When a label is defined within a
nested scope - such as inside a function literal or a closure - it
can shadow a label with the same name in the outer scope.
If the rewrite logic does not account for this shadowing, it may
incorrectly associate a branch with a nested label rather than the
intended loop label. Since the typechecker already guarantees that
labels are unique within their respective scopes, any duplicate label
name encountered must belong to a nested scope. These should be
skipped to ensure branch computing correctly targets the current
range-loop scope.
Fixes#78408
Change-Id: I4dce8a4d956f41b3a717a509f8c3f7478720be9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/761420
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jakub Ciolek <jakub@ciolek.dev>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: Keith Randall <khr@google.com>
The order pass ensures that initialization operations for clear(expr)
are scheduled. However, if 'expr' is a conversion that the walk pass
subsequently optimizes away or transforms, the resulting nodes can
be left in an un-walked state.
These un-walked nodes reach the SSA backend, which does not expect
high-level IR, resulting in an ICE.
This change ensures the expression is always walked during the
transformation of the 'clear' builtin.
Fixes#78410
Change-Id: I1997a28af020f39b2d325a58429eff9495048b1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/760981
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The sync package uses linkname to access internal/runtime/atomic
package's LoadAcquintptr and StoreReluintptr functions. It was not
able to import the package when the package was
runtime/internal/atomic. Now that it moves to internal/runtime,
the sync package can just import it and call the functions
normally.
Change-Id: Ic7399e33d0e965fdcdf505be67a7f90e0260ddee
Reviewed-on: https://go-review.googlesource.com/c/go/+/750160
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, when Server.Shutdown is called with a given context, an
HTTP/3 server implementation does not have access to said context. This
forces HTTP/3 server implementations to guess a reasonable fixed timeout
when attempting to gracefully shutdown, which is not ideal.
Therefore, add ShutdownContext method to http3ServerHandler to handle
this.
For #77440
Change-Id: Ib15b615f646fd08788981eb06f3a70606a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/761480
Reviewed-by: Nicholas Husin <husin@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
We have only seen the wrappersym case reported in the opposite order in
practice, but since these are intentionally racy, they could
theoretically all occur in the opposite order.
It would be nice to have a bit more structure to these tests so the test
itself could easily flip the order. However, since they are just regular
expressions, for now I've simply listed both orders.
Fixes#78394.
Change-Id: I92e04127f275c2394a12d63d2f2a3ce56a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/761161
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The noder will need to manipulate type argument lists. Because it is
outside types2, it needs exported APIs to do so, which then must also
be reflected in go/types.
We don't want APIs which only the noder cares about to be surfaced so
broadly. It might be better for the noder to use its own
representation for type lists; a []Type is fine for now.
Change-Id: Ia0917a6d26e00218fc9ccfd443d8d07224b1db5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/760360
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The isGenericMethod helper will be necessary for upcoming changes
to UIR, though it's not currently used.
Since all generic methods are concrete methods, we also define the
isConcreteMethod helper to illustrate the subset relationship
between the two classes of methods. We use this helper for encoding
method dictionaries.
Change-Id: Ib7cdd7224fc733553726c8f86c0fe59ad60bff67
Reviewed-on: https://go-review.googlesource.com/c/go/+/759781
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
The memProfCycle struct holds allocation counts and bytes allocated, and
frees and bytes freed. But the memory profile records are already
aggregated by allocation size, which is stored in the "size" field of
the bucket struct. We can derive the bytes allocated/freed using the
counts and the size we already store. Thus we can delete the bytes
fields from memProfCycle, saving 64 bytes per memRecord.
We can do something similar for the profilerecord.MemProfileRecord type.
We just need to know the object size and we can derive the allocated and
freed bytes accordingly.
Change-Id: I103885c2f29471b25283e330674fc16d6a6a6964
Reviewed-on: https://go-review.googlesource.com/c/go/+/760140
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
There is no need to cross build a Mach-O binary in order to test
this. Only run it on Mach-O platforms. Also just do native build
instead of forcing GOARCH=amd64.
For #78266.
Change-Id: I7603ba9a51ea4f13411fdb4e159709f981ee755d
Reviewed-on: https://go-review.googlesource.com/c/go/+/759260
TryBot-Bypass: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
