In CL 371574 PatchSet 18, we replaced all !{{Less}} with {{GreaterOrEqual}} to fix a problem(handle NaNs when sorting float64 slice) in exp/slices.
We don't actually need this change, because we don't guarantee that the slice will be sorted eventually if there are NaNs(we could have a[i] < a[j] for some i,j with i>j).
This CL reverts all the replacements in exp/slices and does not affect any codes in the sort package.
Change-Id: Idc225d480de3e2efef2add35c709ed880d1306cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/400534
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
These tests run the runtime, reflect, and sync package tests with the
two maymorestack hooks we have.
These tests only run on the longtest builders (or with
GO_TEST_SHORT=false) because we're running the runtime test two
additional times and the mayMoreStackMove hook makes it about twice as
slow (~230 seconds).
To run just these tests by hand, do
GO_TEST_SHORT=false go tool dist test -run mayMoreStack
Updates #48297.
This detected #49354, which was found as a flake on the dashboard, but
was reliably reproducible with these tests; and #49395.
Change-Id: If785a8b8d6e1b9ad4d2ae67493b54055ab6cbc85
Reviewed-on: https://go-review.googlesource.com/c/go/+/361212
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There are a few tests of the scheduler run queue API that allocate a
local []g and test using those G's. However, the run queue API
frequently converts between *g and guintptr, which is safe for "real"
Gs because they're heap-allocated and hence don't move, but if these
tests get a stack movement while holding one of these local *g's as a
guintptr, it won't get updated and the test will fail.
Updates #48297.
Change-Id: Ifd424147ce1a1b53732ff0cf55a81df1a9beeb3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/402157
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Signed-off-by: Park Zhou <buildpaas@gmail.com>
Change-Id: Idbbd2779264a7310b839af8291315e5e38b7ced9
Reviewed-on: https://go-review.googlesource.com/c/go/+/402120
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Fix an off-by-one error in COFFSymbolReadSectionDefAux, specifically
the code that tests whether a symbol index is valid.
Fixes#52525.
Change-Id: I1b6e5dacfd99249c694bef5ae606e90fdb2ef521
Reviewed-on: https://go-review.googlesource.com/c/go/+/402156
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fix up TestEd25519Vectors to download files into its own temporary mod
cache, as opposed relying on whatever GOPATH or GOMODCACHE setting is
in effect when the test is run.
Change-Id: I523f1862f5874b0635a6c0fa83d35a6cfac6073b
Reviewed-on: https://go-review.googlesource.com/c/go/+/402154
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Values are taken from cmd/internal/sys/arch.go. Also fix some incorrect
alphabetical sorting to put arm > amd.
Updates #46229Fixes#52495
Change-Id: If7d2c675238093692060358003915f1649792cf5
Reviewed-on: https://go-review.googlesource.com/c/go/+/401576
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: WANG Xuerui <git@xen0n.name>
Reviewed-by: xiaodong liu <teaofmoli@gmail.com>
OpenBSD has a default soft limit of 512 and hard limit of 1024 - as such,
attempting to open 1200 files is always going to fail unless the defaults
have been changed. On this platform use 768 instead such that it passes
without requiring customisation.
Fixes#51713
Change-Id: I7679c8fd73d4b263145129e9308afdb29d67bb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/401594
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: 谢致邦 <xiezhibang@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
This CL adds support for debugger function calls on linux arm64
platform. The protocol is basically the same as in CL 109699, except for
the following differences:
1, The abi difference which affect parameter passing and frame layout.
2, Stores communication information in R20.
3, The closure register is R26.
4, Use BRK 0 instruction to generate a breakpoint. The saved PC in
sigcontext is the PC where the signal occurred, not the next PC.
In addition, this CL refactors the existing code (which is dedicated to
amd64) for easier multi-arch scaling.
Fixes#50614
Change-Id: I06b14e345cc89aab175f4a5f2287b765da85a86b
Reviewed-on: https://go-review.googlesource.com/c/go/+/395754
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Built using racebuild.
Note that racebuild fails when trying to test the .syso, because the
Go runtime doesn't think we support s390x race yet. But it builds the
.syso as a side effect which I grabbed. There's something of a
chicken-and-egg bootstrapping problem here, unfortunately.
Change-Id: Ibc6d04fd3a9bfb3224d08e8b78dcf09bb139a59d
Reviewed-on: https://go-review.googlesource.com/c/go/+/401714
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Jonathan Albrecht <jonathan.albrecht@ibm.com>
The proposal accepted the name ErrNestingDepth.
For #51684
Change-Id: I702365f19e5e1889dbcc3c971eecff68e0b08727
Reviewed-on: https://go-review.googlesource.com/c/go/+/401854
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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: Rob Pike <r@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This fixes a deadlock-on-failure that I probably introduced in
CL 385314.
This doesn't explain why the failure observed in #52492 occurred, but
it will at least give us more information to diagnose the failure if
it happens again. (The deadlock currently prevents the t.Fatal log
message from being written to the test's output.)
Fixes#52492.
Change-Id: I9e7874985e2820a6a4b703abe4f8e2035d5138c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401575
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This is an exact copy of CL 401096 after fixing #52472 in CL 401654.
For #51087
For #52472
Change-Id: Ib3c914949a15517aacdca2d72e69e1c7b217e430
Reviewed-on: https://go-review.googlesource.com/c/go/+/401656
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is an exact copy of CL 388478 after fixing #52472 in CL 401654.
For #51087
For #52472
Change-Id: I6c6bd7ddcab1512c682e6b44f61c7bcde97f5c58
Reviewed-on: https://go-review.googlesource.com/c/go/+/401655
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The test has proven to be flaky on OpenBSD since March, and there
hasn't been progress on resolving this finding. Mark the test as
flaky to so that this problem doesn't block the Go 1.19 release.
Updates #51482.
Change-Id: I92ad7498c20cfa94565880363bec85f9a4f3e916
Reviewed-on: https://go-review.googlesource.com/c/go/+/401335
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Use error_.errorf for reporting related error information rather than
inlining the "\n\t". This aligns go/types with types2 in cases where the
related information has no position information. In other cases,
go/types needs to report a "continuation error" (starting with '\t') so
that users can access multiple error positions.
Change-Id: Ica98466596c374e0c1e502e7227c8d8c803b4c22
Reviewed-on: https://go-review.googlesource.com/c/go/+/400825
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
To begin aligning with types2 error reporting, use an error_ type to
hold unevaluated error information, to report via Checker.report.
Change-Id: Ic5ac515759961e55b81acc9eeaac4db25b61804c
Reviewed-on: https://go-review.googlesource.com/c/go/+/400824
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Checker.err was only called to report errors created with
Checker.newError or Checker.newErrorf. Update the API to pass around
*Error rather than error, eliminating unnecessary type assertions and
handling.
Change-Id: I995a120c7e87266e656b8ff3fd9ed3d368fd17fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/400823
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
Change-Id: I664e74dcabf5dc7ed46802859174606454e8f1d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/321715
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This CL adds support for the reg ABI to the bytes functions for
riscv64. These are initially under control of the
GOEXPERIMENT macro until all changes are in.
Change-Id: I026295ae38e2aba055f7a51c77f92c1921e5ec97
Reviewed-on: https://go-review.googlesource.com/c/go/+/361916
Run-TryBot: mzh <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 205457 added the flag -Wno-nullability-completeness to work
around a user-reported build breakage on macOS Catalina.
However, according to
https://golang.org/issue/35247#issuecomment-589115489 the root cause
of the breakage may be a toolchain misconfiguration on the host
(perhaps compiling the XCode stdlib using a Homebrew build of the
"clang" compiler?).
Adding an obscure warning flag to enable building stdlib.h with an
otherwise-broken toolchain seems clearly inappropriate to me.
If need be we can instead provide guidance to users on how to unbreak
their toolchain.
Updates #35247Fixes#49913
Change-Id: I84def34e101bed7911d8d78a991a29095b8791fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/368634
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In CL 339309 this was probably copied from the respective godoc comment
in package inet.af/netaddr, also see
https://pkg.go.dev/inet.af/netaddr#IP.Is4
In net/netip the type is named Addr, so adjust the godoc comment
accordingly.
Change-Id: Ib5ab8054067f8b74119efa4732192a8407189f9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/401394
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Also update the file in $GOROOT/api/next to use proposal number.
For #51684
Change-Id: I28bfa6bc1cee98a17b13da196d41cda34d968bb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401076
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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: Dmitri Shuralyov <dmitshur@google.com>
The following Value methods are now inlineable:
Bool for ~bool
String for ~string (but not other kinds)
Bytes for []byte (but not ~[]byte or ~[N]byte)
Len for ~[]T (but not ~[N]T, ~chan T, ~map[K]V, or ~string)
Cap for ~[]T (but not ~[N]T or ~chan T)
For Bytes, we only have enough inline budget to inline one type,
so we optimize for unnamed []byte, which is far more common than
named []byte or [N]byte.
For Len and Cap, we only have enough inline budget to inline one kind,
so we optimize for ~[]T, which is more common than the others.
The exception is string, but the size of a string can be obtained
through len(v.String()).
Performance:
Bool 1.65ns ± 0% 0.51ns ± 3% -68.81% (p=0.008 n=5+5)
String 1.97ns ± 1% 0.70ns ± 1% -64.25% (p=0.008 n=5+5)
Bytes 8.90ns ± 2% 0.89ns ± 1% -89.95% (p=0.008 n=5+5)
NamedBytes 8.89ns ± 1% 8.88ns ± 1% ~ (p=0.548 n=5+5)
BytesArray 10.0ns ± 2% 10.2ns ± 1% +1.58% (p=0.048 n=5+5)
SliceLen 1.97ns ± 1% 0.45ns ± 1% -77.22% (p=0.008 n=5+5)
MapLen 2.62ns ± 1% 3.07ns ± 1% +17.24% (p=0.008 n=5+5)
StringLen 1.96ns ± 1% 1.98ns ± 2% ~ (p=0.151 n=5+5)
ArrayLen 1.96ns ± 1% 2.19ns ± 1% +11.46% (p=0.008 n=5+5)
SliceCap 1.76ns ± 1% 0.45ns ± 2% -74.28% (p=0.008 n=5+5)
There's a slight slowdown (~10-20%) for obtaining the length
of a string or map, but a substantial improvement for slices.
Performance according to encoding/json:
CodeMarshal 555µs ± 2% 562µs ± 4% ~ (p=0.421 n=5+5)
MarshalBytes/32 163ns ± 1% 157ns ± 1% -3.82% (p=0.008 n=5+5)
MarshalBytes/256 453ns ± 1% 447ns ± 1% ~ (p=0.056 n=5+5)
MarshalBytes/4096 4.10µs ± 1% 4.09µs ± 0% ~ (p=1.000 n=5+4)
CodeUnmarshal 3.16ms ± 2% 3.02ms ± 1% -4.18% (p=0.008 n=5+5)
CodeUnmarshalReuse 2.64ms ± 3% 2.51ms ± 2% -4.81% (p=0.016 n=5+5)
UnmarshalString 65.4ns ± 4% 64.1ns ± 0% ~ (p=0.190 n=5+4)
UnmarshalFloat64 59.8ns ± 5% 58.9ns ± 2% ~ (p=0.222 n=5+5)
UnmarshalInt64 51.7ns ± 1% 50.0ns ± 2% -3.26% (p=0.008 n=5+5)
EncodeMarshaler 23.6ns ±11% 20.8ns ± 1% -12.10% (p=0.016 n=5+4)
Add all inlineable methods of Value to cmd/compile/internal/test/inl_test.go.
Change-Id: Ifc192491918af6b62f7fe3a094a5a5256bfb326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/400676
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@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: Dmitri Shuralyov <dmitshur@google.com>
Partially fixes https://github.com/golang/go/issues/38674
The first commit has the actual unification, the second commit just cleans things up by moving shared code into its own package for clarity.
Change-Id: I85067f8b247df02f94684ec1297a1a42263bba0c
GitHub-Last-Rev: 370a4ecad3
GitHub-Pull-Request: golang/go#52315
Reviewed-on: https://go-review.googlesource.com/c/go/+/399542
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Currently bufio.Writer implements forwarding to the underlying Writer
for large writes via Write, but it does not do the same for large
writes via WriteString.
If the underlying Writer is also a StringWriter, use the same "large
writes" logic also in WriteString while taking care to only check
once per call to WriteString whether the underlying Writer implements
StringWriter.
Change-Id: Id81901c07b035936816b9e41b1f5688e699ee8e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/380074
Reviewed-by: Ian Lance Taylor <iant@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: Dmitri Shuralyov <dmitshur@google.com>
Also correct parameter name in comment.
Change-Id: Ic9486e08c2eea184faccf181cda7da808793def6
Reviewed-on: https://go-review.googlesource.com/c/go/+/400674
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This is a re-do of CL 388477, fixing #52472.
It is unsafe to call syscall.RawSyscall from syscall.Syscall with
-coverpkg=all and -race. This is because:
1. Coverage adds a sync/atomic call in RawSyscall to increment the
coverage counter.
2. Race mode instruments sync/atomic calls with TSAN runtime calls. TSAN
eventually calls runtime.racecallbackfunc, which expects
getg().m.p != 0, which is no longer true after entersyscall().
cmd/go actually avoids adding coverage instrumention to package runtime
in race mode entirely to avoid these kinds of problems. Rather than also
excluding all of syscall for this one function, work around by calling
RawSyscall6 instead, which avoids coverage instrumention both by being
written in assembly and in package runtime/*.
For #51087Fixes#52472
Change-Id: Iaffd27df03753020c4716059a455d6ca7b62f347
Reviewed-on: https://go-review.googlesource.com/c/go/+/401654
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
cmd/trace is currently somewhat painful to use in odd environments since
it depends on the presence of $GOROOT/misc/trace to serve the static
trace viewer content.
Use //go:embed to embed this content directly into cmd/trace for easier
use.
Change-Id: I83b7d97dbecc9773f3b5a6b3bc4a6597473bc01a
Reviewed-on: https://go-review.googlesource.com/c/go/+/378194
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Just like https://golang.org/cl/401454 removed the work from gofmt for a
nice ~5% speed-up in the default case, we can also use the option in the
equivalent go/format for programs which use it rather than gofmt,
as go/format makes no use of objects either.
No benchmark numbers as we already measured the ~5% speed-up with gofmt
in the other CL linked above.
See #46485.
Change-Id: Icbf98e6d46a616081314e2faa13f1dfade3bbaef
Reviewed-on: https://go-review.googlesource.com/c/go/+/401474
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
go/parser will by default resolve objects as per the go/ast.Object type,
which is then used by gofmt's rewrite and simplify flags.
However, none of that is needed if neither of the flags is set,
so we can avoid the work entirely for a nice speed-up.
benchcmd -n 8 GofmtSrcCmd gofmt -l ~/tip/src/cmd
name old time/op new time/op delta
GofmtSrcCmd 957ms ± 7% 908ms ± 7% -5.12% (p=0.028 n=8+8)
name old user-time/op new user-time/op delta
GofmtSrcCmd 11.2s ± 1% 10.4s ± 1% -7.23% (p=0.001 n=7+7)
name old sys-time/op new sys-time/op delta
GofmtSrcCmd 325ms ±29% 286ms ±22% ~ (p=0.065 n=8+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
GofmtSrcCmd 295MB ±17% 276MB ±15% ~ (p=0.328 n=8+8)
See #46485.
Change-Id: Iad1ae294953710c233f7837d7eb02e23d11c6185
Reviewed-on: https://go-review.googlesource.com/c/go/+/401454
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This reverts CL400377, which restricted serials passed to
x509.CreateCertificate to <= 20 octets. Unfortunately this turns out to
be something _a lot_ of people get wrong. Since it's not particularly
obvious how to properly generate conformant serials, until we provide
an easier way for people to get this right, reverting this restriction
makes sense (possible solution discussed in #52444.)
Change-Id: Ia85a0ffe61e2e547abdaf1389c3e1ad29e28a2be
Reviewed-on: https://go-review.googlesource.com/c/go/+/401657
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When the user is trying to list or build a package in a module that's
outside of the workspace provide a more clear message hinting to the
user that they can add the module to the workspace using go work use.
Fixes#51604
Change-Id: I1202ecb2f22fd6351bfdec88ed613b8167687fb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/400014
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Future CLs will be changing the provenance of these functions. Move the
declarations to the individual OS files now so that future CLs can
change only 1 OS at a time rather than changing all at once.
For #51087
Change-Id: I5e1bca71e670263d8c0faa586c1b6b4de1a114b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/388474
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL exports the existing ir.UintptrKeepAlive via the new directive
//go:uintptrkeepalive. This makes the compiler insert KeepAlives for
pointers converted to uintptr in calls, keeping them alive for the
duration of the call.
//go:uintptrkeepalive requires //go:nosplit, as stack growth can't
handle these arguments (it cannot know which are pointers). We currently
check this on the immediate function, but the actual restriction applies
to all transitive calls.
The existing //go:uintptrescapes is an extension of
//go:uintptrkeepalive which forces pointers to escape to the heap, thus
eliminating the stack growth issue.
This pragma is limited to the standard library.
For #51087
Change-Id: If9a19d484d3561b4219e5539b70c11a3cc09391e
Reviewed-on: https://go-review.googlesource.com/c/go/+/388095
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a code simplification using the new API added in #50599.
Change-Id: Icb9628bcd0daa3dc2d653e9654b38099730137d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/401535
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
With #50599 implemented, base.AppendPWD is redundant if cmd.Env would
otherwise be nil, and calls to os.Environ followed by base.AppendPWD
can be replaced by a simpler call to cmd.Environ.
Updates #50599.
Change-Id: I94a22e2a4cc8e83c815ac41702ea0b1ee5034ecc
Reviewed-on: https://go-review.googlesource.com/c/go/+/401534
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: If3d8391d81e8de869dbb3c857f0570817e8aa440
Reviewed-on: https://go-review.googlesource.com/c/go/+/400914
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5698c7576a0f39ae62de7bea64286ac8e578d421
Reviewed-on: https://go-review.googlesource.com/c/go/+/400916
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I5ccbcea4c53658136b25ca608faec19eeec2e908
Reviewed-on: https://go-review.googlesource.com/c/go/+/400915
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 400877.
Reason for revert: broke TestScript/test_output_wait and the
regression test for #18153 on certain builders.
Fixes#52461.
Change-Id: I98627ce5e22088b0784be502c459480c41ba353a
Reviewed-on: https://go-review.googlesource.com/c/go/+/401494
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Per RFC 4158 Section 2.4.2, when we are discarding candidate
certificates during path building, use the SANs as well as subject and
public key when checking whether a certificate is already present in
the built path. This supports the case where a certificate in the chain
(typically a leaf) has the exact same subject and public key as another
certificate in the chain (typically its parent) but has SANs which don't
match.
Change-Id: I212c234e94a1f6afbe9691e4a3ba257461db3a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/401115
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Does what it says on the tin.
Fixes#51088
Change-Id: I12c0fa6bba1c1ce96c1ad31ba387c77a93f801c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/384894
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Once #50599 is implemented, the entries will be observable via the
Environ method. I find it confusing for later entries in the list to
jump arbitrarily far forward based on entries for the same key that no
longer exist.
This also fixes the deduplication logic for the degenerate Windows
keys observed in #49886, which were previously deduplicated as empty
keys.
(It does not do anything about the even-more-degenerate keys observed
in #52436.)
For #50599.
Change-Id: Ia7cd2200ec34ccc4b9d18631cb513194dc420c25
Reviewed-on: https://go-review.googlesource.com/c/go/+/401339
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There is an issue where 'go test' will hang after the tests complete if
a test starts a sub-process that does not exit (see #24050).
However, go test only exhibits that behavior when a package name is
explicitly passed as an argument. If 'go test' is invoked without any
package arguments then the package in the working directory is assumed,
however in that case (and only that case) os.Stdout is used as the test
process's cmd.Stdout, which does *not* cause 'go test' wait for the
sub-process to exit (see #23019).
This change wraps os.Stdout in an io.Writer struct in this case, hiding
the *os.File from the os/exec package, causing cmd.Wait to always wait
for the full output from the test process and any of its sub-processes.
In other words, this makes 'go test' exhibit the same behavior as
'go test .' (or 'go test ./...' and so on).
Update #23019
Update #24050
Change-Id: Ica09bf156f3b017f9a31aad91ed0f16a7837195b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400877
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Andrew Gerrand <adg@golang.org>
Auto-Submit: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Support fastrand64 in the runtime, although fastrand uses wyrand to generate 64-bit random number, it still returns uint32. In some cases, we need to generate a 64-bit random number, the new API would be faster and easier to use, and at least we can use the new function in these places:
src/net/dnsclient.go:randInt()
src/hash/maphash/maphash.go:MakeSeed()
src/runtime/map.go:mapiterinit()
name time/op
Fastrand-16 0.09ns ± 5%
Fastrand64-16 0.09ns ± 6%
Change-Id: Ibb97378c7ca59bc7dc15535d4872fa58ea112e6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/400734
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
overflowPad variable in bucketOf function is a holdover from a NaCl port
and never used now.
Change-Id: Ib68fdb054e1b6a655ffbfd34521a3f8773a22694
GitHub-Last-Rev: f281be9c11
GitHub-Pull-Request: golang/go#52449
Reviewed-on: https://go-review.googlesource.com/c/go/+/401274
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The WHATWG Mime Sniffing Standard we follow dropped support for
.snd / audio/basic.
https://github.com/whatwg/mimesniff/issues/151
Change-Id: Iae1bd8b29063b06b5b3909a944e12ead5974a526
Reviewed-on: https://go-review.googlesource.com/c/go/+/400754
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
When we have an error in a function type used in an expression
we don't know until we see an opening { whether we have a function
literal or a function type. Use "function type" as context because
that's always correct in the specific error message.
Change-Id: I9aad8fcddf31ae53daa53cebd2c2001f08eabde0
Reviewed-on: https://go-review.googlesource.com/c/go/+/401316
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
If the user provides the -json flag to explicitly specify fields, but
doesn't specify the Deps or DepsErrors fields, skip computing the deps
fields.
For #29666
Change-Id: I15596c374aba1af13bdf5808d11d54abdc838667
Reviewed-on: https://go-review.googlesource.com/c/go/+/392495
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
Auto-Submit: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
This test forces GOARCH to amd64, but currently uses the default GOOS.
This works on every OS that supports amd64, which is every OS we
support except AIX. Hence, on AIX this fails with an unsupported
GOOS/GOARCH combination.
Fix this by forcing GOOS to linux.
Fixes#52451.
Change-Id: I9321dd6386c7ef0fe2b47d77ed900aafc53f2a46
Reviewed-on: https://go-review.googlesource.com/c/go/+/401334
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This case was missed in CL 370894, and masked by the lack of an
Illumos TryBot.
Fixes#52452.
Change-Id: I7cda193e33c11a9d04eb888fdb5ec9218e6ed1b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/401294
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <valsorda@google.com>
An error message like "could not import os/user (exit status 1)"
(observed in https://go.dev/issue/52407) is fairly inscrutable.
On the other hand, srcimporter doesn't report errors with quite enough
structure to dump the entire stderr output from 'go tool cgo' without
potentially overwhelming the caller. Here, we split the difference by
describing which command failed but not printing the output of that
command.
For #52407, that would at least provide a stronger clue connecting
to #52408.
Change-Id: Iabdc95b17ba20a0f6ff38e5c7084e5081e1ef5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/400817
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The POSIX standard requires the PWD variable to be an absolute path.
Fixes#46832
Change-Id: I1938592538633e1a0a0958276f1fefc3c4808399
Reviewed-on: https://go-review.googlesource.com/c/go/+/378396
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Fixes#52438.
Change-Id: I5cbf8c448dba037e9e0c5fe8f209401d6bf7d43f
Reviewed-on: https://go-review.googlesource.com/c/go/+/401134
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Be careful before accessing an operand's expr field (which may
be nil in some rare cases).
While at it, factor out position information so that it's only
computed when there's an error, which is almost never.
In go/types, remove an unnecessary argument to Checker.overflow.
The code is otherwise ok as it's structured slightly differently
due to the way positions are recorded in AST nodes.
Fixes#52401.
Change-Id: I447ebd9bb0c33eb6bff5e7b4d5aee37ceb0a4b14
Reviewed-on: https://go-review.googlesource.com/c/go/+/400798
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Before Go 1.18, an embedded type name in an interface could not be
parenthesized. With generalized embedding of types in interfaces,
where one might write ~(chan<- int) for clarity (making clear that
the ~ applies to the entire channel type), it also makes sense to
permit (chan<- int), or (int) for that matter.
Adjust the parser accordingly to match the spec.
(go/types already accepts the notation as specified by the spec.)
Fixes#52391.
Change-Id: Ifdd9a199c5ccc3473b2dac40dbca31d2df10d12b
Reviewed-on: https://go-review.googlesource.com/c/go/+/400797
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
The kernel's RNG is fast enough, and buffering means taking locks, which
we don't want to do. So just remove all buffering. This also means the
randomness we get is "fresher". That also means we don't need any
locking, making this potentially faster if multiple cores are hitting
GetRandom() at the same time on newer Linuxes.
Also, change the build tag of the tests to be 'unix' instead of
enumerating them.
Change-Id: Ia773fab768270d2aa20c0649f4171c5326b71d02
Reviewed-on: https://go-review.googlesource.com/c/go/+/390038
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We're using bufio to batch reads of /dev/urandom to 4k, but we weren't
doing the same on newer platforms with getrandom/getentropy. Since the
overhead is the same for these -- one syscall -- we should batch reads
of these into the same 4k buffer. While we're at it, we can simplify a
lot of the constant dispersal.
This also adds a new test case to make sure the buffering works as
desired.
Change-Id: I7297d4aa795c00712e6484b841cef8650c2be4ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/370894
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
Auto-Submit: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The x + (-y) => x - y rule is hitted 75 times while building stage 3 and tools
and make the linux-amd64 go binary 0.007% smaller.
It transform:
NEG AX
ADD BX, AX
Into:
SUB BX, AX
Which is 2X faster (assuming this assembly in a vacum).
The x ^ (-1) => ^x rule is not hitted in the toolchain.
It transforms:
XOR $-1, AX
Into:
NOT AX
Which is more compact as it doesn't encode the immediate.
Cache usage aside, this does not affect performance
(assuming this assembly in a vacum).
On my ryzen 3600, with some surrouding code, this randomly might be 2X faster,
I guess this has to do with loading the immediate into a temporary register.
Combined to an other rule that already exists it also rewrite manual two's
complement negation from:
XOR $-1, AX
INC AX
Into:
NEG AX
Which is 2X faster.
The other rules just eliminates similar trivial cases and help constants
folding.
This should generalise to other architectures.
Change-Id: Ia1e51b340622e7ed88e5d856f3b1aa424aa039de
GitHub-Last-Rev: ce35ff2efd
GitHub-Pull-Request: golang/go#52395
Reviewed-on: https://go-review.googlesource.com/c/go/+/400714
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Change-Id: If2887f84b3d14fac3c059fc5bad4186ec9d69d0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/401077
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
All APIs in the now-deprecated io/ioutil package have a direct
replacement in either the io or os package with the same signature,
with the notable exception of ioutil.ReadDir, as os.ReadDir has a
slightly different signature with fs.DirEntry rather than fs.FileInfo.
New code can easily make use of []fs.DirEntry directly,
but existing code may need to continue using []fs.FileInfo for backwards
compatibility reasons. For instance, I had a bit of code that exposed
the slice as a public API, like:
return ioutil.ReadDir(name)
It took me a couple of minutes to figure out what the exact equivalent
in terms of os.ReadDir would be, and a code sample would have helped.
Add one for future reference.
For #42026.
For #51927.
Change-Id: I76d46cd7d68fc609c873821755fdcfc299ffd56c
Reviewed-on: https://go-review.googlesource.com/c/go/+/399854
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The linker performs a global analysis of all nosplit call chains to
check they fit in the stack space ensured by splittable functions.
That analysis has two problems right now:
1. It's inefficient. It performs a top-down analysis, starting with
every nosplit function and the nosplit stack limit and walking *down*
the call graph to compute how much stack remains at every call. As a
result, it visits the same functions over and over, often with
different remaining stack depths. This approach is historical: this
check was originally written in C and this approach avoided the need
for any interesting data structures.
2. If some call chain is over the limit, it only reports a single call
chain. As a result, if the check does fail, you often wind up playing
whack-a-mole by guessing where the problem is in the one chain, trying
to reduce the stack size, and then seeing if the link works or reports
a different path.
This CL completely rewrites the nosplit stack check. It now uses a
bottom-up analysis, computing the maximum stack height required by
every function's call tree. This visits every function exactly once,
making it much more efficient. It uses slightly more heap space for
intermediate storage, but still very little in the scheme of the
overall link. For example, when linking cmd/go, the new algorithm
virtually eliminates the time spent in this pass, and reduces overall
link time:
│ before │ after │
│ sec/op │ sec/op vs base │
Dostkcheck 7.926m ± 4% 1.831m ± 6% -76.90% (p=0.000 n=20)
TotalTime 301.3m ± 1% 296.4m ± 3% -1.62% (p=0.040 n=20)
│ before │ after │
│ B/op │ B/op vs base │
Dostkcheck 40.00Ki ± 0% 212.15Ki ± 0% +430.37% (p=0.000 n=20)
Most of this time is spent analyzing the runtime, so for larger
binaries, the total time saved is roughly the same, and proportionally
less of the overall link.
If the new implementation finds an error, it redoes the analysis,
switching to preferring quality of error reporting over performance.
For error reporting, it computes stack depths top-down (like the old
algorithm), and reports *all* paths that are over the stack limit,
presented as a tree for compactness. For example, this is the output
from a simple test case from test/nosplit with two over-limit paths
from f1:
main.f1: nosplit stack overflow
main.f1
grows 768 bytes, calls main.f2
grows 56 bytes, calls main.f4
grows 48 bytes
80 bytes over limit
grows 768 bytes, calls main.f3
grows 104 bytes
80 bytes over limit
While we're here, we do a few nice cleanups:
- We add a debug output flag, which will be useful for understanding
what our nosplit chains look like and which ones are close to
running over.
- We move the implementation out of the fog of lib.go to its own file.
- The implementation is generally more Go-like and less C-like.
Change-Id: If1ab31197f5215475559b93695c44a01bd16e276
Reviewed-on: https://go-review.googlesource.com/c/go/+/398176
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Storing this information in the Arch eliminates some code duplication
between the compiler and linker. This information is entirely
determined by the Arch, so the current approach of attaching it to an
entire Ctxt is a little silly. This will also make it easier to use
this information from tests.
The next CL will be a rote refactoring to eliminate the
Ctxt.FixedFrameSize methods.
Change-Id: I315c524fa66a0ea99f63ae5a2a6fdc367d843bad
Reviewed-on: https://go-review.googlesource.com/c/go/+/400818
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When linking a PIE binary with the internal linker, TOC relative
relocations need to be generated. Update trampolines to indirect
call using R12 to more closely match the AIX/ELFv2 regardless of
buildmode, and work with position-indepdent code.
Likewise, update the check for offseting R_CALLPOWER relocs to
make a local call. It should be checking ldr.AttrExternal, not
ldr.IsExternal. This offset should not be adjusted for external
(non-go) object files, it is handled when ELF reloc are translated
into go relocs.
And, update trampoline tests to verify these are generated correctly
and produce a working binary using -buildmode=pie on ppc64le.
Fixes#52337
Change-Id: I8a2dea06c3237bdf0e87888b56a17b6c4c99a7de
Reviewed-on: https://go-review.googlesource.com/c/go/+/400234
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This allows the caller to decide whether MapIter should be
stack allocated or heap allocated based on whether it escapes.
In most cases, it does not escape and thus removes the utility
of MapIter.Reset (#46293). In fact, use of sync.Pool with MapIter
and calling MapIter.Reset is likely to be slower.
Change-Id: Ic93e7d39e5dd4c83e7fca9e0bdfbbcd70777f0e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/400675
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@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>
These timeouts are empirically sometimes (but rarely) too short on
slower builders, and at any rate if this test fails “for real” we'll
want a goroutine dump in order to debug it anyway. A goroutine dump is
exactly what we get if we let the test time out on its own.
Fixes#52414.
Change-Id: Id2dd3839977bd8a41f296d67d1cccbf068fd73f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/400816
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Endlineno is lost when we call "genericSubst" to create the new
instantiation of the generic function. This will cause "readFuncLines"
to fail to read the target function.
To fix this issue, as @mdempsky pointed out, add the line in
cmd/compile/internal/noder/stencil.go:
newf.Endlineno = gf.Endlineno
Fixes#51988
Change-Id: Ib408e4ed0ceb68df8dedda4fb551309e8385aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/399057
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This improves performance for memclr for sizes >= 64 and < 512 by
unrolling the loop to clear 64 bytes at a time, whereas before it was
doing 32 bytes.
On a power9, the improvement is:
Memclr/64 6.07ns ± 0% 5.17ns ± 0% -14.86% (p=1.000 n=1+1)
Memclr/256 11.8ns ± 0% 8.3ns ± 0% -30.10% (p=1.000 n=1+1)
GoMemclr/64 5.58ns ± 0% 5.02ns ± 0% -10.04% (p=1.000 n=1+1)
GoMemclr/256 12.0ns ± 0% 8.8ns ± 0% -26.62% (p=1.000 n=1+1)
Change-Id: I929389ae9e50128cba81e0c412e7ba431da7facc
Reviewed-on: https://go-review.googlesource.com/c/go/+/399895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
actualReader and tc.expectedReader are reflect.Type instances,
not the actual objects.
Change-Id: I7c9cfa489e3297b94c603b62bad1ed84bd207057
GitHub-Last-Rev: d581402375
GitHub-Pull-Request: golang/go#52339
Reviewed-on: https://go-review.googlesource.com/c/go/+/400235
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
This allows the result of Type to be computed much faster.
Performance:
old new delta
1.76ns 0.66ns -62.27%
Change-Id: Ie007fd175aaa41b2f67c71fa2a34ab8d292dd0e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/400335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
As is already done in strings package.
Change-Id: Ia45e6443ddf6beac5e70a1cc493119030e173139
GitHub-Last-Rev: 1174c25035
GitHub-Pull-Request: golang/go#52348
Reviewed-on: https://go-review.googlesource.com/c/go/+/400239
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This code was trying to iterate codepoints, but didn't reslice the string,
so it was reading the first codepoint over and over, if the string length was
not a multiple of the first codepoint length, this would cause to overshoot
past the end of the string.
This was a latent bug introduced in CL 384265 but was revealed to
Ngolo-fuzzing in OSS-Fuzz in CL 397277.
Fixes#52353
Change-Id: I13f0352e6ad13a42878927f3b1c18c58360dd40c
GitHub-Last-Rev: 424f6cfad1
GitHub-Pull-Request: golang/go#52356
Reviewed-on: https://go-review.googlesource.com/c/go/+/400240
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
No test because we already have a test in the syscall package.
The issue reports 1 failure per 100,000 iterations, which is rare enough
that our builders won't catch the problem.
Fixes#52226
Change-Id: I17633ff6cf676b6d575356186dce42cdacad0746
Reviewed-on: https://go-review.googlesource.com/c/go/+/400315
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
There are some symbol attributes that are encoded in the object
file. Currently, they are lost when cloning a symbol to external.
Copy them over.
Also delete CopyAttributes as it is no longer called anywhere.
Change-Id: I1497e3223a641704bf35aa3e904dd0eda2f8ec3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/400574
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
No separate test because this makes no difference for valid PE files.
Fixes#52350
Change-Id: I2aa011a4e8b34cb08052222e94c52627ebe99fbf
Reviewed-on: https://go-review.googlesource.com/c/go/+/400378
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The current implementation, although more succinct, relies on a runtime
lookup to a "constant" unexported map (which also needs to be
initialized at runtime).
The proposed implementation is able to be optimized by the compiler at
build-time, resulting in *much* more efficient instructions.
Additionally, unused string literals may even be removed altogether
from the generated binary in some cases.
This change is fully backwards-compatible behavior-wise with the
existing implementation.
Change-Id: I36450320aacff5b322195820552f2831d4fecd52
GitHub-Last-Rev: e2058f132e
GitHub-Pull-Request: golang/go#49811
Reviewed-on: https://go-review.googlesource.com/c/go/+/367201
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Refuse to create certificates with negative serial numbers, as they
are explicitly disallowed by RFC 5280.
We still allow parsing certificates with negative serial numbers,
because in the past there were buggy CA implementations which would
produce them (although there are currently *no* trusted certificates
that have this issue). We may want to revisit this decision if we can
find metrics about the prevalence of this issue in enterprise settings.
Change-Id: I131262008db99b6354f542f335abc68775a2d6d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/400494
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Auto-Submit: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>