summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* cmd/asm: remove unsupported opcodes MOVNP and STLP for arm64HEADmastererifan012023-05-183-468/+442
| | | | | | | | | | | | | ARM64 doesn't have MOVNP/MOVNPW and STLP/STLPW instructions, which are currently useless instructions as well. This CL deletes them. At the same time this CL sorts the opcodes by name, which looks cleaner. Change-Id: I25cfb636b23356ba0a50cba527a8c85b3f7e2ee4 Reviewed-on: https://go-review.googlesource.com/c/go/+/495695 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Eric Fang <eric.fang@arm.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: enable more lenient type inference for untyped argumentsRobert Griesemer2023-05-184-4/+26
| | | | | | | | | | | | | | | | | This enables the implementation for proposal #58671, which is a likely accept. By enabling it early we get a bit extra soak time for this feature. The change can be reverted trivially, if need be. For #58671. Change-Id: Id6c27515e45ff79f4f1d2fc1706f3f672ccdd1ab Reviewed-on: https://go-review.googlesource.com/c/go/+/495955 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* doc/go1.21: document that -pgo=auto enabled by defaultCherry Mui2023-05-171-2/+7
| | | | | | | | | | Updates #58099. Change-Id: I95c0397add696f677c86ab7618482e07eb4e9fda Reviewed-on: https://go-review.googlesource.com/c/go/+/495477 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime/cgo: store M for C-created thread in pthread keyCherry Mui2023-05-1746-69/+1018
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reapplies CL 485500, with a fix drafted in CL 492987 incorporated. CL 485500 is reverted due to #60004 and #60007. #60004 is fixed in CL 492743. #60007 is fixed in CL 492987 (incorporated in this CL). [Original CL 485500 description] This reapplies CL 481061, with the followup fixes in CL 482975, CL 485315, and CL 485316 incorporated. CL 481061, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 482975 is a followup fix to a C declaration in testprogcgo. CL 485315 is a followup fix for x_cgo_getstackbound on Illumos. CL 485316 is a followup cleanup for ppc64 assembly. CL 479915 passed the G to _cgo_getstackbound for direct updates to gp.stack.lo. A G can be reused on a new thread after the previous thread exited. This could trigger the C TSAN race detector because it couldn't see the synchronization in Go (lockextra) preventing the same G from being used on multiple threads at the same time. We work around this by passing the address of a stack variable to _cgo_getstackbound rather than the G. The stack is generally unique per thread, so TSAN won't see the same address from multiple threads. Even if stacks are reused across threads by pthread, C TSAN should see the synchonization in the stack allocator. A regression test is added to misc/cgo/testsanitizer. [Original CL 481061 description] This reapplies CL 392854, with the followup fixes in CL 479255, CL 479915, and CL 481057 incorporated. CL 392854, by doujiang24 <doujiang24@gmail.com>, speed up C to Go calls by binding the M to the C thread. See below for its description. CL 479255 is a followup fix for a small bug in ARM assembly code. CL 479915 is another followup fix to address C to Go calls after the C code uses some stack, but that CL is also buggy. CL 481057, by Michael Knyszek, is a followup fix for a memory leak bug of CL 479915. [Original CL 392854 description] In a C thread, it's necessary to acquire an extra M by using needm while invoking a Go function from C. But, needm and dropm are heavy costs due to the signal-related syscalls. So, we change to not dropm while returning back to C, which means binding the extra M to the C thread until it exits, to avoid needm and dropm on each C to Go call. Instead, we only dropm while the C thread exits, so the extra M won't leak. When invoking a Go function from C: Allocate a pthread variable using pthread_key_create, only once per shared object, and register a thread-exit-time destructor. And store the g0 of the current m into the thread-specified value of the pthread key, only once per C thread, so that the destructor will put the extra M back onto the extra M list while the C thread exits. When returning back to C: Skip dropm in cgocallback, when the pthread variable has been created, so that the extra M will be reused the next time invoke a Go function from C. This is purely a performance optimization. The old version, in which needm & dropm happen on each cgo call, is still correct too, and we have to keep the old version on systems with cgo but without pthreads, like Windows. This optimization is significant, and the specific value depends on the OS system and CPU, but in general, it can be considered as 10x faster, for a simple Go function call from a C thread. For the newly added BenchmarkCGoInCThread, some benchmark results: 1. it's 28x faster, from 3395 ns/op to 121 ns/op, in darwin OS & Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz 2. it's 6.5x faster, from 1495 ns/op to 230 ns/op, in Linux OS & Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz [CL 479915 description] Currently, when C calls into Go the first time, we grab an M using needm, which sets m.g0's stack bounds using the SP. We don't know how big the stack is, so we simply assume 32K. Previously, when the Go function returns to C, we drop the M, and the next time C calls into Go, we put a new stack bound on the g0 based on the current SP. After CL 392854, we don't drop the M, and the next time C calls into Go, we reuse the same g0, without recomputing the stack bounds. If the C code uses quite a bit of stack space before calling into Go, the SP may be well below the 32K stack bound we assumed, so the runtime thinks the g0 stack overflows. This CL makes needm get a more accurate stack bound from pthread. (In some platforms this may still be a guess as we don't know exactly where we are in the C stack), but it is probably better than simply assuming 32K. [CL 492987 description] On the first call into Go from a C thread, currently we set the g0 stack's high bound imprecisely based on the SP. With CL 485500, we keep the M and don't recompute the stack bounds when it calls into Go again. If the first call is made when the C thread uses some deep stack, but a subsequent call is made with a shallower stack, the SP may be above g0.stack.hi. This is usually okay as we don't check usually stack.hi. One place where we do check for stack.hi is in the signal handler, in adjustSignalStack. In particular, C TSAN delivers signals on the g0 stack (instead of the usual signal stack). If the SP is above g0.stack.hi, we don't see it is on the g0 stack, and throws. This CL makes it get an accurate stack upper bound with the pthread API (on the platforms where it is available). Also add some debug print for the "handler not on signal stack" throw. Fixes #51676. Fixes #59294. Fixes #59678. Fixes #60007. Change-Id: Ie51c8e81ade34ec81d69fd7bce1fe0039a470776 Reviewed-on: https://go-review.googlesource.com/c/go/+/495855 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
* cmd/gofmt: try to write original data on rewrite failureIan Lance Taylor2023-05-172-26/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When gofmt needs to rewrite a file, it first copies it into a backup. If the rewrite fails, it used to rename the backup to the original. However, if for some reason the file is owned by some other user, and if the rewrite fails because gofmt doesn't have permission to write to the file, then renaming the backup file will change the file owner. This CL changes gofmt so that if it fails to rewrite a file, it tries to write the original contents. If writing the original content fails, it reports the problem to the user referring to the backup file, rather than trying a rename. Also create the backup file with the correct permissions, to avoid a tiny gap when some process might get write access to the file contents that it shouldn't have. (This tiny gap only applies to files that are not formatted correctly, and have read-only permission, and are in a directory with write permission.) Fixes #60225 Change-Id: Ic16dd0c85cf416d6b2345e0650d5e64413360847 Reviewed-on: https://go-review.googlesource.com/c/go/+/495316 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
* cmd/compile: build compiler with PGOCherry Mui2023-05-173-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapplies CL 451292, which is reverted at CL 495475. The failure is fixed at CL 495595. Build the compiler with PGO. As go build -pgo=auto is enabled by default, we just need to store a profile in the compiler's directory. The profile is collected from building all std and cmd packages on Linux/AMD64 machine, using profile.sh. This improves the compiler speed. On Linux/AMD64, name old time/op new time/op delta Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39) Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39) GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39) Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40) SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40) Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40) GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40) Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39) Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39) XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40) [Geo mean] 253ms 248ms -2.13% The profile is pretty transferable. Using the same profile, we see a bigger win on Darwin/ARM64, name old time/op new time/op delta Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20) Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20) GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20) Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20) SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20) Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20) GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19) Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19) Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20) XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20) [Geo mean] 127ms 121ms -4.73% Change-Id: Ifbe35e48b3ea3b29430249b4667d2df8a2515aeb Reviewed-on: https://go-review.googlesource.com/c/go/+/495596 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
* os: if descriptor is non-blocking, retain that in Fd methodIan Lance Taylor2023-05-176-5/+78
| | | | | | | | | | | | | | For #58408 Fixes #60211 Change-Id: I30f5678b46e15121865b19d1c0f82698493fad4e Reviewed-on: https://go-review.googlesource.com/c/go/+/495079 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
* crypto/x509: fix certificate validation with FQDN on WindowsPatryk Chelmecki2023-05-173-1/+24
| | | | | | | | | | | | | | | | | | Currently certificate verification on Windows fails if the provided dns name ends with a dot (which means it is a Fully Qualified Domain Name). The certificates according to RFC 6066 (https://www.rfc-editor.org/rfc/rfc6066#section-3) do not contain that ending dot. Go uses CertVerifyCertificateChainPolicy Windows system call with CERT_CHAIN_POLICY_SSL option for verification of the certificates. That call fails if the specified domain name contains the dot at the end. Examples of other open source codebases that use the same system call and trim the trailing dot before executing it: MongoDb - https://github.com/mongodb/mongo/blob/master/src/mongo/util/net/ssl_manager_windows.cpp#L1777 Dot Net - https://github.com/dotnet/runtime/blob/v7.0.5/src/libraries/System.Net.Security/src/System/Net/Security/SslAuthenticationOptions.cs#L52 Change-Id: I5db558eb277cf00f5401ec0ffc96c935023ad100 GitHub-Last-Rev: cc69ab9be35f79a93279bd618912a3fd6aaa9f88 GitHub-Pull-Request: golang/go#59846 Reviewed-on: https://go-review.googlesource.com/c/go/+/489135 Run-TryBot: Roland Shoemaker <roland@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Patryk Chełmecki <patchelmecki@google.com> Auto-Submit: Roland Shoemaker <roland@golang.org>
* runtime: publish netpoll info after incrementing fdseqIan Lance Taylor2023-05-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | I think there is a theoretical possibility of a mistake before this CL. pollCache.free would increment fdseq, but would not update atomicInfo. The epoll code could compare to fdseq before the increment, but suspend before calling setEventErr. The pollCache could get reallocated, and pollOpen could clear eventErr. Then the setEventErr could continue and set it again. Then pollOpen could call publishInfo. Avoid this rather remote possibility by calling publishInfo after incrementing fdseq. That ensures that delayed setEventErr will not modify the eventErr flag. Fixes #60133 Change-Id: I69e336535312544690821c9fd53f3023ff15b80c Reviewed-on: https://go-review.googlesource.com/c/go/+/495297 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
* cmd/link, internal/abi: minor follow-up cleanupsDavid Chase2023-05-172-4/+4
| | | | | | | | | | | | these address comments on CLs in the large refactoring stack recently submitted. Change-Id: Ic9023c32aafe4dda953b42c9a36834d3ab3432eb Reviewed-on: https://go-review.googlesource.com/c/go/+/495835 Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
* cmd/dist: add -json flagAustin Clements2023-05-173-14/+344
| | | | | | | | | | | | | | | | | | | This enables JSON output for all tests run by dist. Most the complexity here is that, in order to disambiguate JSON records from different package variants, we have to rewrite the JSON stream on the fly to include variant information. We do this by rewriting the Package field to be pkg:variant so existing CI systems will naturally pick up the disambiguated test name. Fixes #37486. Change-Id: I0094e5e27b3a02ffc108534b8258c699ed8c3b87 Reviewed-on: https://go-review.googlesource.com/c/go/+/494958 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* cmd/dist: refactor rtPreFunc to print skips in only one placeAustin Clements2023-05-171-21/+22
| | | | | | | | | | | | | | | | | Currently, all uses of rtPreFunc are to print a message and skip a test. When we move to JSON, the logic to just "print a message" is going to be more complicated, so refactor this so the function returns the skip message and we print it in just one place. We also rename the option to rtSkipFunc to better represent what we use it for. For #37486. Change-Id: Ibd537064fa646a956a1c0f85a5d8c6febd098dde Reviewed-on: https://go-review.googlesource.com/c/go/+/495856 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* cmd/dist: make it possible to filter output of background commandsAustin Clements2023-05-171-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | Many of the commands dist test executes are "background" commands run by a work queue system. The work queue allows it to run commands in parallel, but still serialize their output. Currently, the work queue system assumes that exec.Cmd.Stdout and Stderr will be nil and that it can take complete control over them. We're about to inject output filters on many of these commands, so we need a way to interpose on Stdout and Stderr. This CL rearranges responsibilities in the work queue system to make that possible. Now, the thing enqueuing the work item is responsible to constructing the Cmd to write its output to work.out. There's only one place that constructs work objects (there used to be many more), so that's relatively easy, and sets us up to add filters. For #37486. Change-Id: I55ab71ddd456a12fdbf676bb49f698fc08a5689b Reviewed-on: https://go-review.googlesource.com/c/go/+/494957 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* cmd/dist: simplify work list functionsAustin Clements2023-05-171-27/+6
| | | | | | | | | | | | | | | | | There are no uses of addCmd, so delete it. The only use of bgDirCmd is dirCmd, so inline it. Now the only function that interacts with the work queue is registerTest and dist's "background commands" are used exclusively in goTest.bgCommand and registerTest (which calls goTest.bgCommand). For #37486. Change-Id: Iebbb24cf9dbee45f3975fe9504d858493e1cd947 Reviewed-on: https://go-review.googlesource.com/c/go/+/494956 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* cmd: update vendored golang.org/x/modDmitri Shuralyov2023-05-175-5/+63
| | | | | | | | | | | | | | | | | | | | Pull in CL 492990. This teaches 'go mod tidy' and other go subcommands that write go.mod files to use semantic sort for exclude blocks, gated on said files declaring Go version 1.21 or higher. go get golang.org/x/mod@e7bea8f1d64f # includes CL 492990 go mod tidy go mod vendor Fixes #60028. Change-Id: Ia9342dcc23cd68de068a70657b59c25f69afa381 Reviewed-on: https://go-review.googlesource.com/c/go/+/494578 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
* doc/go1.21: document wasip1 portCherry Mui2023-05-171-1/+14
| | | | | | | | | | | Updates #58141. Change-Id: Iad11e7880efb37e9a1e17daf48d36b886725f75d Reviewed-on: https://go-review.googlesource.com/c/go/+/495476 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Eli Bendersky <eliben@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* encoding/xml: wrap charsetReader errorsThuy Linh Luu2023-05-171-1/+4
| | | | | | | | | | | | | | | | | This change wraps the errors from the CharsetReader function so the caller can distinguish different error conditions. Context: I have an XML file with an unknown encoding which I like to handle separately. I like to use the CharsetReader for this but the error type has not been forwarded. Change-Id: I6739a0dee04ec376cd20536be2806ce7f50c5213 GitHub-Last-Rev: ada9dd510f9a5b7f8c9473f6864077e0ed6898bd GitHub-Pull-Request: golang/go#60199 Reviewed-on: https://go-review.googlesource.com/c/go/+/494897 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org>
* runtime: replace sysBlockTraced with tracedSyscallEnterMichael Anthony Knyszek2023-05-172-9/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sysBlockTraced is a subtle and confusing flag. Currently, it's only used in one place: a condition around whether to traceGoSysExit when a goroutine is about to start running. That condition looks like "gp.syscallsp != 0 && gp.trace.sysBlockTraced". In every case but one, "gp.syscallsp != 0" is equivalent to "gp.trace.sysBlockTraced." That one case is where a goroutine is running without a P and racing with trace start (world is stopped). It switches itself back to _Grunnable from _Gsyscall before the trace start goroutine notices, such that the trace start goroutine fails to emit a EvGoInSyscall event for it (EvGoInSyscall or EvGoSysBlock must precede any EvGoSysExit event). sysBlockTraced is set unconditionally on every syscall entry and the trace start goroutine clears it if there was no EvGoInSyscall event emitted (i.e. did not observe _Gsyscall on the goroutine). That way when the goroutine-without-a-P wakes up and gets scheduled, it only emits EvGoSysExit if the flag is set, i.e. trace start didn't _clear_ the flag. What makes this confusing is the fact that the flag is set unconditionally and the code relies on it being *cleared*. Really, all it's trying to communicate is whether the tracer is aware of a goroutine's syscall at the point where a goroutine that lost its P during a syscall is trying to run again. Therefore, we can replace this flag with a less subtle one: tracedSyscallEnter. It is set when GoSysCall is traced, indicating on the goroutine that the tracer is aware of the syscall. Later, if traceGoSysExit is called, the tracer knows its safe to emit an event because the tracer is aware of the syscall. This flag is then also set at trace start, when it emits EvGoInSyscall, which again, lets the goroutine know the tracer is aware of its syscall. The flag is cleared by GoSysExit to indicate that the tracer is no longer aware of any syscalls on the goroutine. It's also cleared by trace start. This is necessary because a syscall may have been started while a trace was stopping. If the GoSysExit isn't emitted (because it races with the trace end STW) then the flag will be left set at the start of the next trace period, which will result in an erroneous GoSysExit. Instead, the flag is cleared in the same way sysBlockTraced is today: if the tracer doesn't notice the goroutine is in a syscall, it makes that explicit to the goroutine. A more direct flag to use here would be one that explicitly indicates whether EvGoInSyscall or EvGoSysBlock specifically were already emitted for a goroutine. The reason why we don't just do this is because setting the flag when EvGoSysBlock is emitted would be racy: EvGoSysBlock is emitted by whatever thread is stealing the P out from under the syscalling goroutine, so it would need to synchronize with the goroutine its emitting the event for. The end result of all this is that the new flag can be managed entirely within trace.go, hiding another implementation detail about the tracer. Tested with `stress ./trace.test -test.run="TestTraceStressStartStop"` which was occasionally failing before the CL in which sysBlockTraced was added (CL 9132). I also confirmed also that this test is still sensitive to `EvGoSysExit` by removing the one use of sysBlockTraced. The result is about a 5% error rate. If there is something very subtly wrong about how this CL emits `EvGoSysExit`, I would expect to see it as a test failure. Instead: 53m55s: 200434 runs so far, 0 failures Change-Id: If1d24ee6b6926eec7e90cdb66039a5abac819d9b Reviewed-on: https://go-review.googlesource.com/c/go/+/494715 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
* runtime: hide sysExitTicks a little betterMichael Anthony Knyszek2023-05-172-9/+10
| | | | | | | | | | | Just another step to hiding implementation details. Change-Id: I71b7cc522d18c23f03a9bf32e428279e62b39a89 Reviewed-on: https://go-review.googlesource.com/c/go/+/494192 Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
* cmd/compile: don't inline from norace packages in race modeCherry Mui2023-05-172-1/+26
| | | | | | | | | | | | | | | | | | | In race mode (or other instrumentation mode), if the caller is in a regular package and the callee is in a norace (or noinstrument) package, don't inline. Otherwise, when the caller is instumented it will also affect the inlined callee. An example is sync.(*Mutex).Unlock, which is typically not inlined but with PGO it can be inlined into a regular function, which is then get instrumented. But the rest of the sync package, in particular, the Lock function is not instrumented, causing the race detector to signal false race. Change-Id: Ia78bb602c6da63a34ec2909b9a82646bf20873f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/495595 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* crypto/ed25519,crypto/rsa: make Equal methods constant timeFilippo Valsorda2023-05-172-5/+12
| | | | | | | | | | | | | Fixes #53849 Updates #57752 Change-Id: I055564f31a47c79565b82bf9844fcf626989b295 Reviewed-on: https://go-review.googlesource.com/c/go/+/492955 Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime: capture per-p trace state in a typeMichael Anthony Knyszek2023-05-173-25/+31
| | | | | | | | | | | More tightening up of the tracer's interface. Change-Id: I992141c7f30e5c2d5d77d1fcd6817d35bc6e5f6d Reviewed-on: https://go-review.googlesource.com/c/go/+/494191 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime: capture per-m trace state in a typeMichael Anthony Knyszek2023-05-172-10/+19
| | | | | | | | | | | | | | More tightening up of the tracer's interface. While we're here, clarify why waittraceskip isn't included by explaining what the wait* fields in the M are really for. Change-Id: I0e7b4cac79fb77a7a0b3ca6b6cc267668e3610bc Reviewed-on: https://go-review.googlesource.com/c/go/+/494190 Auto-Submit: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* runtime: capture per-g trace state in a typeMichael Anthony Knyszek2023-05-174-58/+65
| | | | | | | | | | | | | | | More tightening up of the tracer's interface. This increases the size of each G very slightly, which isn't great, but we stay within the same size class, so actually memory use will be unchanged. Change-Id: I7d1f5798edcf437c212beb1e1a2619eab833aafb Reviewed-on: https://go-review.googlesource.com/c/go/+/494188 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com>
* hash/maphash: weaken avalanche test a bitKeith Randall2023-05-172-2/+2
| | | | | | | | | | | | | | | | | Give the test a bit more wiggle room. Previously the allowed range was about 46.5% to 53.5%. Now it is about 43% TO 57%. Fixes #60170 Change-Id: Ieda471e0986c52edb9f6d31beb8e41917876d6c5 Reviewed-on: https://go-review.googlesource.com/c/go/+/495415 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org>
* runtime: factor our oneNewExtraM trace codeMichael Anthony Knyszek2023-05-172-6/+14
| | | | | | | | | | | | In the interest of further cleaning up the trace.go API, move the trace logic in oneNewExtraM into its own function. Change-Id: I5cf478cb8cd0d301ee3b068347ed48ce768b8882 Reviewed-on: https://go-review.googlesource.com/c/go/+/494186 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* internal/abi: update type name in commentIan Lance Taylor2023-05-171-1/+1
| | | | | | | | | | | | | | | method -> Method For #59670 Change-Id: I78e0410f3d5094aa12b2f3ccd6735fec0d696190 Reviewed-on: https://go-review.googlesource.com/c/go/+/494795 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com>
* cmd/go: prune more dependencies in 'go get'Bryan C. Mills2023-05-1713-537/+1100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this change, 'go get' pulled in every version of each module whose path is explicitly listed in the go.mod file. When graph pruning is enabled (that is, when the main module is at 'go 1.17' or higher), that pulled in transitive dependencies of older-than-selected versions of dependencies, which are normally pruned out by other 'go' commands (including 'go mod tidy' and 'go mod graph'). To make matters worse, different parts of `go get` were making different assumptions about which kinds of conflicts would be reported: the modget package assumed that any conflict is necessarily due to some explicit constraint, but 'go get' was imposing an additional constraint that modules could not be incidentally upgraded in the course of a downgrade. When that additional constraint failed, the modload package reported the failure as though it were a real (caller-supplied) constraint, confusing the caller (which couldn't identify any specific package or argument that caused the failure). This change fixes both of those problems by replacing the modload.EditRequirements algorithm with a different one. The new algorithm is, roughly, as follows. 1. Propose a list of “root requirements” to be written to the updated go.mod file. 2. Load the module graph from those requirements mostly as usual, but if any root is upgraded due to transitive dependencies, retain the original roots and the paths leading from those roots to the upgrades. (This forms an “extended graph”, in which we can trace a path from to each version that appears in the graph starting at one or more of the original roots.) 3. Identify which roots caused any module path to be upgraded above its passed-in version constraint. For each such root, either report an unresolvable conflict (if the root itself is constrained to a specific version) or identify an updated version to propose: either a downgrade to the next-highest version, or an upgrade to the actually-selected version of the root (if that version is allowed). To avoid looping forever or devolving into an NP-complete search, we never propose a version that was already rejected previously, regardless of what other roots were present alongside it at the time. 4. If the version of any root was changed, repeat from (1). This algorithm is guaranteed to terminate, because there are finitely many root versions and we permanently reject at least one each time we downgrade its path to a lower version. In addition, this change implements support for the '-v' flag to log more information about version changes at each iteration. Fixes #56494. Fixes #55955. Change-Id: Iebc17dd7586594d5732e228043c3c4c6da230f44 Reviewed-on: https://go-review.googlesource.com/c/go/+/471595 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
* cmd/go: add a test that reproduces the root cause of issue #56494Bryan C. Mills2023-05-172-1/+137
| | | | | | | | | | | For #56494. Change-Id: I9bbded6d014ac73d81b973f2d7b4783e64380031 Reviewed-on: https://go-review.googlesource.com/c/go/+/447797 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com>
* crypto/rsa: use BoringCrypto for 4096 bit keysFilippo Valsorda2023-05-171-1/+2
| | | | | | | | | | | Fixes #58803 Change-Id: I097938ff61dae2b65214f8d0126d68de63525f5b Reviewed-on: https://go-review.googlesource.com/c/go/+/474515 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
* runtime: consistently define fcntlIan Lance Taylor2023-05-1734-86/+209
| | | | | | | | | | | | | | | | Clean up and consolidate on a single consistent definition of fcntl, which takes three int32 arguments and returns either a positive result or a negative errno value. Change-Id: Id9505492712db4b0aab469c6bd15e4fce3c9ff6e Reviewed-on: https://go-review.googlesource.com/c/go/+/495075 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com>
* slices: for Insert and Replace, grow slices like append doesKeith Randall2023-05-162-4/+38
| | | | | | | | | | | | | | | | | | | | | | At least when we're inserting/replacing near the end of a slice, when we have to grow it use the same multiplicative growth factor that the runtime uses for append. Before this CL, we would grow the slice one page (8192 bytes) at a time for large slices. This would cause O(n^2) work when appending near the end should only take O(n) work. This doesn't fix the problem if you insert/replace near the start of the array, but maybe that doesn't need fixing because it is O(n^2) anyway. Fixes #60134 Change-Id: If05376bc512ab839769180e5ce4cb929f47363b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/495296 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
* slices: handle aliasing cases in Insert/ReplaceKeith Randall2023-05-163-22/+320
| | | | | | | | | | | | | | | | | | | Handle cases where the inserted slice is actually part of the slice that is being inserted into. Requires a bit more work, but no more allocations. (Compare to #494536.) Not entirely sure this is worth the complication. Fixes #60138 Change-Id: Ia72c872b04309b99025e6ca5a4a326ebed2abb69 Reviewed-on: https://go-review.googlesource.com/c/go/+/494817 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
* go/types, types2: permit partially instantiated functions as function argumentsRobert Griesemer2023-05-168-102/+328
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL changes Checker.genericExprList such that it collects partially instantiated generic functions together with their (partial) type argument (and corresponding) expression lists, instead of trying to infer the missing type arguments in place or to report an error. Special care is being taken to explictly record expression types where needed (because we can't use one of the usual expr evaluators which takes care of that), or to track the correct instance expression for later recording with Checker.arguments. The resulting generic expression list is passed to Checker.arguments which is changed to accept explicit partial type argument (and corresponding) expression lists. The provided type arguments are fed into type inference, matching up with their respective type parameters (which were collected already, before this CL). If type inference is successful, the instantiated functions are recorded as needed. For now, the type argument expression lists are collected and passed along but not yet used. We may use them eventually for better error reporting. Fixes #59958. For #59338. Change-Id: I26db47ef3546e64553da49d62b23cd3ef9e2b549 Reviewed-on: https://go-review.googlesource.com/c/go/+/494116 Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com>
* go/types, types2: remove superfluous argument test in Checker.argumentsRobert Griesemer2023-05-164-24/+2
| | | | | | | | | | | | | | | | | | | | | | | | There's only two places which call Checker.arguments: Checker.callExpr and Checker.builtin. Both ensure that the passed argument list doesn't contain type expressions, so we don't need that extra check at the start of Checker.arguments. The remaining check causes Checker.arguments to exit early if any of the passed arguments is invalid. This reduces the number of reported errors in rare cases but is executed all the time. If the extra errors are a problem, it would be better to not call Checker.arguments in the first place, or only do the extra check before Checker.arguments reports an error. Removing this code for now. Removes a long-standing TODO. Change-Id: Ief654b680eb6b6a768bb1b4c621d3c8169953f17 Reviewed-on: https://go-review.googlesource.com/c/go/+/495395 Run-TryBot: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
* cmd/compile: call phiElimValue from removePhiArgJakub Ciolek2023-05-164-8/+2
| | | | | | | | | | | | | | | | | With the exception of the shortcircuit pass, removePhiArg is always unconditionally followed by phiElimValue. Move the phiElimValue inside removePhiArg. Resolves a TODO. See CL 357964 for more info. Change-Id: I8460b35864f4cd7301ba86fc3dce08ec8041da7f Reviewed-on: https://go-review.googlesource.com/c/go/+/465435 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Jakub Ciolek <jakub@ciolek.dev>
* doc/go1.21: document reflect.Value escape improvementsCherry Mui2023-05-161-0/+12
| | | | | | | | | | | | | With CL 408826, CL 413474, etc. reflect.ValueOf no longer unconditionally escapes its argument, allowing a Value's content to be allocated on the stack. Change-Id: I3a0af85c11e2fd0df42b056095565f0ce5548886 Reviewed-on: https://go-review.googlesource.com/c/go/+/494657 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
* cmd/compile/internal/noder: suppress unionType consistency checkMatthew Dempsky2023-05-162-13/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the types1 universe, we only need to represent value types. For interfaces, this means we only need to worry about pure interfaces. A pure interface can embed a union type, but the overall union must be equivalent to "any". In go.dev/cl/458619, we changed the types1 reader to return "any", but to incorporate a consistency check to make sure this is valid. Unfortunately, a pure interface can actually still reference impure interfaces, and in general this is hard to check precisely without reimplementing a lot of types2 data structures and logic into types1. We haven't had any other reports of this check failing since 1.20, so it seems simplest to just suppress for now. Fixes #60117. Change-Id: I5053faafe2d1068c6d438b2193347546bf5330cd Reviewed-on: https://go-review.googlesource.com/c/go/+/495455 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
* Revert "cmd/compile: build compiler with PGO"Cherry Mui2023-05-163-25/+0
| | | | | | | | | | | | | This reverts CL 451292. Reason for revert: causes the racecompile builder failure. https://build.golang.org/log/32d2fc21bd6e3bd415495d04befe806c0f10ea8b Change-Id: I5863437d4b814712b1280a1c21ba86009c332645 Reviewed-on: https://go-review.googlesource.com/c/go/+/495475 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
* cmd/compile: build compiler with PGOCherry Mui2023-05-163-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Build the compiler with PGO. As go build -pgo=auto is enabled by default, we just need to store a profile in the compiler's directory. The profile is collected from building all std and cmd packages on Linux/AMD64 machine, using profile.sh. This improves the compiler speed. On Linux/AMD64, name old time/op new time/op delta Template 138ms ± 5% 136ms ± 4% -1.44% (p=0.005 n=36+39) Unicode 147ms ± 4% 140ms ± 4% -4.99% (p=0.000 n=40+39) GoTypes 780ms ± 3% 778ms ± 4% ~ (p=0.172 n=39+39) Compiler 105ms ± 5% 99ms ± 7% -5.64% (p=0.000 n=40+40) SSA 5.83s ± 6% 5.80s ± 6% ~ (p=0.556 n=40+40) Flate 89.0ms ± 5% 87.0ms ± 6% -2.18% (p=0.000 n=40+40) GoParser 172ms ± 4% 167ms ± 4% -2.72% (p=0.000 n=39+40) Reflect 333ms ± 4% 333ms ± 3% ~ (p=0.426 n=40+39) Tar 128ms ± 4% 126ms ± 4% -1.82% (p=0.000 n=39+39) XML 173ms ± 4% 170ms ± 4% -1.39% (p=0.000 n=39+40) [Geo mean] 253ms 248ms -2.13% The profile is pretty transferable. Using the same profile, we see a bigger win on Darwin/ARM64, name old time/op new time/op delta Template 71.0ms ± 2% 68.3ms ± 2% -3.90% (p=0.000 n=20+20) Unicode 71.8ms ± 2% 66.8ms ± 2% -6.90% (p=0.000 n=20+20) GoTypes 444ms ± 1% 428ms ± 1% -3.53% (p=0.000 n=19+20) Compiler 48.9ms ± 3% 45.6ms ± 3% -6.81% (p=0.000 n=20+20) SSA 3.25s ± 2% 3.09s ± 1% -5.03% (p=0.000 n=19+20) Flate 44.0ms ± 2% 42.3ms ± 2% -3.72% (p=0.000 n=19+20) GoParser 76.7ms ± 1% 73.5ms ± 1% -4.15% (p=0.000 n=18+19) Reflect 172ms ± 1% 165ms ± 1% -4.13% (p=0.000 n=20+19) Tar 63.1ms ± 1% 60.4ms ± 2% -4.24% (p=0.000 n=19+20) XML 83.2ms ± 2% 79.2ms ± 2% -4.79% (p=0.000 n=20+20) [Geo mean] 127ms 121ms -4.73% Change-Id: I44735b3f7fd6903efbbe6b19c05dee874bea4c89 Reviewed-on: https://go-review.googlesource.com/c/go/+/451292 Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile: add more information to the bisect-verbose reportDavid Chase2023-05-162-5/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | running on cmd/compile/internal/testdata/inlines now shows: ``` --- change set #1 (enabling changes causes failure) b/b.go:16:6: loop variable i now per-iteration (loop inlined into b/b.go:10) b/b.go:16:6: loop variable i now per-iteration ./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into a/a.go:18) ./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:37) ./b/b.go:16:6: loop variable b.i now per-iteration (loop inlined into ./main.go:38) --- ``` and ``` --- change set #2 (enabling changes causes failure) ./main.go:27:6: loop variable i now per-iteration ./main.go:27:6: loop variable i now per-iteration (loop inlined into ./main.go:35) --- ``` Still unsure about the utility of mentioning the inlined occurrence, but better than mysteriously repeating the line over and over again. Change-Id: I357f5d419ab4928fa316f4612eec3b75e7f8ac34 Reviewed-on: https://go-review.googlesource.com/c/go/+/494296 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: David Chase <drchase@google.com>
* cmd/link/internal/ppc64: link ELFv2 objects built with -mcpu=power10Paul E. Murphy2023-05-161-51/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, objects built via cgo using CGO_CFLAGS="-O2 -g -mcpu=power10". These use new relocations defined by ELFv2 1.5, and the R_PPC64_REL24_NOTOC relocation. These objects contain functions which may not use a TOC pointer requiring the insertion of trampolines to use correctly. The relocation targets of these ELFv2 objects may also contain non-zero values. Clear the relocated bits before setting them. Extra care is taken if GOPPC64 < power10. The R_PPC64_REL24_NOTOC reloc existed prior to ELFv2 1.5. The presence of this relocation itself does not imply a power10 target. Generate power8 compatible stubs if GOPPC64 < power10. Updates #44549 Change-Id: I06ff8c4e47ed9af835a7dcfbafcfa4c538f75544 Reviewed-on: https://go-review.googlesource.com/c/go/+/492617 Run-TryBot: Paul Murphy <murp@ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
* cmd/compile: make memcombine pass a bit more robust to reassociation of exprsKeith Randall2023-05-162-24/+43
| | | | | | | | | | | | | | | Be more liberal about expanding the OR tree. Handle any tree shape instead of a fully left or right associative tree. Also remove tail feature, it isn't ever needed. Change-Id: If16bebef94b952a604d6069e9be3d9129994cb6f Reviewed-on: https://go-review.googlesource.com/c/go/+/494056 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ryan Berger <ryanbberger@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com>
* log/slog: create prefix buffer earlierJonathan Amsterdam2023-05-162-18/+34
| | | | | | | | | | | | | | | | | | | | | It's possible that the replacement for a built-in attribute is a Group. That would cause a nil pointer exception because the handleState.prefix field isn't set until later, in appendNonBuiltIns. So create the prefix field earlier, at the start of commonHandler.handle. Once we do this, we can simplify the code by creating and freeing the prefix in newHandleState. Along the way I discovered a line that wasn't being tested: state.prefix.WriteString(h.groupPrefix) so I modified an existing test case to cover it. Change-Id: Ib385e3c13451017cb093389fd5a1647d53e610bf Reviewed-on: https://go-review.googlesource.com/c/go/+/494037 Run-TryBot: Jonathan Amsterdam <jba@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/compile/internal/walk: delete statement that don't needcuiweixie2023-05-161-1/+0
| | | | | | | | | Change-Id: I7253aed4808a06379caebf0949aec0f305245d23 Reviewed-on: https://go-review.googlesource.com/c/go/+/494835 Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: xie cui <523516579@qq.com>
* runtime: improve ppc64x memclr for tail bytesLynn Boger2023-05-161-5/+15
| | | | | | | | | | | | | This improves memclr for the last few bytes when compiling for power9 or earlier. Change-Id: I46940ebc7e98e27a2e48d4b319acb7d2106a6f29 Reviewed-on: https://go-review.googlesource.com/c/go/+/495035 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Paul Murphy <murp@ibm.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
* net: use and assert correct res state size at compile time when cgo ↵Mateusz Poliwczak2023-05-162-1/+22
| | | | | | | | | | | | | | | available on darwin Change-Id: I961bb18604dd1568ea21431545f43aa6a417b3d9 GitHub-Last-Rev: 735f3364a4f2182f3e3e1b84f39a042e86987967 GitHub-Pull-Request: golang/go#60046 Reviewed-on: https://go-review.googlesource.com/c/go/+/493415 Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Mateusz Poliwczak <mpoliwczak34@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
* cmd/dist: introduce test variantsAustin Clements2023-05-161-33/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the concept of test variants in dist, which are different configurations of the same package. The variant of a test is a short string summarizing the configuration. The "variant name" of a test is either the package name if the variant is empty, or package:variant if not. Currently this isn't used for anything, but soon we'll use this as the Package field of the test JSON output so that we can disambiguate output from differently configured runs of the same test package, and naturally flow this through to any test result viewer. The long-term plan is to use variant names as dist's own test names and eliminate the ad hoc names it has right now. Unfortunately, the build coordinator is aware of many of the ad hoc dist test names, so some more work is needed to get to that point. This CL keeps almost all test names the same, with the exception of tests registered by registerCgoTests, where we regularize test names a bit using variants to avoid some unnecessary complexity (I believe nothing depends on the names of these tests). For #37486. Change-Id: I119fec2872e40b12c1973cf2cddc7f413d62a48c Reviewed-on: https://go-review.googlesource.com/c/go/+/495016 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
* cmd/dist: put cgo tests under a "Testing cgo" headingAustin Clements2023-05-161-26/+24
| | | | | | | | | | | | | | | | | | | Currently the cgo tests mostly use their package name as a heading, which means we get a large number of test sections that each have a single test package in them. Unify them all under "Testing cgo" to reduce output noise. This leaves just the cmd/api test without a heading, so we give it a heading and require that all tests have a heading. Change-Id: I24cd9a96eb35bbc3ff9335ca8a382ec2426306c1 Reviewed-on: https://go-review.googlesource.com/c/go/+/494497 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
* cmd/dist: refactor adding to the test list into a methodAustin Clements2023-05-161-103/+92
| | | | | | | | | | | | | | | | | | Currently, there are four places that add distTests to the tester.tests list. That means we're already missing a few name uniqueness checks, and we're about to start enforcing some more requirements on tests that would be nice to have in one place. Hence, to prepare for this, this CL refactors the process of adding to the tester.tests list into a method. That also means we can trivially use a map to check name uniqueness rather than an n^2 slice search. For #37486. Change-Id: Ib7b64c7bbf65e5e870c4f4bfaca8c7f70983605c Reviewed-on: https://go-review.googlesource.com/c/go/+/495015 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
View Lorry Controller Status