CL 206078 introduced a stray errno check that was always false. This CL removes it.

Updates #35276

Change-Id: I6996bb595d347fe81752786a3d83d3432735c9cb
GitHub-Last-Rev: e026e71b16c8532ad707a0b43b4f02c7a366257e
GitHub-Pull-Request: golang/go#35650
Reviewed-on: https://go-review.googlesource.com/c/go/+/207577
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This allows maphash.Hash to be allocated on the stack for typical uses.

Fixes #35636

Change-Id: I8366507d26ea717f47a9fb46d3bd69ba799845ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/207444
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #35616

Change-Id: I51b2490100cfe0e902da09eee8d027e0ec86ed53
Reviewed-on: https://go-review.googlesource.com/c/go/+/207466
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

On AIX, addresses returned by mmap are between 0x0a00000000000000
and 0x0afffffffffffff. The previous solution to handle these large
addresses was to increase the arena size up to 60 bits addresses,
cf CL 138736.

However, with the new page allocator, the 60bit heap addresses are
causing huge memory allocations, especially by (s *pageAlloc).init. mmap
and munmap syscalls dealing with these allocations are reducing
performances of every Go programs.

In order to avoid these allocations, arenaBaseOffset is set to
0x0a00000000000000 and heap addresses are on 48bit, as others operating
systems.

Updates: #35451

Change-Id: Ice916b8578f76703428ec12a82024147a7592bc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/206841
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

This reverts CL 207352

Reason for revert: broke more builders than it fixed. 😞

Change-Id: Ic5adefe92edfa2230b9c7d750c922473a6a5ded4
Reviewed-on: https://go-review.googlesource.com/c/go/+/207477Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The test is inherently slightly flaky, so repeat to reduce flakiness.

Fixes #35537

Change-Id: Id918d48d33c7d5e19c4f24df104adc7fbf3720f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/207457
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When we run tests, we may need to write the test binary (and/or test
variants of its dependencies) to GOCACHE. (This also fixes several
test cases in cmd/go, which preserves the GOCACHE variable for
efficiency.)

It is highly unlikely that tests will try to modify .git, and that
directory contains many files, so don't bother with it.

Updates #30316

Change-Id: Id11136c6c64d8f0afc6c6ba5d94c9269df231052
Reviewed-on: https://go-review.googlesource.com/c/go/+/207441
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I5b909df0fd048cd66c5a27fca1b06466d3bcaac7
GitHub-Last-Rev: 778c5d21311abee09a5fbda2e4005a5fd4cc3f9f
GitHub-Pull-Request: golang/go#35624
Reviewed-on: https://go-review.googlesource.com/c/go/+/207421
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

CL 205340 changed the linker to skip certain flags when linking
for iOS. However, for host linking on iOS (such as on the Corellium
darwin/arm64 builders) the MachO platform defaults to PLATFORM_MACOS,
and the flags are not skipped.

Avoids warnings such as

    ld: warning: -no_pie ignored for arm64

Updates #32963

Change-Id: Ib6b4c2375fd14cf89410bf5ff1537b692b7a1c15
Reviewed-on: https://go-review.googlesource.com/c/go/+/206337
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

While running various tests for #28387, I keep ending up with an
unwritable GOROOT after a failure.

While the unwritable GOROOT is a fairly exotic condition (normally
only happens on builders), it's somewhat annoying when debugging, so
I'm switching all of the log.Fatal* call sites to use the existing
fatalf function, which supports general atexit-like cleanup.

Updates #28387

Change-Id: I473cda7eacd9ad82bdeab647766373126dc7390e
Reviewed-on: https://go-review.googlesource.com/c/go/+/207341
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Updates #28387
Fixes #35619

Change-Id: I162f3427b7901c117e3f3e403df7edec7c529bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/207352
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Previously, we were writing binaries to GOROOT without ever reading them.

Updates #28387

Change-Id: Ic84999f46a367fcbf2ae1eac8bfdcbceb24dc748
Reviewed-on: https://go-review.googlesource.com/c/go/+/207342
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #33848

Change-Id: I505490906be7cd6fbcdc6a05c1017c779dbf7bba
Reviewed-on: https://go-review.googlesource.com/c/go/+/207397
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #34254

Change-Id: Ib4e476d31264342538c2cf381177823183cba890
Reviewed-on: https://go-review.googlesource.com/c/go/+/206761
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>

Fixes #35617

Change-Id: I514f4e5f80ba9866c5cad3eb1fecd6f346c82f14
Reviewed-on: https://go-review.googlesource.com/c/go/+/207340
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

In scavengeOne's fast path, we currently don't check the summary for the
chunk that scavAddr points to, which means that we might accidentally
scavenge unused address space if the previous scavenge moves the
scavAddr into that space. The result of this today is a crash.

This change makes it so that scavengeOne's fast path only happens after
the check, following the comment in mpagealloc.go. It also adds a test
for this case.

Fixes #35465.
Updates #35112.

Change-Id: I861d44ee75e42a0e1f5aaec243bc449228273903
Reviewed-on: https://go-review.googlesource.com/c/go/+/206978
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Go specification says: A value x is assignable to a variable of type T if x
is a bidirectional channel value, T is a channel type, x's type V and T have
identical element types, and at least one of V or T is not a defined type.
However, the current reflection implementation is incorrect which makes
"x is assignable to T" even if type V and T are both defined type.

The current reflection implementation also mistakes the base types of two
non-defined pointer types share the same underlying type when the two
base types satisfy the above mentioned special channel assignability rule.

Fixes #29469

Change-Id: Ia4b9c4ac47dc8e76a11faef422b2e5c5726b78b3
GitHub-Last-Rev: 487c20a564091a1d2ba5feb95ab5196331c699c2
GitHub-Pull-Request: golang/go#29739
Reviewed-on: https://go-review.googlesource.com/c/go/+/157822
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Like on other 64-bit GOARCHes, EpollEvent needs padding before Fd for
mips64 and mips64le.

Change-Id: I87773a1b305552ab4ed039623b40d2fff1f20d9b
Reviewed-on: https://go-review.googlesource.com/c/go/+/207298
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The 2-instruction TLS access sequence
	MOVQ TLS, BX
	MOVQ 0(BX)(TLS*1), BX
is not async preemptible, as if it is preempted and resumed on a
different thread, the TLS address may become invalid.

May fix #35349. (This is a rare failure and I haven't been able
to reproduce it.)

Change-Id: Ie1a366fd0d7d73627dc62ee2de01c0aa09365f2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/206903
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>

When we receive a signal, if G is nil we call badsignal, which
calls needm. When cgo is not used, there is no extra M, so needm
will just hang. In this situation, even GOTRACEBACK=crash cannot
get a stack trace, as we're in the signal handler and cannot
receive another signal (SIGQUIT).

Instead, just crash.

For #35554.
Updates #34391.

Change-Id: I061ac43fc0ac480435c050083096d126b149d21f
Reviewed-on: https://go-review.googlesource.com/c/go/+/206959
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The existing implementation is erroneously assume that having no
deadline in context.Context means that time returned from Deadline
method will have IsZero() == true. But technically speaking this is an
invalid assumption. The context.Context interface specification doesn't
specify what time should be returned from Deadline method when there is
no deadline set. It only specifies that second result of Deadline should
be false.

Fixes #35594

Change-Id: Ife00aad77ab3585e469f15017550ac6c0431b140
Reviewed-on: https://go-review.googlesource.com/c/go/+/207297
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When -trimpath is used, packages built from the module cache still
have debug into that contains the module path and version. Only the
module cache directory is stripped.

With this CL, we now include the module path and version in the cache
key for build actions.

Fixes #35412

Change-Id: I1956592d0d86fcea2cca7c5fc8957e83543d6aa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/207317
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Updates #28387
Updates #30316
Fixes #35574

Change-Id: I21c9e18573909e092ed8dcec91b8542bb97e9f5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/207263Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The NDK is switching to ldd, and will stop including the gold linker.

Change-Id: If74168017c9874134b34010906ab1d94001528b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/206840
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

tryAdd shouldn't succeed (and accept the new frame) if the last
existing frame on the deck is not an inlined frame.

For example, when we see the followig stack
[300656 300664 300655 300664]

with each PC corresponds to

[{PC:300656 Func:nil Function:runtime.nanotime File:/workdir/go/src/runtime/time_nofake.go Line:19 Entry:300416 {0x28dac8 0x386c80}}]
[{PC:300664 Func:0x28dac8 Function:runtime.checkTimers File:/workdir/go/src/runtime/proc.go Line:2623 Entry:300416 {0x28dac8 0x386c80}}]
[{PC:300655 Func:nil Function:runtime.nanotime File:/workdir/go/src/runtime/time_nofake.go Line:19 Entry:300416 {0x28dac8 0x386c80}}]
[{PC:300664 Func:0x28dac8 Function:runtime.checkTimers File:/workdir/go/src/runtime/proc.go Line:2623 Entry:300416 {0x28dac8 0x386c80}}]

PC:300656 and PC:300664 belong to a single location entry,
but the bug in the current tryAdd logic placed the entire stack into one
location entry.

Also adds tests - this crash is a tricky case to test because I think it
should happen with normal go code. The new TestTryAdd simulates it by
using fake call sequences. The test crashed without the fix.

Update #35538

Change-Id: I6d3483f757abf4c429ab91616e4def90832fc04a
Reviewed-on: https://go-review.googlesource.com/c/go/+/206958Reviewed-by: Keith Randall <khr@golang.org>

Fixes #35085

Change-Id: Ice611e1223392f687061a43fd4c2298ea22774fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/207081
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Fixes #35492

Change-Id: I00dce8fd1228f809e0c61013ac4de7a5953cbbf9
Reviewed-on: https://go-review.googlesource.com/c/go/+/206997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

'go build' now reports a more useful error when a relative path on the
command line points to a directory that doesn't exist or a directory
without .go files. Errors are generated by go/build.Context.ImportDir
instead of a vague call to base.Fatalf in modload.

Fixes #35414

Change-Id: I2642230c5e409107b98bb6d6c3a484d8d25b4147
Reviewed-on: https://go-review.googlesource.com/c/go/+/206902
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

It turns out that there is a path that initializes netpoll and opens
file descriptors before running the os/exec init function: on some
systems, the uses of NewFile when setting os.Stdin and friends can
initialize netpoll which can open file descriptors. This in itself
is not a problem, but when we check whether the new files are open
using os.NewFile, a side-effect is to put them into non-blocking mode.
This can then break future uses of netpoll.

Updates #35469
Fixes #35566

Change-Id: I1b2e2c943695d1c2d29496b050abbce9ee710a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/207078Reviewed-by: Bryan C. Mills <bcmills@google.com>

The bash version of the test wrote intermediate files to its testdata directory.

Updates #28387
Updates #30316
Fixes #35536

Change-Id: Ib81b547d3c43e90df713a2172c8f399fefb53c68
Reviewed-on: https://go-review.googlesource.com/c/go/+/206901
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The bounds in the last carry branch were wrong as there
is no reason for len(u) >= n+n/2 to always hold true.

We also adjust test to avoid using a remainder of 1
(in which case, the last step of the algorithm computes
(qhatv+1) - qhatv which rarely produces a carry).

Change-Id: I69fbab9c5e19d0db1c087fbfcd5b89352c2d26fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/206839
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

In the discussion of CL 171828 we decided that it was not necessary to
acquire timersLock around the call to moveTimers, because the world is
stopped. However, that is not correct, as sysmon runs even when the world
is stopped, and it calls timeSleepUntil which looks through the timers.
timeSleepUntil acquires timersLock, but that doesn't help if moveTimers
is running at the same time.

Updates #6239
Updates #27707
Updates #35462

Change-Id: I346c5bde594c4aff9955ae430b37c2b6fc71567f
Reviewed-on: https://go-review.googlesource.com/c/go/+/206938
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

Change-Id: I09090effcc5d814d4e024da3f944e825365588f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/205477
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Test fix: in dwarf_test.go don't try to run the TestDWARF testpoint on
windows with c-archive build mode (linker + debug/pe support for that
build mode on Windows is not fully baked it seems).

Fixes #35512.

Change-Id: I1c87ff3d62e5b98e75062b184d762fb5ed937745
Reviewed-on: https://go-review.googlesource.com/c/go/+/206899
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Our attempts to close existing open files are flaky. They will fail if,
for example, file descriptor 3 is open when the test binary starts.
Instead, report any such cases, and skip TestExtraFiles.

Updates #35469

Change-Id: I7caec083f3f4a31579bf28fc9c82ae89b1bde49a
Reviewed-on: https://go-review.googlesource.com/c/go/+/206939Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

change "fp" to "fd".

Change-Id: I00e5fafcb68891356d508c49aa89969bfed7ed10
GitHub-Last-Rev: b06f976a3bacc6fc6f1fd0e4fc8c50da9764f736
GitHub-Pull-Request: golang/go#35557
Reviewed-on: https://go-review.googlesource.com/c/go/+/207038Reviewed-by: Keith Randall <khr@golang.org>

In CL 206757 I added a log.Printf to identify when GOROOT is not read-only.
However, it interacts badly with test sharding in the builders:
the log is repeated for every shard.

Since the log statement isn't particularly high-value, just remove it.

Updates #30316

Change-Id: I385a7f35da59e38ad8b9beef92dc11af931d9571
Reviewed-on: https://go-review.googlesource.com/c/go/+/206898
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Not a fix, but will give us more info when it flakes again.

Updates #35113

Change-Id: I2f90c24530c1bea81dd9d8c7a59f4b0640dfa4c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/206819
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>

Provide initial linker support for riscv64.

Based on riscv-go port.

Updates #27532

Change-Id: I8a881ce41cd49efef0358bad9171d4d18aaf7ab2
Reviewed-on: https://go-review.googlesource.com/c/go/+/204624
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Change-Id: Icd5006e37861d892a5f3d4397c3826179c1b12ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/206657
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>