Russ Cox [Wed, 11 Mar 2020 04:02:04 +0000 (00:02 -0400)]
cmd/compile: fix buggy AMD64 rewrite from CL 213058
CL 213058's "bonus optimization I noticed while working on this"
turns out to be buggy. It would be correct for CMP, but not TEST.
Fix it to use TEST semantics instead.
This was breaking compilation with the upcoming Spectre mode.
Change-Id: If2d4c3798ed182f35f0244febe74e68c61e4c61b
Reviewed-on: https://go-review.googlesource.com/c/go/+/222853 Reviewed-by: Keith Randall <khr@golang.org>
Bryan C. Mills [Wed, 11 Mar 2020 13:39:54 +0000 (09:39 -0400)]
runtime: skip TestSignalIgnoreSIGTRAP on known-flaky OpenBSD builders
This test is flaky, and the cause is suspected to be an OpenBSD kernel bug.
Since there is no obvious workaround on the Go side, skip the test on
builders whose versions are known to be affected.
Fixes #17496
Change-Id: Ifa70061eb429e1d949f0fa8a9e25d177afc5c488
Reviewed-on: https://go-review.googlesource.com/c/go/+/222856
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>
This change forces CFGs to take the full width of their column
and allows them to be as tall as necessary.
In my (recent) experience, this makes them far less likely to
be cropped, which makes them much more useful.
On rare occasions, this can lead to gigantic CFGs,
but if you've bothered to explicitly request a CFG,
this is still better than an irrevocably truncated CFG.
erifan01 [Sun, 23 Dec 2018 02:15:44 +0000 (02:15 +0000)]
strings, bytes: improve IndexAny and LastIndexAny performance
For the case of a pattern containing multi-byte rune, the time complexity of the
previous algorithm is O(nm), and if both input arguments are long, the search
performance will be poor. This CL improves the searching performance for these
cases by using IndexRune, which is mainly implemented with IndexByte and Index.
As IndexByte and Index are specially optimized with some powerful instructions
for short patterns (an UTF8 rune is 1 to 4 bytes), so they can help to reduce the
runtime complexity of IndexAny and LastIndexAny.
Another optimization method is using hash table, however, the actual test results
show that using indexrune is better, and the space complexity is lower.
There are two fast paths in IndexAny and LastIndexAny for cases where the length
of the input arguements are 1, and their locations are not exactly the same, which
is determined based on the actual test results.
Change-Id: Ie05e306f8b184b989701868cb161ce8b3f18203b
Reviewed-on: https://go-review.googlesource.com/c/go/+/156998
Run-TryBot: eric fang <eric.fang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Dan Scales [Thu, 5 Mar 2020 20:46:04 +0000 (12:46 -0800)]
runtime: fix problem with repeated panic/recover/re-panics and open-coded defers
In the open-code defer implementation, we add defer struct entries to the defer
chain on-the-fly at panic time to represent stack frames that contain open-coded
defers. This allows us to process non-open-coded and open-coded defers in the
correct order. Also, we need somewhere to be able to store the 'started' state of
open-coded defers. However, if a recover succeeds, defers will now be processed
inline again (unless another panic happens). Any defer entry representing a frame
with open-coded defers will become stale once we run the corresponding defers
inline and exit the associated stack frame. So, we need to remove all entries for
open-coded defers at recover time.
The current code was only removing the top-most open-coded defer from the defer
chain during recovery. However, with recursive functions that do repeated
panic-recover-repanic, multiple stale entries can accumulate on the chain. So, we
just adjust the loop to process the entire chain. Since this is at panic/recover
case, it is fine to scan through the entire chain (which should usually have few
elements in it, since most defers are open-coded).
The added test fails with a SEGV without the fix, because it tries to run a stale
open-code defer entry (and the stack has changed).
Fixes #37664.
Change-Id: I8e3da5d610b5e607411451b66881dea887f7484d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222420
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Than McIntosh [Fri, 7 Feb 2020 19:00:26 +0000 (14:00 -0500)]
cmd/link: fix for package name attr testpoint in dwarf_test.go
Tighten up a testpoint that looks for the compile unit
DW_AT_go_package_name attribute. The linker code that injects this
attribute was accidentally broken on the dev.link branch, but in a way
that wasn't detected by the test (attr was generated, but always with
an empty string). The new test will fail if the attr is an empty
string, or if we can't find the attribute for the runtime package.
Change-Id: I8b065e7eb3486646364d0eaf48a73db6acffbd18
Reviewed-on: https://go-review.googlesource.com/c/go/+/218483
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Bryan C. Mills [Thu, 5 Mar 2020 21:17:45 +0000 (16:17 -0500)]
cmd/go/internal/lockedfile: use a retry loop to suppress EDEADLK on AIX and Solaris
AIX, Solaris, and Illumos all appear to implement fcntl deadlock
detection at the granularity of processes. However, we are acquiring
and releasing file locks on individual goroutines running
concurrently: our locking occurs at a much finer granularity. As a
result, these platforms occasionally fail with EDEADLK errors, when
they detect locks that would be _misordered_ in a single-threaded
program but are safely _unordered_ in a multi-threaded context.
To work around the spurious errors, we treat EDEADLK as always
spurious, and retry the failing system call with a bounded exponential
backoff. This approach may introduce substantial latency since we no
longer benefit from kernel-scheduled wakeups in case of collisions,
but high-latency operations seem better than spurious failures.
Updates #33974
Updates #35618
Fixes #32817
Change-Id: I58b2c6a0f143bce55d6460fd4ddc3db83577ada7
Reviewed-on: https://go-review.googlesource.com/c/go/+/222277 Reviewed-by: Jay Conrod <jayconrod@google.com>
Keith Randall [Fri, 6 Mar 2020 22:01:26 +0000 (14:01 -0800)]
runtime: make typehash match compiler generated hashes exactly
If typehash (used by reflect) does not match the built-in map's hash,
then problems occur. If a map is built using reflect, and then
assigned to a variable of map type, the hash function can change. That
causes very bad things.
This issue is rare. MapOf consults a cache of all types that occur in
the binary before making a new one. To make a true new map type (with
a hash function derived from typehash) that map type must not occur in
the binary anywhere. But to cause the bug, we need a variable of that
type in order to assign to it. The only way to make that work is to
use a named map type for the variable, so it is distinct from the
unnamed version that MapOf looks for.
smasher164 [Thu, 27 Feb 2020 08:44:13 +0000 (03:44 -0500)]
cmd/vet: add ifaceassert and stringintconv checks
This change re-vendors x/tools to add the ifaceassert and stringintconv
checks to cmd/vet.
Fixes #32479.
Updates #4483.
Change-Id: I6bd30b0a3278592dfab4bd247036404ddaff09e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/221339
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Keith Randall [Thu, 30 Jan 2020 18:17:01 +0000 (10:17 -0800)]
cmd/compile: insert complicated x86 addressing modes as a separate pass
Use a separate compiler pass to introduce complicated x86 addressing
modes. Loads in the normal architecture rules (for x86 and all other
platforms) can have constant offsets (AuxInt values) and symbols (Aux
values), but no more.
The complex addressing modes (x+y, x+2*y, etc.) are introduced in a
separate pass that combines loads with LEAQx ops.
Organizing rewrites this way simplifies the number of rewrites
required, as there are lots of different rule orderings that have to
be specified to ensure these complex addressing modes are always found
if they are possible.
smasher164 [Thu, 27 Feb 2020 07:42:28 +0000 (02:42 -0500)]
std,cmd: update x/net and github.com/google/pprof
Re-vendor x/net/dns/dnsmessage, x/net/route, and github.com/google/pprof
(commit 1ebb73c). The updated dependencies fix the string(int)
conversions, in preparation for the vet warning.
Updates #32479.
Change-Id: I023a4e30415d060f8b403b9943fe911f6d19f2e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/221337
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/compile: use only bit patterns in isNonNegative
CL 212777 added a check to isNonNegative
to return true for unsigned values.
However, the SSA backend isn't type safe
enough for that to be sound.
The other checks in isNonNegative
look only at the pattern of bits.
Remove the type-based check.
Keith Randall [Mon, 9 Mar 2020 19:46:45 +0000 (12:46 -0700)]
cmd/compile: remove -largemodel flag from docs
It does nothing (it can't even be parsed).
Change-Id: I29abdddea1955d2ad93a97696f6542fa47cdb954
Reviewed-on: https://go-review.googlesource.com/c/go/+/222672 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Neven Sajko [Sat, 7 Mar 2020 17:23:20 +0000 (17:23 +0000)]
internal/xcoff: fix wrong bit masking comparisons
I do not know much about xcoff, but this was probably the intended
behavior. (The comparison is tautologically false, as is.)
Also note: does any other code even depend on the changed code existing?
Maybe it should just be removed, as I did not find any uses of fields
that are written to if the branch condition tests true.
Change-Id: I1f23d33764df40e87f3e64460d63f6efc51a2a78
GitHub-Last-Rev: 268909130fd7fb3993fcf7004143ec48dbfe5e2a
GitHub-Pull-Request: golang/go#37733
Reviewed-on: https://go-review.googlesource.com/c/go/+/222478
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Clément Chigot <clement.chigot%atos.net@gtempaccount.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 8 Jan 2020 16:00:44 +0000 (11:00 -0500)]
test/run: make GO_GCFLAGS mean same thing it does during make.bash
-gcflags=-flag means apply the flags only to the package named
on the command line (the main package, for these tests).
-gcflags=all=-flag means apply the flags to everything in the build,
including the standard library.
cmd/dist uses -gcflags=all=$GO_GCFLAGS, so test/run should do the same,
as the comment already explains, to avoid rebuilding the entire standard
library without the flags during test/run's builds.
We changed the scope of the flags without a pattern a few releases
ago and missed this one.
An Long [Fri, 6 Mar 2020 23:31:35 +0000 (23:31 +0000)]
mime: add .json to built-in list of MIME types
Since json is popular and mime package's builtin type does not contain
it, and some Linux distributions do not contain the '/etc/mime.types' file
with minimal installations.
Jay Conrod [Thu, 5 Mar 2020 16:11:47 +0000 (11:11 -0500)]
cmd/go: make go test -json report failures for panicking/exiting tests
'go test -json' should report that a test failed if the test binary
did not exit normally with status 0. This covers panics, non-zero
exits, and abnormal terminations.
These tests don't print a final result when run with -test.v (which is
used by 'go test -json'). The final result should be "PASS" or "FAIL"
on a line by itself. 'go test' prints "FAIL" in this case, but
includes error information.
test2json was changed in CL 192104 to report that a test passed if it
does not report a final status. This caused 'go test -json' to report
that a test passed after a panic or non-zero exit.
With this change, test2json treats "FAIL" with error information the
same as "FAIL" on a line by itself. This is intended to be a minimal
fix for backporting, but it will likely be replaced by a complete
solution for #29062.
Fixes #37555
Updates #29062
Updates #31969
Change-Id: Icb67bcd36bed97e6a8d51f4d14bf71f73c83ac3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222243
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Michael Pratt [Fri, 28 Feb 2020 19:16:41 +0000 (14:16 -0500)]
runtime/pprof: expand final stack frame to avoid truncation
When generating stacks, the runtime automatically expands inline
functions to inline all inline frames in the stack. However, due to the
stack size limit, the final frame may be truncated in the middle of
several inline frames at the same location.
As-is, we assume that the final frame is a normal function, and emit and
cache a Location for it. If we later receive a complete stack frame, we
will first use the cached Location for the inlined function and then
generate a new Location for the "caller" frame, in violation of the
pprof requirement to merge inlined functions into the same Location.
As a result, we:
1. Nondeterministically may generate a profile with the different stacks
combined or split, depending on which is encountered first. This is
particularly problematic when performing a diff of profiles.
2. When split stacks are generated, we lose the inlining information.
We avoid both of these problems by performing a second expansion of the
last stack frame to recover additional inline frames that may have been
lost. This expansion is a bit simpler than the one done by the runtime
because we don't have to handle skipping, and we know that the last
emitted frame is not an elided wrapper, since it by definition is
already included in the stack.
Fixes #37446
Change-Id: If3ca2af25b21d252cf457cc867dd932f107d4c61
Reviewed-on: https://go-review.googlesource.com/c/go/+/221577
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Robert Griesemer [Thu, 27 Feb 2020 05:31:00 +0000 (21:31 -0800)]
cmd/compile/internal/syntax: faster and simpler source reader
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 3 of 3:
This change contains a complete rewrite of source.go, the file that
implements reading individual Unicode characters from the source.
The new implementation is easier to use and has simpler literal
buffer management, resulting in faster scanner and thus parser
performance.
Thew new source.go (internal) API is centered around nextch() which
advances the scanner by one character. The scanner has been adjusted
around nextch() and now consistently does one character look-ahead
(there's no need for complicated ungetr-ing anymore). Only in one
case backtrack is needed (when finding '..' rather than '...') and
that case is now more cleanly solved with the new reset() function.
Measuring line/s parsing peformance by running
go test -run StdLib -fast -skip "syntax/(scanner|source)\.go"
(best of 5 runs on "quiet" MacBook Pro, 3.3GHz Dual-Core i7, 16GB RAM,
OS X 10.15.3) before and after shows consistently 3-5% improvement of
line parsing speed:
old: parsed 1788155 lines (3969 files) in 1.255520307s (1424234 lines/s)
new: parsed 1788155 lines (3969 files) in 1.213197037s (1473919 lines/s)
(scanner.go and parser.go are skipped because this CL changed those files.)
Change-Id: Ida947f4b538d42eb2d2349062c69edb6c9e5ca66
Reviewed-on: https://go-review.googlesource.com/c/go/+/221603 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Ivan Trubach [Thu, 12 Dec 2019 13:33:42 +0000 (13:33 +0000)]
cmd/doc: fix merging comments in -src mode
These changes fix go doc -src mode that vomits comments from random files if
filesystem does not sort files by name. The issue was with parse.ParseDir
using the Readdir order of files, which varies between platforms and filesystem
implementations. Another option is to merge comments using token.FileSet.Iterate
order in cmd/doc, but since ParseDir is mostly used in go doc, I’ve opted for
smaller change because it’s unlikely to break other uses or cause any perfomance
issues.
Example (macOS APFS): `go doc -src net.ListenPacket`
Change-Id: I7f9f368c7d9ccd9a2cbc48665f2cb9798c7b3a3f
GitHub-Last-Rev: 654fb450421266a0bb64518016944db22bd681e3
GitHub-Pull-Request: golang/go#36104
Reviewed-on: https://go-review.googlesource.com/c/go/+/210999
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 2 of 3:
This change contains improvements to the scanner error messages:
- Use "rune literal" rather than "character literal" to match the
spec nomenclature.
- Shorter, more to the point error messages.
(For instance, "more than one character in rune literal" rather
than "invalid character literal (more than one character)", etc.)
Change-Id: I1aaf79003374a68dbb05926437ed305cf2a8ec96
Reviewed-on: https://go-review.googlesource.com/c/go/+/221602
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is one of several changes that were part of a larger rewrite
which I made in early 2019 after switching to the new number literal
syntax implementation. The purpose of the rewrite was to simplify
reading of source code (Unicode character by character) and speed up
the scanner but was never submitted for review due to other priorities.
Part 1 of 3:
This change contains improvements to the scanner tests.
Change-Id: Iecfcaef00fdeb690b0db786edbd52e828417141b
Reviewed-on: https://go-review.googlesource.com/c/go/+/221601 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Diogo Pinela [Tue, 3 Mar 2020 21:03:40 +0000 (21:03 +0000)]
cmd/compile: use staticuint64s instead of staticbytes
There are still two places in src/runtime/string.go that use
staticbytes, so we cannot delete it just yet.
There is a new codegen test to verify that the index calculation
is constant-folded, at least on amd64. ppc64, mips[64] and s390x
cannot currently do that.
There is also a new runtime benchmark to ensure that this does not
slow down performance (tested against parent commit):
name old time/op new time/op delta
ConvT2EByteSized/bool-4 1.07ns ± 1% 1.07ns ± 1% ~ (p=0.060 n=14+15)
ConvT2EByteSized/uint8-4 1.06ns ± 1% 1.07ns ± 1% ~ (p=0.095 n=14+15)
Updates #37612
Change-Id: I5ec30738edaa48cda78dfab4a78e24a32fa7fd6a
Reviewed-on: https://go-review.googlesource.com/c/go/+/221957
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
erifan01 [Thu, 21 Nov 2019 06:38:25 +0000 (14:38 +0800)]
bytes, strings: moves indexRabinKarp function to internal/bytealg
In order to facilitate optimization of IndexAny and LastIndexAny, this patch moves
three Rabin-Karp related functions indexRabinKarp, hashStr and hashStrRev in strings
package to initernal/bytealg. There are also three functions in the bytes package with
the same names and functions but different parameter types. To highlight this, this
patch also moves them to internal/bytealg and gives them slightly different names.
Clément Chigot [Tue, 3 Mar 2020 15:24:32 +0000 (16:24 +0100)]
misc/cgo/test: fix sigaltstack test on AIX
Increase the size of the signal stack as the value given by SIGSTKSZ
is too small for the Go signal handler.
Fixes #37609
Change-Id: I56f1006bc69a2a9fb43f9e0da00061964290a690
Reviewed-on: https://go-review.googlesource.com/c/go/+/221804 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Keith Randall [Tue, 3 Mar 2020 17:56:20 +0000 (17:56 +0000)]
cmd/compile: don't allow NaNs in floating-point constant ops
Trying this CL again, with a fixed test that allows platforms
to disagree on the exact behavior of converting NaNs.
We store 32-bit floating point constants in a 64-bit field, by
converting that 32-bit float to 64-bit float to store it, and convert
it back to use it.
That works for *almost* all floating-point constants. The exception is
signaling NaNs. The round trip described above means we can't represent
a 32-bit signaling NaN, because conversions strip the signaling bit.
To fix this issue, just forbid NaNs as floating-point constants in SSA
form. This shouldn't affect any real-world code, as people seldom
constant-propagate NaNs (except in test code).
Additionally, NaNs are somewhat underspecified (which of the many NaNs
do you get when dividing 0/0?), so when cross-compiling there's a
danger of using the compiler machine's NaN regime for some math, and
the target machine's NaN regime for other math. Better to use the
target machine's NaN regime always.
Russ Cox [Tue, 25 Feb 2020 18:01:59 +0000 (13:01 -0500)]
net/http: fix handling of HTTP/2 upgrade failures
If an error occurs during the HTTP/2 upgrade phase, originally this
resulted in a pconn with pconn.alt set to an http2erringRoundTripper,
which always fails. This is not wanted - we want to retry in this case.
CL 202078 added a check for the http2erringRoundTripper to treat it
as a failed pconn, but the handling of the failure was wrong in the case
where the pconn is not in the idle list at all (common in HTTP/2).
This made the added test TestDontCacheBrokenHTTP2Conn flaky.
CL 218097 (unsubmitted) proposed to expand the handling of the
http2erringRoundTripper after the new check, to dispose of the pconn
more thoroughly. Bryan Mills pointed out in that review that we probably
shouldn't make the never-going-to-work pconn in the first place.
This CL changes the upgrade phase look for the http2erringRoundTripper
and return the underlying error instead of claiming to have a working
connection. Having done that, the CL undoes the change in CL 202078
and with it the need for CL 218097, but it keeps the new test added
by CL 202078.
On my laptop, before this commit, TestDontCacheBrokenHTTP2Conn
failed 66 times out of 20,000. With this commit, I see 0 out of 20,000.
Tim Cooper [Tue, 3 Mar 2020 13:08:06 +0000 (07:08 -0600)]
encoding/hex: remove unused variable from BenchmarkDump
Change-Id: I1fd47e5eab27346cec488098d4f6102a0749bd28
Reviewed-on: https://go-review.googlesource.com/c/go/+/221788
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Munday [Mon, 20 May 2019 18:55:56 +0000 (11:55 -0700)]
cmd/compile: optimize integer-in-range checks
This CL incorporates code from CL 201206 by Josh Bleecher Snyder
(thanks Josh).
This CL restores the integer-in-range optimizations in the SSA
backend. The fuse pass is enhanced to detect inequalities that
could be merged and fuse their associated blocks while the generic
rules optimize them into a single unsigned comparison.
For example, the inequality `x >= 0 && x < 10` will now be optimized
to `unsigned(x) < 10`.
Overall has a fairly positive impact on binary sizes.
Robert Griesemer [Sat, 29 Feb 2020 06:25:39 +0000 (22:25 -0800)]
cmd/compile/internal/syntax: add -skip flag to exclude files from TestStdLib
TestStdLib reports parsed lines and lines/s information. To make
it easier to compare apples to apples when making changes in the
std lib, a regular expression provided via the -skip flag filters
files we don't want to process.
runtime: prevent allocation when converting small ints to interfaces
Prior to this change, we avoid allocation when
converting 0 to an interface.
This change extends that optimization to larger value types
whose values happens to be in the range 0 to 255.
This is marginally more expensive in the case of a 0 value,
in that the address is computed rather than fixed.
Robert Griesemer [Sat, 8 Feb 2020 00:01:01 +0000 (16:01 -0800)]
go/types: simplify method set computation
After fixing #37081 we don't need to explicitly keep track of
field collisions in the method set computation anymore; we only
need to know which field (names) exists at each embedding level.
Simplify the code by removing the dedicated fieldSet data type
in favor of a simple string set.
Follow-up on https://golang.org/cl/218617; separate CL to make it
easier to identify a problem with these two changes, should there
be one.
Updates #37081.
Change-Id: I5c259c63c75a148a42d5c3e1e4860e1ffe5631bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/218618 Reviewed-by: Alan Donovan <adonovan@google.com>
Robert Griesemer [Fri, 7 Feb 2020 23:26:19 +0000 (15:26 -0800)]
go/types: fix method set computation
When computing method sets, any struct field that "shadows" a
method at a lower embedding level eliminates that method from
the method set. Treat any field at a given level as a "collision"
for any methods at lower embedding level.
Method sets are not directly used by go/types (except for self-
verification in debug mode); they are a functionality provided
by go/types. Thus, the method sets that go/types is using were
not affected by this bug.
Fixes #37081.
Change-Id: Ic1937e01891b3614a6f7965d4384aeb485f3fe3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/218617 Reviewed-by: Alan Donovan <adonovan@google.com>
This change adds the option to run the ssa checker with a random seed.
The current system uses a completely fixed seed,
which is good for reproducibility but bad for exploring the state space.
Preserve what we have, but also provide a way for the caller
to provide a seed. The caller can report the seed
alongside any failures.
Change-Id: I2676a8112d8260e6cac86d95d2e8db4d3221aeeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/216418 Reviewed-by: Keith Randall <khr@golang.org>
Const64 gets lowered to MOVDconst.
Change rules using interior Const64 to use MOVDconst instead,
to be less dependent on rule application order.
As a result of doing this, some of the rules end up being
exact duplicates; remove those.
We had those exact duplicates because of the order dependency;
ppc64 had no way to optimize away shifts by a constant
if the initial lowering didn't catch it.
Add those optimizations as well.
The outcome is the same, but this makes the overall rules more robust.
Keith Randall [Fri, 28 Feb 2020 20:59:38 +0000 (12:59 -0800)]
runtime: print instruction bytes when reporting a SIGILL
Print the bytes of the instruction that generated a SIGILL.
This should help us respond to bug reports without having to
go back-and-forth with the reporter to get the instruction involved.
Might also help with SIGILL problems that are difficult to reproduce.
Update #37513
Change-Id: I33059b1dbfc97bce16142a843f32a88a6547e280
Reviewed-on: https://go-review.googlesource.com/c/go/+/221431
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/compile: make pre-elimination of rulegen bounds checks more precise
In cases in which we had a named value whose args were all _,
like this rule from ARM.rules:
(MOVBUreg x:(MOVBUload _ _)) -> (MOVWreg x)
We previously inserted
_ = x.Args[1]
even though it is unnecessary.
This change eliminates this pointless bounds check.
And in other cases, we now check bounds just as far as strictly necessary.
No significant movement on any compiler metrics.
Just nicer (and less) code.
cmd/compile: add specialized Value reset for OpCopy
This:
* Simplifies and shortens the generated code for rewrite rules.
* Shrinks cmd/compile by 86k (0.4%) and makes it easier to compile.
* Removes the stmt boundary code wrangling from Value.reset,
in favor of doing it in the one place where it actually does some work,
namely the writebarrier pass. (This was ascertained by inspecting the
code for cases in which notStmtBoundary values were generated.)
Bryan C. Mills [Mon, 2 Mar 2020 15:16:39 +0000 (10:16 -0500)]
net/http: verify RoundTripper invariants in the send function
Issue #37598 reports a nil-panic in *Client.send that can
only occur if one of the RoundTripper invariants is violated.
Unfortunately, that condition is currently difficult to diagnose: it
manifests as a panic during a Response field access, rather than
something the user can easily associate with an specific erroneous
RoundTripper implementation.
No test because the new code paths are supposed to be unreachable.
Tobias Klauser [Mon, 2 Mar 2020 08:31:44 +0000 (09:31 +0100)]
internal/cpu: use anonymous struct for CPU feature vars
Like in x/sys/cpu, use anonymous structs to declare the CPU feature vars
instead of defining single-use types. Also, order the vars
alphabetically.
Change-Id: Iedd3ca51916e3cbb852d2aeed18b3a4c6613e778
Reviewed-on: https://go-review.googlesource.com/c/go/+/221757 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Jean de Klerk [Sun, 1 Mar 2020 00:35:51 +0000 (17:35 -0700)]
time: use values larger than 24 for day for time.Format examples
Currently, the time.Format docs use 7 Mar 2015 as the day/month/year. In numeric
form, that is either 7/3/2015 or 3/7/2015 depending on which part of the world
you're from. This is extremely confusing.
In fact, the reference time being defined in a very US-centric way is quite
confusing for the rest of the world, too [1].
We can't change that, but we can make the time.Format docs more comprehendable
to the rest of the world without sacrificing by simply choosing a day that is
not ambiguous (a value greater than 24 for day). This CL does makes the
necessary change.
Note: this CL moves some of the padding examples into their own example, since
those examples do need a <10 day to demonstrate padding.
1: Additional context: a very old golang-nuts thread in which Rob expresses some
regret about the format being the USA standard, rather than the alternative:
https://groups.google.com/forum/m/#!msg/golang-nuts/0nQbfyNzk9E/LWbMgpRQNOgJ.
Change-Id: If0a07c5e0dab86f8420cbf59543405eb857aa7f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/221612
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
Richard Musiol [Sun, 1 Mar 2020 16:01:58 +0000 (17:01 +0100)]
syscall: fix Fchdir on js/wasm
NodeJS does not support fchdir so it has to be emulated with chdir by
saving the path when opening a directory.
However, if the path opened is relative, saving this path is not
sufficient, because after changing the working directory the path
does not resolve correctly any more, thus a subsequent fd.Chdir() fails.
This change fixes the issue by resolving a relative path when
opening the directory and saving the absolute path instead.
cmd/compile: add specialized AddArgN functions for rewrite rules
This shrinks the compiler without impacting performance.
(The performance-sensitive part of rewrite rules is the non-match case.)
Passes toolstash-check -all.
Mark Pulford [Thu, 13 Feb 2020 21:34:31 +0000 (08:34 +1100)]
runtime: deflake CGO traceback tests
The CGO traceback function is called whenever CGO code is executing and
a signal is received. This occurs much more frequently now SIGURG
is used for preemption.
Disable signal preemption to significantly increase the likelihood that
a signal results in a profile sample during the test.
Updates #37201
Change-Id: Icb1a33ab0754d1a74882a4ee265b4026abe30bdc
Reviewed-on: https://go-review.googlesource.com/c/go/+/219417
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bradford Lamson-Scribner [Thu, 20 Feb 2020 16:07:48 +0000 (09:07 -0700)]
cmd/compile: add a dark mode to ssa html generation which can be toggled
add a tag that when clicked, toggles a dark mode. It keeps intact
the grayed out dead values/blocks, all the highlight colors, and ensures
text is always readable.
Alex Brainman [Tue, 25 Feb 2020 07:42:24 +0000 (18:42 +1100)]
cmd/go, cmd/link: implement -buildmode=pie on windows
This CL implements windows version of -buildmode=pie code in both
cmd/go and cmd/link.
Windows executables built with -buildmode=pie set (unlike the one
built with -buildmode=exe) will have extra .reloc PE section, and
will have no IMAGE_FILE_RELOCS_STRIPPED flag set. They will also
have IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag set, and
IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA flag set for windows/amd64.
Both cgo and non-cgo versions are implemented. And TestBuildmodePIE
is extended to test both cgo and non-cgo versions on windows and
linux.
This CL used some code from CLs 152759 and 203602.
RELNOTE=yes
Fixes #27144
Updates #35192
Change-Id: I1249e4ffbd79bd4277efefb56db321c390c0f76f
Reviewed-on: https://go-review.googlesource.com/c/go/+/214397
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Thu, 27 Feb 2020 19:24:24 +0000 (11:24 -0800)]
runtime/pprof/internal/profile: make error message readable
The error message for an unrecognized type in decodeField was using
string(i) for an int type i. It was recently changed (by me) to
string(rune(i)), but that just avoided a vet warning without fixing
the problem. This CL fixes the problem by using fmt.Errorf.
We also change the message to "unknown wire type" to match the master
copy of this code in github.com/google/pprof/profile/proto.go.
Updates #32479
Change-Id: Ia91ea6d5edbd7cd946225d1ee96bb7623b52bb44
Reviewed-on: https://go-review.googlesource.com/c/go/+/221384
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
We try to preserve type correctness of generic ops.
phiopt modified a bool to be an int without a conversion.
Add a conversion. There are a few random fluctations in the
generated code as a result, but nothing noteworthy or systematic.