Michael Pratt [Fri, 30 May 2025 21:05:41 +0000 (17:05 -0400)]
runtime: acquire/release C TSAN lock when calling cgo symbolizer/tracebacker
When calling into C via cmd/cgo, the generated code calls
_cgo_tsan_acquire / _cgo_tsan_release around the C call to report a
dummy lock to the C/C++ TSAN runtime. This is necessary because the
C/C++ TSAN runtime does not understand synchronization within Go and
would otherwise report false positive race reports. See the comment in
cmd/cgo/out.go for more details.
Various C functions in runtime/cgo also contain manual calls to
_cgo_tsan_acquire/release where necessary to suppress race reports.
However, the cgo symbolizer and cgo traceback functions called from
callCgoSymbolizer and cgoContextPCs, respectively, do not have any
instrumentation [1]. They call directly into user C functions with no
TSAN instrumentation.
This means they have an opportunity to report false race conditions. The
most direct way is via their argument. Both are passed a pointer to a
struct stored on the Go stack, and both write to fields of the struct.
If two calls are passed the same pointer from different threads, the C
TSAN runtime will think this is a race.
This is simple to achieve for the cgo symbolizer function, which the
new regression test does. callCgoSymbolizer is called on the standard
goroutine stack, so the argument is a pointer into the goroutine stack.
If the goroutine moves Ms between two calls, it will look like a race.
On the other hand, cgoContextPCs is called on the system stack. Each M
has a unique system stack, so for it to pass the same argument pointer
on different threads would require the first M to exit, free its stack,
and the same region of address space to be used as the stack for a new
M. Theoretically possible, but quite unlikely.
Both of these are addressed by providing a C wrapper in runtime/cgo that
calls _cgo_tsan_acquire/_cgo_tsan_release around calls to the symbolizer
and traceback functions.
There is a lot of room for future cleanup here. Most runtime/cgo
functions have manual instrumentation in their C implementation. That
could be removed in favor of instrumentation in the runtime. We could
even theoretically remove the instrumentation from cmd/cgo and move it
to cgocall. None of these are necessary, but may make things more
consistent and easier to follow.
[1] Note that the cgo traceback function called from the signal handler
via x_cgo_callers _does_ have manual instrumentation.
Fixes #73949.
Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64,gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Change-Id: I6a6a636c9daa38f7fd00694af76b75cb93ba1886
Reviewed-on: https://go-review.googlesource.com/c/go/+/677955 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Alan Donovan [Thu, 25 Sep 2025 16:41:08 +0000 (12:41 -0400)]
cmd/fix: remove all functionality
The buildtag fixer has been incorporated into the vet analyzer
of the same name; all other fixers were already no-ops since
CL 695855.
Fixes #73605
Updates #71859
Change-Id: I90b6c730849a5ecbac3e6fb6fc0e062b5de74831
Reviewed-on: https://go-review.googlesource.com/c/go/+/706758 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Cherry Mui [Tue, 16 Sep 2025 17:34:19 +0000 (13:34 -0400)]
cmd/link: handle -w flag in external linking mode
Currently, when the -w flag is set, it doesn't actually disable
the debug info generation with in external linking mode. (It does
make the Go object have no debug info, but C objects may still
have.) Pass "-Wl,-S" to let the external linker disable debug info
generation.
Change-Id: I0fce56b9f23a45546b69b9e6dd027c5527b1bc87
Reviewed-on: https://go-review.googlesource.com/c/go/+/705857 Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joel Sing [Tue, 9 Sep 2025 15:00:22 +0000 (01:00 +1000)]
cmd/internal/obj/riscv: remove ACFLWSP/ACFSWSP and ACFLW/ACFSW
These are RV32-only instructions that will not be implemented.
Updates #71105
Change-Id: Ie386fe36e56f1151bb8756088dd79804584317c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/702395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
image/jpeg: replace fdct.go and idct.go with new implementation in dct.go
The fdct.go and idct.go files were derived from the MPEG-SSG and
JPEG-IJG reference code and therefore carry licenses specific to those
groups. Various license checkers flag these files as potentially
problematic. The code is also not terribly well documented.
This CL fixes the license problem by adding a new, from-scratch
implementation using a different algorithm. As a bonus, the new code
is both faster and more accurate than the old encumbered code.
On speed, the new code is up to 20% faster; benchmarks below.
On accuracy, in the set of blocks used in the test, we can measure
the number of output values that are off-by-one from the exact rounded answer.
The old FDCT was off in 8.6% of values; the new one is off in 2.5%.
The old IDCT was off in 1.4% of values; the new one is off in 1.2%.
goos: darwin
goarch: arm64
pkg: image/jpeg
cpu: Apple M3 Pro
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-12 619.6n ± 3% 586.5n ± 1% -5.34% (p=0.000 n=10)
IDCT-12 752.4n ± 4% 628.0n ± 1% -16.54% (p=0.000 n=10)
goos: linux
goarch: amd64
cpu: Intel(R) Xeon(R) CPU @ 2.30GHz
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-16 1.817µ ± 0% 1.542µ ± 0% -15.11% (p=0.000 n=10)
IDCT-16 1.897µ ± 0% 1.514µ ± 0% -20.22% (p=0.000 n=10)
goos: linux
goarch: arm64
cpu: whatever gotip-linux-arm64 has
│ old │ new │
│ sec/op │ sec/op vs base │
FDCT-8 1.844µ ± 0% 1.847µ ± 0% +0.14% (p=0.000 n=10)
IDCT-8 2.127µ ± 0% 1.973µ ± 0% -7.26% (p=0.000 n=10)
Change-Id: Ie6d14103c8478ba5a779f234da84f345828eb925
Reviewed-on: https://go-review.googlesource.com/c/go/+/705518
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Nigel Tao <nigeltao@google.com>
image/jpeg: correct and test reference slowFDCT and slowIDCT
The reference implementations slowFDCT and slowIDCT were not
rounding correctly, making the test not as good as it could be.
Before, the real implementations were required to always produce
values within ±2 of the reference; now, with no changes,
the real implementations produce values within ±1 of the (corrected)
reference.
Also tighten the test to return an error not just on a single value
exceeding tolerance but also on too many values at exactly that
tolerance.
Change-Id: I3dd6ca7582178fef972fb812d848f7a0158a6ed8
Reviewed-on: https://go-review.googlesource.com/c/go/+/705517
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Keith Randall [Tue, 23 Sep 2025 23:31:26 +0000 (16:31 -0700)]
cmd/compile: don't rely on loop info when there are irreducible loops
Loop information is sketchy when there are irreducible loops.
Sometimes blocks inside 2 loops can be recorded as only being part of
the outer loop. That causes tighten to move values that want to move
into such a block to move out of the loop altogether, breaking the
invariant that operations have to be scheduled after their args.
Fixes #75569
Change-Id: Idd80e6d2268094b8ae6387563081fdc1e211856a
Reviewed-on: https://go-review.googlesource.com/c/go/+/706355 Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
Michael Matloob [Mon, 17 Mar 2025 15:45:52 +0000 (11:45 -0400)]
runtime: add specialized malloc functions for sizes up to 512 bytes
This CL adds a generator function in runtime/_mkmalloc to generate
specialized mallocgc functions for sizes up throuht 512 bytes. (That's
the limit where it's possible to end up in the no header case when there
are scan bits, and where the benefits of the specialized functions
significantly diminish according to microbenchmarks). If the
specializedmalloc GOEXPERIMENT is turned on, mallocgc will call one of
these functions in the no header case.
malloc_generated.go is the generated file containing the specialized
malloc functions.
malloc_stubs.go contains the templates that will be stamped to create
the specialized malloc functions.
malloc_tables_generated contains the tables that mallocgc will use to
select the specialized function to call.
I've had to update the two stdlib_test.go files to account for the new
submodule mkmalloc is in. mprof_test accounts for the changes in the
stacks since different functions can be called in some cases.
I still need to investigate heapsampling.go.
Change-Id: Ia0f68dccdf1c6a200554ae88657cf4d686ace819
Reviewed-on: https://go-review.googlesource.com/c/go/+/665835 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Fri, 15 Aug 2025 17:09:05 +0000 (17:09 +0000)]
runtime: eliminate global span queue [green tea]
This change removes the locked global span queue and replaces the
fixed-size local span queue with a variable-sized local span queue. The
variable-sized local span queue grows as needed to accomodate local
work. With no global span queue either, GC workers balance work amongst
themselves by stealing from each other.
The new variable-sized local span queues are inspired by the P-local
deque underlying sync.Pool. Unlike the sync.Pool deque, however, both
the owning P and stealing Ps take spans from the tail, making this
incarnation a strict queue, not a deque. This is intentional, since we
want a queue-like order to encourage objects to accumulate on each span.
These variable-sized local span queues are crucial to mark termination,
just like the global span queue was. To avoid hitting the ragged barrier
too often, we must check whether any Ps have any spans on their
variable-sized local span queues. We maintain a per-P atomic bitmask
(another pMask) that contains this state. We can also use this to speed
up stealing by skipping Ps that don't have any local spans.
The variable-sized local span queues are slower than the old fixed-size
local span queues because of the additional indirection, so this change
adds a non-atomic local fixed-size queue. This risks getting work stuck
on it, so, similarly to how workbufs work, each worker will occasionally
dump some spans onto its local variable-sized queue. This scales much
more nicely than dumping to a global queue, but is still visible to all
other Ps.
For #73581.
Change-Id: I814f54d9c3cc7fa7896167746e9823f50943ac22
Reviewed-on: https://go-review.googlesource.com/c/go/+/700496 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Alan Donovan [Thu, 18 Sep 2025 18:04:43 +0000 (14:04 -0400)]
cmd/compile/internal: support new(expr)
This CL adds compiler support for new(expr),
a feature of go1.26 that allows the user to specify
the initial value of the variable instead of its
type.
Also, a basic test of dynamic behavior.
See CL 704737 for spec change and CL 704935 for
type-checker changes.
For #45624
Change-Id: I65d27de1ee3aabb819b57cce8ea77f3073447757
Reviewed-on: https://go-review.googlesource.com/c/go/+/705157 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Mateusz Poliwczak <mpoliwczak34@gmail.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
cmd/cgo: don't hardcode section name in TestNumberOfExportedFunctions
TestNumberOfExportedFunctions checks the number of exported functions
announced in the PE export table, getting it from the .edata section.
If the section is not found, the test is skipped. However, the PE spec
doesn't mandate that the export table be in a section named .edata,
making this test prone to being skipped unnecessarily.
While here, remove a check in cmd/go.testBuildmodePIE that was testing
the same thing in order to verify that the binary had a relocation table
. Not only the test is duplicated, but also it in unnecessary because
it already testing that the PE characteristics doesn't contain the
IMAGE_FILE_RELOCS_STRIPPED flag.
Closes #46719
Cq-Include-Trybots: luci.golang.try:gotip-windows-arm64
Change-Id: I28d1e261b38388868dd3c19ef6ddddad7bf105ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/705755 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
cmd/compile: prevent shapifying of pointer shape type
CL 641955 changes the Unified IR reader to not doing shapify when
reading reshaping expression, prevent losing of the original type.
This is an oversight, as the main problem isn't about shaping during the
reshaping process itself, but about the specific case of shaping a
pointer shape type. This bug occurs when instantiating a generic
function within another generic function with a pointer shape type as
type parameter, which will convert `*[]go.shape.T` to `*go.shape.uint8`,
resulting in the loss of the original expression's type.
This commit changes Unified IR reader to avoid pointer shaping for
`*[]go.shape.T`, ensures that the original type is preserved when
processing reshaping expressions.
runtime/cgo: retry when CreateThread fails with ERROR_ACCESS_DENIED
_cgo_beginthread used to retry _beginthread only when it failed with
EACCESS, but CL 651995 switched to CreateThread and incorrectly mapped
EACCESS to ERROR_NOT_ENOUGH_MEMORY. The correct mapping is
ERROR_ACCESS_DENIED.
Fixes #72814
Fixes #75381
Change-Id: I8ba060114aae4e8249576f11a21eff613caa8001
Reviewed-on: https://go-review.googlesource.com/c/go/+/706075 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Anthony Knyszek [Fri, 5 Sep 2025 17:39:09 +0000 (17:39 +0000)]
runtime: split gcMarkWorkAvailable into two separate conditions
Right now, gcMarkWorkAvailable is used in two scenarios. The first is
critical: we use it to determine whether we're approaching mark
termination, and it's crucial to reaching a fixed point across the
ragged barrier in gcMarkDone. The second is a heuristic: should we spin
up another GC worker?
This change splits gcMarkWorkAvailable into these two separate
conditions. This change also deduplicates the logic for updating
work.nwait into more abstract helpers "gcBeginWork" and "gcEndWork."
This change is solely refactoring, and should be a no-op. There are only
two functional changes:
- work.nwait is incremented after setting pp.gcMarkWorkerMode in the
background worker code. I don't believe this change is observable
except if the code fails to update work.nwait (either it results in a
non-sensical number, or the stack is corrupted) in which case the
goroutine may not be labeled as a mark worker in the resulting stack
trace (it should be obvious from the stack frames though).
- endCheckmarks also checks work.nwait == work.nproc, which should be
fine since we never mutate work.nwait on that path. That extra check
should be a no-op.
Splitting these two use-cases for gcMarkWorkAvailable is conceptually
helpful, and the checks may also diverge from Green Tea once we get rid
of the global span queue.
Change-Id: I0bec244a14ee82919c4deb7c1575589c0dca1089
Reviewed-on: https://go-review.googlesource.com/c/go/+/701176 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Cherry Mui [Tue, 16 Sep 2025 02:50:51 +0000 (22:50 -0400)]
cmd/link: make -w behavior consistent on Windows
On UNIX-like platforms, the -w flag disables DWARF, and the -s
flag implies -w (so it disables both the symbol table and DWARF).
The implied -w can be negated with -w=0, i.e. -s -w=0 disables the
symbol table but keeps the DWARF. Currently, this negation doesn't
work on Windows. This CL makes it so, so it is consistent on all
platforms (that support DWARF).
Change-Id: I19764a15768433afe333b37061cea16f06cb901b
Reviewed-on: https://go-review.googlesource.com/c/go/+/703998 Reviewed-by: Than McIntosh <thanm@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Michael Anthony Knyszek [Mon, 22 Sep 2025 17:36:03 +0000 (17:36 +0000)]
runtime: don't re-read metrics before check in TestReadMetricsSched
The two remaining popular flakes in TestReadMetricsSched are with
waiting and not-in-go goroutines. I believe the reason for both of these
is pollution due to other goroutines in the test binary, and we can be a
little bit more robust to them.
In particular, both of these tests spin until there's a particular
condition met in the metrics. Then they both immediately re-read the
metrics. The metrics being checked are not guaranteed to stay that way
in the re-read. For example, for the waiting case, it's possible for
>1000 to be waiting, but then some leftover goroutines from a previous
test wake up off of some condition, causing the number to dip again on
the re-read. This is supported by the fact that in some of these
failures, the test takes very little time to execute (the condition that
there are at least 1000 waiting goroutines is almost immediately
satisfied) but it still fails (the re-read causes us to notice that there
are <1000 waiting goroutines).
This change makes the test more robust by not performing this re-read.
This means more possible false negatives, but the error cases we're
looking for (bad metrics) should still show up with some reasonable
probability when something *is* truly wrong.
For #75049.
Change-Id: Idc3a8030bed8da51f24322efe15f3ff13da05623
Reviewed-on: https://go-review.googlesource.com/c/go/+/705875 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
cmd/cgo/internal/test: skip TestMultipleAssign when using UCRT on Windows
The Universal C Runtime (UCRT) default behavior is to crash the program
when strtol is called with an invalid base (that is, not 0 or 2..36).
This an invalid base (that is, not 0 or 2..36). This changes the test to
skip when running on Windows and linking with UCRT.
When using external linking mode this test passes if using the Mingw-w64
toolchain, even when linking with UCRT. That's because the Mingw-w64
linker adds a _set_invalid_parameter_handler call at startup that
overrides the default UCRT behavior. However, other toolchains, like
MSVC and LLVM, doesn't override the default behavior.
Overriding the default behavior is out of the scope for this test, so
the test is skipped instead.
Fixes #62887
Change-Id: I60f140faf0eda80a2de4e10876be25e0dbe442d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/705455 Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/dist: disable FIPS 140-3 mode when testing maphash with purego
hash/maphash can't be built with FIPS 140-3 mode and the purego tag
since CL 703095. That change precludes running "GODEBUG=fips140=on go
dist test" with, as there is a test variant that tests maphash with the
purego tag.
Change-Id: Iaedfaf3bb79281a799ef95283310c96d2e64207f
Reviewed-on: https://go-review.googlesource.com/c/go/+/705775
Auto-Submit: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Filippo Valsorda <filippo@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reason for revert: change was incorrect. ignores setting of CGO_ENABLED in some cases
Change-Id: I8e6e68dd600be5306a247a3314f4b57175f1aa56
Reviewed-on: https://go-review.googlesource.com/c/go/+/705495
Auto-Submit: Michael Matloob <matloob@google.com> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Ian Alexander <jitsu@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
time: improve ParseDuration performance for invalid input
Add "parseDurationError" to reduce memory allocation in the error path of
"ParseDuration" and delay the generation of error messages. This improves
the performance when dealing with invalid input.
The format of the error message remains unchanged.
Benchmarks:
│ old │ new │
│ sec/op │ sec/op vs base │
ParseDurationError-10 132.10n ± 4% 45.93n ± 2% -65.23% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
ParseDurationError-10 192.00 ± 0% 64.00 ± 0% -66.67% (p=0.000 n=10)
│ old │ new │
│ allocs/op │ allocs/op vs base │
ParseDurationError-10 6.000 ± 0% 2.000 ± 0% -66.67% (p=0.000 n=10)
Fixes #75521
Change-Id: I0dc9f28c9601b6be07b70d0a98613757d76e2c97
GitHub-Last-Rev: 737273936ad0cafd710fa58d99333416e71e657e
GitHub-Pull-Request: golang/go#75531
Reviewed-on: https://go-review.googlesource.com/c/go/+/705195 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Cherry Mui [Thu, 18 Sep 2025 17:59:41 +0000 (13:59 -0400)]
cmd/compile: duplicate nil check to two branches of write barrier
Currently, for a write of a pointer (e.g. *p = x where x is a
pointer), we generate an explicit nil check of p, despite that the
store instruction may have the same faulting behavior as the nil
check. This is because the write needs a write barrier, which
creates a control flow, which prevents the nil check being removed
as it is in a differnt block as the actual store.
This CL duplicates the nil check to two branches, so it is likely
that they will be followed by the actual store and the write
barrier load, which may have the same faulting behavior, so they
can be removed.
Change-Id: Ied9480de5dd6a8fcbd5affc5f6e029944943cc07
Reviewed-on: https://go-review.googlesource.com/c/go/+/705156 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>
Daniel Maslowski [Thu, 18 Sep 2025 15:43:42 +0000 (15:43 +0000)]
runtime: use futexes with 64-bit time on Linux
Linux introduced new syscalls to fix the year 2038 issue.
To still be able to use the old ones, the Kconfig option
COMPAT_32BIT_TIME would be necessary.
Use the new syscall with 64-bit values for futex by default.
Define _ENOSYS for detecting if it's not available.
Add a fallback to use the older syscall in case the new one is
not available, since Go runs on Linux from 2.6.32 on, per
https://go.dev/wiki/MinimumRequirements.
Updates #75133
Change-Id: I65daff0a3d06b55440ff05d8f5a9aa1c07eb201d
GitHub-Last-Rev: 96dd1bd84bd12d898e971157fc83da562cc4f6b4
GitHub-Pull-Request: golang/go#75306
Reviewed-on: https://go-review.googlesource.com/c/go/+/701615 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Kir Kolyshkin [Thu, 18 Sep 2025 01:00:10 +0000 (18:00 -0700)]
cmd/compile/internal/abi: use clear built-in
Replace for loop with clear, available since Go 1.21.
Change-Id: I949da08b2a11845cc8a02b2639af78835e316970
Reviewed-on: https://go-review.googlesource.com/c/go/+/704879
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Kir Kolyshkin [Thu, 18 Sep 2025 00:59:32 +0000 (17:59 -0700)]
bytes: use clear in test
Replace for loop with clear built-in, available since Go 1.21.
Change-Id: I66d0124b9004ffd0b52abb679ccff86bb600c1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/704878 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev>
Kir Kolyshkin [Thu, 18 Sep 2025 00:57:27 +0000 (17:57 -0700)]
crypto: use clear built-in
Replace for loops with clear built-in, available since Go 1.21.
Change-Id: I16a2691a68042e9c5cd9bc4197690fa541a081eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/704877 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Sean Liao <sean@liao.dev>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Loading and calling testHookCanceledDial in the function passed to
context.AfterFunc is racey, because the function runs in a separate
goroutine, and is not synchronized with the test code that restores
the original testHookCanceledDial value.
We could add a channel and wait for the "AfterFunc" to return in
the deferred function, but that's a lot of synchronization overhead
just for a bit of test code. Instead we simply load
testHookCanceledDial into a local variable synchronously. This fixes
the race without introducing any overhead.
Fixes #75474
Change-Id: If8fbd0f5f65375577c2ded64a13a15b406c45ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/704455 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Damien Neil [Mon, 15 Sep 2025 22:18:57 +0000 (15:18 -0700)]
net/http: avoid connCount underflow race
Remove a race condition in counting the number of connections per host,
which can cause a connCount underflow and a panic.
The race occurs when:
- A RoundTrip call attempts to use a HTTP/2 roundtripper (pconn.alt != nil)
and receives an isNoCachedConn error. The call removes the pconn from
the idle conn pool and decrements the connCount for its host.
- A second RoundTrip call on the same pconn succeeds,
and delivers the pconn to a third RoundTrip waiting for a conn.
- The third RoundTrip receives the pconn at the same moment its request
context is canceled. It places the pconn back into the idle conn pool.
At this time, the connCount is incorrect, because the conn returned to
the idle pool is not matched by an increment in the connCount.
Fix this by not adding HTTP/2 pconns back to the idle pool in
wantConn.cancel.
Fixes #61474
Change-Id: I104d6cf85a54d0382eebf3fcf5dda99c69a7c3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/703936
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Damien Neil [Thu, 18 Sep 2025 18:15:47 +0000 (11:15 -0700)]
context: don't return a non-nil from Err before Done is closed
The Context.Err documentation states that it returns nil if the
context's done channel is not closed. Fix a race condition introduced
by CL 653795 where Err could return a non-nil error slightly before
the Done channel is closed.
No impact on Err performance when returning nil.
Slows down Err when returning non-nil by about 3x,
but that's still almost 2x faster than before CL 653795
and the performance of this path is less important.
(A tight loop checking Err for doneness will be terminated
by the first Err call to return a non-nil result.)
goos: darwin
goarch: arm64
pkg: context
cpu: Apple M4 Pro
│ /tmp/bench.0 │ /tmp/bench.1 │
│ sec/op │ sec/op vs base │
ErrOK-14 1.806n ± 1% 1.774n ± 0% -1.77% (p=0.000 n=8)
ErrCanceled-14 1.821n ± 1% 7.525n ± 3% +313.23% (p=0.000 n=8)
geomean 1.813n 3.654n +101.47%
Fixes #75533
Change-Id: Iea22781a199ace7e7f70cf65168c36e090cd2e2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/705235
TryBot-Bypass: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org>
Auto-Submit: Damien Neil <dneil@google.com>
Michael Pratt [Wed, 17 Sep 2025 17:25:03 +0000 (13:25 -0400)]
runtime: make explicit nil check in heapSetTypeSmallHeader
This is another case very similar to CL 684015 and #74375.
In spans with type headers, mallocgc always writes to the page before
returning the allocated memory. This initial write is done by
runtime.heapSetTypeSmallHeader. Prior to the write, the compiler inserts
a nil check, implemented as a dummy instruction reading from memory.
On a freshly mapped page, this read triggers a page fault, mapping the
zero page read-only. Immediately afterwards, the write triggers another
page fault, copying to a writeable page and performing a TLB flush.
This problem is exacerbated as the process scales up. At GOMAXPROCS=6,
the tile38 sweet benchmark spends around 0.1% of cycles directly
handling these page faults. On the same machine at GOMAXPROCS=192, it
spends about 2.7% of cycles directly handling these page faults.
Replacing the read with an explicit nil check reduces the direct cost of
these page faults down to around 0.1% at GOMAXPROCS=192. There are
additional positive side-effects due to reduced contention, so the
overall time spent in page faults drops from around 12.8% to 6.8%. Most
of the remaining time in page faults is spent on automatic NUMA page
migration (completely unrelated to this issue).
cmd/internal/obj/riscv: add support for Zicond instructions
This patch implement assembler for the Zicond extension: CZEROEQZ and CZERONEZ.
Follow-up to CL 631576
Updates #75350
Change-Id: Icf4be131fe61c3b7a3bde4811cf42dc807660907
GitHub-Last-Rev: 6539cc86cbf3c49c3247ed935bcbbb31bb886dea
GitHub-Pull-Request: golang/go#75408
Reviewed-on: https://go-review.googlesource.com/c/go/+/702677 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
TryBot-Bypass: Joel Sing <joel@sing.id.au>
Roland Shoemaker [Wed, 17 Sep 2025 21:10:11 +0000 (21:10 +0000)]
runtime: don't enable heap randomization if MSAN or ASAN is enabled
MSAN and ASAN do confusing things to the memory layout, which are likely
to conflict with heap base randomization, so if they are enabled,
ignore randomizedHeapBase64.
We already didn't turn it on when TSAN was enabled.
Change-Id: I41e59dfc33d8bb059c208a9595442571fb31eea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/704856
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
Roland Shoemaker [Wed, 17 Sep 2025 21:04:56 +0000 (21:04 +0000)]
runtime: fix CheckScavengedBitsCleared with randomized heap base
We cannot easily determine the base address of the arena we added the
random padding pages to, which can cause confusing
TestScavengedBitsCleared failures when the arena we padded does not have
the lowest address of all of the arenas.
Instead of attempting to determine the correct arena to ignore when
checking the scav and alloc bits, switch to just tolerating _one_ arena
having mismatches, which is expected when randomizedHeapBase64 is
enabled. Any other number of arenas having mismatches is likely a real
error.
Fixes #75502
Change-Id: Iacc445b2905824f9f71970c7abd33f187793cf39
Reviewed-on: https://go-review.googlesource.com/c/go/+/704855 Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Kir Kolyshkin [Wed, 3 Sep 2025 19:48:44 +0000 (12:48 -0700)]
path/filepath: fix EvalSymlinks to return ENOTDIR on plan9
CL 155597 added a test to check EvalSymlinks returns ENOTDIR
for existing path which ends with a slash.
CL 404954 added a separate evalSymlinks implementation for plan9,
which has a kludge to ensure the ENOTDIR is returned in the above case.
Apparently the added kludge is not working now (and maybe never worked),
as seen in [1]:
=== RUN TestIssue29372
path_test.go:1730: test#0: want "not a directory", got "stat /tmp/TestIssue293724085649913/001/file.txt/: not a directory: '/tmp/TestIssue293724085649913/001/file.txt/'"
--- FAIL: TestIssue29372 (0.00s)
This happens because on plan9 errors are strings and they contain the
file name after the error text, and the check assumes the "not a
directory" text is at the end of the message.
The fix is to check whether the error is somewhere in the error text,
not ends with it (as it is done in other plan9 code, for example, see
checkErrMessageContent added in CL 163058).
This should fix the above test failure.
PS perhaps the kludge should be moved up the call chain to os.Stat/Lstat?
[1]: https://ci.chromium.org/ui/p/golang/builders/try/gotip-plan9-amd64/b8704772617873749345/test-results?q=ExactID%3Apath%2Ffilepath.TestIssue29372+VHash%3Aa63f5798e9f8f502
Change-Id: I6afb68be5f65a28929b2f717247ab34ff3b4a812
Reviewed-on: https://go-review.googlesource.com/c/go/+/700775
Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Richard Miller <millerresearch@gmail.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
go/ast: document that (*ast.File).Comments is sorted by position
This is the way that go/parser produces it and in every AST manipulation
that we do, we preserve such property. Also printer expects it is such
order.
Change-Id: I6a6a696424a679a2cf1f9bb7eb41bdd47523efa9
Reviewed-on: https://go-review.googlesource.com/c/go/+/704255 Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
qmuntal [Tue, 13 May 2025 09:24:30 +0000 (11:24 +0200)]
cmd/link: simplify PE relocations mapping
The code for mapping Windows PE relocations to Go relocations was
difficult to follow and contains some duplicated code. Also, it was
mapping IMAGE_REL_AMD64_ADDR32 to R_PCREL instead of R_ADDR.
This CL commit simplifies the code and fixes the mapping. I haven't been
able to coerce mingw-w64 to generate IMAGE_REL_AMD64_ADDR32 relocations,
so I haven't been able to test this change. However, the previous
implementation was clearly wrong.
While here, remove code supporting the unsupported windows/arm support.
Updates #71671
Updates #75485
Change-Id: Id0d6f352fa7d5df9e00509fcdf09ca0cb91ca524
Reviewed-on: https://go-review.googlesource.com/c/go/+/672155 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Kir Kolyshkin [Thu, 11 Sep 2025 19:22:43 +0000 (12:22 -0700)]
os/user: align test file name and build tags
TestNegativeUid tests code in cgo_lookup_unix.go, so let's use
the very same go:build line for the test file, and rename
the test file accordingly.
Change-Id: Iee3dbc25aeb8a7659c734d97dde3e9c670e80fae
Reviewed-on: https://go-review.googlesource.com/c/go/+/702976
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/go: check pattern for utf8 validity before call regexp.MustCompile
Do not panic if the package path or the package version contains
invalid UTF-8 characters.
Fixes #75251
Change-Id: Ib787e74277cf814253857b911d378ea5e53d8824
Reviewed-on: https://go-review.googlesource.com/c/go/+/700815 Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Alexander <jitsu@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
cmd/go: disable cgo by default if CC unset and DefaultCC doesn't exist
CL 621995 disrupted the behavior
introduced by CL 450739, now restore it.
Fixes #75340
Change-Id: Icd1a0eb970876995f9446e0547ceb9e78990f6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/703555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Ian Alexander <jitsu@google.com> Reviewed-by: Sean Liao <sean@liao.dev>
Sean Liao [Sun, 14 Sep 2025 15:24:57 +0000 (16:24 +0100)]
bytes,strings: remove reference to non-existent SplitFunc
Fixes #75462
Updates #72841
Change-Id: Ie2cbbdb031578a3138ecc6e60c0025807f1990e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/703675
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Joel Sing [Fri, 12 Sep 2025 10:54:49 +0000 (20:54 +1000)]
cmd/internal/obj/riscv: improve handling of float point moves
Translate moves from an integer register to a floating point register, or
from a floating point register to an integer register, to the appropriate
move instruction (i.e. FMVXW/FMVWX/FMVXD/FMVDX).
Add support for MOVF with a constant - we previously added support for MOVD
but not for MOVF. Add special handling for 0.0, which we can translate to
a move from the zero register to a floating point register (leveraging the
above mentioned change).
Change-Id: If8df2f5610e69b4ec0af85efb884951024685f5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/703216 Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Oleksandr Redko [Fri, 18 Jul 2025 10:30:55 +0000 (13:30 +0300)]
crypto/x509/internal/macos: standardize package name
Rename "macOS" to "macos".
Change-Id: I33ca7afaa14c910a97a19ead518894fb4917662c
Reviewed-on: https://go-review.googlesource.com/c/go/+/688695 Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Roland Shoemaker <roland@golang.org>
cmd/link: remove support for windows/arm relocations
The windows/arm port is no longer supported. We can remove the
related code from cmd/link/internal/arm.
For #71671
Change-Id: I00de1231482cc2f28ec5fc9dc62e81f0ba3fe481
Reviewed-on: https://go-review.googlesource.com/c/go/+/703778
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
cmd/link: remove support for darwin/386 relocations
The darwin/386 port has been unsupported for years, but some
relocation handling specific to it has managed to survive till now.
Updates #37610
Change-Id: I27ae2ac5462c5f3ec219e9cb5dce6f83b037b816
Reviewed-on: https://go-review.googlesource.com/c/go/+/703777 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
https://github.com/riscv/riscv-opcodes/pull/361. After this pr was
merged, riscv-opcode can generate RVV segment load/store instructions
for Go. Implement vector segment load/store instuctions.
Change-Id: I154bb75be70c0a45e2279a75c67f68b5bb57c36e
Reviewed-on: https://go-review.googlesource.com/c/go/+/691695 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
cmd/asm: add double precision comparision testcases for riscv64
Change-Id: If8e03dfdb332a22ec9c6a0021d7e7955520f3ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/702136 Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Joel Sing <joel@sing.id.au> Reviewed-by: Michael Knyszek <mknyszek@google.com>
The various TestSehUnwind tests recently started to fail due an
unrelated refactor (in CL 698098) that made the stack frames to
not match the expected pattern. This CL updates the tests to
be more robust to such changes.
Fixes #75467
Change-Id: I7950332bb6ca54e4bf693d13e2490b3d9d901dde
Reviewed-on: https://go-review.googlesource.com/c/go/+/703779
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
In Go 1.25+, strings.SplitSeq offers better
performance. Here are the benchmark results comparing
strings.Split and strings.SplitSeq in a for-loop, with the
benchmark code located in src/strings/iter_test.go:
cmd/compile: combine doubling with shift on riscv64
Change-Id: I4bee2770fedf97e35b5a5b9187a8ba3c41f9ec2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/702697 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@google.com>
Michael Anthony Knyszek [Thu, 11 Sep 2025 23:50:00 +0000 (23:50 +0000)]
cmd/internal/testdir: re-enable default all codegen flag on linux-amd64
This was limited to just the mainline linux-amd64 builder, but we don't
use that name anymore. Use the LUCI name instead, gotip-linux-amd64.
Change-Id: Ib4377ad336c529512d9939ff9dce0ea242528b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/703136
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I823f2da9ebbdbef943cb37123d44a7ad2e6d708b
Reviewed-on: https://go-review.googlesource.com/c/go/+/703896 Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
Kir Kolyshkin [Thu, 11 Sep 2025 02:00:19 +0000 (19:00 -0700)]
os: add and use errProcessReleased
This error is already used in three places, so let's define it.
Change-Id: I73565d94aebcf3d5a278201d96839d82db85a2d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/702436
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Michael Pratt <mpratt@google.com>
Kir Kolyshkin [Wed, 3 Sep 2025 23:12:39 +0000 (16:12 -0700)]
internal/syscall/unix: add KernelVersionGE
There are a few places in the code which checks that the running kernel
is greater than or equal to x.y. The check takes a few lines and the
checking code is somewhat distracting.
Let's abstract this check into a simple function, KernelVersionGE,
and convert the users accordingly.
Add a test case (I'm not sure it has much value, can be dropped).
Change-Id: I8ec91dcc7452363361f95e46794701c0ae57d956
Reviewed-on: https://go-review.googlesource.com/c/go/+/700796
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
Cherry Mui [Fri, 12 Sep 2025 17:46:31 +0000 (13:46 -0400)]
cmd/link: support race mode with MSVC clang
I couldn't make --print-file-name work with -msvc clang. (The
library name is synchronization.lib, but even with that name it
still doesn't print the full path.) Assume it always
synchronization.lib.
Change-Id: I22e8f14824f7f7e96b71b913217b1f604f1e2da7
Reviewed-on: https://go-review.googlesource.com/c/go/+/703398 Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Florian Zenker <floriank@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
test/codegen: check zerobase for newobject on 0-sized types
This CL also adds riscv64 checks
Change-Id: I693e4e606f470615f6b49085592d6d5ca61473d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/703716 Reviewed-by: Pengcheng Wang <wangpengcheng.pp@bytedance.com>
Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
qmuntal [Tue, 26 Aug 2025 09:47:51 +0000 (11:47 +0200)]
runtime: deduplicate syscall assembly for darwin
The darwin port provides different syscall functions that only
differ on how they handle the errors, and they are all written
in assembly.
This duplication can be removed by factoring out the error handling
logic to arch-agnostic Go code and leaving the assembly functions
with the only reponsibility of making the syscall and mapping
parameters between ABIs.
Updates #51087
Cq-Include-Trybots: luci.golang.try:gotip-darwin-arm64-longtest,gotip-darwin-amd64-longtest
Change-Id: I9524377f3ef9c9a638412c7e87c8f46a33ee3453
Reviewed-on: https://go-review.googlesource.com/c/go/+/699135 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Mark Freeman <markfreeman@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
database64128 [Wed, 27 Aug 2025 09:38:13 +0000 (17:38 +0800)]
net: use context.AfterFunc in connect
This saves a goroutine when ctx can be but is not canceled during
the connect call.
The redundant fd.Close() call is removed, because the caller closes
the fd on error.
Change-Id: I124d7e480294a48ef74d5650d8ef0489bdfc64d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/699256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Sean Liao <sean@liao.dev> Reviewed-by: Mark Freeman <markfreeman@google.com>
Alan Donovan [Thu, 11 Sep 2025 15:02:03 +0000 (11:02 -0400)]
cmd/go/internal/work: copy vet tool's stdout to our stdout
The go command connects both the stdout and stderr files of
its child commands (cmd/compile, cmd/vet, etc) to the go
command's own stderr. If the child command is supposed to
produce structure output on stderr, as is the case for
go vet -json or go fix -diff, it will be merged with the
error stream, making it useless.
This change to the go vet <-> unitchecker protocol specifies
the name of a file into which the vet tool should write its
stdout. On success, the go command will then copy the entire
content of that file to its own stdout, under a lock.
This ensures that partial writes to stdout in case of failure,
concurrent writes to stdout by parallel vet tasks, or other
junk on stderr, cannot interfere with the integrity of the
go command's structure output on stdout.
CL 702835 is the corresponding change on the x/tools side.
For #75432
Change-Id: Ib4db25b6b0095d359152d7543bd9bf692551bbfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/702815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>