Fixes#68000
Change-Id: Ie70a8ecc9573b2a4cf57119bda57e0af5e16c42f
Reviewed-on: https://go-review.googlesource.com/c/go/+/609395
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Add a field to Server and Transport containing HTTP/2 configuration
parameters.
This field will have no effect until golang.org/x/net/http2 is updated
to make use of it, and h2_bundle.go is updated with the new http2
package.
For #67813
Change-Id: I81d7f8e9ddea78f9666383983aec43e3884c13ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/602175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Update x/telemetry to fix#68976 and #68946.
Commands run:
go get golang.org/x/telemetry@a797f33
go mod tidy
go mod vendor
Fixes#68946Fixes#68946
Change-Id: I321ce609b41ef210a19150dce1f07b204e7c118e
Reviewed-on: https://go-review.googlesource.com/c/go/+/609237
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This can be used to toggle runtime usages of ISA extensions as such
usages appear.
Only the CRC32 bit is exposed for now, as the others are not going to be
utilized in the standard library for a while.
Change-Id: I774032ca84dc8bcf1c9f17558917315af07c7314
Reviewed-on: https://go-review.googlesource.com/c/go/+/482416
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Enables V2 unified IR bitstreams when GOEXPERIMENT aliastypeparams
are enabled.
Allows pkgbits.NewPkgEncoder to set the output version.
Reenables support for writing V0 streams.
Updates #68778
Updates #68526
Change-Id: I590c494d81ab7db148232ceaba52229068d1e986
Reviewed-on: https://go-review.googlesource.com/c/go/+/608595
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Fixes#69104
Change-Id: Ie928239d5ef198ce36759ec4cffb7f6320ff3b82
Reviewed-on: https://go-review.googlesource.com/c/go/+/609175
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
For #68960
Change-Id: I5495b3d45ad3817d7edf6336a5e24a331d5cf8d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/609115
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
When GORISCV64 enables rva22u64, combined shift and addition using the
SH1ADD, SH2ADD and SH3ADD instructions that are available via the Zba
extension. This results in more than 2000 instructions being removed
from the Go binary on riscv64.
Change-Id: Ia62ae7dda3d8083cff315113421bee73f518eea8
Reviewed-on: https://go-review.googlesource.com/c/go/+/606636
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Mark Ryan <markdryan@rivosinc.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Change the rules for how //go:build "file versions" are applied: instead
of considering whether a file version is an upgrade or downgrade from
the -lang version, always use max(fileVersion, go1.21). This prevents
file versions from downgrading the version below go1.21. Before Go 1.21
the //go:build version did not have the meaning of setting the file's
langage version.
This fixes an issue that was appearing in GOPATH builds: Go 1.23.0
started providing -lang versions to the compiler in GOPATH mode (among
other places) which it wasn't doing before, and it set -lang to the
toolchain version (1.23). Because the -lang version was greater than
go1.21, language version used to compile the file would be set to the
//go:build file version. //go:build file versions below 1.21 could cause
files that could previously build to stop building.
For example, take a Go file with a //go:build line specifying go1.10.
If that file used a 1.18 feature, that use would compile fine with a Go
1.22 toolchain. But it would produce an error when compiling with the
1.23.0 toolchain because it set the language version to 1.10 and
disallowed the 1.18 feature. This breaks backwards compatibility: when
the build tag was added, it did not have the meaning of restricting the
language version.
For #68658
Change-Id: I6cedda81a55bcccffaa3501eef9e2be6541b6ece
Reviewed-on: https://go-review.googlesource.com/c/go/+/607955
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
As of CL 580255, the runtime tracks the frame pointer (or base pointer,
bp) when entering syscalls, so that we can use fpTracebackPCs on
goroutines that are sitting in syscalls. That CL mostly got things
right, but missed one very subtle detail.
When calling from Go->C->Go, the goroutine stack performing the calls
when returning to Go is free to move around in memory due to growth,
shrinking, etc. But upon returning back to C, it needs to restore
gp.syscall*, including gp.syscallsp and gp.syscallbp. The way syscallsp
currently gets updated is automagically: it's stored as an
unsafe.Pointer on the stack so that it shows up in a stack map. If the
stack ever moves, it'll get updated correctly. But gp.syscallbp isn't
saved to the stack as an unsafe.Pointer, but rather as a uintptr, so it
never gets updated! As a result, in rare circumstances, fpTracebackPCs
can correctly try to use gp.syscallbp as the starting point for the
traceback, but the value is stale.
This change fixes the problem by just storing gp.syscallbp to the stack
on cgocallback as an unsafe.Pointer, like gp.syscallsp. It also adds a
comment documenting this subtlety; the lack of explanation for the
unsafe.Pointer type on syscallsp meant this detail was missed -- let's
not miss it again in the future.
Now, we have a fix, what about a test? Unfortunately, testing this is
going to be incredibly annoying because the circumstances under which
gp.syscallbp are actually used for traceback are non-deterministic and
hard to arrange, especially from within testprogcgo where we don't have
export_test.go and can't reach into the runtime.
So, instead, add a gp.syscallbp check to reentersyscall and
entersyscallblock that mirrors the gp.syscallbp consistency check. This
probably causes some miniscule slowdown to the syscall path, but it'll
catch the issue without having to actually perform a traceback.
Fixes#69085.
Change-Id: Iaf771758f1666024b854f5fbe2b2c63cbe35b201
Reviewed-on: https://go-review.googlesource.com/c/go/+/608775
Reviewed-by: Nick Ripley <nick.ripley@datadoghq.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Fixes#69076
Change-Id: I1a16675c466722f44d0734e95d3c8111e33ff580
Reviewed-on: https://go-review.googlesource.com/c/go/+/607736
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Zxilly Chou <zxilly@outlook.com>
Run-TryBot: shuang cui <imcusg@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
By using maps.Clone and omitting nil checks when calling
http.Header.Clone.
I'm not using slices.Clone because the result of slices.Clone
may have additional unused capacity.
Change-Id: I4aed0fea218404c7270e35324e6bd62d855296c7
GitHub-Last-Rev: 9fd5dd5907
GitHub-Pull-Request: golang/go#69070
Reviewed-on: https://go-review.googlesource.com/c/go/+/608295
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Damien Neil <dneil@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
An invalid executable may claim to have a data section bigger than the
executable, causing readData in searchMagic to hit EOF. Since readData
suppresses all EOF errors, searchData would keep attempting to search
through a potentially huge "section" despite readData continuously
failing.
Fix by suppressing EOF only on partial read. If nothing is read, allow
EOF. Note that most of the admittedly tedious EOF handling in this
package is around ensuring we return errNotGoExe in most cases.
This was discovered by the new fuzz test. This fuzz test was inspired
by #69066, though it has not found that specific bug.
Change-Id: Icf413e996cecc583c084c9e44249b9294c3d8f10
Reviewed-on: https://go-review.googlesource.com/c/go/+/608637
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The $HOME/sdk/go1.17 and $HOME/go1.17 paths were initially added as
places to look for a bootstrap toolchain to make.{bash,bat,rc} scripts
and in cmd/dist (CL 370274). Those two go1.17 directories have since
been updated in the make scripts to go1.20.6 (CL 512275) and later on
to go1.22.6 (CL 606156), but the same list in cmd/dist was missed.
Fix the inconsistency now. But maybe cmd/dist doesn't need to maintain
this logic, if it's required to be invoked via one of the make scripts,
since they're responsible for setting GOROOT_BOOTSTRAP?
For #64751.
Change-Id: I0988005c559014791363138f2f722cc1f9a78bcf
Reviewed-on: https://go-review.googlesource.com/c/go/+/607821
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
If the length reported for the object file is more than the amount of
data we actually read, then the count can tell us that there is
sufficient remaining data but the slice operation can fail.
No test case because the problem can only happen for invalid data.
Let the fuzzer find cases like this.
Fixes#69066
Change-Id: I8d12ca8ade3330517ade45c7578b477772b7efd2
Reviewed-on: https://go-review.googlesource.com/c/go/+/608517
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Add a check to ensure that intrinsics are not being overwritten.
Remove two S390X intrinsics that are being replaced by aliases and
are therefore ineffective.
Change-Id: I4187a169c14ca75c45a67f41a1d626d76b82bb72
Reviewed-on: https://go-review.googlesource.com/c/go/+/605479
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Now that we can pass configuration to initIntrinsics, clean up the
intrinsic test and always enable power10. Additionally, provide an
-update flag that prints out updated golden values.
Change-Id: Ibfef339d513a4d67d53a5a310a82165592ca338f
Reviewed-on: https://go-review.googlesource.com/c/go/+/607055
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>
Reviewed-by: Keith Randall <khr@golang.org>
Create an intrinsicBuilders type that has functions for adding and
looking up intrinsics. This makes the implementation more self contained,
readable and testable. Additionally, pass an *intrinsicBuildConfig to
initIntrinsics to improve testability without needing to modify package
level variables.
Change-Id: I0ee0a19c192dd6da9f1c5f1c29b98a3ad8161fe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/605478
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Keith Randall <khr@golang.org>
No point in keeping values in registers when their next use is after
a call, as we'd have to spill/restore them anyway.
cmd/go is 0.1% smaller.
Fixes#59297
Change-Id: I10ee761d0d23229f57de278f734c44d6a8dccd6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/509255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
filepath.Rel can sometimes return the a relative path that doesn't work.
If the basepath contains a symlink as a path component, and the targpath
does not exist with the directory pointed to by the innermost symlink,
the relative path can "cross" the symlink. The issue is that for the
return value for filepath.Rel to be correct, the ".." components of the
relative path would need to be collapsed before the symlinks are
expanded, but it was verified by doing local testing that the opposite
is true.
go work use (and cmd/go/internal/modload.ReadModFile) both try to
shorten absolute path arguments to relative paths from the working
directory (for better error messages, for instance). Avoid doing so when
the relative path could be wrong using a more conservative rule than the
above: if expanding the symlinks in the current directory produces a
different result, and the relative path we'd return starts with ".." and
then the path separator.
Fixes#68383
Change-Id: I0a6202be672484d4000fc753c69f2165615f3f72
Reviewed-on: https://go-review.googlesource.com/c/go/+/603136
TryBot-Bypass: Michael Matloob <matloob@golang.org>
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Parse materialized aliases in indexed format.
This was in https://go.dev/cl/574717 in x/tools.
Updates #68778
Change-Id: I2f0871aeb5a2e74c803176001f178757766a4a0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/607498
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This field is unused since shape-based stenciling was added for Unified
IR (CL 421821). The derived types information is now explicitly using
derived-type dictionaries (CL 331829).
This CL follows the pattern used in CL 606035.
Updates #68778
Change-Id: Ie784b6443c0a651854bfbcebb8a5166b1481408b
Reviewed-on: https://go-review.googlesource.com/c/go/+/608216
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Tim King <taking@google.com>
So next CL can use it to remove unnecessary derivedInfo needed field.
Updates #68778
Change-Id: Ia4e0f638beaf4a448fbf10a9aa1bc9425349a5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/608215
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This can be done efficiently with few instructions.
This also adds MULHDUCC for further codegen improvement.
Change-Id: I06320ba4383a679341b911a237a360ef07b19168
Reviewed-on: https://go-review.googlesource.com/c/go/+/605975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Archana Ravindar <aravinda@redhat.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
just removed a single byte :)
Change-Id: Icd734f9f8f22b2ed0d9d0125d18b6d291bb14cd6
GitHub-Last-Rev: 93c0fd00d8
GitHub-Pull-Request: golang/go#69056
Reviewed-on: https://go-review.googlesource.com/c/go/+/607878
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: Iecbfe986da386b5c9b8c366904f659acc8f34cfc
GitHub-Last-Rev: ed6c744bbd
GitHub-Pull-Request: golang/go#69039
Reviewed-on: https://go-review.googlesource.com/c/go/+/608015
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The current implementation has a panic when the database is closed
concurrently with a new connection attempt.
connRequestSet.CloseAndRemoveAll sets connRequestSet.s to a nil slice.
If this happens between calls to connRequestSet.Add and
connRequestSet.Delete, there is a panic when trying to write to the nil
slice. This is sequence is likely to occur in DB.conn, where the mutex
is released between calls to db.connRequests.Add and
db.connRequests.Delete
This change updates connRequestSet.CloseAndRemoveAll to set the curIdx
to -1 for all pending requests before setting its internal slice to nil.
CloseAndRemoveAll already iterates the full slice to close all the request
channels. It seems appropriate to set curIdx to -1 before deleting the
slice for 3 reasons:
1. connRequestSet.deleteIndex also sets curIdx to -1
2. curIdx will not be relevant to anything after the slice is set to nil
3. connRequestSet.Delete already checks for negative indices
Fixes#68949
Change-Id: I6b7ebc5a71b67322908271d13865fa12f2469b87
GitHub-Last-Rev: 7d2669155b
GitHub-Pull-Request: golang/go#68953
Reviewed-on: https://go-review.googlesource.com/c/go/+/607238
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Commit-Queue: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Writes the field for type parameter names for aliases when
the bitstream is >= V2.
This is a no-op at the moment as the writer is hardwired to V1.
Updates #68778
Change-Id: I5887e3608239b9a6a47e3cc21cacb75b84e1d186
Reviewed-on: https://go-review.googlesource.com/c/go/+/607235
Reviewed-by: David Chase <drchase@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The tests added by CL 601778 highlighted missing buffer overlap
checks in the ppc64 specific aes-gcm implementation.
Fixes#69007
Change-Id: I80c3b5628c5079cfed2c3dace7298512c16a8f46
Reviewed-on: https://go-review.googlesource.com/c/go/+/607519
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
1. Replace "rooted path name" with a more accurate "absolute path name".
Using "absolute" seems to be preferred terminology on Unix. On Windows,
there are multiple roots in Windows, thus "a rooted path name" can be
one relative to a drive letter or a server name. Note that Windows'
GetCurrentDirectory documentation [1] also says "the absolute path to the
current directory".
2. Add a note about using $PWD on Unix.
[1]: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getcurrentdirectory
Change-Id: Ic310f0f8776ff059544789306ae5cfa1fa267b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/607615
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 574695 added caching the os.Chdir argument for Windows, and used the
cached value to assess the length of the current working directory in
addExtendedPrefix (used by fixLongPath).
It did not take into account that Chdir can accept relative paths, and
thus the pathLength calculation in addExtendedPrefix can be wrong.
Let's only cache the os.Chdir argument if it's absolute, and clean the
cache otherwise, thus improving the correctness of fixLongPath.
For #41734
For #21782
For #36375
Change-Id: Ie24a5ed763a7aacc310666d2e4cbb8e298768670
Reviewed-on: https://go-review.googlesource.com/c/go/+/607437
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change adds documentation to "go help telemetry" and "go help
environment" for the unsettable GOTELEMETRY and GOTELEMETRYDIR go env
variables.
For #68928
Change-Id: I8c139bd8585ffb0c45b9dd722ef6e7a9a33df192
Reviewed-on: https://go-review.googlesource.com/c/go/+/607855
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The commands to build the bootstrap toolchains and go commands are run
from modules created by two bootstrap go.mod files: one is used when
building toolchain1 and go_bootstrap, and the other is used for
toolchain2 and toolchain3, and the final build. Currently the first has
a go directive specifying go 1.20, and the second one does not have a go
directive at all. This affects the default GODEBUG setting when building
the final toolchain: the default GODEBUG value is based on the go
version of the go.mod file, and when the go.mod file does not have a
version it defaults to go1.16. We should set the go directive on the
bootstrap used for the second half of the builds to use the current go
verison from the std's go.mod file (which is the same as the version on
cmd's go.mod file).
The go.mod file used for the initial bootstrap should have a go
directive with the minimum version of the toolchain required for
bootstrapping. That version is the current version - 2 rounded down to
an even number.
For #64751Fixes#68797
Change-Id: Ibdddf4bc36dc963291979d603c4f3fc55264f65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/604799
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
nanotime1 is broken on windows/arm since CL 526358, which
unintentionally removed a necessary instruction. It hasn't been
noticed till now because the there is no windows/arm builder.
This CL restores the instruction.
Fixes#68996.
Change-Id: I52ef6891a3bd8e608b8538f456d181e08f93efaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/607776
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
With this, ReadDir will fail a tad earlier (on open rather than on
readdir syscall). This should be the only effect of this change.
Change-Id: Icf2870f47ea6c19aad29670e78ba9bfcc13c0ac3
Reviewed-on: https://go-review.googlesource.com/c/go/+/588915
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Add basic test coverage for the intrinisic table - this at least allows
us to tell if intrinsics are added or removed unexpectedly. Code
generation changes resulting from intrinsics is not covered and is
left for test/codegen and others.
Change-Id: I3d538708b90cd04d3f449945e0fd9388097d683e
Reviewed-on: https://go-review.googlesource.com/c/go/+/605475
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: David Chase <drchase@google.com>
