The only ways to construct an OLITERAL node are (1) a basic literal
from the source package, (2) constant folding within evconst (which
only folds Go language constants), (3) the universal "nil" constant,
and (4) implicit conversions of nil to some concrete type.
Passes toolstash-check.
Change-Id: I30fc6b07ebede7adbdfa4ed562436cbb7078a2ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/166981
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
All setconst calls now happen within evconst. While here, get rid of
callrecv, which (incompletely) duplicates the logic of hascallchan.
Passes toolstash-check.
Change-Id: Ic67b9dd2a1b397d4bc25e8c8b6f81daf4f6cfb75
Reviewed-on: https://go-review.googlesource.com/c/go/+/166980
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We already have a pure go code sequence that is compiled into single load.
Just use it everywhere, instead of pointer hackery.
Passes toolstash-check.
Change-Id: I0c42b5532fa9a5665da3385913609c6d42aaff27
Reviewed-on: https://go-review.googlesource.com/c/go/+/118568
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This reduces the number of extra bounds check hints we need to
insert. For example, rather than producing:
_ = v.Args[2]
x := v.Args[0]
y := v.Args[1]
z := v.Args[2]
We now produce:
z := v.Args[2]
x := v.Args[0]
y := v.Args[1]
This gets rid of about 7000 lines of code from the rewrite rules.
Change-Id: I1291cf0f82e8d035a6d65bce7dee6cedee04cbcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/167397
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ppc64{,le} processor level selection allows the compiler to generate instructions
targeting newer processors and processor-specific optimizations without breaking
compatibility with our current baseline. This feature introduces a new environment
variable, GOPPC64.
GOPPC64 is a GOARCH=ppc64{,le} specific option, for a choice between different
processor levels (i.e. Instruction Set Architecture versions) for which the
compiler will target. The default is 'power8'.
Change-Id: Ic152e283ae1c47084ece4346fa002a3eabb3bb9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/163758
Run-TryBot: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When a jump at the end of a block is about to be marked as
a statement, if the first real instruction in the target
block is also a statement for the same line, remove the
mark from the jump.
This is a first effort at a minimal-harm heuristic.
A better heuristic might skip over any "not-statement"
values preceding a definitely marked value.
Fixes#29443.
Change-Id: Ibd52783713b4936e0c2dfda8d708bf186f33b00a
Reviewed-on: https://go-review.googlesource.com/c/go/+/159977
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This internally exported function allowed merging environment variable
lists, and was mostly a convenience for the rest of cmd/go/internal.
It seems to date all the way back to 2013.
However, since CL 37586 in early 2017, os/exec has already taken care of
deduplicating environment variable lists. Thus, it's unnecessary for
cmd/go to take care of that before calling exec.Cmd.Start.
Moreover, because os/exec will deduplicate the list in any case, we're
adding extra work in all these scenarios.
Finally, remove an unnecessary addition of GOROOT= in internal/tool.
cfg.OrigEnv may not have the correct GOROOT set up, but os.Environ does;
cmd/go's main function makes sure of that.
Change-Id: I1f92f65fb927dc15bc7b0397cfd1a572b6337bb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/164703
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Most of the decoding time is spent in the first Decode loop, since the
rest of the function only deals with the few remaining bytes. Any
unnecessary work done in that loop body matters tremendously.
One such unnecessary bottleneck was the use of the enc.decodeMap table.
Since enc is a pointer receiver, and the field is used within the
non-inlineable function decode64, the decoder must perform a nil check
at every iteration.
To fix that, move the enc.decodeMap uses to the parent function, where
we can lift the nil check outside the loop. That gives roughly a 15%
speed-up. The function no longer performs decoding per se, so rename it.
While at it, remove the now unnecessary receivers.
An unfortunate side effect of this change is that the loop now contains
eight bounds checks on src instead of just one. However, not having to
slice src plus the nil check removal well outweigh the added cost.
The other piece that made decode64 slow was that it wasn't inlined, and
had multiple branches. Use a simple bitwise-or trick suggested by Roger
Peppe, and collapse the rest of the bitwise logic into a single
expression. Inlinability and the reduced branching give a further 10%
speed-up.
Finally, add these two functions to TestIntendedInlining, since we want
them to stay inlinable.
Apply the same refactor to decode32 for consistency, and to let 32-bit
architectures see a similar performance gain for large inputs.
name old time/op new time/op delta
DecodeString/2-8 47.3ns ± 1% 45.8ns ± 0% -3.28% (p=0.002 n=6+6)
DecodeString/4-8 55.8ns ± 2% 51.5ns ± 0% -7.71% (p=0.004 n=5+6)
DecodeString/8-8 64.9ns ± 0% 61.7ns ± 0% -4.99% (p=0.004 n=5+6)
DecodeString/64-8 238ns ± 0% 198ns ± 0% -16.54% (p=0.002 n=6+6)
DecodeString/8192-8 19.5µs ± 0% 14.6µs ± 0% -24.96% (p=0.004 n=6+5)
name old speed new speed delta
DecodeString/2-8 84.6MB/s ± 1% 87.4MB/s ± 0% +3.38% (p=0.002 n=6+6)
DecodeString/4-8 143MB/s ± 2% 155MB/s ± 0% +8.41% (p=0.004 n=5+6)
DecodeString/8-8 185MB/s ± 0% 195MB/s ± 0% +5.29% (p=0.004 n=5+6)
DecodeString/64-8 369MB/s ± 0% 442MB/s ± 0% +19.78% (p=0.002 n=6+6)
DecodeString/8192-8 560MB/s ± 0% 746MB/s ± 0% +33.27% (p=0.004 n=6+5)
Updates #19636.
Change-Id: Ib839577b0e3f5a2bb201f5cae580c61365d92894
Reviewed-on: https://go-review.googlesource.com/c/go/+/151177
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
This change makes it possible the runtime-integrated network poller and
APIs in the package internal/poll to report an event scanning error on a
read event.
The latest Go releases open up the way of the manipulation of the poller
for users. On the other hand, it starts misleading users into believing
that the poller accepts any user-configured file or socket perfectly
because of not reporting any error on event scanning, as mentioned in
issue 30426. The initial implementation of the poller was designed for
just well-configured, validated sockets produced by the package net.
However, the assumption is now obsolete.
Fixes#30624.
Benchmark results on linux/amd64:
benchmark old ns/op new ns/op delta
BenchmarkTCP4OneShot-4 24649 23979 -2.72%
BenchmarkTCP4OneShotTimeout-4 25742 24411 -5.17%
BenchmarkTCP4Persistent-4 5139 5222 +1.62%
BenchmarkTCP4PersistentTimeout-4 4919 4892 -0.55%
BenchmarkTCP6OneShot-4 21182 20767 -1.96%
BenchmarkTCP6OneShotTimeout-4 23364 22305 -4.53%
BenchmarkTCP6Persistent-4 4351 4366 +0.34%
BenchmarkTCP6PersistentTimeout-4 4227 4255 +0.66%
BenchmarkTCP4ConcurrentReadWrite-4 2309 1839 -20.36%
BenchmarkTCP6ConcurrentReadWrite-4 2180 1791 -17.84%
benchmark old allocs new allocs delta
BenchmarkTCP4OneShot-4 26 26 +0.00%
BenchmarkTCP4OneShotTimeout-4 26 26 +0.00%
BenchmarkTCP4Persistent-4 0 0 +0.00%
BenchmarkTCP4PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP6OneShot-4 26 26 +0.00%
BenchmarkTCP6OneShotTimeout-4 26 26 +0.00%
BenchmarkTCP6Persistent-4 0 0 +0.00%
BenchmarkTCP6PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00%
BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00%
benchmark old bytes new bytes delta
BenchmarkTCP4OneShot-4 2000 2000 +0.00%
BenchmarkTCP4OneShotTimeout-4 2000 2000 +0.00%
BenchmarkTCP4Persistent-4 0 0 +0.00%
BenchmarkTCP4PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP6OneShot-4 2144 2144 +0.00%
BenchmarkTCP6OneShotTimeout-4 2144 2145 +0.05%
BenchmarkTCP6Persistent-4 0 0 +0.00%
BenchmarkTCP6PersistentTimeout-4 0 0 +0.00%
BenchmarkTCP4ConcurrentReadWrite-4 0 0 +0.00%
BenchmarkTCP6ConcurrentReadWrite-4 0 0 +0.00%
Change-Id: Iab60e504dff5639e688dc5420d852f336508c0af
Reviewed-on: https://go-review.googlesource.com/c/go/+/166497
Run-TryBot: Mikio Hara <mikioh.public.networking@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
-mcmodel=large and -Wl,-bbigtoc must always be passed to gcc in order to
prevent TOC overflow error. However, a warning is still issued by ld. It
is removed as it doesn't give any useful information.
Change-Id: I95a78e8993cc7b5c0f329654d507409785f7eea6
Reviewed-on: https://go-review.googlesource.com/c/go/+/164008
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
DWARF relocations isn't working with some older ld, because of
-Wl,-bnoobjreorder which is needed on Go.
This commit checks ld's version and disable DWARF generation in cmd/link
if it's too old. Some tests must therefore be skipped.
Change-Id: I2e794c263eb0dfe0b42e7062fb80c26f086b44d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/164007
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
With math/big supporting underscores directly, there is no need to
manually remove them before calling the math/big conversion routines.
Updates #28493.
Change-Id: I6f865c8f87c3469ffd6c33f960ed540135055226
Reviewed-on: https://go-review.googlesource.com/c/go/+/166417
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The primary change is in nat.scan which now accepts underscores for base 0.
While at it, streamlined error handling in that function as well.
Also, improved the corresponding test significantly by checking the
expected result values also in case of scan errors.
The second major change is in scanExponent which now accepts underscores when
the new sepOk argument is set. While at it, essentially rewrote that
function to match error and underscore handling of nat.scan more closely.
Added a new test for scanExponent which until now was only tested
indirectly.
Finally, updated the documentation for several functions and added many
new test cases to clients of nat.scan.
A major portion of this CL is due to much better test coverage.
Updates #28493.
Change-Id: I7f17b361b633fbe6c798619d891bd5e0a045b5c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/166157
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Lines with single cells prompt a flush. Unfortunately, a call to
Writer.Flush also means two defers, which is an expensive operation to
do if many lines consist of single cells.
This is common when formatting code with aligned comments. Most lines
aren't going to have any comments at all, so the performance hit is
going to be noticeable.
The Write method already has a "defer handlePanic" of its own, so we
don't need to worry about panics leaking out. The error will now mention
"Write" instead of "Flush" if a panic is encountered during that nested
flush, but arguably that's a good thing; the user called Write, not
Flush.
For the reset call, add a non-deferred call as part of flushNoDefers, as
that's still necessary. Otherwise, the exported Flush method still does
a "defer b.reset".
The current tabwriter benchmarks are unaffected, since they don't
contain many single-cell lines, and because lines are written one at a
time. For that reason, we add a benchmark which has both of these
characteristics.
name old time/op new time/op delta
Code-8 2.72µs ± 0% 1.77µs ± 0% -34.88% (p=0.000 n=6+5)
name old alloc/op new alloc/op delta
Code-8 648B ± 0% 648B ± 0% ~ (all equal)
name old allocs/op new allocs/op delta
Code-8 13.0 ± 0% 13.0 ± 0% ~ (all equal)
Perhaps unsurprisingly, go/printer also gets a bit faster, as it too
buffers its output before writing it to tabwriter.
name old time/op new time/op delta
Print-8 6.53ms ± 0% 6.39ms ± 0% -2.22% (p=0.008 n=5+5)
Change-Id: Ie01fea5ced43886a9eb796cb1e6c810f7a810853
Reviewed-on: https://go-review.googlesource.com/c/go/+/166797
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I typo'd this variable in CL 165745, and neither I, the reviewer, nor the TryBots noticed.
But the longtest builder noticed, and it's not happy about it.
Updates #30571
Change-Id: I5e3d267346407855ec0d1f340a72dc2c521ecc63
Reviewed-on: https://go-review.googlesource.com/c/go/+/167086
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test invokes 'go build', so in module mode it needs a module
cache to guard edits to go.mod.
Fixes#30776
Change-Id: I89ebef1fad718247e7f972cd830e31d6f4a83e4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/167085
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The sheer length of the generated rules files makes my
editor and git client unhappy.
This change is a small step towards shortening them.
We recognize a few magic variables during rulegen: b, config, fe, typ.
Of these, only b appears prone to false positives.
By tightening the heuristic and fixing one case in MIPS.rules,
we can make the heuristic enough that it has no failures.
That allows us to remove the hedge assignments to _,
removing 3000 pointless lines of code.
Change-Id: I080cde5db28c8277cb3fd9ddcd829306c9a27785
Reviewed-on: https://go-review.googlesource.com/c/go/+/166979
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#30123
Change-Id: I310b89a344a262bb758d39dfdd485ed2940cc6aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/166577
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GOPATH/pkg contains, among other things, the module cache (and associated lockfiles).
Fixes#30776
Change-Id: I305cb3c0daab8cedd2e6ad235d4733f66af18723
Reviewed-on: https://go-review.googlesource.com/c/go/+/167082
Reviewed-by: Jay Conrod <jayconrod@google.com>
Chdir leaves the test in the wrong working directory if objdumpOutput
calls t.Fatalf (or panics), and it isn't necessary here anyway. Set
the Dir field on the commands instead.
Change-Id: I9f0eb0d4f8d15043f1e13472126ca1a1ce4b7cb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/167081
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This CL documents the new binary and octal integer literals,
hexadecimal floats, generalized imaginary literals and digit
separators for all number literals in the spec.
Added empty lines between abutting paragraphs in some places
(a more thorough cleanup can be done in a separate CL).
A minor detail: A single 0 was considered an octal zero per the
syntax (decimal integer literals always started with a non-zero
digit). The new octal literal syntax allows 0o and 0O prefixes
and when keeping the respective octal_lit syntax symmetric with
all the others (binary_lit, hex_lit), a single 0 is not automatically
part of it anymore. Rather than complicating the new octal_lit syntax
to include 0 as before, it is simpler (and more natural) to accept
a single 0 as part of a decimal_lit. This is purely a notational
change.
R=Go1.13
Updates #12711.
Updates #19308.
Updates #28493.
Updates #29008.
Change-Id: Ib9fdc6e781f6031cceeed37aaed9d05c7141adec
Reviewed-on: https://go-review.googlesource.com/c/go/+/161098
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds a fast path for ASCII strings to both
strings.TrimSpace and bytes.TrimSpace. It doesn't slow down the
non-ASCII path much, if at all.
I added benchmarks for strings.TrimSpace as it didn't have any, and
I fleshed out the benchmarks for bytes.TrimSpace as it just had one
case (for ASCII). The benchmarks (and the code!) are now the same
between the two versions. Below are the benchmark results:
strings.TrimSpace:
name old time/op new time/op delta
TrimSpace/NoTrim-8 18.6ns ± 0% 3.8ns ± 0% -79.53% (p=0.000 n=5+4)
TrimSpace/ASCII-8 33.5ns ± 2% 6.0ns ± 3% -82.05% (p=0.008 n=5+5)
TrimSpace/SomeNonASCII-8 97.1ns ± 1% 88.6ns ± 1% -8.68% (p=0.008 n=5+5)
TrimSpace/JustNonASCII-8 144ns ± 0% 143ns ± 0% ~ (p=0.079 n=4+5)
bytes.TrimSpace:
name old time/op new time/op delta
TrimSpace/NoTrim-8 18.9ns ± 1% 4.1ns ± 1% -78.34% (p=0.008 n=5+5)
TrimSpace/ASCII-8 29.9ns ± 0% 6.3ns ± 1% -79.06% (p=0.008 n=5+5)
TrimSpace/SomeNonASCII-8 91.5ns ± 0% 82.3ns ± 0% -10.03% (p=0.008 n=5+5)
TrimSpace/JustNonASCII-8 150ns ± 0% 150ns ± 0% ~ (all equal)
Fixes#29122
Change-Id: Ica45cd86a219cadf60173ec9db260133cd1d7951
Reviewed-on: https://go-review.googlesource.com/c/go/+/152917
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
strings.HasPrefix is not good enough to determine whether a path
is a subdirectory of another because it does not respect path
boundaries. filepath.Rel is good eonugh as long as we filter out results
that use parent directories, "..".
Hopefully fix the android emulator builders on the subrepositories.
Change-Id: I17ee7e0028c0b0b26a6c5f67629f53c9a660c6e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/167117
Run-TryBot: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I thought I had removed all of the 'mod=vendor' hacks I had inserted
previously, but apparently missed this one in a bad merge or rebase.
Updates #30228
Change-Id: Ia5aea754bf986458373fefd08fa9dd3941e31e43
Reviewed-on: https://go-review.googlesource.com/c/go/+/167077
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The CL 164718 adds new condition flags for floating-point comparisons
in arm64 backend, but dose not add the handling in rewrite.go for
corresponding Ops, which causes issue 30679. And this CL fixes this
issue.
Fixes#30679
Change-Id: I8acc749f78227c3e9e74fa7938f05fb442fb62c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/166579
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Move the shared code into byteal.memeqbody. This will allow to implement
optimizations (e.g. for #29001) in a single function.
Change-Id: Iaa34ddeb7068d92c35a8b4e581b7fd92da56535c
Reviewed-on: https://go-review.googlesource.com/c/go/+/166677
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Support for FreeBSD 10 will be dropped with Go 1.13, so revert the
workaround introduced in CL 157099.
Updates #29633
Updates #27619
Change-Id: I1a2e50d3f807a411389f3db07c0f4535a590da02
Reviewed-on: https://go-review.googlesource.com/c/go/+/165801
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before this CL, uid/gid mapping was always set up from the parent
process, which is a privileged operation.
When using unprivileged user namespaces, a process can modify its
uid/gid mapping after the unshare(2) call (but setting the uid/gid
mapping from another process is NOT possible).
Fixes#29789
Change-Id: I8c96a03f5da23fe80bbb83ef051ad89cf185d750
Reviewed-on: https://go-review.googlesource.com/c/go/+/158298
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
New test for issue 30659 (compilation error due to bad
export data).
Updates #30659.
Change-Id: I2541ee3c379e5b22033fea66bb4ebaf720cc5e1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/166917
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The android emulator builders is running out of space after CL 165797
copied most of GOROOT to the device.
The pkg directory is by far the largest, so only include what seems
necessary to build the x/ repositories: pkg/android_$GOARCH and
pkg/tool/android_$GOARCH.
While here, rename the device root directory to match the exec
wrapper name and make sure the deferred cleanups actually run before
os.Exit.
Hopefully fixes the emulator builders.
Updates #23824
Change-Id: I4d1e3ab2c89fd1e5818503d323ddb87f073094da
Reviewed-on: https://go-review.googlesource.com/c/go/+/166397
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This also updates the vendored-in versions of several packages: 'go
mod vendor' selects a consistent version of each module, but we had
previously vendored an ad-hoc selection of packages.
Notably, x/crypto/hkdf was previously vendored in at a much newer
commit than the rest of x/crypto. Bringing the rest of x/crypto up to
that commit introduced an import of golang.org/x/sys/cpu, which broke
the js/wasm build, requiring an upgrade of x/sys to pick up CL 165749.
Updates #30228
Updates #30241
Updates #25822
Change-Id: I5b3dbc232b7e6a048a158cbd8d36137af1efb711
Reviewed-on: https://go-review.googlesource.com/c/go/+/164623
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This change preserves the maximum versions from cmd/vendor/vendor.json
where feasible, but bumps the versions of x/sys (for CL 162987) and
x/tools (for CL 162989 and CL 160837) so that 'go test all' passes in
module mode when run from a working directory in src/cmd.
A small change to cmd/vet (not vendored) was necessary to preserve its
flag behavior given a pristine copy of x/tools; see CL 162989 for more
detail.
This change was generated by running 'go mod vendor' at CL 164622.
(Welcoooome to the fuuuuuture!)
Updates #30228
Updates #30241
Change-Id: I889590318dc857d4a6e20c3023d09a27128d8255
Reviewed-on: https://go-review.googlesource.com/c/go/+/164618
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Two tests (load_le_byte8_uint64_inv and load_be_byte8_uint64)
pass but the generated code isn't actually correct.
The test regexp provides a false negative, as it matches the
MOVQ (SP), BP instruction in the epilogue.
Combined loads never worked for these cases - the test was added in error
as part of a batch and not noticed because of the above false match.
Normalize the amd64/386 tests to always negative match on narrower
loads and OR.
Change-Id: I256861924774d39db0e65723866c81df5ab5076f
Reviewed-on: https://go-review.googlesource.com/c/go/+/166837
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
os.Pipe is not implemented on wasm/js so for that purpose use
a temporary file for js/wasm. This change creates two versions
of runExample:
* runExample verbatim that still uses os.Pipe for non js/wasm
* runExample that uses a temporary file
Also added a TODO to re-unify these function versions back into
example.go wasm/js gets an os.Pipe implementation.
Change-Id: I9f418a49b2c397e1667724c7442b7bbe8942225e
Reviewed-on: https://go-review.googlesource.com/c/go/+/165357
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
