Also remove existing special cases that transform "go" into
gorootBinGo, because they make debugging and code-reviews more
difficult: log messages that don't include the full path can mask bugs
like #31567, and the reader of the code has to trace through the
various call chains to verify that the correct "go" is being used.
Instead, we can make the use of the correct "go" command plainly
obvious in the code by using one consistent name for it.
(Prior to this CL, we had three different names for it:
gorootBinGo, "go", and cmdGo. Now we have only one.
Updates #31567.
Change-Id: Ia9ff27e5e800c79af5a4e9f2803c9ea5ccafbf35
Reviewed-on: https://go-review.googlesource.com/c/go/+/452678
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Sym.Def used to be used for symbol resolution during the
old (pre-types2) typechecker. But since moving to types2-based IR
construction, we haven't really had a need for Sym.Def to ever refer
to anything but the package-scope definition, because types2 handles
symbol resolution for us.
This CL finally removes the Markdcl/Pushdcl/Popdcl functions that have
been a recurring source of issues in the past.
Change-Id: I2b012a0f17203efdd724ebd1e9314bd128cc2d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/458625
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
This CL removes a handful of features that were only needed for the
pre-unified frontends.
In particular, Type.Pkg was a hack for iexport so that
go/types.Var.Pkg could be precisely populated for struct fields and
signature parameters by gcimporter, but it's no longer necessary with
the unified export data format because we now write export data
directly from types2-supplied type descriptors.
Several other features (e.g., OrigType, implicit interfaces, type
parameters on signatures) are no longer relevant to the unified
frontend, because it only uses types1 to represent instantiated
generic types.
Updates #57410.
Change-Id: I84fd1da5e0b65d2ab91d244a7bb593821ee916e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/458622
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
These were used by the nounified frontend for representing
uninstantiated generic types; however, the unified frontend only needs
types1 to represent instantiated types.
Updates #57410.
Change-Id: Iac417fbf2b86f4e08bd7fdd26ae8ed17395ce833
Reviewed-on: https://go-review.googlesource.com/c/go/+/458621
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This CL removes most of the code specific to the nounified
frontend. To simplify review, it's a strict remove-only CL.
Updates #57410.
Change-Id: Ic3196570aa4286618c1d5e7fd0d0e6601a18195b
Reviewed-on: https://go-review.googlesource.com/c/go/+/458620
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
In the types1 universe under the unified frontend, we never need to
worry about type parameter constraints, so we only see pure
interfaces. However, we might still see interfaces that contain union
types, because of interfaces like "interface{ any | int }" (equivalent
to just "any").
We can handle these without needing to actually represent type unions
within types1 by simply mapping any union to "any".
Updates #57410.
Change-Id: I5e4efcf0339edbb01f4035c54fb6fb1f9ddc0c65
Reviewed-on: https://go-review.googlesource.com/c/go/+/458619
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Before this CL, the comment used the case of a recursive generic
function call as an example for uni-directional unification.
However, such cases are now more generally (and correctly) addressed
through renaming of the type parameters.
Change-Id: I69e94f53418e1fb4ca9431aeb27c639c40d19b09
Reviewed-on: https://go-review.googlesource.com/c/go/+/463735
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Doing this allows updates to swig so it can access slices
and strings in a somewhat less-unsafe way.
Change-Id: If2af8f8cf58d2287569dcd7c7ce09728e20b5ff0
Reviewed-on: https://go-review.googlesource.com/c/go/+/463396
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The getrandom syscall was added to NetBSD in version 10.0, see
https://man.netbsd.org/NetBSD-10.0-STABLE/getrandom.2
Change-Id: I2714c1040791f7f4728be8d869058a38cbd93d4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/463123
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
This CL marks some darwin assembly functions as NOFRAME to avoid relying
on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Change-Id: I797f3909bcf7f7aad304e4ede820c884231e54f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/460235
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Preserve sensitive headers on a redirect to a different port of the same host.
Fixes#35104
Change-Id: I5ab57c414ce92a70e688ee684b9ff02fb062b3c6
GitHub-Last-Rev: 8d53e71e22
GitHub-Pull-Request: golang/go#54539
Reviewed-on: https://go-review.googlesource.com/c/go/+/424935
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Now that GOEXPERIMENT=nounified is removed, we can assume InlineCall
and HaveInlineBody will always be overridden with the unified
frontend's implementations. Similarly, we can assume expandDecl will
never be called.
This CL changes the code paths into Fatalfs, so subsequent CLs can
remove all the unreachable code.
Updates #57410.
Change-Id: I2a0c3edb32916c30dd63c4dce4f1bd6f18e07468
Reviewed-on: https://go-review.googlesource.com/c/go/+/458618
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This flag forced the compiler to eagerly type check all available
inline function bodies, which presumably was useful in the early days
of implementing inlining support. However, it shouldn't have any
significance with the unified frontend, since the same code paths are
used for constructing normal function bodies as for inlining.
Updates #57410.
Change-Id: I6842cf86bcd0fbf22ac336f2fc0b7b8fe14bccca
Reviewed-on: https://go-review.googlesource.com/c/go/+/458617
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The use of typecheck.Resolve was previously necessary to interoperate
with the non-unified frontend, because it hooked into iimport. It's no
longer necessary with unified IR, where we can just lookup the
".inittask" symbol and access Def directly.
Updates #57410.
Change-Id: I73bdfd53f65988ececd2b777743cd8b591a6db48
Reviewed-on: https://go-review.googlesource.com/c/go/+/458616
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When we're compiling a resultInArg0 op, we need to clobber the
register containing the input value. So we first make a register copy
of the input value. We can then clobber either of the two registers
the value is in and still have the original input value in a register
for future uses.
Before this CL, we always clobbered the original, not the copy.
But that's not always the right decision - if the original is already
in a specific register that it needs to be in later (typically, a
return value register), clobber the copy instead.
This optimization can remove a mov instruction. It saves 1376 bytes
of instructions in cmd/go.
Redo of CL 460656, reverted at CL 463475, with a fix for s390x.
The new code just ensures that the copied value is in a register
which is a valid input register for the instruction.
Change-Id: Id570b8a60a6d2da9090de80a90b6bb0266e9e38a
Reviewed-on: https://go-review.googlesource.com/c/go/+/463221
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
runtime·cbctxts has been unused since CL 258938, but it was left over.
Change-Id: I374ad26e668a36994e41f5d17593b33090bdc644
Reviewed-on: https://go-review.googlesource.com/c/go/+/463119
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL removes the GOEXPERIMENT=nounified knob, and any conditional
statements that depend on that knob. Further CLs to remove unreachable
code follow this one.
Updates #57410.
Change-Id: I39c147e1a83601c73f8316a001705778fee64a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/458615
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
ExampleWithDeadline and ExampleWithTimeout used an arbitrary 1-second
timeout for a “blocked” select case, which could fail if the test
goroutine happens to be descheduled for over a second, or perhaps if
an NTP synchronization happens to jump by a second at just the right
time.
Either case is plausible, especially on a heavily-loaded or slow
machine (as is often the case for builders for unusual ports).
Instead of an arbitrary timeout, use a “ready” channel that is never
actually ready.
Fixes#57594.
Change-Id: I9ff68f50b041a3382e7b267c28c5259e886a9d23
Reviewed-on: https://go-review.googlesource.com/c/go/+/460999
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
The 1-second timeout on execution of this test is empirically too
short on some platforms. Rather than trying to tune the timeout, allow
the test to time out on its own (and dump goroutines) if it deadlocks.
Fixes#57993.
Fixes#57994.
Change-Id: I69ee86c75034469e4b4cd391b8dc5616b93468b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/463180
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Since this may add a large number of --export-dynamic-symbol options,
use a response file if the command line gets large.
Fixes#53579
Change-Id: Ic226bf372bf1e177a3dae886d1c48f4ce3569c0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/414654
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts CL 460656
Reason for revert: This breaks s390x.
Change-Id: I8fada14fabc90593b8033ed11188c04963d2da75
Reviewed-on: https://go-review.googlesource.com/c/go/+/463475
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
When we're compiling a resultInArg0 op, we need to clobber the
register containing the input value. So we first make a register copy
of the input value. We can then clobber either of the two registers
the value is in and still have the original input value in a register
for future uses.
Before this CL, we always clobbered the original, not the copy.
But that's not always the right decision - if the original is already
in a specific register that it needs to be in later (typically, a
return value register), clobber the copy instead.
This optimization can remove a mov instruction. It saves 1376 bytes
of instructions in cmd/go.
Change-Id: I162870c84b9a180da6715bb24c296a902974fed3
Reviewed-on: https://go-review.googlesource.com/c/go/+/460656
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
When calling a c library function, you discover that an error has
occurred, typically by looking at the return value of the function. Only
after that can you use errno to figure out the cause of the error.
Nothing about cgo changes that story -- you still have to look at the
result before checking the error that represents errno. If not you can
get false errors if the function happens to leak a non-zero errno.
Fix testpty to check errors correctly.
Change-Id: Idb95f8dd6a8ed63f653190c2e722e742cf50542b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463397
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This code path is unreachable anyway, and it adds new uses of
Type.Pkg, which shouldn't be used anymore.
Mark Type.Pkg as deprecated while here.
Updates #57410.
Change-Id: I1eec1c8ed99207d58d0ba0c44822bbad29dc64f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/458575
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This also makes path/filepath.Walk more consistent between
Windows and POSIX platforms.
According to
https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/basedefs/V1_chap04.html#tag_04_12
symlinks in a path that includes a trailing slash must be resolved
before a function acts on that path.
POSIX defines an lstat function, whereas the Win32 API does not, so
Go's os.Lstat should follow the (defined) POSIX semantics instead of
doing something arbitrarily different.
CL 134195 added a test for the correct POSIX behavior when os.Lstat is
called on a symlink. However, the test turned out to be broken on Windows,
and when it was fixed (in CL 143578) it was fixed with different Lstat
behavior on Windows than on all other platforms that support symlinks.
In #50807 we are attempting to provide consistent symlink behavior for
cmd/go. This unnecessary platform difference, if left uncorrected,
will make that fix much more difficult.
CL 460595 reworked the implementation of Stat and Lstat on Windows,
and with the new implementation this fix is straightforward.
For #50807.
Updates #27225.
Change-Id: Ia28821aa4aab6cefa021da2d9b803506cdb2621b
Reviewed-on: https://go-review.googlesource.com/c/go/+/463177
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
This CL adds the NOFRAME flag to runtime·rt0_go, which should
had been added in CL 459395 but didn't and broke fix windows-amd64-2008.
Change-Id: I4583f2034bf114e1f7aaddef9ba505f53536c3eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/463120
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Update race_windows_amd64.syso to latest tsan (V3) runtime.
This version of the runtime depends on libsynchronization.a, so to
use this syso, you need to also be using a sufficiently up to date
version of GCC (notably GCC 5.1, installed on the Go windows builders
right now, does not include this library).
Updates #48231.
Updates #35006.
Fixes#49761.
Change-Id: Ia1e2b1d8fe7e2c99728150734935a2c522006caa
Reviewed-on: https://go-review.googlesource.com/c/go/+/420197
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The various forkAndExecInChild implementations have comments
explaining that they pre-declare variables to force allocations
to occur before forking, but then later use ":=" declarations
for additional variables.
To make it clearer that those ":=" declarations do not allocate,
we move their declarations up to the predeclared blocks.
For #57208.
Change-Id: Ie8cb577fa7180b51b64d6dc398169053fdf8ea97
Reviewed-on: https://go-review.googlesource.com/c/go/+/456516
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This brings the exported field names on these GOARCHes
in line with the other supported linux platforms.
Fixes#57313.
Change-Id: I2107a7116ba60dc0c0a27f776318e3eb69e51682
Reviewed-on: https://go-review.googlesource.com/c/go/+/457557
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This helps simplify the noise when adding ppc codegen tests. ppc64x
is used in other places to indicate something which runs on either
endian.
This helps cleanup existing codegen tests which are mostly
identical between endian variants.
condmove tests are converted as an example.
Change-Id: I2b2d98a9a1859015f62db38d62d9d5d7593435b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/462895
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
Replace deprecated // +build lines by their respective //go:build line
counterpart. Also remove build constraints implied by file name or type.
Change-Id: I8d18cd40071ca28d7654da8f0d22841f43729ca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/460538
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
https://go.dev/cl/460543 stopped using the "expect" parameter in
bootstrapType, but we forgot to actually remove it.
While here, staticcheck correctly points out that we can use the copy
builtin to fill builtinIdToTypeSlice, now that it and idToType are an
array and slice respectively.
Change-Id: I48078415ab9bdd5633cf41f33ab4dc78eb30b48a
Reviewed-on: https://go-review.googlesource.com/c/go/+/462301
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This has been investigated and explained on the issue tracker.
Fixes#54402.
Change-Id: I4d8b971faa810591983ad028b7db16411f3b3b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/461456
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
This CL marks non-leaf nosplit assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Updates #57302
Updates #40044
Change-Id: Ia4d26f8420dcf2b54528969ffbf40a73f1315d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/459395
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This will be generated by go code built for dynamic linking when
built with GOPPC64=power10 in a future change.
Change-Id: I9bd7ca6b2a65c360465e35ef12b10d3fa6d75745
Reviewed-on: https://go-review.googlesource.com/c/go/+/463015
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation does a float64 to int64 conversion in order to check whether the number is odd, however it does not check for overflows. If an overflow occurs, the result is implementation-defined and while it happens to work on amd64 and i386, it produces an incorrect result on arm64 and possibly other architectures.
This change fixes that and also avoids calling isOddInt altogether if the base is +0, because it's unnecessary.
(I was considering avoiding the extra check if runtime.GOARCH is "amd64" or "i386", but I can't see this pattern being used anywhere outside the tests. And having separate files with build tags just for isOddInt() seems like an overkill)
Fixes#57465
Change-Id: Ieb243796194412aa6b98fac05fd19766ca2413ef
GitHub-Last-Rev: 3bfbd85c4c
GitHub-Pull-Request: golang/go#57494
Reviewed-on: https://go-review.googlesource.com/c/go/+/459815
Auto-Submit: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Bypass: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Change-Id: I3e9f05d221990b1ae464545d6d8b2e22c35bca21
Reviewed-on: https://go-review.googlesource.com/c/go/+/463077
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This reverts commit 3680b5e9c4.
Reason for revert: causes long compile times on certain functions. See issue #57959
Change-Id: Ie9e881ca8abbc79a46de2bfeaed0b9d6c416ed42
Reviewed-on: https://go-review.googlesource.com/c/go/+/463295
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The importcycles method has not been useful since April 2016 when a large code deletion was performed.
The compiler itself provides some protection against import cycles, and the linker does import cycle detection in linksetup -> postorder.
For #57400
Change-Id: I3095bdb3f16a82ba25681bf4a20ceaa3c9613921
GitHub-Last-Rev: 87a46153b1
GitHub-Pull-Request: golang/go#57462
Reviewed-on: https://go-review.googlesource.com/c/go/+/459475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
When -m=N (where N > 1) is in effect, include a note in the trace
output if a given function is considered "big" during inlining
analysis, since this causes the inliner to be less aggressive. If a
small change to a large function happens to nudge it over the large
function threshold, it can be confusing for developers, thus it's
probably worth including this info in the remark output.
Change-Id: Id31a1b76371ab1ef9265ba28a377f97b0247d0a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/460317
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Keith Randall <khr@google.com>
This CL updates File.readdir() on windows so it uses
GetFileInformationByHandleEx with FILE_ID_BOTH_DIR_INFO
instead of Find* APIs. The former is more performant because
it allows us to buffer IO calls and reduces the number of system calls,
passing from 1 per file to 1 every ~100 files
(depending on the size of the file name and the size of the buffer).
This change improve performance of File.ReadDir by 20-30%.
name old time/op new time/op delta
ReadDir-12 562µs ±14% 385µs ± 9% -31.60% (p=0.000 n=9+9)
name old alloc/op new alloc/op delta
ReadDir-12 29.7kB ± 0% 29.5kB ± 0% -0.88% (p=0.000 n=8+10)
name old allocs/op new allocs/op delta
ReadDir-12 399 ± 0% 397 ± 0% -0.50% (p=0.000 n=10+10)
This change also speeds up calls to os.SameFile when using FileStats
returned from File.readdir(), as their file ID can be inferred while
reading the directory.
Change-Id: Id56a338ee66c39656b564105cac131099218fb5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/452995
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
This CL removes badsignal2 function, as it is unused on Windows.
badsignal2 was originally intended to abort the process when
an exception was raised on a non-Go thread, following the same approach
as Linux and others.
Since it was added, back on https://golang.org/cl/5797068, it has caused
several issues on Windows, see #8224 and #50877. That's because we can't
know wether the signal is bad or not, as our trap might not be at the
end of the exception handler chain.
To fix those issues, https://golang.org/cl/104200046 and CL 442896
stopped calling badsignal2, and CL 458135 removed one last incorrect
call on amd64 and 386.
Change-Id: I5bd31ee2672118ae0f1a2c8b46a1bb0f4893a011
Reviewed-on: https://go-review.googlesource.com/c/go/+/463116
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
