This adds the go get security fix.
* 1dcb5836 cmd/go: accept only limited compiler and linker flags in #cgo directives
Change-Id: Ib2caf2039d2cefabe3afa0bb4dcc4c0dc8d664ff
Both gcc and clang accept an option -fplugin=code.so to load
a plugin from the ELF shared object file code.so.
Obviously that plugin can then do anything it wants
during the build. This is contrary to the goal of "go get"
never running untrusted code during the build.
(What happens if you choose to run the result of
the build is your responsibility.)
Disallow this behavior by only allowing a small set of
known command-line flags in #cgo CFLAGS directives
(and #cgo LDFLAGS, etc).
The new restrictions can be adjusted by the environment
variables CGO_CFLAGS_ALLOW, CGO_CFLAGS_DISALLOW,
and so on. See the documentation.
In addition to excluding cgo-defined flags, we also have to
make sure that when we pass file names on the command
line, they don't look like flags. So we now refuse to build
packages containing suspicious file names like -x.go.
A wrinkle in all this is that GNU binutils uniformly accept
@foo on the command line to mean "if the file foo exists,
then substitute its contents for @foo in the command line".
So we must also reject @x.go, flags and flag arguments
beginning with @, and so on.
Fixes#23672, CVE-2018-6574.
Change-Id: I59e7c1355155c335a5c5ae0d2cf8fa7aa313940a
Reviewed-on: https://team-review.git.corp.google.com/209949
Reviewed-by: Ian Lance Taylor <iant@google.com>
* b2d3d6e6 cmd/link/internal/loadelf: fix logic for computing ELF flags on ARM
* c07095cd cmd/cgo: revert CL 49490 "fix for function taking pointer typedef"
* 23e8e197 cmd/compile: use unsigned loads for multi-element comparisons
* 85bdd05c cmd/go: rebuild as needed for tests of packages that add methods
* fd7331a8 text/template: revert CL 66410 "add break, continue actions in ranges"
* f54f780d cmd/vet: unexported interface{} fields on %s are ok
* a0222ec5 cmd/internal/obj/arm64: fix assemble add/adds/sub/subs/cmp/cmn(extended register) bug
* 59523176 cmd/go: only run -race test if -race works
* 4558321e doc/editors: remove feature matrix for various editors/IDEs
* e6756ec1 cmd/go: ignore coverpkg match on sync/atomic in atomic coverage mode
* 10d096fe cmd/go: fix import config debugging flag
* f598ad58 go/internal/gccgoimporter: remove old and exp gccgo packages in test
* 2a8229d9 misc/cgo/test: get uintptr, not pointer, from dlopen
* 851e98f0 spec: remove need for separate Function production (cleanup)
* cbe1a61e net: fix the kernel state name for TCP listen queue on FreeBSD
* 6f37fee3 cmd/go: fix TestNoCache on Plan 9
* e5186895 runtime: restore RSB for sigpanic call on mips64x
* 3ff41cdf runtime: suppress "unexpected return pc" any time we're in cgo
* d929e40e syscall: use SYS_GETDENTS64 on linux/mips64{,le}
* 43288467 test: add test for gccgo bug 23545
* 19150303 cmd/go: if unable to initialize cache, just disable it
* ebe38b86 runtime: fail silently if we unwind over sigpanic into C code
* 5c2be42a runtime: don't unwind past asmcgocall
* 03e10bd9 os/signal: skip TestTerminalSignal if posix_openpt fails with EACCES
* d30591c1 cmd/vendor/github.com/google/pprof: cherry-pick fix to cope with $HOME not being writable
* bcc86d5f doc: add GOMIPS to source installation docs
* 926f2787 cmd/fix: cleanup directories created during typecheck
* 32a08d09 bootstrap.bash: only fetch git revision if we need it
* 14f8027a cmd/vet: extra args if any formats are indexed are ok
* 4072608b cmd/vet: %s is valid for an array of stringer
* 1f85917f cmd/vet: **T is not Stringer if *T has a String method
* 8c1f21d9 cmd/vet: disable complaint about 0 flag in print
* d529aa93 doc: fix the closing tag in contribute.html
* f8610bbd doc: fix two small mistakes in 1.10 release notes
* 5af1e7d7 cmd/go: skip external tests on plan9/arm
* 00587e89 doc: fix spelling mistake
* 3ee8c3cc os: document inheritance of thread state over exec
* b5b35be2 cmd/compile: don't inline functions that call recover
* 651ddbdb database/sql: buffers provided to Rows.Next should not be modified by drivers
* 7350297e doc: remove Sarah Adams from conduct working group contacts
Change-Id: I3c04d83706cd4322252ddf732688afe5d938c1f5
The linker contains complicated logic for figuring out which float ABI to
indicate it is using on (32 bit) ARM systems: it parses a special section in
host object files to look for a flag indicating use of the hard float ABI. When
loadelf got split into its own package a bug was introduced: if the last host
object file does not contain a float ABI related tag, the ELF header's flag was
set to 0, rather than using the value from the last object file which contained
an ABI tag. Fix the code to only change the value used for the ELF header if a
tag was found.
This fixes an extremely confusing build failure on Ubuntu's armhf builders.
Change-Id: I0845d68d082d1383e4cae84ea85164cdc6bcdddb
Reviewed-on: https://go-review.googlesource.com/92515
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 49490 fixed a warning when compiling the C code generated by cgo,
but it introduced typedef conflicts in Go code that cgo is supposed to
avoid.
Original CL description:
cmd/cgo: fix for function taking pointer typedef
Fixes#19832
Updates #19832Fixes#23720
Change-Id: I22a732db31be0b4f7248c105277ab8ee44ef6cfb
Reviewed-on: https://go-review.googlesource.com/92455
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When loading multiple elements of an array into a single register,
make sure we treat them as unsigned. When treated as signed, the
upper bits might all be set, causing the shift-or combo to clobber
the values higher in the register.
Fixes#23719.
Change-Id: Ic87da03e9bd0fe2c60bb214b99f846e4e9446052
Reviewed-on: https://go-review.googlesource.com/92335
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
If A's external test package imports B, which imports A,
and A's (internal) test code also adds something to A that
invalidates anything in the export data from a build of A
without its test code, then strictly speaking we need to
rebuild B against the test-augmented version of A before
using it to build A's external test package.
We've been skating by without doing this for a very long time,
but I knew we'd need to handle it better eventually,
I planned for it in the new build cache simplifications,
and the code was ready. Now that we have a real-world
test case that needs it, turn on the "proper rebuilding" code.
It doesn't really matter how much things slow down, since
a real-world test cases that caused an internal compiler error
before is now handled correctly, but it appears to be small:
I wasn't able to measure an effect on "go test -a -c fmt".
And of course most builds won't use -a and will be cached well.
Fixes#6204.
Fixes#23701.
Change-Id: I2cd60cf400d1928428979ab05831f48ff7cee6ca
Reviewed-on: https://go-review.googlesource.com/92215
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new break and continue actions do not work in html/template, and
fixing them requires thinking about security issues that seem too
tricky at this stage of the release. We will try again for 1.11.
Original CL description:
text/template: add break, continue actions in ranges
Adds the two range control actions "break" and "continue". They act the
same as the Go keywords break and continue, but are simplified in that
only the innermost range statement can be broken out of or continued.
Fixes#20531
Updates #20531
Updates #23683
Change-Id: Ia7fd3c409163e3bcb5dc42947ae90b15bdf89853
Reviewed-on: https://go-review.googlesource.com/92155
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For example, the following program is valid:
type T struct {
f interface{}
}
func main() {
fmt.Printf("%s", T{"foo"}) // prints {foo}
}
Since the field is of type interface{}, we might have any value in it.
For example, if we had T{3}, fmt would complain. However, not knowing
what the type under the interface is, we must be conservative.
However, as shown in #17798, we should issue an error if the field's
type is statically known to implement the error or fmt.Stringer
interfaces. In those cases, the user likely wanted the %s format to call
those methods. Keep the vet error in those cases.
While at it, add more field type test cases, such as custom error types,
and interfaces that extend the error interface.
Fixes#23563.
Change-Id: I063885955555917c59da000391b603f0d6dce432
Reviewed-on: https://go-review.googlesource.com/90516
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current code encodes the wrong option value in the binary.
The fix reconstructs the function opxrrr() that does not encode the option
value into the binary value when arguments is sign or zero-extended register.
Add the relevant test cases and negative tests.
Fixes#23501
Change-Id: Ie5850ead2ad08d9a235a5664869aac5051762f1f
Reviewed-on: https://go-review.googlesource.com/88876
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The speed of feature development for these products outpaces the
standard Go 6-month release cycle tied to this page. The cost of
maintaining this list is becoming a burden as we make every
attempt at being impartial. As of this writing, we believe feature
lists belong on the pages of the editors/IDEs themselves.
Change-Id: Ie2dfe0e0d47d203c913373e58cbb65cb0fb14d0c
Reviewed-on: https://go-review.googlesource.com/91976
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Otherwise we get into a dependency loop as we try to apply coverage
analysis to sync/atomic when the coverage analysis itself requires
sync/atomic.
Fixes#23694
Change-Id: I3a74ef3881ec5c6197ed348acc7f9e175417f6c7
Reviewed-on: https://go-review.googlesource.com/91875
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The old and exp packages listed in gccgoinstallation_test.go have been
removed from gccgo. Remove them from the test.
Fixes#20932
Change-Id: I04a5148e18dccef332904b836c42098b55f2516c
Reviewed-on: https://go-review.googlesource.com/91656
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The dlopen function returns an opaque handle, and it is possible for
it to look like a Go pointer, causing garbage collector and cgo
confusion.
Fixes#23663
Change-Id: Id080e2bbcee8cfa7ac4a457a927f96949eb913f8
Reviewed-on: https://go-review.googlesource.com/91596
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The EBNF production
Function = Signature FunctionBody .
was used in FunctionDecl, MethodDecl, and FunctionLit, but only
for the latter it shortened the syntax slightly.
This change "inlines" Function which simplifies FunctionDecl and
MethodDecl and gets rid of the Function production.
This has no impact on the specified language. Also, the Function
production is never referred to by the prose, so it's safe to
remove it from the spec.
Finally, neither go/ast nor go/parser have a representation of
this production via a corresponding node or parse function, so
no possibly valuable documentation is lost, either.
Change-Id: Ia2875d31c6ec2d2079081ef481e50bad4f43c694
Reviewed-on: https://go-review.googlesource.com/91515
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
CL 91097 added TestNoCache. However, this
test is failing on Plan 9 because the HOME
environment variable doesn't contain the
home directory where the Go cache is located.
This change fixes the TestNoCache test
by using the home environment variable
instead of HOME on Plan 9.
Fixes#23644.
Change-Id: Icfb7a7a4c2852f159c93032b4081411628a2787f
Reviewed-on: https://go-review.googlesource.com/91216
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
preparePanic must set all registers expected by Go runtime conventions
in case the sigpanic is being injected into C code. However, on
mips64x it fails to restore RSB (R28). As a result, if C code modifies
RSB and then raises a signal that turns into a sigpanic call, sigpanic
may crash when it attempts to lock runtime.debuglock (the first global
it references).
Fix this by restoring RSB in the signal context using the same
convention as main and sigtramp.
Fixes#23641.
Change-Id: Ib47e83df89e2a3eece10f480e4e91ce9e4424388
Reviewed-on: https://go-review.googlesource.com/91156
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, gentraceback suppresses the "unexpected return pc" error
for sigpanic's caller if the M was running C code.
However, there are various situations where a sigpanic is injected
into C code that can cause traceback to unwind *past* the sigpanic
before realizing that it's in trouble (the traceback beyond the
sigpanic will be wrong).
Rather than try to fix these issues for Go 1.10, this CL simply
disables complaining about unexpected return PCs if we're in cgo
regardless of whether or not they're from the sigpanic frame. Go 1.9
never complained about unexpected return PCs when printing, so this is
simply a step closer to the old behavior.
This should fix the openbsd-386 failures on the dashboard, though this
issue could affect any architecture.
Fixes#23640.
Change-Id: I8c32c1ee86a70d2f280661ed1f8caf82549e324b
Reviewed-on: https://go-review.googlesource.com/91136
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The getdents64 syscall is only available for mips64/mips64le starting
with Linux kernel 3.10. Since mips64le requires at least 4.8 according
to [1] (regarding #16848) using it should be fine.
[1] https://golang.org/wiki/MinimumRequirements
This CL changes the binary layout of type Dirent for mips64/mips64le,
but not the public API. But since the currently used layout doesn't
match the struct linux_dirent returned by the getdents syscall this
should be fine as well.
Fixes#23624
Change-Id: Iaa7306fa6e4442ad2fed41c60b37627a7314f117
Reviewed-on: https://go-review.googlesource.com/91055
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If we're running C code and the code panics, the runtime will inject a
call to sigpanic into the C code just like it would into Go code.
However, the return PC from this sigpanic will be in C code. We used
to silently abort the traceback if we didn't recognize a return PC, so
this went by quietly. Now we're much louder because in general this is
a bad thing. However, in this one particular case, it's fine, so if
we're in cgo and are looking at the return PC of sigpanic, silence the
debug output.
Fixes#23576.
Change-Id: I03d0c14d4e4d25b29b1f5804f5e9ccc4f742f876
Reviewed-on: https://go-review.googlesource.com/90896
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
asmcgocall switches to the system stack and aligns the SP, so
gentraceback both can't unwind over it when it appears on the system
stack (it'll read some uninitialized stack slot as the return PC).
There's also no point in unwinding over it, so don't.
Updates #23576.
Change-Id: Idfcc9599c7636b80dec5451cb65ae892b4611981
Reviewed-on: https://go-review.googlesource.com/90895
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Executing
$ go tool dist test -run=^go_test:cmd/fix$
leaves a number of directories (fix_cgo_typecheck*) in TMPDIR.
Change-Id: Ia5bdc2f7d884333771d50365063faf514ebf6eae
Reviewed-on: https://go-review.googlesource.com/90795
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For example, the following program is valid:
func main() {
fmt.Printf("%[1]d", 1, 2, 3)
}
If any of the formats are indexed, fmt will not complain about unused
extra arguments. See #22867 for more detail.
Make vet follow the same logic, to avoid erroring on programs that would
run without fmt complaining.
Fixes#23564.
Change-Id: Ic9dede5d4c37d1cd4fa24714216944897b5bb7cc
Reviewed-on: https://go-review.googlesource.com/90495
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
vet was quiet for []stringer, but not for [N]stringer. The source of the
problem was how the recursive call used .Elem().Underlying() for arrays,
but .Elem() for slices. In the first case, the named type is dropped,
thus losing all information of attached methods.
Be consistent across slices and arrays, by dropping the Underlying call
that is causing trouble. Add regression tests too, including cases where
the element type does not implement fmt.Stringer.
Fixes#23552.
Change-Id: I0fde07d101f112d5768be0a79207ef0b3dc45f2e
Reviewed-on: https://go-review.googlesource.com/90455
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
vet recorded what types had String methods defined on them, but it did
not record whether the receivers were pointer types. That information is
important, as the following program is valid:
type T string
func (t *T) String() string {
return fmt.Sprint(&t) // prints address
}
Teach vet that, if *T is Stringer, **T is not.
Fixes#23550.
Change-Id: I1062e60e6d82e789af9cca396546db6bfc3541e8
Reviewed-on: https://go-review.googlesource.com/90417
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The problem is that vet complains about 0 as a Printf flag in some
situations where fmt allows it but probably shouldn't. The two
need to be brought in line, but it's too late in the release cycle.
The situation is messy and should be resolved properly in 1.11. This
CL is a simple fix to disable a spurious complaint for 1.10 that will be
resolved in a more thorough way in 1.11.
The workaround is just to be silent about flag 0, as suggested in
issue 23605.
Fixes#23605
Update #23498
Change-Id: Ice1a4f4d86845d70c1340a0a6430d74e5de9afd4
Reviewed-on: https://go-review.googlesource.com/90695
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 13166, CL 13342 and CL 33425 skipped external tests
on freebsd/arm, linux/arm and linux/mips.
This CL does the same for plan9/arm to reduce test time
on plan9/arm and prevent the Go builder to time out.
Change-Id: I16fcc5d8010a354f480673b8c4a8a11dbc833557
Reviewed-on: https://go-review.googlesource.com/90416
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
recover determines whether it's being called by a deferred frame by
matching its caller's argument frame pointer with the one recorded in
the panic object. That means its caller needs a valid and unique
argument frame pointer, so it must not be inlined.
With this fix, test/recover.go passes with -l=4.
Fixes#23557.
Change-Id: I1f32a624c49e387cfc67893a0829bb248d69c3d4
Reviewed-on: https://go-review.googlesource.com/90035
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously we allowed drivers to modify the row buffer used to scan
values when closing Rows. This is no longer acceptable and can lead
to data races.
Fixes#23519
Change-Id: I91820a6266ffe52f95f40bb47307d375727715af
Reviewed-on: https://go-review.googlesource.com/89936
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
In Plan 9, each OS thread has its own independent working directory,
so the Go runtime for Plan 9 needs to coordinate Chdir and Getwd
operations to keep the working directory consistent for all goroutines.
The function os.Getwd in Plan 9 should always call syscall.Getwd
to retrieve the common working directory. Failure to do this was
the cause of (at least some of) the intermittent failures in the
Plan 9 builders with a seemingly spurious "file does not exist"
message, when a thread's working directory had been removed in
another thread.
Change-Id: Ifb834ad025ee39578234ad3b04d08bc98e939291
Reviewed-on: https://go-review.googlesource.com/89575
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If you use -coverpkg=all you get coverage for all packages in the build.
Go 1.9 used a global counter for all the GoCover variables, so that they
were distinct for the entire build. The global counter caused problems
with caching, so we switched to a per-package counter. But now the
GoCover_0 in one package may be dot-imported into another and
conflict with the GoCover_0 in that other package.
Reestablish (overwhelmingly likely) global uniqueness of GoCover
variables by appending an _xxxxxxxxxxxx suffix, where the x's are
the prefix of the SHA256 hash of the import path. The point is only
to avoid accidents, not to defeat people determined to break the tools.
Fixes#23432.
Change-Id: I3088eceebbe35174f2eefe8d558b7c8b59d3eeac
Reviewed-on: https://go-review.googlesource.com/89135
Reviewed-by: Ian Lance Taylor <iant@golang.org>
pprof expects the samples are scaled and reflects unsampled numbers.
The legacy profile parser uses the sampling period in the output
and multiplies all values with the period.
0138a3cd6d/profile/legacy_profile.go (L815)
Apply the same scaling when we output the mutex profile
in the pprof proto format.
Block profile shares the same code, but how to infer unsampled
values is unclear. Legacy profile parser doesn't do anything special
so we do nothing for block profile here.
Tested by checking the profiles reported with debug=0 (proto format)
are similar to the profiles computed from legacy format profile
when the profile rate is a non-trivial number (e.g. 2) manually.
Change-Id: Iaa33f92051deed67d8be43ddffc7c1016db566ca
Reviewed-on: https://go-review.googlesource.com/89295
Reviewed-by: Peter Weinberger <pjw@google.com>
Remove leading space at the beginning of error strings,
so the strings are consistent between isExist, isNotExist
and isPermission functions.
Here is a list of error strings returned on the most common
file servers on Plan 9:
match cwfs fossil ramfs
"exists" "create/wstat -- file exists" "file already exists" "file exists"
"is a directory" "is a directory" "file is a directory"
"does not exist" "file does not exist" "file does not exist"
"not found" "directory entry not found"
"has been removed" "file has been removed"
"permission denied" "access permission denied" "permission denied" "permission denied"
"no parent" is an error returned by lib9p when removing a file without parent.
Change-Id: I2362ed4b6730b8bec7a707a1052bd1ad8921cd97
Reviewed-on: https://go-review.googlesource.com/89315
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Starting on or about the 2018c archives, www.iana.org is redirected to
data.iana.org. Tell curl to follow the redirect.
Updates: #22487
Change-Id: I00acada1a3ba01ef701d6d4ffae6cc2cbb6a068f
Reviewed-on: https://go-review.googlesource.com/89375
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The compiler allows code to have multiple differently-typed views of a
single argument. For instance, if we have
func f(x float64) {
y := *(*int64)(unsafe.Pointer(&x))
...
}
Then in SSA we get two OpArg ops, one with float64 type and one with
int64 type.
The compiler will try to reuse argument slots for spill slots. It
checks that the argument slot is dead by consulting an interference
graph.
When building the interference graph, we normally ignore cross-type
edges because the values on either end of that edge can't be allocated
to the same slot. (This is just a space-saving optimization.) This
rule breaks down when one of the values is an argument, because of the
multiple views described above. If we're spilling a float64, it is not
enough that the float64 version of x is dead; the int64 version of x
has to be dead also.
Remove the optimization of not recording interference edges if types
don't match. That optimization is incorrect if one of the values
connected by the edge is an argument.
Fixes#23522
Change-Id: I361f85d80fe3bc7249014ca2c3ec887c3dc30271
Reviewed-on: https://go-review.googlesource.com/89335
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
- Don't complain about invalid constant type if the type is
invalid already (we do this in other places as well). This
is useful to do in general, and even more so if we have
invalid types due to import "C".
- Type-check the lhs of an assignment even if we bail out early
due to an error on the rhs. This was simply an oversight. We
already have machinery in place to "use" expressions; in this
case we just have to also make sure we don't overcount "uses"
of variables on the lhs.
- Fix overcount uses correction in assignments: Only do it if
the variable in question is declared inside the same package
to avoid possible race conditions when type-checking exported
variables concurrently.
Fixes#22090.
Change-Id: I4c1b59f9ce38970e7129fedc5f6023908386e4f1
Reviewed-on: https://go-review.googlesource.com/88375
Reviewed-by: Alan Donovan <adonovan@google.com>
Currently, startpanic_m (which prepares for an unrecoverable panic)
goes out of its way to make it possible to allocate during panic
handling by allocating an mcache if there isn't one.
However, this is both potentially dangerous and unnecessary.
Allocating an mcache is a generally complex thing to do in an already
precarious situation. Specifically, it requires obtaining the heap
lock, and there's evidence that this may be able to deadlock (#23360).
However, it's also unnecessary because we never allocate from the
unrecoverable panic path.
This didn't use to be the case. The call to allocmcache was introduced
long ago, in CL 7388043, where it was in preparation for separating Ms
and Ps and potentially running an M without an mcache. At the time,
after calling startpanic, the runtime could call String and Error
methods on panicked values, which could do anything including
allocating. That was generally unsafe even at the time, and CL 19792
fixed this be pre-printing panic messages before calling startpanic.
As a result, we now no longer allocate after calling startpanic.
This CL not only removes the allocmcache call, but goes a step further
to explicitly disallow any allocation during unrecoverable panic
handling, even in situations where it might be safe. This way, if
panic handling ever does an allocation that would be unsafe in unusual
circumstances, we'll know even if it happens during normal
circumstances.
This would help with debugging #23360, since the deadlock in
allocmcache is currently masking the real failure.
Beyond all.bash, I manually tested this change by adding panics at
various points in early runtime init, signal handling, and the
scheduler to check unusual panic situations.
Change-Id: I85df21e2b4b20c6faf1f13fae266c9339eebc061
Reviewed-on: https://go-review.googlesource.com/88835
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, if a _SigPanic signal arrives in a throwsplit context,
nothing is stopping the runtime from injecting a call to sigpanic that
may attempt to grow the stack. This will fail and, in turn, mask the
real problem.
Fix this by checking for throwsplit in the signal handler itself
before injecting the sigpanic call.
Updates #21431, where this problem is likely masking the real problem.
Change-Id: I64b61ff08e8c4d6f6c0fb01315d7d5e66bf1d3e2
Reviewed-on: https://go-review.googlesource.com/87595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we introduced the notion of alias type declarations, we renamed
"named type" to "defined type" to avoid confusion with types denoted
by aliases and thus are also types with names, or "named types".
Some of the old uses of "named types" remained; this change removes
them.
Now the spec consistently uses the terms:
- "defined type" for a type declared via a type definition
- "type name" for any name denoting an (alias or defined) type
- "alias" for a type name declared in an alias declaration
New prose is encouraged to avoid the term "named type" to counter-
act further confusion.
Fixes#23474.
Change-Id: I5fb59f1208baf958da79cf51ed3eb1411cd18e03
Reviewed-on: https://go-review.googlesource.com/89115
Reviewed-by: Rob Pike <r@golang.org>
The current code misassembles VLD1/VST1 instruction with non-zero
offset. The offset is dropped silently without any error message.
The cause of the misassembling is the current code treats argument
(Rn)(Rm) as ZOREG type.
The fix changes the matching rules and considers (Rn)(Rm) as ROFF
type. The fix will report error information when assembles VLD1/VST1
(R8)(R13), [V1.16B].
The fix enables the ARM64Errors test.
Fixes#23448
Change-Id: I3dd518b91e9960131ffb8efcb685cb8df84b70eb
Reviewed-on: https://go-review.googlesource.com/87956
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This error is returned by os.Mkdir when the directory already exists.
This change fixes some upspin tests.
Change-Id: I9ad5aefebb32dff577726d537b4f3826d79868eb
Reviewed-on: https://go-review.googlesource.com/88656
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When there is no go directory inside the swiglib directory then swig
was installed without Go support. Tests in misc/swig will fail when
swig is installed without Go support.
Add additional checks for the presence of a go directory in the directory
reported by 'swig -go -swiglib' to determine if misc/swig tests should
be run.
This avoids all.bash failing when swig but not swig-go is installed
using macports.
Tested on darwin with swig and with and without swig-go installed
using macports.
Fixes#23469
Change-Id: I173201221554982ea0d9f2bea70a3cb85b297cec
Reviewed-on: https://go-review.googlesource.com/88776
Reviewed-by: David Chase <drchase@google.com>
In earlier versions of Go the "go vet" command would run on regular
source files and test files. That was lost in CL74750. Bring it back.
This required moving a chunk of code from internal/test to
internal/load. The diff looks big but the code is unchanged.
Fixes#23395
Change-Id: Ie9ec183337e8db81c5fc421d118a22b351b5409e
Reviewed-on: https://go-review.googlesource.com/87636
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, if anything goes wrong when printing a traceback, we simply
cut off the traceback without any further diagnostics. Unfortunately,
right now, we have a few issues that are difficult to debug because
the traceback simply cuts off (#21431, #23484).
This is an attempt to improve the debuggability of traceback failure
by printing a diagnostic message plus a hex dump around the failed
traceback frame when something goes wrong.
The failures look like:
goroutine 5 [running]:
runtime: unexpected return pc for main.badLR2 called from 0xbad
stack: frame={sp:0xc42004dfa8, fp:0xc42004dfc8} stack=[0xc42004d800,0xc42004e000)
000000c42004dea8: 0000000000000001 0000000000000001
000000c42004deb8: 000000c42004ded8 000000c42004ded8
000000c42004dec8: 0000000000427eea <runtime.dopanic+74> 000000c42004ded8
000000c42004ded8: 000000000044df70 <runtime.dopanic.func1+0> 000000c420001080
000000c42004dee8: 0000000000427b21 <runtime.gopanic+961> 000000c42004df08
000000c42004def8: 000000c42004df98 0000000000427b21 <runtime.gopanic+961>
000000c42004df08: 0000000000000000 0000000000000000
000000c42004df18: 0000000000000000 0000000000000000
000000c42004df28: 0000000000000000 0000000000000000
000000c42004df38: 0000000000000000 000000c420001080
000000c42004df48: 0000000000000000 0000000000000000
000000c42004df58: 0000000000000000 0000000000000000
000000c42004df68: 000000c4200010a0 0000000000000000
000000c42004df78: 00000000004c6400 00000000005031d0
000000c42004df88: 0000000000000000 0000000000000000
000000c42004df98: 000000c42004dfb8 00000000004ae7d9 <main.badLR2+73>
000000c42004dfa8: <00000000004c6400 00000000005031d0
000000c42004dfb8: 000000c42004dfd0 !0000000000000bad
000000c42004dfc8: >0000000000000000 0000000000000000
000000c42004dfd8: 0000000000451821 <runtime.goexit+1> 0000000000000000
000000c42004dfe8: 0000000000000000 0000000000000000
000000c42004dff8: 0000000000000000
main.badLR2(0x0)
/go/src/runtime/testdata/testprog/badtraceback.go:42 +0x49
For #21431, #23484.
Change-Id: I8718fc76ced81adb0b4b0b4f2293f3219ca80786
Reviewed-on: https://go-review.googlesource.com/89016
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Introduce GOANDROID_ADB_FLAGS for additional flags to adb invocations.
With GOANDROID_ADG_FLAGS, the Android builders can distinguish between
emulator and device builds.
Change-Id: I11729926a523ee27f6a3795cb2cfb64a9454f0a5
Reviewed-on: https://go-review.googlesource.com/88795
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When casting between *C.CFTypeRef and *unsafe.Pointer, we used to be
able to do the cast directly. Now with C.CFTypeRef being a uintptr
instead of an unsafe.Pointer, we need an intermediate cast.
Add the insertion of the intermediate cast to the cftype fix module.
Fixes#23091
Change-Id: I891be2f4a08cfd7de1cc4c6ab841b1e0d8c388a6
Reviewed-on: https://go-review.googlesource.com/88175
Reviewed-by: Robert Griesemer <gri@golang.org>
This change expands the documentation for Verify to mention the name
constraints and EKU behaviour.
Change-Id: Ifc80faa6077c26fcc1d2a261ad1d14c00fd13b23
Reviewed-on: https://go-review.googlesource.com/87300
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cgo uses the presence of these functions to determine whether
a given type is in the CFTypeRef hierarchy and thus should be
a uintptr instead of a pointer. But if the *GetTypeID functions
aren't used by the user code, then they won't be present in the
cgo output, and thus cmd/fix won't see them.
Use the simpler rule that anything ending in *Ref should be
rewritten. This could over-rewrite, but I don't see a simpler
solution. Unlike cgo, it is easy to edit the output to fix any
issues. And fix is a much rarer operation than cgo.
This is a revert of portions of CL 87616.
Update #23091
Change-Id: I74ecd9fb25490a3d279b372e107248452bb62185
Reviewed-on: https://go-review.googlesource.com/88075
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Cgo currently maps CFTypeRef and its subtypes to unsafe.Pointer
or a pointer to a named empty struct.
However, Darwin sometimes encodes some of CFTypeRef's subtypes as a
few int fields packed in a pointer wrapper. This hackery confuses the
Go runtime as the pointers can look like they point to things that
shouldn't be pointed at.
Switch CFTypeRef and its subtypes to map to uintptr.
Detecting the affected set of types is tricky, there are over 200 of
them, and the set isn't static across Darwin versions. Fortunately,
downcasting from CFTypeRef to a subtype requires calling CFGetTypeID,
getting a CFTypeID token, and comparing that with a known id from a
*GetTypeID() call. So we can find all the type names by detecting all
the *GetTypeID() prototypes and rewriting the corresponding *Ref types
to uintptr. This strategy covers all the cases I've checked and is
unlikely to have a false positive.
Update #23091.
Change-Id: I487eb4105c9b4785ba564de9c38d472c8c9a76ac
Reviewed-on: https://go-review.googlesource.com/87615
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We used a mix of both before.
I've never heard anybody say "an arr-double you mutex" when speaking.
Fixes#23457
Change-Id: I802b5eb2339f885ca9d24607eeda565763165298
Reviewed-on: https://go-review.googlesource.com/87896
Reviewed-by: Andrew Bonventre <andybons@golang.org>
CL 67332 created the fast no-syscall path for time.Now in High Sierra
but managed to break Sierra and older by forcing them into the slow
syscall path: the version check based on commpage version was wrong.
This CL uses the Darwin version number instead.
The assembly diff is noisy because many variables had to be
renamed, but the only actual change is the version check.
Fixes#23419.
Change-Id: Ie31ef5fb88f66d1517a8693942a7fb6100c213b0
Reviewed-on: https://go-review.googlesource.com/87655
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The tool was moved to tools/Testing/selftests within the Linux kernel
source tree. Adjust the URL in the comments of vdso_linux.go
Change-Id: I86b9cae4b898c4a45bc7c54891ce6ead91a22670
Reviewed-on: https://go-review.googlesource.com/87815
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The cgo checker was issuing an error with cgocheck=2 when a timer
bucket was stored in a pollDesc. The pollDesc values are allocated
using persistentalloc, so they are not in the Go heap. The code is OK
since timer bucket pointers point into a global array, and as such are
never garbage collected or moved.
Mark timersBucket notinheap to avoid the problem. timersBucket values
only occur in the global timers array.
Fixes#23435
Change-Id: I835f31caafd54cdacc692db5989de63bb49e7697
Reviewed-on: https://go-review.googlesource.com/87637
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I found the previous text choppy and hard to follow, and in putting
this CL together, based entirely on the existing text, I found
several details that seemed misleading to me.
This is my attempt to make the text simultaneously easier to
understand, more complete, and more precise. I may have failed in
all three, but I wanted to try.
Change-Id: I088cb457f6fcad8f2b40236949cc3ac43455e600
Reviewed-on: https://go-review.googlesource.com/87735
Reviewed-by: Russ Cox <rsc@golang.org>
After CL 69831, addTransitiveLinkDeps ensures that all dependencies of
a link appear in Deps. We no longer need to traverse through all
actions to find them. And the old scheme of looking through all the
actions and assuming we would see shared library actions before
libraries they depend on no longer works.
Now that we have complete deps, change to a simpler scheme in which we
find the shared libraries in the deps, and then use that to sort the
deps into archives and shared libraries.
Fixes#22224
Change-Id: I14fcc773ac59b6f5c2965cc04d4ed962442cc89e
Reviewed-on: https://go-review.googlesource.com/87497
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Every few months we get a new error report claiming that there
is a typo in the spec related to this specific example. Clearly,
the fact that two types with the same identifier are identical
seems exceedingly obvious to readers; thus the example seems not
worth the trouble. Removing it.
For #9226.
For #22202.
For #22495.
For #23096.
For #23409.
There may be more.
Change-Id: I003ba79dc460ffb028a4ecb5f29efd60f2551912
Reviewed-on: https://go-review.googlesource.com/87417
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Handlers can be registered for specific hosts by specifying the host as
part of the mux pattern. If a trailing slash route is registered for
these host-based patterns, shouldRedirect should indicate that
a redirect is required.
This change modifies shouldRedirect to also take the host of the
request, and now considers host-based patterns while determining if
a request should be redirected.
Fixes#23183
Change-Id: If8753e130d5d877acdc55344833e3b289bbed2b4
Reviewed-on: https://go-review.googlesource.com/84695
Reviewed-by: Kunpei Sakai <namusyaka@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The net/http Transport was testing for a sentinel x/net/http2 error
value with ==, which meant it was only testing the bundled version. If
a user enabled http2 via golang.org/x/net/http2, the error value had a
different name.
This also updates the bundled x/net/http2 to git rev ab555f36 for:
http2: add internal function isNoCachedConnError to test for ErrNoCachedConn
https://golang.org/cl/87297Fixes#22091
Change-Id: I3fb85e2b7ba7d145dd66767e1795a56de633958c
Reviewed-on: https://go-review.googlesource.com/87298
Reviewed-by: Tom Bergan <tombergan@google.com>
GCC always recognizes the -fsplit-stack option, but then tests whether
it is supported by the selected target. If not, it reports
cc1: error: ‘-fsplit-stack’ is not supported by this compiler configuration
Check for that error message when deciding whether a compiler option works.
Change-Id: I2eef8d550bbecba3a087869df2c7351280c77290
Reviewed-on: https://go-review.googlesource.com/87136
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
We've had a series of problems with tests unexpectedly (and innocently)
looking at system files that appear to (but don't) change in meaningful ways,
like /dev/null on OS X having a modification time set to the current time.
Cut all these off by only applying file change detection to the local package
root: the GOROOT or specific sub-GOPATH in which the package being tested
is found.
(This means that if you test reads /tmp/x and you change /tmp/x, the cached
result will still be used. Don't do that, or else use -count=1.)
Fixes#23390.
Change-Id: I30b6dd194835deb645a040aea5e6e4f68af09edb
Reviewed-on: https://go-review.googlesource.com/87015
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These were the last two occurences of exec.Command("go", ...) in all of
std cmd. Checked with:
gogrep '$(f is(func))("go", $*_)' std cmd
Also changed lp_windows_test to use a test package name to avoid a
circular dependency, since internal/testenv imports os/exec.
Change-Id: I9a18948600dfecc8507ad76172e219e78b791ffd
Reviewed-on: https://go-review.googlesource.com/87200
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Given an inlinable method M in package P:
func (r *MyStruct) M(...) {
When M is compiled within its home package, the source position that
the compiler records for 'r' (receiver parameter variable) is
accurate, whereas if M is built as part of the compilation of some
other package (body read from export data), the declaration line
assigned to 'r' will be the line number of the 'import' directive, not
the source line from M's source file.
This inconsistency can cause differences in the size of abstract
parameter DIEs (due to variable-length encoding), which can then in
turn result in bad abstract origin offsets, which in turn triggers
build failures on iOS (dsymutil crashes when it encounters an
incorrect abstract origin reference).
Work around the problem by removing the "declaration line number"
attribute within the abstract parameter abbreviation table entry. The
decl line attribute doesn't contribute a whole lot to the debugging
experience, and it gets rid of the inconsistencies that trigger the
dsymutil crashes.
Updates #23374.
Change-Id: I0fdc8e19a48db0ccd938ceadf85103936f89ce9f
Reviewed-on: https://go-review.googlesource.com/87055
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Ensure that we do not insert any escapers into pipelines that
already contain an equivalent escaper. This prevents overescaping
from occuring even when an aliased parse tree that has already
been escaped is escaped again.
Fixes#21844
Change-Id: Ic00d5e01c97ef09a4e49407009cf71b0d07f5c0e
Reviewed-on: https://go-review.googlesource.com/83920
Reviewed-by: Russ Cox <rsc@golang.org>
There should not be a comma before "and" in the original text,
because what follows is not a complete sentence. Rewrite.
Change-Id: Ie99f204cc87e911fb46149e2eb65e132fa1eb63a
Reviewed-on: https://go-review.googlesource.com/87020
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Type values being comparable implies that Type is a valid map key type.
As previously written, they sound unrelated.
Change-Id: I8e2235275d62898bfb47de850e8257b51ab5cbd6
Reviewed-on: https://go-review.googlesource.com/87021
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Don't suggest that it's always necessary to disable optimizations.
(The text can be misread that way, even if it's not what was meant.)
Change-Id: I9a2dff6a75ce4a3f9210cdf4f5bad6aaaeae9b29
Reviewed-on: https://go-review.googlesource.com/87018
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Suppose you build the Go toolchain in directory A,
move the whole thing to directory B, and then use
it from B to build a new program hello.exe, and then
run hello.exe, and hello.exe crashes with a stack
trace into the standard library.
Long ago, you'd have seen hello.exe print file names
in the A directory tree, even though the files had moved
to the B directory tree. About two years ago we changed
the compiler to write down these files with the name
"$GOROOT" (that literal string) instead of A, so that the
final link from B could replace "$GOROOT" with B,
so that hello.exe's crash would show the correct source
file paths in the stack trace. (golang.org/cl/18200)
Now suppose that you do the same thing but hello.exe
doesn't crash: it prints fmt.Println(runtime.GOROOT()).
And you run hello.exe after clearing $GOROOT from the
environment.
Long ago, you'd have seen hello.exe print A instead of B.
Before this CL, you'd still see hello.exe print A instead of B.
This case is the one instance where a moved toolchain
still divulges its origin. Not anymore. After this CL, hello.exe
will print B, because the linker sets runtime/internal/sys.DefaultGoroot
with the effective GOROOT from link time.
This makes the default result of runtime.GOROOT once again
match the file names recorded in the binary, after two years
of divergence.
With that cleared up, we can reintroduce GOROOT into the
link action ID and also reenable TestExecutableGOROOT/RelocatedExe.
When $GOROOT_FINAL is set during link, it is used
in preference to $GOROOT, as always, but it was easier
to explain the behavior above without introducing that
complication.
Fixes#22155.
Fixes#20284.
Fixes#22475.
Change-Id: Ifdaeb77fd4678fdb337cf59ee25b2cd873ec1016
Reviewed-on: https://go-review.googlesource.com/86835
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The linker has been applying -X options before loading symbols,
meaning that when it sees -X y=z it creates a symbol named y
and initializes its string data to z. The symbol named y is marked
"DUPOK" so that when the actual packages are loaded, no error is
emitted when the real y is seen. The predefined y's data is used
instead of whatever the real y says.
If we define -X y=z and we never load y, then the predefined symbol
is dropped during dead code elimination, but not in shared library
builds. Shared library builds must include all symbols, so we have to
be more careful about not defining symbols that wouldn't have
appeared anyway.
To be more careful, save the -X settings until after all the symbols
are loaded from the packages, and then apply the string changes
to whatever symbols are known (but ignore the ones that were not
loaded at all). This ends up being simpler anyway, since it doesn't
depend on DUPOK magic.
Makes CL 86835 safe.
Fixes#23273.
Change-Id: Ib4c9b2d5eafa97c5a8114401dbec0134c76be54f
Reviewed-on: https://go-review.googlesource.com/86915
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When benchmarks run, they print lines like:
BenchmarkGenericNoMatch-8 3000000 385 ns/op
The first field, padded by spaces and followed by a tab,
is printed when the benchmark begins running.
The rest of the line is printed when the benchmark ends.
Tools and people can watch the timing of these prints
to see which benchmark is running.
To allow tools consuming json output to continue to be
able to see which benchmark is running, this CL adds a
special case to the usual "line at a time" behavior to flush
the benchmark name if it is observed separately from the
rest of the line.
Fixes#23352.
Change-Id: I7b6410698d78034eec18745d7f57b7d8e9575dbb
Reviewed-on: https://go-review.googlesource.com/86695
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apple changed the format of its support page, so we need to
restructure the HTML parser. The HTML table is now parsed using
regular expressions, and certificates are then found in macOS
trust store by their fingerprint.
Fixes#22181
Change-Id: I29e7a40d37770bb005d728f1832299c528691f7e
Reviewed-on: https://go-review.googlesource.com/77252
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
This just adds support on ELF systems, which is OK for now since that
is all that gccgo works on.
For the archive file generated by the compiler we add a new file
_buildid.o that has a section .go.buildid containing the build ID.
Using a new file lets us set the SHF_EXCLUDE bit in the section header,
so the linker will discard the section. It would be nicer to use
`objcopy --add-section`, but objcopy doesn't support setting the
SHF_EXCLUDE bit.
For an executable we just use an ordinary GNU build ID. Doing this
required modifying cmd/internal/buildid to look for a GNU build ID,
and use it if there is no other Go-specific note.
This CL fixes a minor bug in gccgoTOolchain.link: it was using .Target
instead of .built, so it failed for a cached file.
This CL fixes a bug reading note segments: the notes are aligned as
reported by the PT_NOTE's alignment field.
Updates #22472
Change-Id: I4d9e9978ef060bafc5b9574d9af16d97c13f3102
Reviewed-on: https://go-review.googlesource.com/85555
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If a benchmark calls b.Log without failing (without b.Error/b.Fatal/b.FailNow)
then that turns into output very much like a test passing,
except it says BENCH instead of PASS.
Benchmarks failing say FAIL just like tests failing.
Fixes#23346.
Change-Id: Ib188e695952da78057ab4a13f90d49937aa3c232
Reviewed-on: https://go-review.googlesource.com/86396
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is natural for tools to take a large string concatenation like
"1" + "1" + "1" + ... + "1"
and translate that into a sequence of go/constant calls:
x := constant.MakeString("1")
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
...
If the underlying representation of a string constant is a Go string,
then this leads to O(N²) memory for the concatenation of N strings,
allocating memory for "1", "11", "111", "1111", and so on.
This makes go/types and in particular cmd/vet run out of memory
(or at least use far too much) on machine-generated string concatenations,
such as those generated by go-bindata.
This CL allows code like the above to operate efficiently, by delaying
the evaluation of the actual string constant value until it is needed.
Now the representation of a string constant is either a string or an
explicit addition expression. The addition expression is turned into
a string the first time it is requested and then cached for future use.
This slows down the use of single strings, but analyses are likely not
dominated by that use anyway. It speeds up string concatenations,
especially large ones, significantly.
On my Mac running 32-bit code:
name old time/op new time/op delta
StringAdd/1-8 160ns ± 2% 183ns ± 1% +13.98% (p=0.000 n=10+10)
StringAdd/4-8 650ns ± 1% 927ns ± 4% +42.73% (p=0.000 n=10+10)
StringAdd/16-8 3.93µs ± 1% 2.78µs ± 2% -29.12% (p=0.000 n=8+9)
StringAdd/64-8 37.3µs ± 9% 10.1µs ± 5% -73.06% (p=0.000 n=10+10)
StringAdd/256-8 513µs ± 5% 38µs ± 1% -92.63% (p=0.000 n=10+10)
StringAdd/1024-8 5.67ms ± 4% 0.14ms ± 2% -97.45% (p=0.000 n=8+10)
StringAdd/4096-8 77.1ms ± 9% 0.7ms ± 2% -99.10% (p=0.000 n=10+9)
StringAdd/16384-8 1.33s ± 7% 0.00s ±10% -99.64% (p=0.000 n=10+10)
StringAdd/65536-8 21.5s ± 4% 0.0s ± 8% -99.89% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
StringAdd/1-8 232B ± 0% 256B ± 0% +10.34% (p=0.000 n=10+10)
StringAdd/4-8 1.20kB ± 0% 1.24kB ± 0% +3.33% (p=0.000 n=10+10)
StringAdd/16-8 14.7kB ± 0% 4.6kB ± 0% -68.87% (p=0.000 n=10+10)
StringAdd/64-8 223kB ± 0% 16kB ± 0% -92.66% (p=0.000 n=10+10)
StringAdd/256-8 3.48MB ± 0% 0.07MB ± 0% -98.07% (p=0.000 n=10+10)
StringAdd/1024-8 55.7MB ± 0% 0.3MB ± 0% -99.53% (p=0.000 n=10+10)
StringAdd/4096-8 855MB ± 0% 1MB ± 0% -99.88% (p=0.000 n=10+10)
StringAdd/16384-8 13.5GB ± 0% 0.0GB ± 0% -99.97% (p=0.000 n=9+10)
StringAdd/65536-8 215GB ± 0% 0GB ± 0% -99.99% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
StringAdd/1-8 3.00 ± 0% 3.00 ± 0% ~ (all equal)
StringAdd/4-8 9.00 ± 0% 11.00 ± 0% +22.22% (p=0.000 n=10+10)
StringAdd/16-8 33.0 ± 0% 25.0 ± 0% -24.24% (p=0.000 n=10+10)
StringAdd/64-8 129 ± 0% 75 ± 0% -41.86% (p=0.000 n=10+10)
StringAdd/256-8 513 ± 0% 269 ± 0% -47.56% (p=0.000 n=10+10)
StringAdd/1024-8 2.05k ± 0% 1.04k ± 0% -49.29% (p=0.000 n=10+10)
StringAdd/4096-8 8.19k ± 0% 4.12k ± 0% -49.77% (p=0.000 n=10+10)
StringAdd/16384-8 32.8k ± 0% 16.4k ± 0% -49.97% (p=0.000 n=9+10)
StringAdd/65536-8 131k ± 0% 66k ± 0% -50.11% (p=0.000 n=10+10)
https://perf.golang.org/search?q=upload:20180105.2Fixes#23348 (originally reported as cmd/vet failures in comments on #23222).
This makes constant.Values of Kind String no longer meaningful for ==, which
required fixes in go/types. While there, also fix go/types handling of constant.Values
of Kind Int (for uint64), Float, and Complex.
Change-Id: I80867bc9c4232c5c9b213443ff16645434a68b36
Reviewed-on: https://go-review.googlesource.com/86395
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I marked every test that takes more than 0.5 seconds on my machine
as something to run only when not in -short mode, or in -short mode
on the beefy linux/amd64, windows/amd64, and darwin/amd64 builders.
I also shortened a few needlessly-expensive tests where possible.
Cuts the time for go test -short cmd/go from 45s to 15s on my machine.
Should help even more on some of our builders and slower user machines.
Fixes#23287.
Change-Id: I0e36003ef947b0ebe4224a1373731f9fa9216843
Reviewed-on: https://go-review.googlesource.com/86252
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The docs were too specific. Make it vaguer. There are conditions for
which the Transport will try to reuse a connection anyway, even if the
Response Body isn't read to EOF or closed, but we don't need to get
into all the details in the docs.
Fixes#22954
Change-Id: I3b8ae32aeb1a61b396d0026e129552afbfecceec
Reviewed-on: https://go-review.googlesource.com/86276
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 84735 strengthened the -x test to make sure commands succeed,
using set -e, but the gcc flag tests can fail. Change them to say || true.
Fixes#23337.
Change-Id: I01e4017cb36ceb147b56935c2636de52ce7bdfdb
Reviewed-on: https://go-review.googlesource.com/86239
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.
fixes#8549
Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
The spec refers to a map's key and element types; thus the respective
values are "keys" and "elements". Also, a map value is the value of
the entire map.
Similar fix for channels, where appropriate.
Fixes#23254.
Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53
Reviewed-on: https://go-review.googlesource.com/85999
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
If test case framing appears in ordinary test output,
then test2json can get confused. If the fake framing is being
saved with t.Logf/t.Errorf/etc then we can already
distinguish it from real framing, and the code did.
It just forgot to write that framing as output (1-line fix).
If the fake framing is being generated by printing directly
to stdout/stderr, then test2json will simply get confused.
There's not a lot to do at that point (maybe it's even a feature).
Fixes#23036.
Change-Id: I29449c7ace304172b89d8babe23de507c0500455
Reviewed-on: https://go-review.googlesource.com/86238
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If you have a package p1 with an xtest (package p1_test)
that imports p2, where p2 itself imports p1, then when
trying to do coverage for p1 we need to make sure to
recompile p2. The problem was that the overall package
import graph looked like:
main -> p1_test -> p2 -> p1
Since we were recompiling p1 with coverage, we correctly
figured out that because p2 depends on a package being
recompiled due to coverage, p2 also needs to be split (forked) to
insert the dependency on the modified p1. But then we used
the same logic to split p1_test and main, with the effect that
the changes to p2 and p1_test and main were lost, since the
caller was still holding on to the original main, not the split version.
Change the code to treat main and p1_test as "already split"
and just update them in place.
Fixes#23314.
Change-Id: If7edeca6e39cdaeb5b9380d00b0c7d8c5891f086
Reviewed-on: https://go-review.googlesource.com/86237
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
findrunnable loops over allp to check run queues *after* it has
dropped its own P. This is unsafe because allp can change when nothing
is blocking safe-points. Hence, procresize could change allp
concurrently with findrunnable's loop. Beyond generally violating Go's
memory model, in the best case this could findrunnable to observe a
nil P pointer if allp has been grown but the new slots not yet
initialized. In the worst case, the reads of allp could tear, causing
findrunnable to read a word that isn't even a valid *P pointer.
Fix this by taking a snapshot of the allp slice header (but not the
backing store) before findrunnable drops its P and iterating over this
snapshot. The actual contents of allp are immutable up to len(allp),
so this fixes the race.
Updates #23098 (may fix).
Change-Id: I556ae2dbfffe9fe4a1bf43126e930b9e5c240ea8
Reviewed-on: https://go-review.googlesource.com/86215
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update rewrite algorithm by coping code from
go/internal/work/buildid:updateBuildID.
Probably, this is not the best option. We could provide high-level API
in cmd/internal/buildid in the future.
Fixes#23181
Change-Id: I336a7c50426ab39bc9998b55c372af61a4fb21a7
Reviewed-on: https://go-review.googlesource.com/84735
Reviewed-by: Russ Cox <rsc@golang.org>
In func TestXxxx(*testing.T) the Xxxx can be anything that can appear
in an identifier, but can't start with a lowercase letter. Clarify the docs.
Fixes#23322
Change-Id: I5c297916981f7e3890ee955d12bc7422a75488e2
Reviewed-on: https://go-review.googlesource.com/86001
Reviewed-by: Rob Pike <r@golang.org>
CL 78735 description:
time: add space padding layout strings(using underscore) for not only day but others
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Revert this CL because it breaks currently working formats that happen
to use underscores.
Fixes#23259
Change-Id: I64acaaca9b5b74785ee0f0be7910574e87daa649
Reviewed-on: https://go-review.googlesource.com/85998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
We retrieve an error using getsockopt with SO_ERROR. We were reporting
the error as coming from "getsockopt", but really it is coming from
"connect". It is not getsockopt that failed.
Fixes#19302
Change-Id: I510ab76e4b04c70cd9dfdfc46d9a410bf653d017
Reviewed-on: https://go-review.googlesource.com/85997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Commit c2c07c7989 (CL 49331) changed the linker and runtime to always
use 2MB stacks on 64-bit Windows. This is the corresponding change to
make 32-bit Windows always use large (1MB) stacks because it's
difficult to detect when Windows applications will call into arbitrary
C code that may expect a large stack.
This is done as a separate change because it's possible this will
cause too much address space pressure for a 32-bit address space. On
the other hand, cgo binaries on Windows already use 1MB stacks and
there haven't been complaints.
Updates #20975.
Change-Id: I8ce583f07cb52254fb4bd47250f1ef2b789bc490
Reviewed-on: https://go-review.googlesource.com/49610
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
During the refactor in 1126d1483f I
introduced a logical error within one withLock function that used
the result of the call before checking for the error. Change
the order so that the error is checked before the result is used.
None of the other withLock uses have similar issues.
Fixes#23208
Change-Id: I6c5dcf262e36bad4369c850f1e0131066360a82e
Reviewed-on: https://go-review.googlesource.com/85175
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A Select Op could produce a value with upper 32 bits NOT zeroed,
for example, Div32 is lowered to (Select0 (DIVL x y)).
In theory, we could look into the argument of a Select to decide
whether the upper bits are zeroed. As it is late in release cycle,
just disable this optimization for Select for now.
Fixes#23305.
Change-Id: Icf665a2af9ccb0a7ba0ae00c683c9e349638bf85
Reviewed-on: https://go-review.googlesource.com/85736
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Modify the regex in TestLinuxSendfile to not match the parameters of
the syscall, just its name and the opening parenthesis. This is enough
to recognize that the syscall was invoked.
This fixes the TestLinuxSendfile test when running in Clear Linux,
where strace always execute with -yy implied, having output with extra
information in the parameters:
[pid 5336] sendfile(6<TCP:[127.0.0.1:35007->127.0.0.1:55170]>, 8</home/c/src/go/src/net/http/testdata/index.html>, NULL, 22) = 22
Change-Id: If7639b785d5fdf65fae8e6149a97a57b06ea981c
Reviewed-on: https://go-review.googlesource.com/85657
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#23224
The previous Pow code had an optimization for
powers equal to ±0.5 that used Sqrt for
increased accuracy/speed. This caused special
cases involving powers of ±0.5 to disagree with
the Pow spec. This change places the Sqrt optimization
after all of the special case handling.
Change-Id: I6bf757f6248256b29cc21725a84e27705d855369
Reviewed-on: https://go-review.googlesource.com/85660
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Refactoring to make it slightly easier to add tests,
easier to add variable-printing-support for Delve,
and made naming and tagging more consistent.
No changes to the content of the test itself or when it is
run.
Change-Id: I374815b65a203bd43b27edebd90b859466d1c33b
Reviewed-on: https://go-review.googlesource.com/84979
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
golang.org/cl/81315 attempted to distinguish system goroutines
by examining the function name in the goroutine stack. It assumes that
the information would be available when GoSysBlock or GoInSyscall
events are processed, but it turned out the stack information is
set too late (when the goroutine gets a chance to run).
This change initializes the goroutine information entry when
processing GoCreate event which should be one of the very first
events for the every goroutine in trace.
Fixes#22574
Change-Id: I1ed37087ce2e78ed27c9b419b7d942eb4140cc69
Reviewed-on: https://go-review.googlesource.com/83595
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
My previous fix for issue 23179 was incomplete; it turns out that if
an unnamed parameter is below a specific size threshold, it gets
register-promoted away by the compiler (hence not encountered during
some parts of DWARF inline info processing), but if it is sufficiently
large, it is allocated to the stack as a named variable and treated as
a regular parameter by DWARF generation. Interestingly, something in
the ppc64le build of k8s causes an unnamed parameter to be retained
(where on amd64 it is deleted), meaning that this wasn't caught in my
amd64 testing.
The fix is to insure that "_" params are treated in the same way that
"~r%d" return temps are when matching up post-optimization inlined
routine params with pre-inlining declarations. I've also updated the
test case to include a "_" parameter with a very large size, which
also triggers the bug on amd64.
Fixes#23179.
Change-Id: I961c84cc7a873ad3f8f91db098a5e13896c4856e
Reviewed-on: https://go-review.googlesource.com/84975
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The current implementation prints a log, "invalid program: unexpected
type for embedded field", when the form *package.ident is embedded in
a struct declaration.
Note that since valid qualified identifiers must be exported, the result
for a valid program does not change.
Change-Id: If8b9d7056c56b6a6c5482eb749168a63c65ef685
Reviewed-on: https://go-review.googlesource.com/84436
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The helper routine for returning pre-inlining parameter declarations
wasn't properly handling the case where you have more than one
parameter named "_" in a function signature; this triggered a map
collision later on when the function was inlined and DWARF was
generated for the inlined routine instance.
Fixes#23179.
Change-Id: I12e5d6556ec5ce08e982a6b53666a4dcc1d22201
Reviewed-on: https://go-review.googlesource.com/84755
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The driver.Value type may be more then the documented 6 types if the
database driver supports it. Document that fact.
Updates #23077
Change-Id: If7e2112fa61a8cc4e155bb31e94e89b20c607242
Reviewed-on: https://go-review.googlesource.com/84636
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Disable the three linker DWARF tests that invoke the compiler in
non-debug mode on Solaris, since this seems to trigger a split stack
overflow. These can be turned back on once the issue in question is
resolved.
Updates #23168.
Change-Id: I5be1b098e33e8bad3bc234a0964eab1dee7e7954
Reviewed-on: https://go-review.googlesource.com/84655
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Rename -list flag to -errlist to avoid confusion with the go
test flag -list (introduced later).
This flag is only needed to get an error list when running the
go/types test harness manually on select files, e.g., as in:
go test -run=Check -files=x.go -errlist
Change-Id: I67febcf968d2d8f4ff00c81eea7b2df723560eac
Reviewed-on: https://go-review.googlesource.com/84378
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Exercise of preparing a how-to document motivated me to
clean up some of the stupider wonkier bits. Since this
does not run for test -short, expect no change for trybots,
did pass testing with OSX gdb and a refreshed copy of Delve.
Change-Id: I58edd10599b172c4787ff5f110db078f6c2c81c5
Reviewed-on: https://go-review.googlesource.com/83957
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Location lists are only supported on x86 and amd64, so the
test expecting them failed everywhere else. Make that test
skip unless GOARCH is x86 or amd64.
Change-Id: Id86b34d30c6a0b97e6fa0cd5aca31f51ed84f556
Reviewed-on: https://go-review.googlesource.com/84395
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The default test timeout is 10 minutes if unspecified.
The misc/cgo/testshared test didn't use t.timeout(sec), which respects
GO_TEST_TIMEOUT_SCALE, so all builders got the default 10 minute
timeout. arm5 needs more, though, so specify 10 minutes explicitly,
which will then get scaled accordingly on slower builders.
Change-Id: I19ecfdcd9c865f2b69524484415b8fbd2852718e
Reviewed-on: https://go-review.googlesource.com/84315
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Change the compiler's DWARF inline info generation to be more careful
about producing consistent instances of abstract function DIEs. The
new strategy is to insure that the only params/variables created in an
abstract subprogram DIE are those corresponding to declarations in the
original pre-inlining version of the code. If a concrete subprogram
winds up with other vars as part of the compilation process (return
temps, for example, or scalars generated by splitting a structure into
pieces) these are emitted as regular param/variable DIEs instead of
concrete DIEs.
The linker dwarf test now has a couple of new testpoints that include
checks to make sure that all abstract DIE references are
sane/resolvable; this will help catch similar problems in the future.
Fixes#23046.
Change-Id: I9b0030da8673fbb80b7ad50461fcf8c6ac823a37
Reviewed-on: https://go-review.googlesource.com/83675
Run-TryBot: Than McIntosh <thanm@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This attempts to symbolize the PC of morestack's caller when there's a
stack split at a bad time. The stack trace starts at the *caller* of
the function that attempted to grow the stack, so this is useful if it
isn't obvious what's being called at that point, such as in #21431.
Change-Id: I5dee305d87c8069611de2d14e7a3083d76264f8f
Reviewed-on: https://go-review.googlesource.com/84115
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
After go1.10, compiler/linker option flags apply only to the packages
listed directly on the command line unless the matching pattern is
specified. For debugging, we want to apply the flags to all packages.
Change-Id: Ic69eee1491b1080fc140592f200c59a6e03d87ac
Reviewed-on: https://go-review.googlesource.com/84135
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/go has grown slow, even in short mode, and it's now regularly
failing on a number of builders where it's taking over the previous 3
minute timeout. for now, give it more time.
Change-Id: If565baf71c2770880b2e2139b47e03433951331f
Reviewed-on: https://go-review.googlesource.com/84235
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The name-based heuristics fail too often to be on during "go test",
but we really want the printf vet check in "go test", so change to
a list of exactly which standard library functions are print-like.
For a later release we'd like to bring back checking for user-defined
wrappers, but in a completely precise way. Not for Go 1.10, though.
The new, more precise list includes t.Skipf, which caught some
mistakes in standard library tests.
Fixes#22936.
Change-Id: I110448e3f6b75afd4327cf87b6abb4cc2021fd0d
Reviewed-on: https://go-review.googlesource.com/83838
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Two minor changes to allow fixes in cmd/vet's printf checking.
1. Pass package import path in vet config, so that vet knows
whether it is, for example, vetting "fmt".
2. Add new, but undocumented and for now unsupported
flag -vettool to control which vet binary is invoked during go vet.
This lets the cmd/vet tests build and test a throwaway vet.exe
using cmd/go to ensure type checking information, all without
installing a potentially buggy cmd/vet.
For #22936.
Change-Id: I18df7c796ebc711361c847c63eb3ee17fb041ff7
Reviewed-on: https://go-review.googlesource.com/83837
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Srcset is largely the same as a URL, but is escaped in URL contexts.
Inside a srcset attribute, URLs have their commas percent-escaped to
avoid having the URL be interpreted as multiple URLs. Srcset is placed
in a srcset attribute literally.
Fixes#17441
Change-Id: I676b544784c7e54954ddb91eeff242cab25d02c4
Reviewed-on: https://go-review.googlesource.com/38324
Reviewed-by: Kunpei Sakai <namusyaka@gmail.com>
Reviewed-by: Mike Samuel <mikesamuel@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(This only manifested in test vet failures for packages without tests,
or else we'd probably have seen this sooner.)
Fixes#23047.
Change-Id: I41d09a7780999bbe1951377ffcc811ba86ea5000
Reviewed-on: https://go-review.googlesource.com/83955
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
os.NewFile doesn't put the fd into non-blocking mode.
In most cases, an *os.File returned by os.NewFile is in blocking mode.
Updates #7970
Updates #21856
Updates #23111
Change-Id: Iab08432e41f7ac1b5e25aaa8855d478adb7f98ed
Reviewed-on: https://go-review.googlesource.com/83995
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The export prologue goes into the _cgo_export.h file, where it may be
be #include'd by a .swig file. As SWIG defines its own type "intgo",
the definition of "intgo" in the export prologue could conflict.
Since we don't need to define "intgo" in the _cgo_export.h file, don't.
Defining "intgo" in _cgo_export.h was new for this release, so this
should not break any existing code.
No test case as I can't quite bring myself to write a test that
combines SWIG and cgo.
Change-Id: I8073e8300a1860cecd5994b9ad07dd35a4298c89
Reviewed-on: https://go-review.googlesource.com/83936
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
t.Run(f) does not wait for f after f calls t.Parallel.
Otherwise it would be impossible to create new
parallel sibling subtests for f.
Fixes#22993.
Change-Id: I27e1555ab1ff608eb8155db261d5e7ee8f486aef
Reviewed-on: https://go-review.googlesource.com/83880
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If package strings has a particular set of gcflags, then the strings_test
pseudo-package built as part of the test binary started inheriting the
same flags in CL 81496, to fix#22831.
Now the package main and final test binary link built as part of the
strings test binary also inherit the same flags, to fix#22994.
I am slightly uneasy about reusing package strings's flags for
package main, but the alternative would be to introduce some
kind of special case, which I'd be even more uneasy about.
This interpretation preserves the Go 1.9 behavior of existing
commands like:
go test -c -ldflags=-X=mypkg.debugString=foo mypkg
Fixes#22994.
Change-Id: I9ab83bf1a9a6adae530a7715b907e709fd6c1b5d
Reviewed-on: https://go-review.googlesource.com/83879
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current implementation ignores certs wherein the
Subject does not match the Issuer. An example of where
this causes issue is an enterprise environment with
intermediate CAs. In this case, the issuer is separate
(and may be loaded) but the intermediate is ignored.
A TLS handshake that does not include the intermediate
cert would then fail with an untrusted error in Go.
On other platforms (darwin-nocgo included), all trusted
certs are loaded and accepted reguardless of
Subject/Issuer names.
This change removes the Subject/Issuer name-matching
restriction of certificates when trustAsRoot is set,
allowing all trusted certs to be loaded on darwin (cgo).
Refs #16532
Change-Id: I451e929588f8911892be6bdc2143d0799363c5f8
Reviewed-on: https://go-review.googlesource.com/36942
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use Brendan Gregg's FlameGraphs page link.
Mention the flame graph is available from the upstream pprof.
Change-Id: Ife1d5a5f4f93f20cd5952a09083f798b77d25a60
Reviewed-on: https://go-review.googlesource.com/83798
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Change-Id: I886998380489862ab9a324a6774f2e4cf7124122
Reviewed-on: https://go-review.googlesource.com/78735
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
An exec command is normally used on platforms were the test is run in
some unusual way, making it less likely that the testlog will be useful.
Updates #22593
Change-Id: I0768f6da89cb559d8d675fdf6d685db9ecedab9e
Reviewed-on: https://go-review.googlesource.com/83578
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We can't currently inline functions that contain closures anyway, so
just delete this budgeting code for now. Re-enable once we can (if
ever) inline functions with nested closures.
Updates #15561.
Fixes#23093.
Change-Id: Idc5f8e042ccfcc8921022e58d3843719d4ab821e
Reviewed-on: https://go-review.googlesource.com/83538
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When using -importcfg, the import paths recorded by the compiler in
the object file are simply the import paths. When not using -importcfg,
the import paths have a trailing ".a". Assume that if we are using
-importcfg with the compiler, we are using it with the linker,
and so if the linker sees an -importcfg option it should not
strip ".a" from the import path read from the object files.
This was mostly working because the linker only strips a trailing
".x" for a literal dot and any single character 'x'. Since few import
paths end with ".x", most programs worked fine.
Fixes#22986
Change-Id: I6c10a160b97dd63fff3931f27a1514c856e8cd52
Reviewed-on: https://go-review.googlesource.com/81878
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Otherwise, on systems for which syscall does not implement Getwd,
a lot of unnecessary files and directories get added to the testlog,
right up the root directory. This was causing tests on such systems
to fail to cache in practice.
Updates #22593
Change-Id: Ic8cb3450ea62aa0ca8eeb15754349f151cd76f85
Reviewed-on: https://go-review.googlesource.com/83455
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
All plugins issues I would call bugs now closed, so
(with some amount of optimism) update the plugin documentation.
Change-Id: Ia421c18a166d7cdf599ac86f2336541c1ef42a0d
Reviewed-on: https://go-review.googlesource.com/65670
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It causes every test to fail as the log file is on the local file system,
not the NaCl file system.
Updates #22593
Change-Id: Iee3d8307317bd792c9c701baa962ebbbfa34c147
Reviewed-on: https://go-review.googlesource.com/83256
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of requiring that cmd/api/run.go be edited upon each
release to include the next Go version number, look in $GOROOT/api
for files with the prefix go1* and use those instead to perform
API checks.
Change-Id: I5d9407f2bd368ff5e62f487cccdd245641ca9c9b
Reviewed-on: https://go-review.googlesource.com/83355
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use “substantial”, which is believed to be the correct word.
Additionally, this change strips trailing whitespace from the file.
Change-Id: I5b6b718fc09e4b8b911b95e8be0733abd58e165d
Reviewed-on: https://go-review.googlesource.com/83356
Reviewed-by: Andrew Gerrand <adg@golang.org>
The Builder's ReadFrom method allows the underlying unsafe slice to
escape, and for callers to subsequently modify memory that had been
unsafely converted into an immutable string.
In the original proposal for Builder (#18990), I'd noted there should
be no Read methods:
> There would be no Reset or Bytes or Truncate or Read methods.
> Nothing that could mutate the []byte once it was unsafely converted
> to a string.
And in my prototype (https://golang.org/cl/37767), I handled ReadFrom
properly, but when https://golang.org/cl/74931 arrived, I missed that
it had a ReadFrom method and approved it.
Because we're so close to the Go 1.10 release, just remove the
ReadFrom method rather than think about possible fixes. It has
marginal utility in a Builder anyway.
Also, fix a separate bug that also allowed mutation of a slice's
backing array after it had been converted into a slice by disallowing
copies of the Builder by value.
Updates #18990Fixes#23083Fixes#23084
Change-Id: Id1f860f8a4f5f88b32213cf85108ebc609acb95f
Reviewed-on: https://go-review.googlesource.com/83255
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we write a cached test result, we now also write a log of the
environment variables and files inspected by the test run,
along with a hash of their content. Before reusing a cached test result,
we recompute the hash of the content specified by the log, and only
use the result if that content has not changed.
This makes test caching behave correctly for tests that consult
environment variables or stat or read files or directories.
Fixes#22593.
Change-Id: I8608798e73c90e0c1911a38bf7e03e1232d784dc
Reviewed-on: https://go-review.googlesource.com/81895
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, wbBufFlush does nothing if the goroutine is dying on the
assumption that the system is crashing anyway and running the write
barrier may crash it even more. However, it fails to reset the
buffer's "next" pointer. As a result, if there are later write
barriers on the same P, the write barrier will overflow the write
barrier buffer and start corrupting other fields in the P or other
heap objects. Often, this corrupts fields in the next allocated P
since they tend to be together in the heap.
Fix this by always resetting the buffer's "next" pointer, even if
we're not doing anything with the pointers in the buffer.
Updates #22987 and #22988. (May fix; it's hard to say.)
Change-Id: I82c11ea2d399e1658531c3e8065445a66b7282b2
Reviewed-on: https://go-review.googlesource.com/83016
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
heapBits.bits is used during bulkBarrierPreWrite via
heapBits.isPointer, which means it must not be preempted. If it is
preempted, several bad things can happen:
1. This could allow a GC phase change, and the resulting shear between
the barriers and the memory writes could result in a lost pointer.
2. Since bulkBarrierPreWrite uses the P's local write barrier buffer,
if it also migrates to a different P, it could try to append to the
write barrier buffer concurrently with another write barrier. This can
result in the buffer's next pointer skipping over its end pointer,
which results in a buffer overflow that can corrupt arbitrary other
fields in the Ps (or anything in the heap, really, but it'll probably
crash from the corrupted P quickly).
Fix this by marking heapBits.bits go:nosplit. This would be the
perfect use for a recursive no-preempt annotation (#21314).
This doesn't actually affect any binaries because this function was
always inlined anyway. (I discovered it when I was modifying heapBits
and make h.bits() no longer inline, which led to rampant crashes from
problem 2 above.)
Updates #22987 and #22988 (but doesn't fix because it doesn't actually
change the generated code).
Change-Id: I60ebb928b1233b0613361ac3d0558d7b1cb65610
Reviewed-on: https://go-review.googlesource.com/83015
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The package unsafe docs say it's safe to convert an unsafe.Pointer to
uintptr in the argument list to an assembly function, but it was
erroneously only detecting normal pointers converted to unsafe.Pointer
and then to intptr.
Fixes#23051.
Change-Id: Id1be19f6d8f26f2d17ba815191717d2f4f899732
Reviewed-on: https://go-review.googlesource.com/82817
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This essentially applies https://golang.org/cl/81636 to the net package.
The full truth seems too complicated to write in this method's doc, so
I'm going with a simple half truth.
The full truth is that File returns the descriptor in blocking mode,
because that is historically how it worked, and existing programs
would be surprised if the descriptor is suddenly non-blocking. On Unix
systems whether a socket is non-blocking or not is a property of the
underlying file description, not of a particular file descriptor, so
changing the returned descriptor to blocking mode also changes the
existing socket to blocking mode. Blocking mode works fine, althoug I/O
operations now take up a thread. SetDeadline and friends rely on the
runtime poller, and the runtime poller only works if the descriptor is
non-blocking. So it's correct that calling File disables SetDeadline.
The other half of the truth is that if the program is willing to work
with a non-blocking descriptor, it could call
syscall.SetNonblock(f.Fd(), true) to change the descriptor, and
the original socket, to non-blocking mode. At that point SetDeadline
would start working again. I tried to write that in a way that is
short and comprehensible but failed. Since we now have the RawConn
approach to frobbing the descriptor, and hopefully most people can use
that rather than calling File, I decided to punt.
Updates #22934Fixes#21862
Change-Id: If269da762f6f5a88c334e7b6d6f3998f7e10b11e
Reviewed-on: https://go-review.googlesource.com/82915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test has been getting occasional timeouts on the race builder.
The point of the test is whether a file descriptor leaks, not whether
the connection occurs in a certain amount of time. So use a very large
timeout. The connection is normally fast and the timeout doesn't matter.
Updates #13324
Change-Id: Ie1051c4a0be1fca4e63b1277101770be0cdae512
Reviewed-on: https://go-review.googlesource.com/82916
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The jobject type is declared as a pointer, but some JVMs
(Dalvik, ART) store non-pointer values in them. In Go, we must
use uintptr instead of a real pointer for these types.
This is similar to the CoreFoundation types on Darwin which
were "fixed" in CL 66332.
Update #22906
Update #21897
RELNOTE=yes
Change-Id: I0d4c664501d89a696c2fb037c995503caabf8911
Reviewed-on: https://go-review.googlesource.com/81876
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The DNS code can start goroutines and not wait for them to complete.
This does no harm, but in tests this can cause a race condition with
the test hooks that are installed and unintalled around the tests.
Add a WaitGroup that tests of DNS can use to avoid the race.
Fixes#21090
Change-Id: I6c1443a9c2378e8b89d0ab1d6390c0e3e726b0ce
Reviewed-on: https://go-review.googlesource.com/82795
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If (*Template).New replaces an existing template, reset the
existing template that is going to be replaced so that any
later attempt to execute this orphaned template will fail.
Fixes#22780
Change-Id: I0e058f42c1542c86d19dc5f6c4e1e859e670a4a2
Reviewed-on: https://go-review.googlesource.com/78542
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Pointer arithemetic is done mod 2^32 on 386, so we can just
drop the high bits of any large constant offsets.
The bounds check will make sure wraparounds are never observed.
Fixes#21655
Change-Id: I68ae5bbea9f02c73968ea2b21ca017e5ecb89223
Reviewed-on: https://go-review.googlesource.com/82675
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
I can reproduce with a very short timeout (fractions of a millisecond)
combined with -race.
But given that this is inherently sensitive to actual time, add a
testing mechanism to retry with increasingly large times to compensate
for busy buidlers. This also means the test is usually faster now,
too, since we can start with smaller durations.
Fixes#19608
Change-Id: I3a222464720195849da768e9801eb7b43baa4aeb
Reviewed-on: https://go-review.googlesource.com/82595
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The DWARF inline info generation code was using file/line/column (from
src.Pos) as a means of matching up pre- and post-optimization variable
nodes. This turns out to be problematic since it looks as though
distinct formals on the same line can be assigned the same column
number. Work around this issue by adding variable names to the
disambiguation code. Added a testpoint to the linker DWARF test that
checks to make sure each abstract origin offset of distinct within a
given DWARF DW_AT_inlined_routine body.
Fixes#23020.
Change-Id: Ie09bbe01dc60822d84d4085547b138e644036fb3
Reviewed-on: https://go-review.googlesource.com/82396
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL reverts CL 76851 and takes a different approach to #21357.
The changes in encode.go and encode_test.go are reverts that
rolls back the changed behavior in CL 76851 where
embedded pointers to unexported struct types were
unilaterally ignored in both marshal and unmarshal.
Instead, these fields are handled as before with the exception that
it returns an error when Unmarshal is unable to set an unexported field.
The behavior of Marshal is now unchanged with regards to #21357.
This policy maintains the greatest degree of backwards compatibility
and avoids silently discarding data the user may have expected to be present.
Fixes#21357
Change-Id: I7dc753280c99f786ac51acf7e6c0246618c8b2b1
Reviewed-on: https://go-review.googlesource.com/82135
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixed by CL 76025 yesterday, without realizing it:
the testshared and testplugin builds of separate iface_i
packages were colliding incorrectly in the cache.
Including the build directory fixes that.
Fixes#22571.
Change-Id: Id8193781c67c3150823dc1f48eae781dfe3702fb
Reviewed-on: https://go-review.googlesource.com/76371
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There are some basic tests in the packages implementing the hashes,
but this one is meant to be comprehensive for the standard library
as a whole.
Most importantly, it locks in the current representations and makes
sure that they do not change from release to release (and also, as a
result, that future releases can parse the representations generated
by older releases).
The crypto/* MarshalBinary implementations are being changed
in this CL to write only d.x[:d.nx] to the encoding, with zeros for
the remainder of the slice d.x[d.nx:]. The old encoding wrote the
whole d.x, but that exposed an internal detail: whether d.x is
cleared after a full buffer is accumulated, and also whether d.x was
used at all for previous blocks (consider 1-byte writes vs 1024-byte writes).
The new encoding writes only what the decoder needs to know,
nothing more.
In fact the old encodings were arguably also a security hole,
because they exposed data written even before the most recent
call to the Reset method, data that clearly has no impact on the
current hash and clearly should not be exposed. The leakage
is clearly visible in the old crypto/sha1 golden test tables also
being modified in this CL.
Change-Id: I4e9193a3ec5f91d27ce7d0aa24c19b3923741416
Reviewed-on: https://go-review.googlesource.com/82136
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
The docs make it seem like they are all things a single object
would implement. That's true of Driver and DriverContext,
but Connector is really something else. Attempt to clarify.
Change-Id: I8fdf1cff855a0fbe37ea22720c082045c719a267
Reviewed-on: https://go-review.googlesource.com/82082
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Go 1.10 is adding new API MarshalPKCS1PublicKey and
ParsePKCS1PublicKey for converting rsa.PublicKeys.
Even though we'd prefer that users did not, check that
if users call asn1.Marshal and asn1.Unmarshal directly instead,
they get the same results. We know that code exists in the
wild that depends on this.
Change-Id: Ia385d6954fda2eba7da228dc42f229b6839ef11e
Reviewed-on: https://go-review.googlesource.com/82080
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Originally these routines could not fail except by
returning errors from the underlying writer.
Then we realized that header keys containing colons
needed to be rejected, and we started returning an error
from Encode. But that only happens after writing a
partial PEM block to the underlying writer, which is
unfortunate, but at least it was undocumented.
CL 77790 then documented this unfortunate behavior.
Instead of documenting unfortunate behavior, fix it.
Change-Id: Ic7467a576c4cecd16a99138571a1269cc4f96204
Reviewed-on: https://go-review.googlesource.com/82076
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Historically, DetectContentType has returned "text/plain; charset=utf-8"
for an empty body, there was a test for this, and there should continue
to be one.
CL 46631 changed the content-serving handlers to avoid setting any
Content-Type header when serving empty content. Even if that change
in behavior is correct, the CL is explicitly not changing DetectContentType,
so it must also not change DetectContentType's tests.
Change-Id: I7a19c9fabb43be47e349b40e729e49fceb3f2894
Reviewed-on: https://go-review.googlesource.com/82077
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes a regression where only CRLF was folded into LF at EOF.
Now, we also truncate trailing CR at EOF to preserve the old behavior.
Every one of the test cases added exactly matches the behavior
of Go1.9, even if the results are somewhat unexpected.
Fixes#22937
Change-Id: I1bc6550533163ae489ea77ec1e598163267b7eec
Reviewed-on: https://go-review.googlesource.com/81577
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The previous implementation of net.Pipe was just a thin wrapper around
io.Pipe and did not wrap any of the io.Pipe errors as net.Errors.
As a result of Hyrum's law, users have come to depend on the fact that
net.Pipe returns io.ErrClosedPipe when the pipe is closed.
Thus, we preserve this behavior to avoid regressing such use cases.
Change-Id: I06b387877b944c1c08527601f58983872b7557b4
Reviewed-on: https://go-review.googlesource.com/81777
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Sometimes people use run.bash repeatedly
or run go tool dist test by hand for cgo tests.
Avoid test caching in that case, by request.
Refactor code so that all go test commands
share a common prefix.
If not caching is problematic it will be a one-line
change to turn caching back on.
Fixes#22758.
Change-Id: I17d721b832d97bffe26629d21f85b05dbbf2b3ec
Reviewed-on: https://go-review.googlesource.com/80735
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are, unfortunately, intermediate CA ceritificates in circulation
that contain the invalid character '&' in some PrintableString fields,
notably Organization Name. This patch allows for ampersand
to be parsed as though it is valid in an ASN.1 PrintableString.
Fixes#22970
Change-Id: Ifab1a10bbff1cdac68e843c6b857ff1a031051aa
Reviewed-on: https://go-review.googlesource.com/81635
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When the user context which passed in (*DB)BeginTx is canceled or
timeout, the current implementation could cause db transaction leak
in some extreme scenario.
Goroutine 1:
Call (*DB) BeginTx begins a transaction with a userContext.
In (*DB)BeginTx, a new goroutine (*Tx)awaitDone
which monitor context and rollback tx if needed will be created
Goroutine 2(awaitDone):
block on tx.ctx.Done()
Goroutine 1:
Execute some insert or update sqls on the database
Goroutine 1:
Commit the transaction, (*Tx)Commit set
the atomic variable tx.done to 1
Goroutine 3(maybe global timer):
Cancel userContext which be passed in Tx
Goroutine 1:
(*Tx)Commit checks tx.ctx.Done().
Due to the context has been canceled, it will return
context.Canceled or context.DeadlineExceeded error immediately
and abort the real COMMIT operation of transaction
Goroutine 2:
Release with tx.ctx.Done() signal, execute (*Tx)rollback.
However the atomic variable tx.done is 1 currently,
it will return ErrTxDone error immediately and
abort the real ROLLBACK operation of transaction
Fixes#22976
Change-Id: I3bc23adf25db823861d91e33d3cca6189fb1171d
Reviewed-on: https://go-review.googlesource.com/81736
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Make sure that when we're assigning to a map, we evaluate the
right-hand side before we attempt to insert into the map.
We used to evaluate the left-hand side to a pointer-to-slot-in-bucket
(which as a side effect does len(m)++), then evaluate the right-hand side,
then do the assignment. That clearly isn't correct when the right-hand side
might panic.
Fixes#22881
Change-Id: I42a62870ff4bf480568c9bdbf0bb18958962bdf0
Reviewed-on: https://go-review.googlesource.com/81817
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Turn off append-to-itself optimization if optimizations are turned off.
This optimization triggered a bug when doing
s = append(s, s)
where we write to the leftmost s before reading the rightmost s.
Update #17039
Change-Id: I21996532d20a75db6ec8d49db50cb157a1360b80
Reviewed-on: https://go-review.googlesource.com/81816
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This test was added recently as a regress test for the spec relaxation
in #9060, but doesn't work correctly yet. Disable for now to fix noopt
builders.
Updates #22444.
Change-Id: I45c521ae0da7ffb0c6859d6f7220c59828ac6149
Reviewed-on: https://go-review.googlesource.com/81775
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The DWARF inline info generation hooks weren't properly
handling unused auto vars in certain cases, triggering an assert (now
fixed). Also with this change, introduce a new autom "flavor" to
use for autom entries that are added to insure that a specific
auto type makes it into the linker (this is a follow-on to the fix
for 22941).
Fixes#22962.
Change-Id: I7a2d8caf47f6ca897b12acb6a6de0eb25f5cac8f
Reviewed-on: https://go-review.googlesource.com/81557
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The iOS test harness dumps the output of its lldb session to stdout,
but only if the lldb session was successfully started.
Make sure the log is always dumpede, so that lldb startup failures
such as
lldb setup error: exited (lldb start: exit status 253)
can be diagnosed.
For the iOS builders.
Change-Id: Ie0e3341dd8f84a88d26509c34816668d3ebbfaa0
Reviewed-on: https://go-review.googlesource.com/76195
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The whole GOROOT/pkg tree is installed using the GOHOSTOS/GOHOSTARCH
toolchain (installed in GOROOT/pkg/tool/GOHOSTOS_GOHOSTARCH).
The testgo.exe we run during the cmd/go test will be built
for GOOS/GOARCH, which means it will use the GOOS/GOARCH toolchain
(installed in GOROOT/pkg/tool/GOOS_GOARCH).
If these are not the same toolchain, then the entire standard library
will look out of date to testgo.exe (the compilers in those two different
tool directories are built for different architectures and have different
buid IDs), which will cause many tests to do unnecessary rebuilds
and some tests to attempt to overwrite the installed standard library,
which will in turn make it look out of date to whatever runs after the
cmd/go test exits.
Bail out entirely in this case instead of destroying the world.
The changes outside TestMain are checks that might have caught
this a bit earlier and made it much less confusing to debug.
Fixes#22709.
Fixes#22965.
Change-Id: Ibf28fa19e29a1f1b8f17875f446d3474dd04a924
Reviewed-on: https://go-review.googlesource.com/81516
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we're using -covermode=atomic with -coverpkg, to add coverage
to more than just the package being tested, then we need to make sure
to make sync/atomic available to the compiler for every package
being recompiled for coverage.
Fixes#22728.
Change-Id: I27f88f6a62e37d4a7455554cd03c8ca2b21f81a4
Reviewed-on: https://go-review.googlesource.com/81497
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change updates runtime.semasleep to no longer call
runtime.nanotime and instead calls lwp_park with a duration to sleep
relative to the monotonic clock, so the nanotime is never called.
(This requires updating to a newer version of the lwp_park system
call, which is safe, because Go 1.10 will require the unreleased
NetBSD 8+ anyway)
Additionally, this change makes the nanotime function use the
monotonic clock for netbsd/arm, which was forgotten from
https://golang.org/cl/81135 which updated netbsd/amd64 and netbsd/386.
Because semasleep previously depended on nanotime, the past few days
of netbsd have likely been unstable because lwp_park was then mixing
the monotonic and wall clocks. After this CL, lwp_park no longer
depends on nanotime.
Original patch submitted at:
https://www.netbsd.org/~christos/go-lwp-park-clock-monotonic.diff
This commit message (any any mistakes therein) were written by Brad
Fitzpatrick. (Brad migrated the patch to Gerrit and checked CLAs)
Updates #6007Fixes#22968
Also updates netbsd/arm to use monotonic time for
Change-Id: If77ef7dc610b3025831d84cdfadfbbba2c52acb2
Reviewed-on: https://go-review.googlesource.com/81715
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The full truth seems too complicated to write in this method's doc, so
I'm going with a simple half truth.
The full truth is that Fd returns the descriptor in blocking mode,
because that is historically how it worked, and existing programs
would be surprised if the descriptor is suddenly non-blocking. On Unix
systems whether a file is non-blocking or not is a property of the
underlying file description, not of a particular file descriptor, so
changing the returned descriptor to blocking mode also changes the
existing File to blocking mode. Blocking mode works fine, althoug I/O
operations now take up a thread. SetDeadline and friends rely on the
runtime poller, and the runtime poller only works if the descriptor is
non-blocking. So it's correct that calling Fd disables SetDeadline.
The other half of the truth is that if the program is willing to work
with a non-blocking descriptor, it could call
syscall.SetNonblock(descriptor, true) to change the descriptor, and
the original File, to non-blocking mode. At that point SetDeadline
would start working again. I tried to write that in a way that is
short and comprehensible but failed. Since deadlines mostly work on
pipes, and there isn't much reason to call Fd on a pipe, and few
people use SetDeadline, I decided to punt.
Fixes#22934
Change-Id: I2e49e036f0bcf71f5365193831696f9e4120527c
Reviewed-on: https://go-review.googlesource.com/81636
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
That Parse doesn't parse ("foo.com/path" or "foo.com:443/path") has
become something of a FAQ.
Updates #19779
Updates #21415
Updates #22955
Change-Id: Ib68efddb67f59b1374e8ed94effd4a326988dee7
Reviewed-on: https://go-review.googlesource.com/81436
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test binaries accept -timeout=0 to mean no timeout,
but then the backup timer in cmd/go kills the test after 1 minute.
Make cmd/go understand this special case and change
behavior accordingly.
Fixes#14780.
Change-Id: I66bf517173a4ad21d53a5ee88d163f04b8929fb6
Reviewed-on: https://go-review.googlesource.com/81499
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
1. Apply JSON conversion when -bench is in use.
2. Apply JSON conversion to "no test files" result.
3. Apply JSON conversion to test case-ending SKIP status.
Fixes#22769.
Fixes#22790.
Change-Id: I67ad656fc58bacae8c51d23b1e6d543cad190f08
Reviewed-on: https://go-review.googlesource.com/81535
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The cover variable indices could vary from build to build,
but they were not included in the build ID hash, so that
reusing the previously built package was not safe.
Make the indices no longer vary from build to build,
so that caching is safe.
Fixes#22652.
Change-Id: Ie26d73c648aadd285f97e0bf39619cabc3da54f2
Reviewed-on: https://go-review.googlesource.com/81515
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For Go 1.10, works around a go/types bug that can't typecheck
a corner-case type cycle. Once we are confident that bugs like
this are gone from go/types then we can stop ignoring these
failures.
For #22890.
Change-Id: I38da57e01a0636323e1af4484c30871786125df3
Reviewed-on: https://go-review.googlesource.com/81500
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Earlier versions of Go were not very picky about leading spaces
in the -gcflags values. Make the new pattern-enhanced parser
equally lax.
Fixes#22943.
Change-Id: I5cf4d3e81412e895a4b52af325853ed48d0b73f4
Reviewed-on: https://go-review.googlesource.com/81498
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It's not safe to do p+x with unsafe if that would point past the
end of the object. (Valid in C, not safe in Go.)
Pass a "whySafe" reason (compiled away) to explain at each
call site why it's safe.
Fixes#21733.
Change-Id: I5da8c25bde66f5c9beac232f2135dcab8e8bf3b1
Reviewed-on: https://go-review.googlesource.com/80738
Reviewed-by: Austin Clements <austin@google.com>
The number of threads in syscall presented by execution tracer's
trace view includes not only the threads calling system calls on behalf
of user created goroutines, but also those running on behalf of system
goroutines.
When the number of such system goroutines was small, the graph was
useful when examining where a program was saturating the CPU.
But as more and more system goroutines are invloved the graph became
less useful for the purpose - for example, after golang.org/cl/34784,
the timer goroutines dominate in the graph with large P
because the runtime creates per-P timer goroutines.
This change excludes the threads in syscall on behalf of runtime (system
goroutines) from the visualization. Alternatively, I could visualize the
count of such threads in a separate counter but in the same graph.
Given that many other debug endpoints (e.g. /debug/pprof/goroutine) hide
the system goroutines, including them in the same graph can confuse users.
Update #22574
Change-Id: If758cd6b9ed0596fde9a471e846b93246580b9d5
Reviewed-on: https://go-review.googlesource.com/81315
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Minor.
Makes reading failing runtime test stacktraces easier (by having fewer
goroutines to read) on machines where these gdb tests wouldn't have
ever run anyway.
Change-Id: I3fab0667e017f20ef3bf96a8cc4cfcc614d25b5c
Reviewed-on: https://go-review.googlesource.com/81575
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Per the decision for #14844, index expressions that are non-constant
shifts where the LHS operand is representable as an int are now valid.
Fixes#21693.
Change-Id: Ifafad2c0c65975e0200ce7e28d1db210e0eacd9d
Reviewed-on: https://go-review.googlesource.com/81277
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I think of "sending" a signal as calling kill, but sigsend is involved
in handling a signal and, specifically delivering it to the internal
signal queue. The term "delivery" is already used in
signalWaitUntilIdle, so this CL also uses it in the documentation for
sigsend.
Change-Id: I86e171f247f525ece884a680bace616fa9a3c7bd
Reviewed-on: https://go-review.googlesource.com/81235
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, when we minit on a thread that already has an alternate
signal stack (e.g., because the M was an extram being used for a cgo
callback, or to handle a signal on a C thread, or because the
platform's libc always allocates a signal stack like on Android), we
simply drop the Go-allocated gsignal stack on the floor.
This is a problem for Ms on the extram list because those Ms may later
be reused for a different thread that may not have its own alternate
signal stack. On tip, this manifests as a crash in sigaltstack because
we clear the gsignal stack bounds in unminit and later try to use
those cleared bounds when we re-minit that M. On 1.9 and earlier, we
didn't clear the bounds, so this manifests as running more than one
signal handler on the same signal stack, which could lead to arbitrary
memory corruption.
This CL fixes this problem by saving the Go-allocated gsignal stack in
a new field in the m struct when overwriting it with a system-provided
signal stack, and then restoring the original gsignal stack in
unminit.
This CL is designed to be easy to back-port to 1.9. It won't quite
cherry-pick cleanly, but it should be sufficient to simply ignore the
change in mexit (which didn't exist in 1.9).
Now that we always have a place to stash the original signal stack in
the m struct, there are some simplifications we can make to the signal
stack handling. We'll do those in a later CL.
Fixes#22930.
Change-Id: I55c5a6dd9d97532f131146afdef0b216e1433054
Reviewed-on: https://go-review.googlesource.com/81476
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If package strings has a particular set of gcflags, then the strings_test
pseudo-package built as part of the test binary should inherit the same flags.
Fixes#22831.
Change-Id: I0e896b6c0f1063454300b7323f577feffbd6650b
Reviewed-on: https://go-review.googlesource.com/81496
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If the build of the test binary failed, the go command correctly
avoided running the binary, but the -x output indicated otherwise.
Fixes#22659.
Change-Id: Ib4d262bf1735f057c994a45fc23c499d4ebe3246
Reviewed-on: https://go-review.googlesource.com/81495
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The CL introducing merged handling of cover profiles
did not correctly account for the fact that the file name argument
to -coverprofile is required to be interpreted relative to
the -outputdir argument.
Fixes#22804.
Change-Id: I804774013c12187313b8fd2044302978bdbb6697
Reviewed-on: https://go-review.googlesource.com/81455
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code that generates the list of DWARF variables for a function
(params and autos) will emit a "no-location" entry in the DWARF for a
user var that appears in the original pre-optimization version of the
function but is no longer around when optimization is complete. The
intent is that if a GDB user types "print foo" (where foo has been
optimized out), the response will be "<optimized out>" as opposed to
"there is no such variable 'foo'). This change fixes said code to
include vars on the autom list for the function, to insure that the
type symbol for the variable makes it to the linker.
Fixes#22941.
Change-Id: Id29f1f39d68fbb798602dfd6728603040624fc41
Reviewed-on: https://go-review.googlesource.com/81415
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Values must not be copied after the first use.
Using noCopy makes vet complain about copies
even before the first use, which is incorrect
and very frustrating.
Drop it.
Fixes#21504.
Change-Id: Icd3a5ac3fe11e84525b998e848ed18a5d996f45a
Reviewed-on: https://go-review.googlesource.com/80836
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Call is meant to mirror the language semantics, which allow:
var r io.ReadWriter
f := func(io.Reader){}
f(r)
even though the conversion from io.ReadWriter to io.Reader is
being applied to a nil interface. This is different from an explicit
conversion:
_ = r.(io.Reader)
f(r.(io.Reader))
Both of those lines panic, but the implicit conversion does not.
By using E2I, which is the implementation of the explicit conversion,
the reflect.Call equivalent of f(r) was inadvertently panicking.
Avoid the panic.
Fixes#22143.
Change-Id: I6b2f5b808e0cd3b89ae8bc75881e307bf1c25558
Reviewed-on: https://go-review.googlesource.com/80736
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The ssa backend is aggressive about placing constants and
certain other values in the Entry block. It's implausible
that the original line numbers for these constants makes
any sort of sense when it appears to a user stepping in a
debugger, and they're also not that useful in dumps since
entry-block instructions tend to be constants (i.e.,
unlikely to be the cause of a crash).
Therefore, use src.NoXPos for any values that are explicitly
inserted into a function's entry block.
Passes all tests, including ssa/debug_test.go with both
gdb and a fairly recent dlv. Hand-verified that it solves
the reported problem; constructed a test that reproduced
a problem, and fixed it.
Modified test harness to allow injection of slightly more
interesting inputs.
Fixes#22558.
Change-Id: I4476927067846bc4366da7793d2375c111694c55
Reviewed-on: https://go-review.googlesource.com/81215
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts commit 08f19bbde1.
Reason for revert:
The changed transformation takes effect on a larger set
of code snippets than expected.
For example, this:
func foo() {
// Comment
bar()
}
becomes:
func foo() {
// Comment
bar()
}
This is an unintended consequence.
Change-Id: Ifca88d6267dab8a8170791f7205124712bf8ace8
Reviewed-on: https://go-review.googlesource.com/81335
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
GOEXPERIMENT is only set during make.bash, so checking the environment
variable isn't effectual. Instead, check the values exposed by objabi.
These experiments look potentially safe, but it seems too late in the
release cycle to try to assuage that. The one exception is frame
pointer experiment, which is trivially safe: it just amounts to
incrementing some stack offsets by PtrSize.
Fixes#22223.
Change-Id: I46dc7c54b1347143d02d6b9635038230cda6d164
Reviewed-on: https://go-review.googlesource.com/80760
Reviewed-by: Russ Cox <rsc@golang.org>
It's not safe (it crashes), and it's also useless: if you run
multiple benchmarks in parallel you will not get reliable
timing results from any of them.
Fixes#18603.
Change-Id: I00e5a72f7c98151543cf7d5573c38383276e391a
Reviewed-on: https://go-review.googlesource.com/80841
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Otherwise we may delay the delivery of these signals for an arbitrary
length of time. We are already careful to not block signals that the
program has asked to see.
Also make sure that we don't miss a signal delivery if a thread
decides to stop for a while while executing the signal handler.
Also clean up the TestAtomicStop output a little bit.
Fixes#21433
Change-Id: Ic0c1a4eaf7eba80d1abc1e9537570bf4687c2434
Reviewed-on: https://go-review.googlesource.com/79581
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Dim performance has regressed by 14% vs 1.9 on amd64.
Current pure go version of Dim is faster and,
what is even more important for performance, is inlinable, so
instead of tweaking asm implementation, just remove it.
I had to update BenchmarkDim, because it was simply reloading
constant(answer) in a loop.
Perf data below:
name old time/op new time/op delta
Dim-6 6.79ns ± 0% 1.60ns ± 1% -76.39% (p=0.000 n=7+10)
If I modify benchmark to be the same as in this CL results are even better:
name old time/op new time/op delta
Dim-6 10.2ns ± 0% 1.6ns ± 1% -84.27% (p=0.000 n=8+10)
Updates #21913
Change-Id: I00e23c8affc293531e1d9f0e0e49f3a525634f53
Reviewed-on: https://go-review.googlesource.com/80695
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In nat.divLarge (having signature (z nat).divLarge(u, uIn, v nat)),
we check whether z aliases uIn or v, but aliasing is currently not
checked for the u parameter.
Unfortunately, z and u aliasing each other can in some cases cause
errors in the computation.
The q return parameter (which will hold the result's quotient), is
unconditionally initialized as
q = z.make(m + 1)
When cap(z) ≥ m+1, z.make() will reuse z's backing array, causing q
and z to share the same backing array. If then z aliases u, setting q
during the quotient computation will then corrupt u, which at that
point already holds computation state.
To fix this, we add an alias(z, u) check at the beginning of the
function, taking care of aliasing the same way we already do for uIn
and v.
Fixes#22830
Change-Id: I3ab81120d5af6db7772a062bb1dfc011de91f7ad
Reviewed-on: https://go-review.googlesource.com/78995
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The trace command computes IO, Schedule, Block, and Syscall profiles
by following the unblocking links in the execution trace and summing
up the duration. This change offers variations of those profiles
that include only selected goroutine types. The id parameter takes the
goroutine type - i.e. pc of the goroutine.
The output is available from the /goroutine view. So, users can see
where the goroutines of interest typically block.
Also, these profiles are available for download so users can use
pprof or other tools to interpret the output. This change adds links
for download of global profile in the main page.
Change-Id: I35699252056d164e60de282b0406caf96d629c85
Reviewed-on: https://go-review.googlesource.com/75710
Reviewed-by: Sameer Ajmani <sameer@golang.org>
I've been doing these tweaks by hand. I was going to write a tool in
Go for it, but it's not much additional shell here.
Fixes#22912
Updates #9797 (already closed)
Change-Id: Ia15bd9b6876e6f6a76aa9ca86b10f113095e96a3
Reviewed-on: https://go-review.googlesource.com/80895
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GOMIPS is a GOARCH=mips{,le} specific option, for a choice between
hard-float and soft-float. Valid values are 'hardfloat' (default) and
'softfloat'. It is passed to the assembler as
'GOMIPS_{hardfloat,softfloat}'.
Note: GOMIPS will later also be used for a choice of MIPS instruction
set (mips32/mips32r2).
Updates #18162
Change-Id: I35417db8625695f09d6ccc3042431dd2eaa756a6
Reviewed-on: https://go-review.googlesource.com/37954
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Compiler and linker changes to support DWARF inlined instances,
see https://go.googlesource.com/proposal/+/HEAD/design/22080-dwarf-inlining.md
for design details.
This functionality is gated via the cmd/compile option -gendwarfinl=N,
where N={0,1,2}, where a value of 0 disables dwarf inline generation,
a value of 1 turns on dwarf generation without tracking of formal/local
vars from inlined routines, and a value of 2 enables inlines with
variable tracking.
Updates #22080
Change-Id: I69309b3b815d9fed04aebddc0b8d33d0dbbfad6e
Reviewed-on: https://go-review.googlesource.com/75550
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
ORANGE node's Right node is the expression it is ranging over,
which is evaluated before the loop. In the escape analysis,
we should walk this node without loop depth incremented.
Fixes#21709.
Change-Id: Idc1e4c76e39afb5a344d85f6b497930a488ce5cf
Reviewed-on: https://go-review.googlesource.com/80740
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This reverts commit a631daba5f.
Reason for revert: I was wrong. It still fails on the builders.
I don't know what's different about my VMWare VM, but on GCE it fails.
Change-Id: Ic6bee494b69235768bf08ba0bf59026bca41ad12
Reviewed-on: https://go-review.googlesource.com/80915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It must've been fixed since NetBSD 7.0. I can no longer reproduce it
with NetBSD 8-BETA (our new minimum NetBSD requirement).
Fixes#19293
Change-Id: I28f970ca41a53a037e1c6cddf1b7f286bda2d725
Reviewed-on: https://go-review.googlesource.com/80875
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The fix (CL 79575) for #18395 is too risky at this stage of the Go 1.10
release process.
Since issue #18395 is easily recognized (but not easily fixed), report
an error instead of silently continuing. This avoids inscrutable follow
on errors.
Also, make sure all empty interfaces are "completed", and adjust
printing code to report incomplete interfaces.
For #18395.
Change-Id: I7fa5f97ff31ac9775c9a6d318fce9f526b0350cd
Reviewed-on: https://go-review.googlesource.com/80455
Reviewed-by: Alan Donovan <adonovan@google.com>
In the x/arch repo, CL 45098 introduced SymLookup type, replacing
the unnamed function type for lookup functions. This affects the
signature of x86asm.GoSyntax. In particular, it cannot convert
one named type, namely lookupFunc, to the other without an
explicit cast. Make lookupFunc unnamed to fix.
Change-Id: I973300d29ef1dbfdbd7fc2429e89c5849e6a7329
Reviewed-on: https://go-review.googlesource.com/80842
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The note about the single change workflow is included in the
git-codereview installation instructions, but it has nothing to do with
installing git-codereview. This note is more relevant for when a change
is actually being made.
Change-Id: Iccb90f3b7da87fab863fa4808438cd69a21a2fce
Reviewed-on: https://go-review.googlesource.com/76317
Reviewed-by: Steve Francia <spf@golang.org>
Several usages of tar (reasonably) just use the Header.FileInfo
to determine the type of the header. However, the os.FileMode type
is not expressive enough to represent "files" that are not files
at all, but some form of metadata.
Thus, Header{Typeflag: TypeXGlobalHeader}.FileInfo().Mode().IsRegular()
reports true, even though the expected result may have been false.
To reduce (not eliminate) the possibility of failure for such usages,
use the placeholder filename from the global PAX headers.
Thus, in the event the user did not handle special "meta" headers
specifically, they will just be written to disk as a regular file.
As an example use case, the "git archive --format=tgz" command produces
an archive where the first "file" is a global PAX header with the
name "global_pax_header". For users that do not explicitly check
the Header.Typeflag field to ignore such headers, they may end up
extracting a file named "global_pax_header". While it is a bogus file,
it at least does not stop the extraction process.
Updates #22748
Change-Id: I28448b528dcfacb4e92311824c33c71b482f49c9
Reviewed-on: https://go-review.googlesource.com/78355
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL is a simple doc typo fix, uncovered while reviewing the go-wasm
port.
Change-Id: I0fce915c341aaaea3a7cc365819abbc5f2c468c3
Reviewed-on: https://go-review.googlesource.com/80715
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In order to avoid a regression where the date of the ModTime method
changed behavior, simply preserve the old behavior of determining
the date based on the legacy fields.
This ensures that anyone relying on ModTime before Go1.10 will have
the exact same behavior as before.
New users should use FileHeader.Modified instead.
We keep the UTC coersion logic in SetModTime since some users
manually compute timezone offsets in order to have precise control
over the MS-DOS time field.
Fixes#22738
Change-Id: Ib18b6ebd863bcf645748e083357dce9bc788cdba
Reviewed-on: https://go-review.googlesource.com/78031
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If there are no more requests being made, wait to shut down
the response-writing codec until the pending requests are all
answered.
Fixes#17239.
Change-Id: Ie62c63ada536171df4e70b73c95f98f778069972
Reviewed-on: https://go-review.googlesource.com/79515
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Due to err being shadowed in the else brach, the actual err return of
fd1.Chdir() is never checked. Fix it by not shadowing err anymore.
Change-Id: I9f1d52e88d8bc9a1c035960aa7af9f5224a63ab0
Reviewed-on: https://go-review.googlesource.com/80556
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There were too many changes of direction. Tidy up the intro a little
for better flow, and delete some unnecessary comments.
Change-Id: Ib5d85c0992626bd3152f86a51585884d3e0cab72
Reviewed-on: https://go-review.googlesource.com/80495
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Binary import sometimes constructs nodes using functions
that use the global lineno for the Position. This causes
spurious numbers to appear in the assembly and the
debugging output.
Fix (targeted, because late in the cycle): save and restore
lineno around bimport calls known to use lineno-sensitive
functions.
Updates #22600.
(Comment: "This is a weird line to step through")
Change-Id: I9c4094670380609fe4b6696443fb02579521c596
Reviewed-on: https://go-review.googlesource.com/80115
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change drops the support for FreeBSD 9 or below and simplifies
platform-dependent code for the sake of maintenance.
Updates #7187.
Fixes#11412.
Updates #16064.
Updates #18854.
Fixes#19072.
Change-Id: I9129130aafbfc7d0d7e9b674b6fc6cb31b7381be
Reviewed-on: https://go-review.googlesource.com/64910
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Panic if an http Handler does:
rw.WriteHeader(0)
... or other invalid values. (for a forgiving range of valid)
I previously made it kinda work in https://golang.org/cl/19130 but
there's no good way to fake it in HTTP/2, and we want HTTP/1 and
HTTP/2 behavior to be the same, regardless of what programs do.
Currently HTTP/2 omitted the :status header altogether, which was a
protocol violation. In fixing that, I found CL 19130 added a test
about bogus WriteHeader values with the comment:
// This might change at some point, but not yet in Go 1.6.
This now changes. Time to be strict.
Updates golang/go#228800
Change-Id: I20eb6c0e514a31f4bba305ac4c24266f39b95fd5
Reviewed-on: https://go-review.googlesource.com/80077
Reviewed-by: Tom Bergan <tombergan@google.com>
Previously, golang.org/cl/75350 updated ReadMIMEHeader to ignore the
first header line when it begins with a leading space, as in the
following example:
GET / HTTP/1.1
Host: foo.com
Accept-Encoding: gzip
However, golang.org/cl/75350 changed ReadMIMEHeader's behavior for the
following example: before the CL it returned an error, but after the
CL it ignored the first line.
GET / HTTP/1.1
Host foo.com
Accept-Encoding: gzip
This change updates ReadMIMEHeader to always fail when the first header
line starts with a space. During the discussion for golang.org/cl/75350,
we realized we had three competing needs:
1. HTTP clients should accept malformed response headers when possible
(ignoring the malformed lines).
2. HTTP servers should reject all malformed request headers.
3. The net/textproto package is used by multiple protocols (most notably,
HTTP and SMTP) which have slightly different parsing semantics. This
complicates changes to net/textproto.
We weren't sure how to best fix net/textproto without an API change, but
it is too late for API changes in Go 1.10. We decided to ignore initial
lines that begin with spaces, thinking that would have the least impact on
existing users -- malformed headers would continue to parse, but the
initial lines would be ignored. Instead, golang.org/cl/75350 actually
changed ReadMIMEHeader to succeed in cases where it previously failed
(as in the above example).
Reconsidering the above two examples, there does not seem to be a good
argument to silently ignore ` Host: foo.com` but fail on ` Host foo.com`.
Hence, this change fails for *all* headers where the initial line begins
with a space.
Updates #22464
Change-Id: I68d3d190489c350b0bc1549735bf6593fe11a94c
Reviewed-on: https://go-review.googlesource.com/80055
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The comment for phase 2 of checker.interfaceType (typexpr.go:517)
requires that embedded interfaces be complete for correctness of
the algorithm.
Yet, the very next comment (typexpr.go:530) states that underlying
embedded interfaces may in fact be incomplete.
This is in fact the case and the underlying bug in issue #18395.
This change makes sure that new interface types are marked complete
when finished (per the implicit definition in Interface.Complete,
type.go:302). It also adds a check, enabled in debug mode only, to
detect the use of incomplete embedded interfaces during construction
of a new interface. In debug mode, this check fails for the testcase
in the issue (and several others).
This change has no noticeable impact with debug mode disabled.
For #18395.
Change-Id: Ibb81e47257651282fb3755a80a36ab5d392e636d
Reviewed-on: https://go-review.googlesource.com/78955
Reviewed-by: Alan Donovan <adonovan@google.com>
Branch cuts for the elementary complex functions along real or imaginary axes
should be resolved in floating point calculations by one-sided continuity with
signed zero as described in:
"Branch Cuts for Complex Elementary Functions or Much Ado About Nothing's Sign Bit"
W. Kahan
Available at: https://people.freebsd.org/~das/kahan86branch.pdf
And as described in the C99 standard which is claimed as the original cephes source.
Sqrt did not return the correct branch when imag(x) == 0. The branch is now
determined by sign(imag(x)). This incorrect branch choice was affecting the behavior
of the Trigonometric/Hyperbolic functions that use Sqrt in intermediate calculations.
Asin, Asinh and Atan had spurious domain checks, whereas the functions should be valid
over the whole complex plane with appropriate branch cuts.
Fixes#6888
Change-Id: I9b1278af54f54bfb4208276ae345bbd3ddf3ec83
Reviewed-on: https://go-review.googlesource.com/46492
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It appears that TransmitFile Windows API does not work with Windows
pipes. So just copy data from pipe and into TCP connection manually.
Fixes#22278
Change-Id: I4810caca5345eac5bffb3176956689b8ae993256
Reviewed-on: https://go-review.googlesource.com/79775
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ASN.1 has an specific string type, called NumericString (tag 18). The
value of this type can be numeric characters (0-9) and space.
Fixes#22396
Change-Id: Ia6d81ab7faa311ff22759bf76862626974d3013e
Reviewed-on: https://go-review.googlesource.com/78655
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Only a last sentence of A Tour of Go is shifting to the left.
I fixed a HTML tag order according to other sentences it.
Change-Id: I6a301178d15db893f596b8da80a4d98721160386
Reviewed-on: https://go-review.googlesource.com/79856
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
exitsyscall should be recursively nosplit, but we don't have a way to
annotate that right now (see #21314). There's exactly one remaining
place where this is violated right now: exitsyscall -> casgstatus ->
print. The other prints in casgstatus are wrapped in systemstack
calls. This fixes the remaining print.
Updates #21431 (in theory could fix it, but that would just indicate
that we have a different G status-related crash and we've *never* seen
that failure on the dashboard.)
Change-Id: I9a5e8d942adce4a5c78cfc6b306ea5bda90dbd33
Reviewed-on: https://go-review.googlesource.com/79815
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use singular form of panic and remove the unnecessary
'however', when comparing Goexit's behavior to 'a panic'
as well as what happens for deferred recovers with Goexit.
Change-Id: I3116df3336fa135198f6a39cf93dbb88a0e2f46e
Reviewed-on: https://go-review.googlesource.com/79755
Reviewed-by: Rob Pike <r@golang.org>
Following comments on CL 76320.
Breaks Cmd.Std{out,err} doc into three paragraphs and updates Cmd.Stdin
formatting to match.
Fixes an erroneous reference to Stdin in the output goroutine comment, while
keeping the wording consistent between Stdin and Stdout/Stderr.
Change-Id: I186a0e2d4b85dfb939443a17e62a1eb2ef64b1bf
Reviewed-on: https://go-review.googlesource.com/79595
Reviewed-by: Rob Pike <r@golang.org>
dragonfly/386 isn't a valid GOOS/GOARCH pair and there are no generated
files for this pair in syscall.
Change-Id: Ibea2103c2f5e139139d850df3aac9b5a9c4ac9ab
Reviewed-on: https://go-review.googlesource.com/79675
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 79555 added TestLookupLongTXT. However, this test is
failing on Plan 9, because the DNS resolver (ndb/dns)
only returns a single TXT record.
Updates #22857.
Change-Id: I33cdc63a3d3de4d1c7f2684934316c44992fb9e2
Reviewed-on: https://go-review.googlesource.com/79695
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The response to a TXT lookup is a sequence of RRs,
each of which contains a sequence of string fragments.
The correct handling of the response is to do:
for each rr {
list = append(list, strings.Join(rr.fragments, ""))
}
(like in at dnsRR_TXT.Walk, used on most platforms).
The Windows code incorrectly does:
for each rr {
list = append(list, rr.fragments...)
}
This CL fixes it to concatenate fragments, as it must.
Fixes#21472.
Change-Id: I78cce96f172e5e90da9a212b0343457f6d5f92e8
Reviewed-on: https://go-review.googlesource.com/79555
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add test that verifies that go command produces executable
that have security attributes of the target directory.
Update #22343
Change-Id: Ieab02381927a2b09bee21c49c043b3298bd088e6
Reviewed-on: https://go-review.googlesource.com/78215
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This doesn't appear to have caused problems (because we don't depend
on the sort order, it seems) but it's clearly incorrect.
Change-Id: Ib6eb0128a3c17997c7907a618f9ce102b32aaa98
Reviewed-on: https://go-review.googlesource.com/79497
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
newstack manually prints the stack trace if we try to grow the stack
when throwsplit is set. However, the default behavior is to omit
runtime frames. Since runtime frames can be critical to understanding
this crash, this change fixes this traceback to include them.
Updates #21431.
Change-Id: I5aa43f43aa2f10a8de7d67bcec743427be3a3b5d
Reviewed-on: https://go-review.googlesource.com/79518
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If exitsyscall tries to grow the stack it will panic, but throw calls
print, which can grow the stack. Move the two bare throws in
exitsyscall to the system stack.
Updates #21431.
Change-Id: I5b29da5d34ade908af648a12075ed327a864476c
Reviewed-on: https://go-review.googlesource.com/79517
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In golang.org/cl/74352, the print rules were overhauled to give better
error messages. This also meant adding a regex to find and extract the
used formatting verbs.
However, %v was missed. Add it to the expression, and add a test too.
Fixes#22847.
Change-Id: If117cc364db0cb91373742239b8a626c137642b0
Reviewed-on: https://go-review.googlesource.com/79455
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If a Mac user has more than 256 groups, getGroupList returns -1 but
does not correctly set n. We need to retry the syscall with an
ever-increasing group size until we get all of the user's groups.
The easiest way to test this change is to set n to a value lower than
the current user's number of groups, test on a Mac and observe
a failure, then apply the patch and test that it passes.
Fixes#21067.
Change-Id: I0f5c4eac1c465226a460bc0803eff791dcfd4200
Reviewed-on: https://go-review.googlesource.com/51892
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, SetGCPercent(-1) disables GC, but doesn't wait for any
currently running concurrent GC to finish, so GC can still be running
when it returns. This is a change in behavior from Go 1.8, probably
defies user expectations, and can break various runtime tests that
depend on SetGCPercent(-1) to disable garbage collection in order to
prevent preemption deadlocks.
Fix this by making SetGCPercent(-1) block until any concurrently
running GC cycle finishes.
Fixes#22443.
Change-Id: I904133a34acf97a7942ef4531ace0647b13930ef
Reviewed-on: https://go-review.googlesource.com/79195
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The signature of the mapassign_fast* routines need to distinguish
the pointerness of their key argument. If the affected routines
suspend part way through, the object pointed to by the key might
get garbage collected because the key is typed as a uint{32,64}.
This is not a problem for mapaccess or mapdelete because the key
in those situations do not live beyond the call involved. If the
object referenced by the key is garbage collected prematurely, the
code still works fine. Even if that object is subsequently reallocated,
it can't be written to the map in time to affect the lookup/delete.
Fixes#22781
Change-Id: I0bbbc5e9883d5ce702faf4e655348be1191ee439
Reviewed-on: https://go-review.googlesource.com/79018
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Per the comments at the head of fs_nacl.go, unexported methods expect
the fs mutex to have been taken by the caller.
This change brings Link and Rename into line with the other exported
functions wrt fs locking.
Fixes#22690
Change-Id: I46d08f7d227f23ff49bb0099d218214364a45e1a
Reviewed-on: https://go-review.googlesource.com/79295
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 76551 modified inline_callers.go to build everything, including the
runtime, with -l=4. While that works in most places (and ideally
should work everywhere), it blows out the nosplit stack on
solaris/amd64.
Fix this by only building the test itself with -l=4.
This undoes some of the changes to this test from CL 73212, which
originally changed the go tool to rebuild all packages with the given
flags. This change modified the expected output of this test, so now
that we can go back to building only the test itself with inlining, we
revert these changes to the expected output. (That CL also changed
log.Fatalf to log.Printf, but didn't add "\n" to the end of the lines,
so this CL fixes that, too.)
Fixes#22797.
Change-Id: I6a91963a59ebe98edbe0921d8717af6b2c2191b0
Reviewed-on: https://go-review.googlesource.com/79197
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 78538 was updated after running TryBots to depend on
syscall.NanoSleep which isn't available on all non-Linux platforms.
Change-Id: I1fa615232b3920453431861310c108b208628441
Reviewed-on: https://go-review.googlesource.com/79175
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Tzinfo was replaced with TZData during the review of CL 68890, but this
instance was forgotten. Update it for consistency.
Follows CL 68890.
Updates #20629.
Change-Id: Id6d3c4f5f7572b01065f2db556db605452d1b570
Reviewed-on: https://go-review.googlesource.com/79176
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes VBLENDVP{D/S}, VPBLENDVB encoding for /is4 imm8[7:4]
encoded register operand.
Explanation:
`reg[r]+regrex[r]+1` will yield correct values for 8..15 reg indexes,
but for 0..7 it gives `index+1` results.
There was no test that used lower 8 register with /is4 encoding,
so the bug passed the tests.
The proper solution is to get 4th bit from regrex with a proper shift:
`reg[r]|(regrex[r]<<1)`.
Instead of inlining `reg[r]|(regrex[r]<<1)` expr,
using new `regIndex(r)` function.
Test that reproduces this issue is added to
amd64enc_extra.s test suite.
Bug came from https://golang.org/cl/70650.
Change-Id: I846a25e88d5e6df88df9d9c3f5fe94ec55416a33
Reviewed-on: https://go-review.googlesource.com/78815
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
The section about custom pprof paths referenced the wrong path.
This also fixes a couple minor grammatical issues elsewhere in the doc.
Fixes#22832
Change-Id: I890cceb53a13c1958d9cf958c658ccfcbb6863d5
Reviewed-on: https://go-review.googlesource.com/79035
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
The return values of the LoadLocation are inherently dependent
on the runtime environment. Add LoadLocationFromTZData, whose
results depend only on the timezone data provided as arguments.
Fixes#20629
Change-Id: I43b181f4c05c219be3ec57327540263b7cb3b2aa
Reviewed-on: https://go-review.googlesource.com/68890
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Relax the 'phi after non-phi' SSA sanity check to allow
RegKill ops interspersed with phi ops in a block. This fixes
a sanity check failure when -dwarflocationlists is enabled.
Updates #22694.
Change-Id: Iaae604ab6f1a8b150664dd120003727a6fb2f698
Reviewed-on: https://go-review.googlesource.com/77610
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This changes the assembly language output to use the
innermost (instead of outermost) position for line
number and file.
The file is printed separately, only when it changes,
to remove redundant and space-consuming noise from the
output.
Unknown positions have line number "?"
The output format was changed slightly to make it
easier to read.
One source of gratuitous variation in debugging output was
removed.
Change-Id: I1fd9c8b0ddd82766488582fb684dce4b04f35723
Reviewed-on: https://go-review.googlesource.com/78895
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Go's DWARF usually has absolute paths, in which case DW_AT_comp_dir
doesn't matter. But the -trimpath flag produces relative paths, and
then the spec says that they are relative to _comp_dir.
There's no way to know what the "right" value of _comp_dir is without
more user input, but we can at least leave the paths alone rather than
making them absolute.
After this change, Delve can find sources to a program built with
-gcflags=-trimpath=$(pwd) as long as it's run in the right directory.
Change-Id: I8bc7bed098e352d2c06800bfbbe14e8392e1bbed
Reviewed-on: https://go-review.googlesource.com/78415
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The arguments <pstatefield> is a struct that includes two elements,
element reg is special register, elememt enc is pstate field values.
The current code compares two different type values and get a incorrect
result.
The fix follows pstate field to create a systemreg struct,
each system register has a vaule to use in instruction.
Uncomment the msr/mrs cases.
Fixes#21464
Change-Id: I1bb1587ec8548f3e4bd8d5be4d7127bd10d53186
Reviewed-on: https://go-review.googlesource.com/56030
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Improve the error message for wrong
case-field names in composite literals,
by mentioning the correct field name.
Given the program:
package main
type it struct {
ID string
}
func main() {
i1 := &it{id: "Bar"}
}
just like we do for usage of fields, we now
report wrongly cased fields as hints to give:
ts.go:8:14: unknown field 'id' in struct literal of type it (but does have ID)
instead of before:
ts.go:8:14: unknown field 'id' in struct literal of type it
Fixes#22794
Change-Id: I18cd70e75817025cb1df083503cae306e8d659fd
Reviewed-on: https://go-review.googlesource.com/78545
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When instruction has only one argument, Go parser saves the
argument value into prog.From without any special handling.
But assembler gets the argument value from prog.To.
The fix adds special handling for CLREX and puts other instructions
arguments value into prog.From.
Uncomment hlt/hvc/smc/brk/dcps1/dcps2/dcps3/clrex test cases.
Fixes#20765
Change-Id: I1fc0d2faafb19b537cab5a665bd4af56c3a2c925
Reviewed-on: https://go-review.googlesource.com/78275
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
That can occur if we have -u set and there is an upper- and lower-case
name of the same spelling in a single declaration.
A rare corner case but easy to fix.
Fix by remembering what we've printed.
Fixes#21797.
Change-Id: Ie0b681ae8c277fa16e9635ba594c1dff272b8aeb
Reviewed-on: https://go-review.googlesource.com/78715
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In golang.org/cl/59413, the two-argument behavior of cmd/doc was changed
to use findPackage instead of build.Import, meaning that the tool was
more consistent and useful.
However, it introduced a regression:
$ go doc bytes Foo
doc: no such package: bytes
This is because the directory list search would not find Foo in bytes,
and reach the end of the directory list - thus resulting in a "no such
package" error, since no directory matched our first argument.
Move the "no such package" error out of parseArgs, so that the "loop
until something is printed" loop can have control over it. In
particular, it is useful to know when we have reached the end of the
list without any exact match, yet we did find one package matching
"bytes":
$ go doc bytes Foo
doc: no symbol Foo in package bytes
While at it, make the "no such package" error not be fatal so that we
may test for it. It is important to have the test, as parseArgs may now
return a nil package instead of exiting the entire program, potentially
meaning a nil pointer dereference panic.
Fixes#22810.
Change-Id: I90cc6fd755e2d1675bea6d49a1c13cc18ac9bfb9
Reviewed-on: https://go-review.googlesource.com/78677
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
As per the comments in golang.org/cl/78617. Also leaving a comment here,
to make sure noone else thinks to re-introduce the iota like I did.
Change-Id: I2a2275998b81896eaa0e9d5ee0197661ebe84acf
Reviewed-on: https://go-review.googlesource.com/78676
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a regression introduced in golang.org/cl/28817. That change got
rid of the iota, which meant that the type was no longer applied to all
the constant names.
Re-add the iota starting at -1, simplifying the code and adding the
types once more.
Change-Id: I38bd0e04f8d298196bccd33651e29f5011401a8d
Reviewed-on: https://go-review.googlesource.com/78617
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Copying ensures that we respect the NTFS permissions of the parent folder.
I don't know if there is a way to tell when it is safe to simply rename.
Fixes#22343
Change-Id: I424bfe655b53b0e0fe425ce92bbc15450d52d851
Reviewed-on: https://go-review.googlesource.com/72910
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Check for the expected number of arguments in a SQL statement
after arguments are eliminated in the argument converter.
This situation was already tested for in TestNamedValueChecker.
However the test used Exec which didn't have any check for
NumInput on it at all, thus this issue was never caught.
In addition to moving the NumInput check on the Query
methods after the converter, add the NumInput check
to the Exec methods as well.
Fixes#22630
Change-Id: If45920c6e1cf70dca63822a0cedec2cdc5cc611c
Reviewed-on: https://go-review.googlesource.com/76732
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In a previous change to cmd/dist/test.go to fix some pie
testcases, a few other tests were incorrectly dropped.
This returns the testcases that shouldn't have been removed.
Fixes#22708
Change-Id: I2f735f4fd3a378f0f45d12a99768638aeb4787c7
Reviewed-on: https://go-review.googlesource.com/77650
Run-TryBot: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some C types are declared as pointers, but C code
stores non-pointers in them. When the Go garbage
collector sees such a pointer, it gets unhappy.
Instead, for these types represent them on the Go
side with uintptr.
We need this change to handle Apple's CoreFoundation
CF*Ref types. Users of these types might need to
update their code like we do in root_cgo_darwin.go.
The only change that is required under normal
circumstances is converting some nils to 0.
A go fix module is provided to help.
Fixes#21897
RELNOTE=yes
Change-Id: I9716cfb255dc918792625f42952aa171cd31ec1b
Reviewed-on: https://go-review.googlesource.com/66332
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I noticed some files prefixed with ssa_fg_tmp in the /tmp folder of
the s390x builder. runGenTest (a helper for TestGenFlowGraph) wasn't
deleting its temporary files. The distinct prefix made this easy to
figure out.
Change-Id: If0d608aaad04a414e74e29f027ec9443c626e4eb
Reviewed-on: https://go-review.googlesource.com/78475
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Enables AVX2 gather instructions and VSIB support,
which makes vm32{x,y} vm64{x,y} operands encodable.
AXXX constants placed with respect to sorting order.
New VEX optabs inserted near non-VEX entries to simplify
potential transition to auto-generated VSIB optabs.
Tests go into new AMD64 encoder test file (amd64enc_extra.s)
to avoid unnecessary interactions with auto-generated "amd64enc.s".
Side note: x86avxgen did not produced these instructions
because x86.v0.2.csv misses them.
This also explains why x86 test suite have no AVX2 gather
instructions tests.
List of new instructions:
VGATHERPDP
VGATHERDPS
VGATHERQPD
VGATHERQPS
VPGATHERDD
VPGATHERDQ
VPGATHERQD
VPGATHERQQ
Change-Id: Iac852f3c5016523670bd99de6bec6a48f66fb4f6
Reviewed-on: https://go-review.googlesource.com/77970
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
The RFC is a little ambiguous here: “the subject field contains an empty
sequence” could mean that it's a non-empty sequence where one of the
sets contains an empty sequence. But, in context, I think it means “the
subject field is an empty sequence”.
Fixes#22249
Change-Id: Idfe1592411573f6e871b5fb997e7d545597a0937
Reviewed-on: https://go-review.googlesource.com/70852
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 71030 enforced EKU nesting at verification time, to go along with the
change in name constraints behaviour. From scanning the Certificate
Transparency logs, it's clear that some CAs are not getting EKU nesting
correct.
This change relaxes the EKU rules in a few ways:
∙ EKUs in roots are no longer checked.
∙ Any CA certificate may issue OCSP responder certificates.
∙ The ServerAuth and SGC EKUs are treated as a single EKU when
checking nesting.
∙ ServerAuth in a CA can now authorise ClientAuth.
∙ The generic CodeSigning EKU can now authorise two, Microsoft-specific
code-signing EKUs.
Change-Id: I7b7ac787709af0dcd177fe419ec2e485b8d85540
Reviewed-on: https://go-review.googlesource.com/77330
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The GeneralSubtree structure can have additional elements after the name
(minimum and maximum, which are unused). Previously these fields, if
present, would cause a parse error. This change allows trailing data in
the GeneralSubtrees structure.
Change-Id: I6bfb11ec355fa6812810a090c092a5ee0fdeddc3
Reviewed-on: https://go-review.googlesource.com/77333
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The locations chosen for racewalking inserted code can
be wrong and thus cause unwanted next/step behavior in
debuggers. Forcing the positions to be unset results in
better behavior.
Test added, and test harness corrected to deal with
changes to gdb's output caused by -racewalk.
Incidental changes in Delve (not part of the usual testing,
but provided because we care about Delve) also reflected
in this CL.
Fixes#22600.
Change-Id: Idd0218afed52ab8c68efd9eabbdff3c92ea2b996
Reviewed-on: https://go-review.googlesource.com/78336
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Adding s390x to the list of architectures that support c-shared and c-archive.
Required adding load-time initialization (via _rt0_s390x_linux_lib) and adding s390x
to the c-shared and c-archive tests.
Change-Id: I75883b2891c310fe8ce7f08c27b06895c074e123
Reviewed-on: https://go-review.googlesource.com/74910
Reviewed-by: Michael Munday <mike.munday@ibm.com>
I experimented with changing the write barrier to take the value in SI
rather than AX to improve register allocation. It had no effect on
performance and only made the "hello world" text 0.07% smaller, so
let's just remove the comment.
Change-Id: I6a261d14139b7a02a8467b31e74951dfb927ffb4
Reviewed-on: https://go-review.googlesource.com/78033
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
While driver.Connector was previously added to allow non-string
connection arguments and access to the context, most users of
the sql package will continue to rely on a string DSN.
Allow drivers to implement a string DSN to Connector interface
that both allows a single parsing of the string DSN and uses
the Connector interface which passes available context to
the driver dialer.
Fixes#22713
Change-Id: Ia0b862262f4c4670effe2538d0d6d43733fea18d
Reviewed-on: https://go-review.googlesource.com/77550
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
I realized this simplification was possible when writing the vet loop
(just above the code being modified here) but never circled back
to make the compiler loop match.
Change-Id: Ic2277d2a4b6d94ea4897cc3615fc1a29f2fb243c
Reviewed-on: https://go-review.googlesource.com/78395
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
CL 61111 disabled the writing of trivial.c in -n mode, which
made -n mode at least inconsistent with regular mode in
how it was testing for flags. We think that both were getting
the same answer, so avoid creating the file in both modes
to make sure.
If this CL turns out to be wrong, then when we revert it we
should make sure that the empty file is written even in -n mode,
because this check affects the command-line flags printed
by other commands in that mode.
Change-Id: I0a050bfc148fe5a9d430a153d7816b2821277f0d
Reviewed-on: https://go-review.googlesource.com/78115
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(The tests only run when swig is already installed on the local system.)
Change-Id: I172d106a68cfc746a1058f5a4bcf6761bab88912
Reviewed-on: https://go-review.googlesource.com/78175
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL removes the following APIs:
type SparseEntry struct{ ... }
type Header struct{ SparseHoles []SparseEntry; ... }
func (*Header) DetectSparseHoles(f *os.File) error
func (*Header) PunchSparseHoles(f *os.File) error
func (*Reader) WriteTo(io.Writer) (int, error)
func (*Writer) ReadFrom(io.Reader) (int, error)
This API was added during the Go1.10 dev cycle, and are safe to remove.
The rationale for reverting is because Header.DetectSparseHoles and
Header.PunchSparseHoles are functionality that probably better belongs in
the os package itself.
The other API like Header.SparseHoles, Reader.WriteTo, and Writer.ReadFrom
perform no OS specific logic and only perform the actual business logic of
reading and writing sparse archives. Since we do know know what the API added to
package os may look like, we preemptively revert these non-OS specific changes
as well by simply commenting them out.
Updates #13548
Updates #22735
Change-Id: I77842acd39a43de63e5c754bfa1c26cc24687b70
Reviewed-on: https://go-review.googlesource.com/78030
Reviewed-by: Russ Cox <rsc@golang.org>
Maybe a bad git merge - not sure.
In any event, I do miss the trybots.
Noticed while fixing: change print-to-stderr+panic
to pure panic, just so that the test (which catches the panic)
does not print any errors before passing.
Change-Id: If25153ea64e81066455401110ae7a79c36f2f712
Reviewed-on: https://go-review.googlesource.com/78316
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Ian suggested that since test caching is not expected to be perfect
in all cases, we should allow users to clear the test cache separately
from clearing the entire build cache.
This CL adds 'go clean -testcache' to do that. The implementation
does not actually delete files (for that, use 'go clean -cache').
Instead, it writes down the current time, and future go tests will
ignore any cached test results written before that time.
Change-Id: I4f84065d7dfc2499fa3f203e9ab62e68d7f367c5
Reviewed-on: https://go-review.googlesource.com/78176
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we're running coverage on a package using cgo, we need to
apply both cmd/cover and cmd/cgo as source transformers.
To date we've applied cgo, then cover.
Cover is very sensitive to the exact character position of
expressions in its input, though, and cgo is not, so swap
them, applying first cover and then cgo.
The only drawback here is that coverage formerly applied
to SWIG-generated cgo files, and now it does not.
I am not convinced anyone depended critically on that,
and probably the later analysis with go tool cover would
have tried to parse the original .swig file as a Go file and
gotten very confused.
Fixes#8726.
Fixes#9212.
Fixes#9479.
Change-Id: I777c8b64f7726cb117d59e03073954abc6dfa34d
Reviewed-on: https://go-review.googlesource.com/77155
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Passing the absolute path to cgo puts the absolute path in the
generated file's //line directives, which then shows that path
in the compiler output, which the go command can then
make relative to the current directory, same as it does for
other compiler output.
Change-Id: Ia2064fea40078c46fd97e3a3b8c9fa1488f913e3
Reviewed-on: https://go-review.googlesource.com/77154
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cgo has always operated by rewriting the AST and invoking go/printer.
This CL converts it to use the AST to make decisions but then apply
its edits directly to the underlying source text. This approach worked
better in rsc.io/grind (used during the C to Go conversion) and also
more recently in cmd/cover. It guarantees that all comments and
line numbers are preserved exactly.
This eliminates a lot of special concern about comments and
problems with cgo not preserving meaningful comments.
Combined with the CL changing cmd/cover to use the same
approach, it means that the combination of applying cgo and
applying cover still guarantees all comments and line numbers
are preserved exactly.
This sets us up to fix some cgo vs cover bugs by swapping
the order in which they run during the go command.
This also sets up #16623 a bit: the edit list being
accumulated here is nearly exactly what you'd want
to pass to the compiler for that issue.
Change-Id: I7611815be22e7c5c0d4fc3fa11832c42b32c4eb3
Reviewed-on: https://go-review.googlesource.com/77153
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 52810 changed Reader to interpret a quoted \r\n as a raw \r\n
when reading fields. This seems likely to break existing users, and
discussion on both #21201 (the original issue that triggered the change)
and #22746 (discussing whether to revert the change) failed to identify
a single motivating example for this change. To avoid breaking existing
users for no clear reason, revert the change.
The Reader has been rewritten in the interim so this is not a git revert
but instead and adjustment (and slight simplification) of the new Reader.
Fixes#22746.
Change-Id: Ie857b2f4b1359a207d085b6d3c3a6d440a997d12
Reviewed-on: https://go-review.googlesource.com/78295
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
CL 56950 correctly identified code with checks that were impossible.
But instead of correcting the checks it deleted them.
This CL corrects the code to check what was meant.
Change-Id: Ic89222184ee4fa5cacccae12d750601a9438ac8d
Reviewed-on: https://go-review.googlesource.com/78113
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 55972.
Reason for revert: this changes Perm's behavior unnecessarily.
I asked for this change originally but I now regret it.
Reverting so that I don't have to justify it in Go 1.10 release notes.
Edited to keep the change to rand_test.go, which seems to have
been mostly unrelated.
Fixes#22744.
Change-Id: If8bb1bcde3ced0db2fdcd0aa65ab128613686c66
Reviewed-on: https://go-review.googlesource.com/78195
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit 630d176e7d.
Reason for revert: the CL moves a parser for what appears to be an
Android-specific file format into the main code and makes it available
on all platforms. Android-specific file formats should be limited to
Android.
Change-Id: I3f19fe03673d65ed1446a0dcf95e5986053e10c0
Reviewed-on: https://go-review.googlesource.com/77950
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix typo in DWARF register config for GOOARCH=x86; was
picking up the AMD64 set, should have been selecting
x86 set.
Change-Id: I9a4c6f1378baf3cb2f0ad8d60f3ee2f24cd5dc91
Reviewed-on: https://go-review.googlesource.com/77990
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
CL 60630 claimed to and did “improve performance of CopyN”
but in doing so introduced a second copy of the I/O copying loop.
This code is subtle and easy to get wrong and the last thing we
need is of two copies that can drift out of sync. Even the newly
introduced copy contains various subtle changes that are not
obviously semantically equivalent to the original. (They probably
are, but it's not obvious.)
Although the CL description does not explain further what the
important optimization was, it appears that the most critical
one was not allocating a 32kB buffer for CopyN(w, r, 512).
This CL deletes the forked copy of copy and instead applies
the buffer size restriction optimization directly to copy itself.
CL 60630 reported:
name old time/op new time/op delta
CopyNSmall-4 5.09µs ± 1% 2.25µs ±86% -55.91% (p=0.000 n=11+14)
CopyNLarge-4 114µs ±73% 121µs ±72% ~ (p=0.701 n=14+14)
Starting with that CL as the baseline, this CL does not change a ton:
name old time/op new time/op delta
CopyNSmall-8 370ns ± 1% 411ns ± 1% +11.18% (p=0.000 n=16+14)
CopyNLarge-8 18.2µs ± 1% 18.3µs ± 1% +0.63% (p=0.000 n=19+20)
It does give up a small amount of the win of 60630 but preserves
the bulk of it, with the benefit that we will not need to debug these
two copies drifting out of sync in the future.
Change-Id: I05b1a5a7115390c5867847cba606b75d513eb2e2
Reviewed-on: https://go-review.googlesource.com/78122
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
cover -func mode was reporting a coverage for function
declarations without bodies - assembly functions.
Since we are not annotating their code, we have no data
for those functions and should not report them at all.
Fixes#6880.
Change-Id: I4b8cd90805accf61f54e3ee167f54f4dc10c7c59
Reviewed-on: https://go-review.googlesource.com/77152
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that cover does not modify the formatting of the original file
or add any newline characters, we can make it print a //line comment
pointing back at the original, and compiler errors and panics will
report accurate line numbers.
Fixes#6329.
Fixes#15757.
Change-Id: I7b0e386112c69beafe69e0d47c5f9e9abc87c0f5
Reviewed-on: https://go-review.googlesource.com/77151
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Even after disabling on 1-CPU systems, builders are still flaking too often.
Unless there are at least 4 CPUs, don't require test interlacing at all.
Fixes#22665 (again).
Change-Id: Ief792c496c1ee70939532e6ca8bef012fe78178e
Reviewed-on: https://go-review.googlesource.com/77310
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL 21663 allowed drivers to implement ExecerContext without
also implementing Execer, and similarly QueryerContext without
Queryer, but it did not make that clear in the documentation.
This CL updates the documentation.
Change-Id: I9a4accaac32edfe255fe7c0b0907d4c1014322b4
Reviewed-on: https://go-review.googlesource.com/78129
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
CL 70210 added Decoder for #21590, and in doing so it changed
the existing func Decode to return partial results for decoding errors.
That seems like a good change to make to Decode, but it was
untested (except as used by Decoder), inconsistent with DecodeString
in all error cases, and inconsistent with Decoder in not returning
partial results for odd-length input strings.
This CL makes Decode, DecodeString, and Decoder all agree about
the handling of partial results (they are returned) and error
precedence (the error earliest in the input is reported),
and it documents and tests this.
Change-Id: Ifb7d1e100ecb66fe2ed5ba34a621084d480f16db
Reviewed-on: https://go-review.googlesource.com/78120
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Using ASCII values for keys is a bad idea since it makes them vastly
easier to guess. Instead, use the same method as the examples in the
golang.org/x/crypto/nacl package to load keys from a hex value.
Changing the key required updating the ciphertext in many of the
examples.
I am still worried about the fact the examples ask the user to
authenticate messages; authentication isn't trivial, and to be honest
it may be better to steer people to a higher level primitive like
secretbox, unless people really need AES.
Fixes#21012.
Change-Id: I8d918cf194694cd380b06c2d561178167ca61adb
Reviewed-on: https://go-review.googlesource.com/48596
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A sequential lookup using any non-canceled context has a risk of
returning the result of the previous lookup for a canceled context (i.e.
an error).
This is already prevented for timed out context by forgetting the host
immediately and extending this to also compare the error to
`context.Canceled` resolves this issue.
Fixes#22724
Change-Id: I7aafa1459a0de4dc5c4332988fbea23cbf4dba07
Reviewed-on: https://go-review.googlesource.com/77670
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The replacement rune is a valid rune and can appear as itself in valid UTF8
(it encodes as three bytes). To check for invalid UTF8 it is necessary to
look for utf8.DecodeRune returning the replacement rune and size==1.
Change-Id: I169be8d1fe61605c921ac13cc2fde94f80f3463c
Reviewed-on: https://go-review.googlesource.com/78126
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
ctx.Done() == ctx.Background().Done() is just
a long way to write ctx.Done() == nil.
Use the short way.
Change-Id: I7b3198b5dc46b8b40086243aa61882bc8c268eac
Reviewed-on: https://go-review.googlesource.com/78128
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Originally we tried the strict -er suffix as the rule in this case
but eventually we decided it was too awkward: io.WriteByter
became io.ByteWriter. By analogy, here the interface should be
named SessionResetter instead of the awkward ResetSessioner.
This change should not affect any drivers that have already
implemented the interface, because the method name is not changing.
(This was added during the Go 1.10 cycle and has not been
released yet, so we can change it.)
Change-Id: Ie50e4e090d3811f85965da9da37d966e9f45e79d
Reviewed-on: https://go-review.googlesource.com/78127
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
CL 58210 introduced this constant for reasons I don't understand.
It should not be in the exported const block, which will pollute
godoc output with a "... unexported" notice.
Also since we already have a constant named xmlnsPrefix for "xmlns",
it is very confusing to also have xmlNamespacePrefix for "xml".
If we must have the constant at all, rename it to xmlPrefix.
Change-Id: I15f937454d730005816fcd32b1acca703acf1e51
Reviewed-on: https://go-review.googlesource.com/78121
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A record can span multiple lines (the whole reason for the extra field),
so the important fact is that it's the _start_ of the record.
Make that clear in the name.
(This API was added during the Go 1.10 cycle so it can still be cleaned up.)
Change-Id: Id95b3ceb7cdfc4aa0ed5a053cb84da8945fa5496
Reviewed-on: https://go-review.googlesource.com/78119
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Mainly get rid of the weird zero-value struct literal,
but while we're here also group and order things a bit better:
first the reader, then the data, then the call (which takes reader then data).
Change-Id: I901b0661d85d8eaa0807e4482aac66500ca996c7
Reviewed-on: https://go-review.googlesource.com/78118
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
CL 65851 (bytes) and CL 65910 (strings) “improve[d] readability”
by removing the special case that bypassed the whole function body
when chars == "". In doing so, yes, the function was unindented a
level, which is nice, but the runtime of that case went from O(1) to O(n)
where n = len(s).
I don't know if anyone's code depends on the O(1) behavior in this case,
but quite possibly someone's does.
This CL adds the special case back, with a comment to prevent future
deletions, and without reindenting each function body in full.
Change-Id: I5aba33922b304dd1b8657e6d51d6c937a7f95c81
Reviewed-on: https://go-review.googlesource.com/78112
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change error message prefix from "tar:" to "archive/tar:" to maintain
backwards compatibility with Go1.9 and earlier in the unfortunate event
that someone is relying on string parsing of errors.
Fixes#22740
Change-Id: I59039c59818a0599e9d3b06bb5a531aa22a389b8
Reviewed-on: https://go-review.googlesource.com/77933
Reviewed-by: roger peppe <rogpeppe@gmail.com>
If a composite literal contains any comments on their own lines without
any elements, the printer would unindent the comments.
The comments in this edge case are written when the closing '}' is
written. Indent and outdent first so that the indentation is
interspersed before the comment is written.
Also note that the go/printer golden tests don't show the exact same
behaviour that gofmt does. Added a TODO to figure this out in a separate
CL.
While at it, ensure that the tree conforms to gofmt. The changes are
unrelated to this indentation fix, however.
Fixes#22355.
Change-Id: I5ac25ac6de95a236f1e123479127cc4dd71e93fe
Reviewed-on: https://go-review.googlesource.com/74232
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
The CPU time reported in the gctrace for STW phases is simply
work.stwprocs times the wall-clock duration of these phases. However,
work.stwprocs is set to gcprocs(), which is wrong for multiple
reasons:
1. gcprocs is intended to limit the number of Ms used for mark
termination based on how well the garbage collector actually
scales, but the gctrace wants to report how much CPU time is being
stolen from the application. During STW, that's *all* of the CPU,
regardless of how many the garbage collector can actually use.
2. gcprocs assumes it's being called during STW, so it limits its
result to sched.nmidle+1. However, we're not calling it during STW,
so sched.nmidle is typically quite small, even if GOMAXPROCS is
quite large.
Fix this by setting work.stwprocs to min(ncpu, GOMAXPROCS). This also
fixes the overall GC CPU fraction, which is based on the computed CPU
times.
Fixes#22725.
Change-Id: I64b5ce87e28dbec6870aa068ce7aecdd28c058d1
Reviewed-on: https://go-review.googlesource.com/77710
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Permit the C preamble to use the _GoString_ type. Permit Go code to
pass string values directly to those C types. Add accessors for C
code to retrieve sizes and pointers.
Fixes#6907
Change-Id: I190c88319ec88a3ef0ddb99f342a843ba69fcaa3
Reviewed-on: https://go-review.googlesource.com/70890
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Unless you go back and read the hash package documentation, it's
not clear that all the hash packages implement marshaling and
unmarshaling. Document the behaviour specifically in each package
that implements it as it this is hidden behaviour and easy to miss.
Change-Id: Id9d3508909362f1a3e53872d0319298359e50a94
Reviewed-on: https://go-review.googlesource.com/77251
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
I verified this change on a corpus of > 200 GB of emails since the mid-90s. With
this change, more addresses parse than before, and anything which parsed before
still parses.
In said corpus, I came across the edge case of comments preceding an
addr-spec (with angle brackets!), e.g. “(John Doe) <john@example.com>”, which
does not satisfy the conditions to be treated as a fallback, as per my reading
of RFC2822.
This change does not parse quoted-strings within comments (a corresponding TODO
is in the code), but I have not seen that in the wild.
Fixes#22670
Change-Id: I526fcf7c6390aa1c219fdec1852f26c514506f76
Reviewed-on: https://go-review.googlesource.com/77474
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
GDB 7.5 recognizes DWARF4 by default.
GDB 7.5 release note does not explicitly mention DWARF4 support
but according to GCC 4.8 release note
https://gcc.gnu.org/gcc-4.8/changes.html
"DWARF4 is now the default when generating DWARF debug
information. ...
GDB 7.5, Valgrind 3.8.0 and elfutils 0.154 debug information
consumers support DWARF4 by default."
Change-Id: I56b011c7c38fbc103bbd366ceaea3b709c66ab7f
Reviewed-on: https://go-review.googlesource.com/77570
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
change hash/crc32 package to use cpu package instead of using
runtime internal variables to check crc32 instruction
Change-Id: I8f88d2351bde8ed4e256f9adf822a08b9a00f532
Reviewed-on: https://go-review.googlesource.com/76490
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
I submitted two CLs which broke the build. Add temporary placeholder
with false bools to fix the build and restore old behavior.
Updates golang/go#22718 (details of why it broke)
Change-Id: I1f30624e14f631a95f4eff5aae462f1091f723a2
Reviewed-on: https://go-review.googlesource.com/77590
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A clarifying comment was added to indicate that overflow of a
single Word is not possible in the single digit calculation.
Lehmer's paper includes a proof of the bounds on the size of the
cosequences (u0, u1, u2, v0, v1, v2).
Change-Id: I98127a07aa8f8fe44814b74b2bc6ff720805194b
Reviewed-on: https://go-review.googlesource.com/77451
Reviewed-by: Robert Griesemer <gri@golang.org>
Previously when RoundTrip returned a non-nil error, the proxy returned a
StatusBadGateway error, instead of first calling ModifyResponse. This
commit first calls ModifyResponse, whether or not the error returned
from RoundTrip is nil.
Also closes response body when ModifyResponse returns an error. See #22658.
Fixes#21255
Change-Id: I5b5bf23a69ae5608f87d4ece756a1b4985ccaa9c
Reviewed-on: https://go-review.googlesource.com/54030
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the doc for QueryUnescape and PathUnescape, clarify that by 0xAB we
means a substring with any two valid hexadecimal digits.
Fixes#18642
Change-Id: Ib65b130995ae5fcf07e25ee0fcc41fad520c5662
Reviewed-on: https://go-review.googlesource.com/77050
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before terminating the connectionResetter goroutine the connection
pool processes all of the connections on the channel to unlock the
driverConn instances so everthing can shutdown cleanly. However
the channel was never closed so the goroutine hangs on the range.
Close the channel prior to ranging over it. Also prevent additional
connections from being sent to the resetter after the connection
pool has been closed.
Fixes#22699
Change-Id: I440d2b13cbedec2e04621557f5bd0b1526933dd7
Reviewed-on: https://go-review.googlesource.com/77390
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The cryptographic checksums operate in blocks of 64 or 128 bytes,
which means that the last 128 bytes or so of the input may be encoded
in its original (plaintext) form as part of the state.
Document this so users do not falsely assume that the encoded state
carries no reversible information about the input.
Change-Id: I823dbb87867bf0a77aa20f6ed7a615dbedab3715
Reviewed-on: https://go-review.googlesource.com/77372
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 45412 started hiding autogenerated wrapper functions from call
stacks so that call stack semantics better matched language semantics.
This is based on the theory that the wrapper function will call the
"real" function and all the programmer knows about is the real
function.
However, this theory breaks down in two cases:
1. If the wrapper is at the top of the stack, then it didn't call
anything. This can happen, for example, if the "stack" was actually
synthesized by the user.
2. If the wrapper panics, for example by calling panicwrap or by
dereferencing a nil pointer, then it didn't call the wrapped
function and the user needs to see what panicked, even if we can't
attribute it nicely.
This commit modifies the traceback logic to include the wrapper
function in both of these cases.
Fixes#22231.
Change-Id: I6e4339a652f73038bd8331884320f0b8edd86eb1
Reviewed-on: https://go-review.googlesource.com/76770
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Go compiler assumes that pointers escape when passed into assembly
functions. To override this behavior we can annotate assembly functions
with go:noescape, telling the compiler that we know pointers do not
escape from it.
By annotating the assembly functions in the s390x P256 code in this way
we enable more variables to be allocated on the stack rather than
the heap, reducing the number of heap allocations required to execute
this code:
name old alloc/op new alloc/op delta
SignP256 3.66kB ± 0% 2.64kB ± 0% -27.95% (p=0.008 n=5+5)
VerifyP256 4.46kB ± 0% 1.23kB ± 0% -72.40% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
SignP256 40.0 ± 0% 31.0 ± 0% -22.50% (p=0.008 n=5+5)
VerifyP256 41.0 ± 0% 24.0 ± 0% -41.46% (p=0.008 n=5+5)
Change-Id: Id526c30c9b04b2ad79a55d76cab0e30cc8d60402
Reviewed-on: https://go-review.googlesource.com/66230
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Split typecheckrange into two, separating the bigger chunk of code that
takes care of the range expression. It had to sometimes exit early,
which was done via a goto in the larger func. This lets us simplify many
declarations and the flow of the code. While at it, also replace the
toomany int with a bool.
In the case of walkselect, split it into two funcs too since using a
defer for all the trailing work would be a bit much. It also lets us
simplify the declarations and the flow of the code, since now
walkselectcases has a narrower scope and straightforward signature.
Also replace the gotos in typecheckaste with a lineno defer.
Passes toolstash -cmp on std cmd.
Change-Id: Iacfaa0a34c987c44f180a792c473558785cf6823
Reviewed-on: https://go-review.googlesource.com/72374
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If people are interested in contributing to Go, but not sure what
change they'd like to make just yet, we can point them to the scratch
repo, so they can go through the process of submitting and merging
something now, and make more useful contributions later.
My evidence that sending people to the scratch repo would encourage
future contributions is that a number of people who went through the
workshop at Gophercon have continued to send CL's after submitting to
the scratch repo, even though I doubt they planned to before going
through the workshop.
Change-Id: Ieb48415773c0ee7dc400f8bf6f57f752eca8eeb5
Reviewed-on: https://go-review.googlesource.com/49970
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This test fails on 1.9.2, but is ok on tip.
CL 77331 has both the 1.9.2 fix and this test, and is on the 1.9 release branch.
This CL is just the test, and is on HEAD. The buggy code doesn't exist on tip.
Update #22683
Change-Id: I04a24bd6c2d3068e18ca81da3347e2c1366f4447
Reviewed-on: https://go-review.googlesource.com/77332
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 60410 fixes a bug in reflect that allows assignments to an embedded
field of a pointer to an unexported struct type.
This breaks the json package because unmarshal is now unable to assign
a newly allocated struct to such fields.
In order to be consistent in the behavior for marshal and unmarshal,
this CL changes both marshal and unmarshal to always ignore
embedded pointers to unexported structs.
Fixes#21357
Change-Id: If62ea11155555e61115ebb9cfa5305caf101bde5
Reviewed-on: https://go-review.googlesource.com/76851
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GitHub has defined a set of standard meta files to include with projects
hosted on GitHub. According to the GitHub Insights Community page for
go project the only one missing is the code of conduct.
Go has a code of conduct on it's website and we should link to it in the
prescribed `.github/CODE_OF_CONDUCT.md` so that people can find it in
the standard location on GitHub. This would be consistent with the
contribution guidelines that are linked to in `.github/CONTRIBUTING.md`.
Ref: https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/Fixes#22685
Change-Id: Ie89aa39d3df741d7d6ed2dba5c8ba3d0e0dbf618
Reviewed-on: https://go-review.googlesource.com/77231
Reviewed-by: Gabriel Aszalos <gabriel.aszalos@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also, with this change, error locations don't print absolute positions
in [] brackets following positions relative to line directives. To get
the absolute positions as well, specify the -L flag.
Fixes#22660.
Change-Id: I9ecfa254f053defba9c802222874155fa12fee2c
Reviewed-on: https://go-review.googlesource.com/77090
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
cmd/cover rewrites Go source code to add coverage annotations.
The approach to date has been to parse the code to AST, analyze it,
rewrite the AST, and print it back out. This approach fails to preserve
line numbers in the original code and has a very difficult time with
comments, because go/printer does as well.
This CL changes cmd/cover to decide what to modify based on the
AST but to apply the modifications as purely textual substitutions.
In this way, cmd/cover can be sure it never adds or removes a newline
character, nor a comment, so all line numbers and comments are
preserved.
This also allows us to emit a single //line comment at the beginning
of the translated file and have the compiler report errors with
correct line numbers in the original file.
Fixes#6329.
Fixes#15757.
Change-Id: Ia95f6f894bb498e80d1f91fde56cd4a8009d7f9b
Reviewed-on: https://go-review.googlesource.com/77150
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Per discussion with David Chase, need to check GOSSAHASH$n
for increasing n until one is missing. Also if GSHS_LOGFILE is set,
the compiler writes to that file, so arrange never to cache in that case.
Change-Id: I3931b4e296251b99abab9bbbbbdcf94ae8c1e2a6
Reviewed-on: https://go-review.googlesource.com/77111
Reviewed-by: David Chase <drchase@google.com>
It's nice that
go build -gcflags=-m errors
go build -gcflags=-m errors
uses the cache for the second command.
Even nicer is to make the second command
print the same output as the first command.
Fixes#22587.
Change-Id: I64350839f01c86c9a095d9d22f6924cd7a0b9105
Reviewed-on: https://go-review.googlesource.com/77110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Another one that is possible thanks to the new -trimprefix stringer
flag.
The only subtle difference is that, in the previous version, some values
such as TUNSAFEPTR were stringified as "TUNSAFEPTR" instead of
"UNSAFEPTR". The new String method is always consistent in removing the
"T" prefix.
Passes toolstash -cmp on std cmd.
Change-Id: I68407f391795403dfcbbfa68c813018c0235bbb5
Reviewed-on: https://go-review.googlesource.com/77250
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Since the slice of names is almost exactly the same as what stringer is
already generating for us.
Passes toolstash -cmp on std cmd.
Change-Id: I3f1e95efc690c0108236689e721627f00f79a461
Reviewed-on: https://go-review.googlesource.com/77190
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
This allows better precision and (the motivation) empty strings to
be handled correctly. With that in place tests for the behaviour of
empty name constraints can be added.
Also fixes a compatibility issue with NSS. See #22616.
Fixes#22616
Change-Id: I5139439bb58435d5f769828a4eebf8bed2d858e8
Reviewed-on: https://go-review.googlesource.com/74271
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 76873 added TestGoTestJSON. However, this test
is only succeeding on SMP machines.
This change skips TestGoTestJSON on uniprocessor machines.
Fixes#22665.
Change-Id: I3989d3331fb71193a25a3f0bbb84ff3e1b730890
Reviewed-on: https://go-review.googlesource.com/77130
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes getmac lists many interfaces for the same MAC address,
while Interfaces returns only single name for that address. Adjust
the test to ignore the names that are not returned by the Interfaces.
Fixes#21027
Change-Id: I08d98746a7c669f2d730dba2da36e07451a6f405
Reviewed-on: https://go-review.googlesource.com/59411
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
If you run
go test -coverpkg=all fmt
one possible interpretation is that you want coverage for all the
packages involved in the fmt test, not all the packages in the world.
Because coverpkg was previously defined as a list of packages
to be loaded, however, it meant all packages in the world.
Now that the go command has a concept of package notation
being used as a matching filter instead of a direct enumeration,
apply that to -coverpkg, so that -coverpkg=all now has the
more useful filter interpretation.
Fixes#10271.
Fixes#21283.
Change-Id: Iddb77b21ba286d3dd65b62507af27e244865072d
Reviewed-on: https://go-review.googlesource.com/76876
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It's easy to merge the coverage profiles from the
multiple executed tests, so do that.
Also ensures that at least an empty coverage profile
is always written.
Fixes#6909.
Fixes#18909.
Change-Id: I28b88e1fb0fb773c8f57e956b18904dc388cdd82
Reviewed-on: https://go-review.googlesource.com/76875
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is already documented in the time.Time package
but people might not look there.
Followup to CL 76872, which I submitted accidentally
(Gerrit has placed the Submit button next to Reply again.)
Change-Id: Ibfd6a4da241982d591a8698282a0c15fe9f2e775
Reviewed-on: https://go-review.googlesource.com/77010
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL finally adds one of our longest-requested cmd/go features:
a way for test-running harnesses to access test output in structured form.
In fact the structured json output is more informative than the text
output, because the output from multiple parallel tests can be
interleaved as it becomes available, instead of needing to wait for
the previous test to finish before showing any output from the
next test.
See CL 76872 for the conversion details.
Fixes#2981.
Change-Id: I749c4fc260190af9fe633437a781ec0cf56b7260
Reviewed-on: https://go-review.googlesource.com/76873
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Also add cmd/internal/test2json, the actual implementation,
which will be called directly from cmd/go in addition to being
a standalone command (like cmd/buildid and cmd/internal/buildid).
For #2981.
Change-Id: I244ce36d665f424bbf13f5ae00ece10b705d367d
Reviewed-on: https://go-review.googlesource.com/76872
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In past releases, whether test output appears on stdout or stderr
has varied depending on exactly how go test was invoked and
also (indefensibly) on the number of CPUs available.
Standardize on standard output for all test output.
This is easy to explain and makes go test | go tool test2json work nicely.
Change-Id: I605641213fbc6c7ff49e1fd38a0f732045a8383d
Reviewed-on: https://go-review.googlesource.com/76871
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now possible, since stringer just got the -trimprefix flag added.
While at it, simplify a few Op stringifications since we can now use %v,
and no longer have to worry about o<len(opnames).
Passes toolstash -cmp on std cmd.
Fixes#15462.
Change-Id: Icdcde0b0a5eb165d18488918175024da274f782b
Reviewed-on: https://go-review.googlesource.com/76790
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
The old code only worked for double-quoted strings, and only checked
that the end of the literal value was \n". This worked most of the time,
except for some strings like "foo\\n", which doesn't actually translate
into a trailing newline when unquoted.
To fix this, unquote the string first and look for a real newline at the
end of it. Ignore errors, as we don't have anything to do with string
literals using back quotes.
Fixes#22613.
Change-Id: I7cf96916dd578b7068216c2051ec2622cce0b740
Reviewed-on: https://go-review.googlesource.com/76194
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
A header line with leading whitespaces is not valid in HTTP as per
RFC7230. This change ignores these invalid lines in ReadMIMEHeader.
Updates #22464
Change-Id: Iff9f00380d28a9617a55ff7888a76fba82001402
Reviewed-on: https://go-review.googlesource.com/75350
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
this change removes the state field from the lexer,
because it's only used by the run method and can be
replaced with a local variable
Change-Id: Ib7a90ab6e9a894716cba2c7d9ed71bf2ad1240c0
Reviewed-on: https://go-review.googlesource.com/47338
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This changes improves the ConstantTimeByteEq and ConstantTimeEq
primitives to both simplify them and improve their performance.
Also, since there were no benchmarks for this package before,
this change adds benchmarks for ConstantTimeByteEq,
ConstantTimeEq, and ConstantTimeLessOrEq.
benchmarks on darwin/amd64, 10 runs on old vs new code:
name old time/op new time/op delta
ConstantTimeByteEq-4 2.28ns ±16% 1.53ns ± 2% -33.09% (p=0.000 n=10+9)
ConstantTimeEq-4 2.77ns ±10% 1.51ns ± 2% -45.59% (p=0.000 n=10+9)
ConstantTimeLessOrEq-4 1.52ns ± 8% 1.50ns ± 2% ~ (p=0.866 n=9+9)
Change-Id: I29b8cbcf158e1f30411720db82d38b4ecd166b15
Reviewed-on: https://go-review.googlesource.com/45310
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd/go/internal/work.Builder.updateBuildID left a file opened.
But opened files cannot be deleted on Windows, so cmd/go just
leaves these files in %TMP% directory.
Close the file so deletion can succeed.
Fixes#22650
Change-Id: Ia3ea62f6ec7208d73972eae2e17fb4a766407914
Reviewed-on: https://go-review.googlesource.com/76810
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I added this in CL 76024 in order to do compile+link+run. This
is no longer necessary after CL 76551, which changed it back to
"go run". Remove it.
Change-Id: Ifa744d4b2f73f33cad056b24051821e43638cc7f
Reviewed-on: https://go-review.googlesource.com/76690
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The linker will refuse to work on objects larger than
2e9 bytes (see issue #9862 for why).
With this change, the compiler gives a useful error
message explaining this, instead of leaving it to the
linker to give a cryptic message later.
Fixes#1700.
Change-Id: I3933ce08ef846721ece7405bdba81dff644cb004
Reviewed-on: https://go-review.googlesource.com/74330
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The recent vendored pprof update broke the iOS builders. The issue was
reported and patched upstream. Re-vendor the internal pprof copy.
Updates vendored pprof to commit 9e20b5b106e946f4cd1df94c1f6fe3f88456628d
from github.com/google/pprof (2017-11-08).
Fixes#22612
Change-Id: I74c46c75e92ce401e605c55e27d8545c0d66082c
Reviewed-on: https://go-review.googlesource.com/76651
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Even if the go command can see that the target is up-to-date
an mtime-based build system invoking the go command may not
be able to tell. Update the mtime to make clear that the target is
up-to-date, and also to hide exactly how smart the go command
is or is not. This keeps users (and programs) from depending on
the exact details of the go command's staleness determination.
Without this I believe we will get a stream of (completely reasonable)
bug reports that "go install (or go test -c) did not update the binary
after I trivially changed the source code or touched a source file".
Change-Id: I920e4aaed2a57319e3c0c37717f872bc059e484e
Reviewed-on: https://go-review.googlesource.com/76590
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
We want test caching to work even for people with scripts
that set a non-default test timeout. But then that raises the
question of what to do about runs with different timeouts:
is a cached success with one timeout available for use when
asked to run the test with a different timeout?
This CL answers that question by saying that the timeout applies
to the overall execution of either running the test or displaying
the cached result, and displaying a cached result takes no time.
So it's always OK to record a cached result, regardless of timeout,
and it's always OK to display a cached result, again regardless of timeout.
Fixes#22633.
Change-Id: Iaef3602710e3be107602267bbc6dba9a2250796c
Reviewed-on: https://go-review.googlesource.com/76552
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It has always been problematic that there was no way to specify
tool flags that applied only to the build of certain packages;
it was only to specify flags for all packages being built.
The usual workaround was to install all dependencies of something,
then build just that one thing with different flags. Since the
dependencies appeared to be up-to-date, they were not rebuilt
with the different flags. The new content-based staleness
(up-to-date) checks see through this trick, because they detect
changes in flags. This forces us to address the underlying problem
of providing a way to specify per-package flags.
The solution is to allow -gcflags=pattern=flags, which means
that flags apply to packages matching pattern, in addition to the
usual -gcflags=flags, which is now redefined to apply only to
the packages named on the command line.
See #22527 for discussion and rationale.
Fixes#22527.
Change-Id: I6716bed69edc324767f707b5bbf3aaa90e8e7302
Reviewed-on: https://go-review.googlesource.com/76551
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It needs to refer to packages, so it can no longer be in cfg.
No semantic changes here.
Can now be unexported, so that was a net win anyway.
Change-Id: I58bf6cdcd435e6e019291bb8dcd5d5b7f1ac03a3
Reviewed-on: https://go-review.googlesource.com/76550
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In the current implementation, it is possible for a client to
continuously send warning alerts, which are just dropped on the floor
inside readRecord.
This can enable scenarios in where someone can try to continuously
send warning alerts to the server just to keep it busy.
This CL implements a simple counter that triggers an error if
we hit the warning alert limit.
Fixes#22543
Change-Id: Ief0ca10308cf5a4dea21a5a67d3e8f6501912da6
Reviewed-on: https://go-review.googlesource.com/75750
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Plain blocks that contain only uninteresting instructions
(that do not have reliable Pos information themselves)
need to have their Pos left unset so that they can
inherit it from their successors. The "uninteresting"
test was not properly applied and not properly defined.
OpFwdRef does not appear in the ssa.html debugging output,
but at the time of the test these instructions did appear,
and it needs to be part of the test.
Fixes#22365.
Change-Id: I99e5b271acd8f6bcfe0f72395f905c7744ea9a02
Reviewed-on: https://go-review.googlesource.com/74252
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is the equivalent change to 1c105980 but for SHA-512.
SHA-512 certificates are already supported by default since b53bb2ca,
but some servers will refuse connections if the algorithm is not
advertised in the overloaded signatureAndHash extension (see 09b238f1).
This required adding support for SHA-512 signatures on CertificateVerify
and ServerKeyExchange messages, because of said overloading.
Some testdata/Client-TLSv1{0,1} files changed because they send a 1.2
ClientHello even if the server picks a lower version.
Closes#22422
Change-Id: I16282d03a3040260d203711ec21e6b20a0e1e105
Reviewed-on: https://go-review.googlesource.com/74950
Run-TryBot: Filippo Valsorda <hi@filippo.io>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
The docs for xml.Marshal state that the XML elements name is derived
from one of five locations in a specific order of precedence, but does
not mention that if the field is a struct type and has its name defined
in a tag and in the types XMLName field that an error will occur. This
is documented in the structFieldInfo function but not in the function
documentation, and the existing docs in Marshal are misleading without
this behavior being discussed.
Fixes#18564
Change-Id: I29042f124a534bd1bc993f1baeddaa0af2e72fed
Reviewed-on: https://go-review.googlesource.com/76321
Reviewed-by: Ian Lance Taylor <iant@golang.org>
crypto/x509 has always enforced EKUs as a chain property (like CAPI, but
unlike the RFC). With this change, EKUs will be checked at
chain-building time rather than in a target-specific way.
Thus mis-nested EKUs will now cause a failure in Verify, irrespective of
the key usages requested in opts. (This mirrors the new behaviour w.r.t.
name constraints, where an illegal name in the leaf will cause a Verify
failure, even if the verified name is permitted.).
Updates #15196
Change-Id: Ib6a15b11a9879a9daf5b1d3638d5ebbbcac506e5
Reviewed-on: https://go-review.googlesource.com/71030
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL 75253 introduced new SysProcAttr.Token field as Handle.
But we already have exact type for it - Token. Use Token
instead of Handle everywhere - it saves few type conversions
and provides better documentation for new API.
Change-Id: Ibc5407a234a1f49804de15a24b27c8e6a6eba7e0
Reviewed-on: https://go-review.googlesource.com/76314
Reviewed-by: Ian Lance Taylor <iant@golang.org>
WSASocket (unlike socket call) allows to create sockets that
will not be inherited by child process. So call WSASocket to
save on using syscall.ForkLock and calling syscall.CloseOnExec.
Some very old versions of Windows do not have that functionality.
Call socket, if WSASocket failed, to support these.
Change-Id: I2dab9fa00d1a8609dd6feae1c9cc31d4e55b8cb5
Reviewed-on: https://go-review.googlesource.com/72590
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change makes crypto/x509 enforce name constraints for all names in
a leaf certificate, not just the name being validated. Thus, after this
change, if a certificate validates then all the names in it can be
trusted – one doesn't have a validate again for each interesting name.
Making extended key usage work in this fashion still remains to be done.
Updates #15196
Change-Id: I72ed5ff2f7284082d5bf3e1e86faf76cef62f9b5
Reviewed-on: https://go-review.googlesource.com/62693
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently dead goroutines retain their assist credit. This credit can
be used if the goroutine gets recycled, but in general this can make
assist pacing over-aggressive by hiding an amount of credit
proportional to the number of exited (and not reused) goroutines.
Fix this "hidden credit" by flushing assist credit to the global
credit pool when a goroutine exits.
Updates #14812.
Change-Id: I65f7f75907ab6395c04aacea2c97aea963b60344
Reviewed-on: https://go-review.googlesource.com/24703
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This fixes a race on old Linux kernels, in which we might temporarily
set epfd to an invalid value other than -1. It's also the right thing
to do. No test because the problem only occurs on old kernels.
Fixes#22606
Change-Id: Id84bdd6ae6d7c5d47c39e97b74da27576cb51a54
Reviewed-on: https://go-review.googlesource.com/76319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The CMPWUconst op (32-bit unsigned comparison with immediate) takes
an unsigned immediate value. In SSA this should be sign extended to
64-bits to match the Int32 type given in the op and then zero
extended when producing the final assembly. Before this CL we were
zero extending in SSA which caused ssacheck to fail.
While we are here also ensure other 32-bit immediates are sign
extended in SSA.
Passes toolstash -cmp on std on s390x.
Fixes#22611.
Change-Id: I5c061a76a710b10ecb0650c9c42efd9fa1c123cc
Reviewed-on: https://go-review.googlesource.com/76336
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A couple of the CPU profiling testpoints make calls to helper
functions (cpuHog1, for example) where the computed value is always
thrown away by the caller without being used. A smart compiler back
end (in this case LLVM) can detect this fact and delete the contents
of the called function, which can cause tests to fail. Harden the test
slighly by passing in a value read from a global and insuring that the
caller stores the value back to a global; this prevents any optimizer
mischief.
Change-Id: Icbd6e3e32ff299c68a6397dc1404a52b21eaeaab
Reviewed-on: https://go-review.googlesource.com/76230
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Be more pessimistic when parsing if/switch/for headers for better error
messages when things go wrong.
Fixes#22581.
Change-Id: Ibb99925291ff53f35021bc0a59a4c9a7f695a194
Reviewed-on: https://go-review.googlesource.com/76290
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The NonUTF8 field provides users with a way to explictly tell the
ZIP writer to avoid setting the UTF-8 flag.
This is necessary because many readers:
1) (Still) do not support UTF-8
2) And use the local system encoding instead
Thus, even though character encodings other than CP-437 and UTF-8
are not officially supported by the ZIP specification, pragmatically
the world has permitted use of them.
When a non-standard encoding is used, it is the user's responsibility
to ensure that the target system is expecting the encoding used
(e.g., producing a ZIP file you know is used on a Chinese version of Windows).
We adjust the detectUTF8 function to account for Shift-JIS and EUC-KR
not being identical to ASCII for two characters.
We don't need an API for users to explicitly specify that they are encoding
with UTF-8 since all single byte characters are compatible with all other
common encodings (Windows-1256, Windows-1252, Windows-1251, Windows-1250,
IEC-8859, EUC-KR, KOI8-R, Latin-1, Shift-JIS, GB-2312, GBK) except for
the non-printable characters and the backslash character (all of which
are invalid characters in a path name anyways).
Fixes#10741
Change-Id: I9004542d1d522c9137973f1b6e2b623fa54dfd66
Reviewed-on: https://go-review.googlesource.com/75592
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #21317
@mdempsky fixed issue #21317 with CL 66810,
so lock a test in to ensure we don't regress.
The test is manual for now before test/run.go
has support for matching column numbers so do
it old school and match expected output after
an exec.
Change-Id: I6c2a66ddf04248f79d17ed7033a3280d50e41562
Reviewed-on: https://go-review.googlesource.com/76150
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, assigning a []T where T is a go:notinheap type generates an
unnecessary write barrier for storing the slice pointer.
This fixes this by teaching HasHeapPointer that this type does not
have a heap pointer, and tweaking the lowering of slice assignments so
the pointer store retains the correct type rather than simply lowering
it to a *uint8 store.
Change-Id: I8bf7c66e64a7fefdd14f2bd0de8a5a3596340bab
Reviewed-on: https://go-review.googlesource.com/76027
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The cache will take care of keeping go test -tags lldb fast.
Installing runtime/cgo this way just makes all the checkNotStale
tests think runtime/cgo is out of date.
Should fix ios builders.
Fixes#22509.
Change-Id: If092cc4feb189eb848b6a22f6d22b89b70df219c
Reviewed-on: https://go-review.googlesource.com/76020
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The change in cmd/dist ignores debug output, instead of assuming
any output is from the template.
The change in cmd/go makes the debug output show the package name
on every line, so that interlaced prints can be deinterlaced.
Change-Id: Ic3d59ee0256271067cb9be2fde643a0e19405375
Reviewed-on: https://go-review.googlesource.com/76019
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Even though cmd/dist has historically distinguished "CC for gohostos/gohostarch"
from "CC for target goos/goarch", it has not recorded that distinction
for later use by cmd/cgo and cmd/go. Now that content-based staleness
includes the CC setting in the decision about when to rebuild packages,
the go command needs to know the details of which CC to use when.
Otherwise lots of things look out of date and (worse) may be rebuilt with
the wrong CC.
A related issue is that users may want to be able to build a toolchain
capable of cross-compiling for two different non-host targets, and
to date we've required that CC_FOR_TARGET apply to both.
This CL introduces CC_FOR_${GOOS}_${GOARCH}, so that you can
(for example) set CC_FOR_linux_arm and CC_FOR_linux_arm64
separately on a linux/ppc64 host and be able to cross-compile to
either arm or arm64 with the right toolchain.
Fixes#8161.
Half of a fix for #22509.
Change-Id: I7a43769f39d859f659d31bc96980918ba102fb83
Reviewed-on: https://go-review.googlesource.com/76018
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There are multiple valid reasons a tool might print to stderr.
As long as we get the expected output on stdout, that's fine.
Fixes#22588.
Change-Id: I9c5d32da08288cb26dd575530a8257cd5f375367
Reviewed-on: https://go-review.googlesource.com/76017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This was a hack to make a new make.bash avoid reusing installed packages.
The new content-based staleness is precise enough not to need this hack;
now it's just causing unnecessary rebuilds: if a package doesn't import "runtime",
for example, it doesn't need to be recompiled when runtime changes.
(It does need to be relinked, and we still arrange that.)
Change-Id: I4ddf6e16d754cf21b16e9db1ed52bddbf82e96c6
Reviewed-on: https://go-review.googlesource.com/76015
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
I thought SSA check was enabled for those tests, but in fact it
was not. Enable it. So we have SSA check on for at least some
tests on all architectures.
Updates #22499.
Change-Id: I51fcdda3af7faab5aeb33bf46c6db309285ce42c
Reviewed-on: https://go-review.googlesource.com/76024
Reviewed-by: Keith Randall <khr@golang.org>
The ModifiedTime and ModifiedDate fields are not expressive enough
for many of the time extensions that have since been added to ZIP,
nor are they easy to access since they in a legacy MS-DOS format,
and must be set and retrieved via the SetModTime and ModTime methods.
Instead, we add new field Modified of time.Time type that contains
all of the previous information and more.
Support for extended timestamps have been attempted before, but the
change was reverted because it provided no ability for the user to
specify the timezone of the legacy MS-DOS fields.
Technically the old API did not either, but users were manually offsetting
the timestamp to achieve the same effect.
The Writer now writes the legacy timestamps according to the timezone
of the FileHeader.Modified field. When the Modified field is set via
the SetModTime method, it is in UTC, which preserves the old behavior.
The Reader attempts to determine the timezone if both the legacy
and extended timestamps are present since it can compute the delta
between the two values.
Since Modified is a superset of the information in ModifiedTime and ModifiedDate,
we mark ModifiedTime, ModifiedDate, ModTime, and SetModTime as deprecated.
Fixes#18359
Change-Id: I29c6bc0a62908095d02740df3e6902f50d3152f1
Reviewed-on: https://go-review.googlesource.com/74970
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing NaCl filesystem Link system call erroneously allowed
a caller to call Link on an existing target which violates the POSIX
standard and effectively corrupted the internal filesystem
representation.
Fixes#22383
Change-Id: I77b16c37af9bf00a1799fa84277f066180edac47
Reviewed-on: https://go-review.googlesource.com/76110
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the only thing changing in the binary is the embedded main.a action ID,
go install was declining to install the binary, but go list could see that the
binary needed reinstalling (was stale).
Fixes#22531.
Change-Id: I4a53b0ebd4c34aad907bab7da571fada545f3c6f
Reviewed-on: https://go-review.googlesource.com/76014
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
I do not remember why we require deps.go to have a hard-coded
copy of the dependency information for cmd/go, when we can
read it from the source files instead. The answer probably involves
cmd/dist once being a C program.
In any event, stop doing that, which will eliminate the builder-only
failures in the builder-only deps test.
Change-Id: I0abd384c47401940ca08427b5be544812edcbe7f
Reviewed-on: https://go-review.googlesource.com/76021
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
I typed 'go list -josn' without realizing I'd mistyped json, and I was confused for
quite a while as to why I was staring at the 'go help json' text: the actual problem
(a missing flag) scrolls far off the screen. If people want the full text, they can
easily ask for it, but don't drown the important bit - unrecognized flag or other
improper usage - with pages of supporting commentary. The help text does not
help people who just need to be told about a typo.
Change-Id: I179c431baa831e330f3ee495ce0a5369319962d5
Reviewed-on: https://go-review.googlesource.com/76013
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Updates #22389
@mdempsky's CL 70850 fixed the unnecessary
compile stack trace printing during ICE diagnostics.
This CL adds a test to lock in this behavior.
Change-Id: I9ce49923c80b78cb8c0bb5dc4af3c860a43d63ba
Reviewed-on: https://go-review.googlesource.com/74630
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On Plan 9, some file servers, like ramfs, handle the read
offset when reading directories. However, the offset isn't
valid anymore after directory entries have been removed
between successive calls to read.
This issue happens when os.RemoveAll is called on a
directory that doesn't fit on a single 9P response message.
In this case, the first part of the directory is read,
then directory entries are removed and the second read
will be incomplete because the read offset won't be valid
anymore. Consequently, the content of the directory will
only be partially removed.
We change RemoveAll to call fd.Seek(0, 0) before calling
fd.Readdirnames, so the read offset will always be reset
after removing the directory entries.
After adding TestRemoveAllLarge, we noticed the same issue
appears on NaCl and the same fix applies as well.
Fixes#22572.
Change-Id: Ifc76ea7ccaf0168c34dc8ec0f400dc04db1baf8f
Reviewed-on: https://go-review.googlesource.com/75974
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Otherwise, one can't run "go fmt" on a directory containing Go files if
none of them are buildable (e.g. because of build tags). This is
counter-intuitive, as fmt will format all Go files anyway.
If we encounter such a load error, ignore it and carry on. All other
load errors, such as when a package can't be found, should still be
shown to the user.
Add a test for the two kinds of load errors. Use fmt -n so that any
changes to the formatting of the files in testdata don't actually get
applied. The load errors still occur with -n, so the test does its job.
Fixes#22183.
Change-Id: I99d0c0cdd29015b6a3f5286a9bbff50757c78e0d
Reviewed-on: https://go-review.googlesource.com/75930
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
A statement like
foo = bar + qux
might compile to
AX := AX + BX
resulting in a regkill for AX before this instruction.
The buggy behavior is to kill AX "at" this instruction,
before it has executed. (Code generation of no-instruction
values like RegKills applies their effects at the
next actual instruction emitted).
However, bar is still associated with AX until after the
instruction executes, so the effect of the regkill must
occur at the boundary between this instruction and the
next. Similarly, the new value bound to AX is not visible
until this instruction executes (and in the case of values
that require multiple instructions in code generation, until
all of them have executed).
The ranges are adjusted so that a value's start occurs
at the next following instruction after its evaluation,
and the end occurs after (execution of) the first
instruction following the end of the lifetime as a value.
(Notice the asymmetry; the entire value must be finished
before it is visible, but execution of a single instruction
invalidates. However, the value *is* visible before that
next instruction executes).
The test was adjusted to make it insensitive to the result
numbering for variables printed by gdb, since that is not
relevant to the test and makes the differences introduced
by small changes larger than necessary/useful.
The test was also improved to present variable probes
more intuitively, and also to allow explicit indication
of "this variable was optimized out"
Change-Id: I39453eead8399e6bb05ebd957289b112d1100c0e
Reviewed-on: https://go-review.googlesource.com/74090
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For structs, slices, strings, interfaces, etc, propagation of
names to their components (e.g., complex.real, complex.imag)
is fragile (depends on phase ordering) and not done right
for the "dec" pass.
The dec pass is subsumed into decomposeBuiltin,
and then names are pushed into the args of all
OpFooMake opcodes.
compile/ssa/debug_test.go was fixed to pay attention to
variable values, and the reference files include checks
for the fixes in this CL (which make debugging better).
Change-Id: Ic2591ebb1698d78d07292b92c53667e6c37fa0cd
Reviewed-on: https://go-review.googlesource.com/73210
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This test was taking too long on ppc64x.
There were a few reasons.
The first is that the page size on ppc64x is 64k instead of 4k.
That's 16x more work.
The second is that the generic Index is pretty bad in this case.
It first calls IndexByte which does a bunch of setup work only to find
the byte we're looking for at index 0. Then it calls Equal which
has to look at the whole string to find a difference on the last byte.
To fix, just limit our attention to near the end of the page.
Change-Id: I6b8bcbb94652a2da853862acc23803def0c49303
Reviewed-on: https://go-review.googlesource.com/76050
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This change adds code generation tests for multiplication by ±2ⁿ for
arm and arm64, in preparation for a future CL which will remove the
relevant architecture-specific SSA rules (the reduction is already
performed by rules in generic.rules added in CL 36323).
Change-Id: Iebdd5c3bb2fc632c85888569ff0c49f78569a862
Reviewed-on: https://go-review.googlesource.com/75752
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This makes the output they print refer to the code that called them.
For example, instead of
=== RUN TestWindowsStackMemoryCgo
--- SKIP: TestWindowsStackMemoryCgo (0.00s)
testenv.go:213: skipping known flaky test ...
PASS
we see
=== RUN TestWindowsStackMemoryCgo
--- SKIP: TestWindowsStackMemoryCgo (0.00s)
crash_cgo_test.go:471: skipping known flaky test ...
PASS
Change-Id: I5f4c77c3aeab5c0e43c6dde2f15db70a6df24603
Reviewed-on: https://go-review.googlesource.com/76031
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The go repository contains a mix of github.com/golang/go/issues/xxxxx
and golang.org/issues/xxxxx URLs for references to issues in the issue
tracker. We should use one for consistency, and golang.org is preferred
in case the project moves the issue tracker in the future.
This reasoning is taken from a comment Sam Whited left on a CL I
recently opened: https://go-review.googlesource.com/c/go/+/73890.
In that CL I referenced an issue using its github.com URL, because other
tests in the file I was changing contained references to issues using
their github.com URL. Sam Whited left a comment on the CL stating I
should change it to the golang.org URL.
If new code is intended to reference issues via golang.org and not
github.com, existing code should be updated so that precedence exists
for contributors who are looking at the existing code as a guide for the
code they should write.
Change-Id: I3b9053fe38a1c56fc101a8b7fd7b8f310ba29724
Reviewed-on: https://go-review.googlesource.com/75673
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Introduce the presence of the monotonic time reading first,
before the paragraph about comparison that mentions it multiple times.
Change-Id: I91e31e118be013eee6c258163a1bb2cb42501527
Reviewed-on: https://go-review.googlesource.com/76010
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL makes "go install" behave the way many users expect:
install only the things named on the command line.
Future builds still run as fast, thanks to the new build cache (CL 75473).
To install dependencies as well (the old behavior), use "go install -i".
Actual definitions aside, what most users know and expect of "go install"
is that (1) it installs what you asked, and (2) it's fast, unlike "go build".
It was fast because it installed dependencies, but installing dependencies
confused users repeatedly (see for example #5065, #6424, #10998, #12329,
"go build" and "go test" so that they could be "fast" too, but that only
created new opportunities for confusion. We also had to add -installsuffix
and then -pkgdir, to allow "fast" even when dependencies could not be
installed in the usual place.
The recent introduction of precise content-based staleness logic means that
the go command detects the need for rebuilding packages more often than it
used to, with the consequence that "go install" rebuilds and reinstalls
dependencies more than it used to. This will create more new opportunities
for confusion and will certainly lead to more issues filed like the ones
listed above.
CL 75743 introduced a build cache, separate from the install locations.
That cache makes all operations equally incremental and fast, whether or
not the operation is "install" or "build", and whether or not "-i" is used.
Installing dependencies is no longer necessary for speed, it has confused
users in the past, and the more accurate rebuilds mean that it will confuse
users even more often in the future. This CL aims to end all that confusion
by not installing dependencies by default.
By analogy with "go build -i" and "go test -i", which still install
dependencies, this CL introduces "go install -i", which installs
dependencies in addition to the things named on the command line.
Fixes#5065.
Fixes#6424.
Fixes#10998.
Fixes#12329.
Fixes#18981.
Fixes#22469.
Another step toward #4719.
Change-Id: I3d7bc145c3a680e2f26416e182fa0dcf1e2a15e5
Reviewed-on: https://go-review.googlesource.com/75850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds an automatic, limited "go vet" to "go test".
If the building of a test package fails, vet is not run.
If vet fails, the test is not run.
The goal is that users don't notice vet as part of the "go test"
process at all, until vet speaks up and says something important.
This should help users find real problems in their code faster
(vet can just point to them instead of needing to debug a
test failure) and expands the scope of what kinds of things
vet can help with.
The "go vet" runs in parallel with the linking of the test binary,
so for incremental builds it typically does not slow the overall
"go test" at all: there's spare machine capacity during the link.
all.bash has less spare machine capacity. This CL increases
the time for all.bash on my laptop from 4m41s to 4m48s (+2.5%)
To opt out for a given run, use "go test -vet=off".
The vet checks used during "go test" are a subset of the full set,
restricted to ones that are 100% correct and therefore acceptable
to make mandatory. In this CL, that set is atomic, bool, buildtags,
nilfunc, and printf. Including printf is debatable, but I want to
include it for now and find out what needs to be scaled back.
(It already found one real problem in package os's tests that
previous go vet os had not turned up.)
Now that we can rely on type information it may be that printf
should make its function-name-based heuristic less aggressive
and have a whitelist of known print/printf functions.
Determining the exact set for Go 1.10 is #18085.
Running vet also means that programs now have to type-check
with both cmd/compile and go/types in order to pass "go test".
We don't start vet until cmd/compile has built the test package,
so normally the added go/types check doesn't find anything.
However, there is at least one instance where go/types is more
precise than cmd/compile: declared and not used errors involving
variables captured into closures.
This CL includes a printf fix to os/os_test.go and many declared
and not used fixes in the race detector tests.
Fixes#18084.
Change-Id: I353e00b9d1f9fec540c7557db5653e7501f5e1c9
Reviewed-on: https://go-review.googlesource.com/74356
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds caching of successful test results, keyed by the
action ID of the test binary and its command line arguments.
Suppose you run:
go test -short std
<edit a typo in a comment in math/big/float.go>
go test -short std
Before this CL, the second go test would re-run all the tests
for the std packages. Now, the second go test will use the cached
result immediately (without any compile or link steps) for any
packages that do not transitively import math/big, and then
it will, after compiling math/big and seeing that the .a file didn't
change, reuse the cached test results for the remaining packages
without any additional compile or link steps.
Suppose that instead of editing a typo you made a substantive
change to one function, but you left the others (including their
line numbers) unchanged. Then the second go test will re-link
any of the tests that transitively depend on math/big, but it still
will not re-run the tests, because the link will result in the same
test binary as the first run.
The only cacheable test arguments are:
-cpu
-list
-parallel
-run
-short
-v
Using any other test flag disables the cache for that run.
The suggested argument to mean "turn off the cache" is -count=1
(asking "please run this 1 time, not 0").
There's an open question about re-running tests when inputs
like environment variables and input files change. For now we
will assume that users will bypass the test cache when they
need to do so, using -count=1 or "go test" with no arguments.
This CL documents the new cache but also documents the
previously-undocumented distinction between "go test" with
no arguments (now called "local directory mode") and with
arguments (now called "package list mode"). It also cleans up
a minor detail of package list mode buffering that used to change
whether test binary stderr was sent to go command stderr based
on details like exactly how many packages were listed or
how many CPUs the host system had. Clearly the file descriptor
receiving output should not depend on those, so package list mode
now consistently merges all output to stdout, where before it
mostly did that but not always.
Fixes#11193.
Change-Id: I120edef347b9ddd5b10e247bfd5bd768db9c2182
Reviewed-on: https://go-review.googlesource.com/75631
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
CL 65071 enabled inlining for local closures with no captures.
To determine safety of inlining a call sites, we check whether the
variable holding the closure has any assignments after its original
definition.
Unfortunately, that check did not catch OAS2MAPR and OAS2DOTTYPE,
leading to incorrect inlining when a variable holding a closure was
subsequently reassigned through a type conversion or a 2-valued map
access.
There was another more subtle issue wherein reassignment check would
always return a false positive for closure calls inside other
closures. This was caused by the Name.Curfn field of local variables
pointing to the OCLOSURE node instead of the corresponding ODCLFUNC,
which resulted in reassigned walking an empty Nbody and thus never
seeing any reassignments.
This CL fixes these oversights and adds many more tests for closure
inlining which ensure not only that inlining triggers but also the
correctness of the resulting code.
Updates #15561
Change-Id: I74bdae849c4ecfa328546d6d62b512e8d54d04ce
Reviewed-on: https://go-review.googlesource.com/75770
Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make sure Index and IndexByte don't read past the queried byte slice.
Hopefully will be helpful for CL 33597.
Also remove the code which maps/unmaps the Go heap.
Much safer to play with protection bits off-heap.
Change-Id: I50d73e879b2d83285e1bc7c3e810efe4c245fe75
Reviewed-on: https://go-review.googlesource.com/75890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This adds new rules to recognize consecutive byte loads and
stores and lowers them to loads and stores such as lhz, lwz, ld,
sth, stw, std. This change only covers the little endian cases
on little endian machines, such as is found in encoding/binary
UintXX or PutUintXX for little endian. Big endian will be done
later.
Updates were also made to binary_test.go to allow the benchmark
for Uint and PutUint to actually use those functions because
the way they were written, those functions were being
optimized out.
Testcases were also added to cmd/compile/internal/gc/asm_test.go.
Updates #22496
The following improvement can be found in golang.org/x/crypto
poly1305:
Benchmark64-16 142 114 -19.72%
Benchmark1K-16 1717 1424 -17.06%
Benchmark64Unaligned-16 142 113 -20.42%
Benchmark1KUnaligned-16 1721 1428 -17.02%
chacha20poly1305:
BenchmarkChacha20Poly1305Open_64-16 1012 885 -12.55%
BenchmarkChacha20Poly1305Seal_64-16 971 836 -13.90%
BenchmarkChacha20Poly1305Open_1350-16 11113 9539 -14.16%
BenchmarkChacha20Poly1305Seal_1350-16 11013 9392 -14.72%
BenchmarkChacha20Poly1305Open_8K-16 61074 53431 -12.51%
BenchmarkChacha20Poly1305Seal_8K-16 61214 54806 -10.47%
Other improvements of around 10% found in crypto/tls.
Results after updating encoding/binary/binary_test.go:
BenchmarkLittleEndianPutUint64-16 1.87 0.93 -50.27%
BenchmarkLittleEndianPutUint32-16 1.19 0.93 -21.85%
BenchmarkLittleEndianPutUint16-16 1.16 1.03 -11.21%
Change-Id: I7bbe2fbcbd11362d58662fecd907a0c07e6ca2fb
Reviewed-on: https://go-review.googlesource.com/74410
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Unlike the legacy text format that outputs the count and the number of
cycles, the pprof tool expects contention profiles to include the count
and the delay time measured in nanoseconds. printCountCycleProfile
performs the conversion from cycles to nanoseconds.
(See parseContention function in
cmd/vendor/github.com/google/pprof/profile/legacy_profile.go)
Fixes#21474
Change-Id: I8e8fb6ea803822d7eaaf9ecf1df3e236ad225a7b
Reviewed-on: https://go-review.googlesource.com/64410
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The name of the temporary directory containing _testmain.go
was leaking into the binary.
Found with GODEBUG=gocacheverify=1 go test std.
Change-Id: I5b35f049b564f3eb65c6a791ee785d15255c7885
Reviewed-on: https://go-review.googlesource.com/75630
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL adds caching of built package files in $GOCACHE, so that
a second build with a particular configuration will be able to reuse
the work done in the first build of that configuration, even if the
first build was only "go build" and not "go install", or even if there
was an intervening "go install" that wiped out the installed copy of
the first build.
The benchjuju benchmark runs go build on a specific revision of jujud 10 times.
Before this CL:
102.72u 15.29s 21.98r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
105.99u 15.55s 22.71r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
106.49u 15.70s 22.82r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
107.09u 15.72s 22.94r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
108.19u 15.85s 22.78r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
108.92u 16.00s 23.02r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
109.25u 15.82s 23.05r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
109.57u 15.96s 23.11r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
109.86u 15.97s 23.17r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
110.50u 16.05s 23.37r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
After this CL:
113.66u 17.00s 24.17r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.85u 0.68s 3.49r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.98u 0.72s 3.63r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
4.07u 0.72s 3.57r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.98u 0.70s 3.43r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
4.58u 0.70s 3.58r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.90u 0.70s 3.46r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.85u 0.71s 3.52r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.70u 0.69s 3.64r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
3.79u 0.68s 3.41r go build -o /tmp/jujud github.com/juju/juju/cmd/jujud ...
This CL reduces the overall all.bash time from 4m22s to 4m17s on my laptop.
Not much faster, but also not slower.
See also #4719, #20137, #20372.
Change-Id: I101d5363f8c55bf4825167a5f6954862739bf000
Reviewed-on: https://go-review.googlesource.com/75473
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The README is there to help people who stumble across the directory.
The access log is there to help us evaluate potential algorithms for
managing and pruning cache directories. For now the management
is manual: users have to run "go clean -cache" if they want the cache
to get smaller.
As a low-resolution version of the access log, we also update the
mtime on each cache file as they are used by the go command.
A simple refinement of go clean -cache would be to delete
(perhaps automatically) cache files that have not been used in more
than one day, or some suitable time period.
Change-Id: I1dd6309952942169d71256c4b50b723583d21fca
Reviewed-on: https://go-review.googlesource.com/75471
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The current GOROOT documentation could indicate that changing the
environment variable at runtime would affect the return value of
GOROOT. This is false as the returned value is the one used for the
build. This CL aims to clarify the confusion.
Fixes#22302
Change-Id: Ib68c30567ac864f152d2da31f001a98531fc9757
Reviewed-on: https://go-review.googlesource.com/75751
Reviewed-by: Russ Cox <rsc@golang.org>
This change applies x86avxgen output.
https://go-review.googlesource.com/c/arch/+/66972
As an effect, many new AVX instructions are now available.
One of the side-effects of this patch is
sorted AXXX (A-enum) constants.
Some AVX1/2 instructions still not added due to:
1. x86.csv V0.2 does not list them;
2. partially because of (1), test suite does not contain tests for
these instructions.
Change-Id: I90430d773974ca5c995d6950d90e2c62ec88ef47
Reviewed-on: https://go-review.googlesource.com/75490
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
BFC (Bit Field Clear) and BFI (Bit Field Insert) were
introduced in ARMv6T2, and the compiler can use them
to do further optimization.
Change-Id: I5a3fbcd2c2400c9bf4b939da6366c854c744c27f
Reviewed-on: https://go-review.googlesource.com/72891
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With GOBUILDTIMELOGFILE set, make.bash logs the starting time using
$ echo $(date) > file
and expects to be able to read the date back with
time.Parse(time.UnixDate)
but in some locales the default date format is not the same as
time.UnixDate; for example on LC_TIME="en_GB.UTF-8"
$ locale date_fmt
%a %e %b %H:%M:%S %Z %Y
Fix this by setting LC_TIME=C before the date command invocation.
Fixes#22541
Change-Id: I59bf944bb868e2acdd816c7e35134780cdbfc6a6
Reviewed-on: https://go-review.googlesource.com/75370
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current code can potentially return a smaller processor count on a
linux kernel when its cpumask_size (controlled by both kernel config and
boot parameter) is not a multiple of the pointer size, because
r/sys.PtrSize will be rounded down. Since sched_getaffinity returns the
size in bytes, we can just allocate the buf as a byte array to avoid the
extra calculation with the pointer size and roundups.
Change-Id: I0c21046012b88d8a56b5dd3dde1d158d94f8eea9
Reviewed-on: https://go-review.googlesource.com/75591
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Instead of trying to validate map key types eagerly in some
cases, delay their validation to the end of type-checking,
when we all type information is present.
Passes go build -toolexec 'toolstash -cmp' -a std .
Fixes#21273.
Fixes#21657.
Change-Id: I532369dc91c6adca1502d6aa456bb06b57e6c7ff
Reviewed-on: https://go-review.googlesource.com/75310
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The godoc for RoundTrip already specifies when it's ok to reuse a
request that contains a body: the caller must wait until RoundTrip
calls Close on Request.Body.
This CL adds a small clarification: If the request does not have a
body, it can be reused as long as the caller does not mutate the
Request until RoundTrip fails or the Response.Body is closed.
Fixes#19653
Change-Id: I56652a9369978d11650e2e6314104831c2ce5e78
Reviewed-on: https://go-review.googlesource.com/75671
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Usage of atomic.Value has a subtle requirement that the
value be of the same concrete type. In prior usage, the intention
was to consistently store a value of the error type.
Since error is an interface, the underlying concrete can differ.
Fix this by creating a type-safe abstraction over atomic.Value
that wraps errors in a struct{error} type to ensure consistent types.
Change-Id: Ica74f2daba15e4cff48d2b4f830d2cb51c608fb6
Reviewed-on: https://go-review.googlesource.com/75594
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation names a c net.Conn return which is
never user. Leaving the returns unamed is marginally clearer.
Change-Id: If9a411c9235b78c116a8ffb21fef71f7a4a4ce8f
Reviewed-on: https://go-review.googlesource.com/66890
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this CL loads with sign extension could not be replaced with
indexed loads (only loads with zero extension).
This CL also prevents large offsets (more than 20-bits) from being
merged into indexed loads. It is better to keep such offsets
separate.
Gives a small improvement in binary size, ~1.5KB from .text in cmd/go.
Change-Id: Ib848ffc2b05de6660c5ce2394ae1d1d144273e29
Reviewed-on: https://go-review.googlesource.com/36845
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
These are likely from the time when gc was written in C. There is no
need for any of these to be passed pointers, as the previous values are
not kept in any way, and the pointers are never nil. Others were left
untouched as they fell into one of these useful cases.
While at it, also turn some 0/1 integers into booleans.
Passes toolstash -cmp on std cmd.
Change-Id: Id3a9c9e84ef89536c4dc69a7fdbacd0fd7a76a9b
Reviewed-on: https://go-review.googlesource.com/72990
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
To improve readability when exported fields are removed,
forbid the printer from emitting an empty line before the first comment
in a const, var, or type block.
Also, when printing the "Has filtered or unexported fields." message,
add an empty line before it to separate the message from the struct
or interfact contents.
Before the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
After the change:
<<<
type NamedArg struct {
// Name is the name of the parameter placeholder.
//
// If empty, the ordinal position in the argument list will be
// used.
//
// Name must omit any symbol prefix.
Name string
// Value is the value of the parameter.
// It may be assigned the same value types as the query
// arguments.
Value interface{}
// contains filtered or unexported fields
}
>>>
Fixes#18264
Change-Id: I9fe17ca39cf92fcdfea55064bd2eaa784ce48c88
Reviewed-on: https://go-review.googlesource.com/71990
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
* Avoid calculating insertk until needed.
* Avoid a pointer into b.tophash and just track the insertion index.
This avoids b.tophash being marked as escaping to heap.
* Calculate val only once at the end of the mapassign functions.
Function sizes decrease slightly, e.g. for mapassign_faststr:
before "".mapassign_faststr STEXT size=1166 args=0x28 locals=0x78
after "".mapassign_faststr STEXT size=1080 args=0x28 locals=0x68
name old time/op new time/op delta
MapAssign/Int32/256-4 19.4ns ± 4% 19.5ns ±11% ~ (p=0.973 n=20+20)
MapAssign/Int32/65536-4 32.5ns ± 2% 32.4ns ± 3% ~ (p=0.078 n=20+19)
MapAssign/Int64/256-4 20.3ns ± 6% 17.6ns ± 5% -13.01% (p=0.000 n=20+20)
MapAssign/Int64/65536-4 33.3ns ± 2% 33.3ns ± 1% ~ (p=0.444 n=20+20)
MapAssign/Str/256-4 22.3ns ± 3% 22.4ns ± 3% ~ (p=0.343 n=20+20)
MapAssign/Str/65536-4 44.9ns ± 1% 43.9ns ± 1% -2.39% (p=0.000 n=20+19)
Change-Id: I2627bb8a961d366d9473b5922fa129176319eb22
Reviewed-on: https://go-review.googlesource.com/74870
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
We already do this for floor/ceil, but RoundToEven was added later.
Intrinsify it also.
name old time/op new time/op delta
RoundToEven-8 3.00ns ± 1% 0.68ns ± 2% -77.34% (p=0.000 n=10+10)
Change-Id: Ib158cbceb436c6725b2d9353a526c5c4be19bcad
Reviewed-on: https://go-review.googlesource.com/74852
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>
The comment on invalid time values in Constants and example
refers to _ zero padding when it should refer to space padding.
Change-Id: I5784356e389d324703e20eec6203f147db92880f
Reviewed-on: https://go-review.googlesource.com/75410
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The ztypes_windows* file names indicate that these are auto-generated
but they aren't. Rename them to types_windows* to avoid this confusion.
This follows CL 52950 which did the same for golang.org/x/sys.
Change-Id: Ia557ec5d4bcfb6bae20e34e71b5f3f190285794f
Reviewed-on: https://go-review.googlesource.com/75390
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The only file that really changed is
x/net/idna (upstream 8253218a).
See CL 73730: avoid memory leak in validation codes
The rest is just a small change in the
generation line at the top.
Change-Id: I62c5172f77f63d919c41d11c6db0a9517bc2a221
Reviewed-on: https://go-review.googlesource.com/74953
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Handle make(map[any]any) and make(map[any]any, hint) where
hint <= BUCKETSIZE special to allow for faster map initialization
and to improve binary size by using runtime calls with fewer arguments.
Given hint is smaller or equal to BUCKETSIZE in which case
overLoadFactor(hint, 0) is false and no buckets would be allocated by makemap:
* If hmap needs to be allocated on the stack then only hmap's hash0
field needs to be initialized and no call to makemap is needed.
* If hmap needs to be allocated on the heap then a new special
makehmap function will allocate hmap and intialize hmap's
hash0 field.
Reduces size of the godoc by ~36kb.
AMD64
name old time/op new time/op delta
NewEmptyMap 16.6ns ± 2% 5.5ns ± 2% -66.72% (p=0.000 n=10+10)
NewSmallMap 64.8ns ± 1% 56.5ns ± 1% -12.75% (p=0.000 n=9+10)
Updates #6853
Change-Id: I624e90da6775afaa061178e95db8aca674f44e9b
Reviewed-on: https://go-review.googlesource.com/61190
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Add support for ADX cpuid bit detection and all instructions,
implied by that bit (ADOX/ADCX). They are useful for rsa and math/big in
general.
Change-Id: Idaa93303ead48fd18b9b3da09b3e79de2f7e2193
Reviewed-on: https://go-review.googlesource.com/74850
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The comment currently implies that a zero will be added, but the
underscore is used to add a space for single-digit dates.
Change-Id: Ib3bac8a16bc2d1fcb26ab3bb7ad172b89e1a4a24
Reviewed-on: https://go-review.googlesource.com/75230
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since CL 33071, testCPUProfile is only one user of the badOS map.
Replace it by the corresponding switch, with the "plan9" case removed
because it is already checked earlier in the same function.
Change-Id: Id647b8ee1fd37516bb702b35b3c9296a4f56b61b
Reviewed-on: https://go-review.googlesource.com/75110
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If GODEBUG=gocacheverify=1, then instead of using the cache to
avoid computations, the go command will do the computations and
double-check that they match any existing cache entries.
This is handled entirely in the cache implementation; there's no
complexity added to any of the cache usage sites.
(As of this CL there aren't any cache usage sites, but soon there will be.)
Also change GOCMDDEBUGHASH to the more usual GODEBUG=gocachehash=1.
Change-Id: I574f181e06b5299b1d9c6d402e40c57a0e064e74
Reviewed-on: https://go-review.googlesource.com/75294
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Use a build cache separate from the default user cache,
one that will be wiped out during startup, so that make.bash
continues to start from a clean slate.
Change-Id: I38733991015c66efb89fc170c71701b1dd9de28d
Reviewed-on: https://go-review.googlesource.com/75291
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This makes ImportDir("$GOROOT/src/math", 0)
and Import("math", "", 0) equivalent. It was an
oversight that they were not before.
An upcoming change to the go command relies on
the two returning the same results.
Change-Id: I187da4830fae85f8dde673c22836ff2da6801047
Reviewed-on: https://go-review.googlesource.com/75290
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The cache is stored in $GOCACHE, which is printed by go env and
defaults to a subdirectory named "go-build" in the standard user cache
directory for the host operating system.
This CL only implements the cache. Future CLs will store data in it.
Change-Id: I0b4965a9e50f852e17e44ec3d6dafe05b58f0d22
Reviewed-on: https://go-review.googlesource.com/68116
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
At the end of type-checking a function or closure, unused local variables
are reported by looking at all variables in the function scope and its
nested children scopes. If a nested scope belonged to a nested function
(closure), that scope would be searched twice, leading to multiple error
messages for unused variables.
This CL introduces an internal-only marker to identify function scopes
so that they can be ignored where needed.
Fixes#22524.
Change-Id: If58cc17b2f0615a16f33ea262f50dffd0e86d0f0
Reviewed-on: https://go-review.googlesource.com/75251
Reviewed-by: Alan Donovan <adonovan@google.com>
Mac OS X 10.13 introduced APFS which stores nanosecond resolution
timestamps. The implementation of os.Stat already returns full
resolution timestamps, but os.Chtimes only sets timestamps with
microsecond resolution.
Fix this by using setattrlist on Darwin, which takes a struct timeval
with nanosecond resolution. This is what Mac OS X 10.13 appears uses
to implement utimensat, according to dtruss.
Fixes#22528
Change-Id: I397dabef6b2b73a081382999aa4c4405ab8c6015
Reviewed-on: https://go-review.googlesource.com/74952
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Whitespace is ignored in bool values and attrs. It is convenient and
relatively safe since whitespace around a bool value is often
unimportant. The same logic can be applied to numeric values of types
int, uint, and float.
Fixes#22146
Change-Id: Ie0462def90304af144b8e2e72d85b644857c27cc
Reviewed-on: https://go-review.googlesource.com/73891
Reviewed-by: Sam Whited <sam@samwhited.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Sam Whited <sam@samwhited.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also replaces verbs for error message from %s to %v. In general, low
level IO APIs return an error value containing non-string types and
there's no guarantee that all the types implement fmt.Stringer
interface.
Change-Id: I8a6e2a80d5c721c772a83b9556bac16556eaa771
Reviewed-on: https://go-review.googlesource.com/73931
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In CL 50510, the Content-Type header started to be set in Redirect when
request method is GET. (Prior to that, it wasn't set at all, which is
what said CL was fixing.) However, according to HTTP specification,
the expected response for a HEAD request is identical to that of a
GET request, but without the response body.
This CL updates the behavior to set the Content-Type header for HEAD
method in addition to GET.
This actually allows a simpler implementation than before. This change
largely reverts CL 50510, and applies the simpler implementation.
Add a test for Content-Type header and body for GET, HEAD requests.
Updates CL 50510.
Change-Id: If33ea3f4bbc5246bb5dc751458004828cfe681b9
Reviewed-on: https://go-review.googlesource.com/65190
Run-TryBot: Dmitri Shuralyov <shurcool@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
It is easy to miss the documentation information that no arguments
in the Notify function means that the Notify will catch all possible signals.
So the example was added with explicit comment above the Notify usage.
Fixes#22257
Change-Id: Ia6a16dd4a419f7c77d89020ca5db85979b5b474e
Reviewed-on: https://go-review.googlesource.com/74730
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The counter part, writeInt in cmd/internal/obj, writes int64s.
So the reader side should also read int64s. This may cause a
larger range of values being accepted, some of which should
not be that large. This is probably ok: for example, for
size/index/length, the very large value (due to corruption)
may be well past the end and causes other errors. And we did
not do much bound check anyway.
One exmaple where this matters is ARM32's object file. For one
type of relocation it encodes the instruction into Reloc.Add
field (which itself may be problematic and worth fix) and the
instruction encoding overflows int32, causing ARM32 object
file being rejected by goobj (and so objdump and nm) before.
Unskip ARM32 object file tests in goobj, nm, and objdump.
Updates #19811.
Change-Id: Ia46c2b68df5f1c5204d6509ceab6416ad6372315
Reviewed-on: https://go-review.googlesource.com/69010
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
An initial draft of the Newton code for Float.Sqrt was structured like
this:
for condition
// do Newton iteration..
prec *= 2
since prec, at the end of the loop, was double the precision used in
the last Newton iteration, the termination condition was set to
2*limit. The code was later rewritten in the form
for condition
prec *= 2
// do Newton iteration..
but condition was not updated, and it's still 2*limit, which is about
double what we actually need, and is triggering the execution of an
additional, and unnecessary, Newton iteration.
This change adjusts the Newton termination condition to the (correct)
value of z.prec, plus 32 guard bits as a safety margin.
name old time/op new time/op delta
FloatSqrt/64-4 798ns ± 3% 802ns ± 3% ~ (p=0.458 n=8+8)
FloatSqrt/128-4 1.65µs ± 1% 1.65µs ± 1% ~ (p=0.290 n=8+8)
FloatSqrt/256-4 3.10µs ± 1% 2.10µs ± 0% -32.32% (p=0.000 n=8+7)
FloatSqrt/1000-4 8.83µs ± 1% 4.91µs ± 2% -44.39% (p=0.000 n=8+8)
FloatSqrt/10000-4 107µs ± 1% 40µs ± 1% -62.68% (p=0.000 n=8+8)
FloatSqrt/100000-4 2.91ms ± 1% 0.96ms ± 1% -67.13% (p=0.000 n=8+8)
FloatSqrt/1000000-4 240ms ± 1% 80ms ± 1% -66.66% (p=0.000 n=8+8)
name old alloc/op new alloc/op delta
FloatSqrt/64-4 416B ± 0% 416B ± 0% ~ (all equal)
FloatSqrt/128-4 720B ± 0% 720B ± 0% ~ (all equal)
FloatSqrt/256-4 1.34kB ± 0% 0.82kB ± 0% -39.29% (p=0.000 n=8+8)
FloatSqrt/1000-4 5.09kB ± 0% 2.50kB ± 0% -50.94% (p=0.000 n=8+8)
FloatSqrt/10000-4 45.9kB ± 0% 23.5kB ± 0% -48.81% (p=0.000 n=8+8)
FloatSqrt/100000-4 533kB ± 0% 251kB ± 0% -52.90% (p=0.000 n=8+8)
FloatSqrt/1000000-4 9.21MB ± 0% 4.61MB ± 0% -49.98% (p=0.000 n=8+8)
name old allocs/op new allocs/op delta
FloatSqrt/64-4 9.00 ± 0% 9.00 ± 0% ~ (all equal)
FloatSqrt/128-4 13.0 ± 0% 13.0 ± 0% ~ (all equal)
FloatSqrt/256-4 15.0 ± 0% 12.0 ± 0% -20.00% (p=0.000 n=8+8)
FloatSqrt/1000-4 24.0 ± 0% 19.0 ± 0% -20.83% (p=0.000 n=8+8)
FloatSqrt/10000-4 40.0 ± 0% 35.0 ± 0% -12.50% (p=0.000 n=8+8)
FloatSqrt/100000-4 66.0 ± 0% 55.0 ± 0% -16.67% (p=0.000 n=8+8)
FloatSqrt/1000000-4 143 ± 0% 122 ± 0% -14.69% (p=0.000 n=8+8)
Change-Id: I4868adb7f8960f2ca20e7792734c2e6211669fc0
Reviewed-on: https://go-review.googlesource.com/75010
Reviewed-by: Robert Griesemer <gri@golang.org>
Recurse into structs/arrays of one element when
assigning names.
Test incorporated into existing end-to-end debugger test,
hand-verified that it fails without this CL.
Fixes#19868
Revives CL 40010
Old-Change-Id: I0266e58af975fb64cfa17922be383b70f0a7ea96
Change-Id: I122ac2375931477769ec8d763607c1ec42d78a7f
Reviewed-on: https://go-review.googlesource.com/71731
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Dsymutil, an utility used on macOS when externally linking executables,
does not support base address selector entries in debug_ranges.
To work around this deficiency this commit removes base address
selectors from debug_ranges and emits instead a list composed only of
compile unit relative addresses.
A new type of relocation is introduced, R_ADDRCUOFF, similar to
R_ADDROFF, that relocates an address to its offset from the low_pc of
the symbol's compile unit.
Fixes#21945
Change-Id: Ie991f9bc1afda2b49ac5d734eb41c37d3a37e554
Reviewed-on: https://go-review.googlesource.com/72371
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
After this CL, "go vet" can be guaranteed to have complete type information
about the packages being checked, even if cgo or swig is in use,
which will in turn make it reasonable for vet checks to insist on type
information. It also fixes vet's understanding of unusual import paths
like relative paths and vendored packages.
For now "go tool vet" will continue to cope without type information,
but the eventual plan is for "go tool vet" to query the go command for
what it needs, and also to be able to query alternate build systems
like bazel. But that's future work.
Fixes#4889.
Fixes#12556 (if not already fixed).
Fixes#15182.
Fixes#16086.
Fixes#17571.
Change-Id: I932626ee7da649b302cd269b82eb6fe5d7b9f0f2
Reviewed-on: https://go-review.googlesource.com/74750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL adds support for accepting package config from
the go command. Paired with CL 74356 this lets us make
sure vet has complete information about package sources.
This fixes many issues (see CL 74356 for the list), including
mishandling of cgo and vendoring.
Change-Id: Ia4a1dce6f9b1b0a8ef5fdf9005a20a8b294969f1
Reviewed-on: https://go-review.googlesource.com/74355
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The check of uintptr(newcap) > maxSliceCap(et.size) in addition
to capmem > _MaxMem is needed to prevent a reproducible overflow
on 32bit architectures.
On 64bit platforms this problem is less likely to occur as allocation
of a sufficiently large array or slice to be append is likely to
already exhaust available memory before the call to append can be made.
Example program that without the fix in this CL does segfault on 386:
type T [1<<27 + 1]int64
var d T
var s []T
func main() {
s = append(s, d, d, d, d)
print(len(s), "\n")
}
Fixes#21586
Change-Id: Ib4185435826ef43df71ba0f789e19f5bf9a347e6
Reviewed-on: https://go-review.googlesource.com/55133
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes 'go install cmd/compile' in one directory produce
a different binary from running it in another directory,
which is problematic for reproducible builds.
Change-Id: If26685d2e45d2695413b472142b49694716575fa
Reviewed-on: https://go-review.googlesource.com/74790
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When a SyntaxError occurs, report the current offset within the stream.
The code already accounted for the offset within the current buffer
being scanned. By including how much data was already scanned, the
current offset can be computed.
Fixes#22478
Change-Id: I91ecd4cad0b85a5c1556bc597f3ee914e769af01
Reviewed-on: https://go-review.googlesource.com/74251
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add a DisallowUnknownFields flag to Decoder.
DisallowUnknownFields causes the Decoder to return an error when
the the decoding destination is a struct and the input contains
object keys which do not match any non-ignored, public field the
destination, including keys whose value is set to null.
Note: this fix has already been worked on in 27231, which seems
to be abandoned. This version is a slightly simpler implementation
and is up to date with the master branch.
Fixes#15314
Change-Id: I987a5857c52018df334f4d1a2360649c44a7175d
Reviewed-on: https://go-review.googlesource.com/74830
Reviewed-by: Joe Tsai <joetsai@google.com>
Run-TryBot: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since Go1.8, different types of GC mark workers were annotated and the
annotation strings were recorded during StartTrace. This change fixes
two issues around the use of traceString from StartTrace here.
1) "failed to parse trace: no consistent ordering of events possible"
This issue is a result of a missing 'batch' event entry. For efficient
tracing, tracer maintains system allocated buffers and once a buffer
is full, it is Flushed out for writing. Moreover, tracing assumes all
the records in the same buffer (batch) are already ordered and implements
more optimization in encoding and defers the completing order
reconstruction till the trace parsing time. Thus, when a Flush happens
and a new buffer is used, the new buffer should contain an event to
indicate the start of a new batch. Before this CL, the batch entry was
written only by traceEvent only when the buffer position is 0 and
wasn't written when flush occurs during traceString.
This CL fixes it by moving the batch entry write to the traceFlush.
2) crash during tracing due to invalid memory access, or during parsing
due to duplicate string entries
This issue is a result of memory allocation during traceString calls.
Execution tracer traces some memory allocation activities. Before this
CL, traceString took the buffer address (*traceBuf) and mutated the buffer.
If memory tracing occurs in the meantime from the same P, the allocation
tracing (traceEvent) will take the same buffer address through the pointer
to the buffer address (**traceBuf), and mutate the buffer.
As a result, one of the followings can happen:
- the allocation record is overwritten by the following trace string
record (data loss)
- if buffer flush occurs during the allocation tracing, traceString
will attempt to write the string record to the old buffer and
eventually causes invalid memory access crash.
- or flush on the same buffer can occur twice (once from the memory
allocation, and once from the string record write), and in this case
the trace can contain the same data twice and the parse will complain
about duplicate string record entries.
This CL fixes the second issue by making the traceString take
**traceBuf (*traceBufPtr).
Change-Id: I24f629758625b38e1916fbfc7d7be6ea210586af
Reviewed-on: https://go-review.googlesource.com/50873
Run-TryBot: Austin Clements <austin@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently, both the background mark worker and the goal GC CPU are
both fixed at 25%. The trigger controller's goal is to achieve the
goal CPU usage, and with the previous commit it can actually achieve
this. But this means there are *no* assists, which sounds ideal but
actually causes problems for the trigger controller. Since the
controller can't lower CPU usage below the background mark worker CPU,
it saturates at the CPU goal and no longer gets feedback, which
translates into higher variability in heap growth.
This commit fixes this by allowing assists 5% CPU beyond the 25% fixed
background mark. This avoids saturating the trigger controller, since
it can now get feedback from both sides of the CPU goal. This leads to
low variability in both CPU usage and heap growth, at the cost of
reintroducing a low rate of mark assists.
We also experimented with 20% background plus 5% assist, but 25%+5%
clearly performed better in benchmarks.
Updates #14951.
Updates #14812.
Updates #18534.
Combined with the previous CL, this significantly improves tail
mutator utilization in the x/bechmarks garbage benchmark. On a sample
trace, it increased the 99.9%ile mutator utilization at 10ms from 26%
to 59%, and at 5ms from 17% to 52%. It reduced the 99.9%ile zero
utilization window from 2ms to 700µs. It also helps the mean mutator
utilization: it increased the 10s mutator utilization from 83% to 94%.
The minimum mutator utilization is also somewhat improved, though
there is still some unknown artifact that causes a miniscule fraction
of mutator assists to take 5--10ms (in fact, there was exactly one
10ms mutator assist in my sample trace).
This has no significant effect on the throughput of the
github.com/dr2chase/bent benchmarks-50.
This has little effect on the go1 benchmarks (and the slight overall
improvement makes up for the slight overall slowdown from the previous
commit):
name old time/op new time/op delta
BinaryTree17-12 2.40s ± 0% 2.41s ± 1% +0.26% (p=0.010 n=18+19)
Fannkuch11-12 2.95s ± 0% 2.93s ± 0% -0.62% (p=0.000 n=18+15)
FmtFprintfEmpty-12 42.2ns ± 0% 42.3ns ± 1% +0.37% (p=0.001 n=15+14)
FmtFprintfString-12 67.9ns ± 2% 67.2ns ± 3% -1.03% (p=0.002 n=20+18)
FmtFprintfInt-12 75.6ns ± 3% 76.8ns ± 2% +1.59% (p=0.000 n=19+17)
FmtFprintfIntInt-12 123ns ± 1% 124ns ± 1% +0.77% (p=0.000 n=17+14)
FmtFprintfPrefixedInt-12 148ns ± 1% 150ns ± 1% +1.28% (p=0.000 n=20+20)
FmtFprintfFloat-12 212ns ± 0% 211ns ± 1% -0.67% (p=0.000 n=16+17)
FmtManyArgs-12 499ns ± 1% 500ns ± 0% +0.23% (p=0.004 n=19+16)
GobDecode-12 6.49ms ± 1% 6.51ms ± 1% +0.32% (p=0.008 n=19+19)
GobEncode-12 5.47ms ± 0% 5.43ms ± 1% -0.68% (p=0.000 n=19+20)
Gzip-12 220ms ± 1% 216ms ± 1% -1.66% (p=0.000 n=20+19)
Gunzip-12 38.8ms ± 0% 38.5ms ± 0% -0.80% (p=0.000 n=19+20)
HTTPClientServer-12 78.5µs ± 1% 78.1µs ± 1% -0.53% (p=0.008 n=20+19)
JSONEncode-12 12.2ms ± 0% 11.9ms ± 0% -2.38% (p=0.000 n=17+19)
JSONDecode-12 52.3ms ± 0% 53.3ms ± 0% +1.84% (p=0.000 n=19+20)
Mandelbrot200-12 3.69ms ± 0% 3.69ms ± 0% -0.19% (p=0.000 n=19+19)
GoParse-12 3.17ms ± 1% 3.19ms ± 1% +0.61% (p=0.000 n=20+20)
RegexpMatchEasy0_32-12 73.7ns ± 0% 73.2ns ± 1% -0.66% (p=0.000 n=17+20)
RegexpMatchEasy0_1K-12 238ns ± 0% 239ns ± 0% +0.32% (p=0.000 n=17+16)
RegexpMatchEasy1_32-12 69.1ns ± 1% 69.2ns ± 1% ~ (p=0.669 n=19+13)
RegexpMatchEasy1_1K-12 365ns ± 1% 367ns ± 1% +0.49% (p=0.000 n=19+19)
RegexpMatchMedium_32-12 104ns ± 1% 105ns ± 1% +1.33% (p=0.000 n=16+20)
RegexpMatchMedium_1K-12 33.6µs ± 3% 34.1µs ± 4% +1.67% (p=0.001 n=20+20)
RegexpMatchHard_32-12 1.67µs ± 1% 1.62µs ± 1% -2.78% (p=0.000 n=18+17)
RegexpMatchHard_1K-12 50.3µs ± 2% 48.7µs ± 1% -3.09% (p=0.000 n=19+18)
Revcomp-12 384ms ± 0% 386ms ± 0% +0.59% (p=0.000 n=19+19)
Template-12 61.1ms ± 1% 60.5ms ± 1% -1.02% (p=0.000 n=19+20)
TimeParse-12 307ns ± 0% 303ns ± 1% -1.23% (p=0.000 n=19+15)
TimeFormat-12 323ns ± 0% 323ns ± 0% -0.12% (p=0.011 n=15+20)
[Geo mean] 47.1µs 47.0µs -0.20%
https://perf.golang.org/search?q=upload:20171030.4
It slightly improve the performance the x/benchmarks:
name old time/op new time/op delta
Garbage/benchmem-MB=1024-12 2.29ms ± 3% 2.22ms ± 2% -2.97% (p=0.000 n=18+18)
Garbage/benchmem-MB=64-12 2.24ms ± 2% 2.21ms ± 2% -1.64% (p=0.000 n=18+18)
HTTP-12 12.6µs ± 1% 12.6µs ± 1% ~ (p=0.690 n=19+17)
JSON-12 11.3ms ± 2% 11.3ms ± 1% ~ (p=0.163 n=17+18)
and fixes some of the heap size bloat caused by the previous commit:
name old peak-RSS-bytes new peak-RSS-bytes delta
Garbage/benchmem-MB=1024-12 1.88G ± 2% 1.77G ± 2% -5.52% (p=0.000 n=20+18)
Garbage/benchmem-MB=64-12 248M ± 8% 226M ± 5% -8.93% (p=0.000 n=20+20)
HTTP-12 47.0M ±27% 47.2M ±12% ~ (p=0.512 n=20+20)
JSON-12 206M ±11% 206M ±10% ~ (p=0.841 n=20+20)
https://perf.golang.org/search?q=upload:20171030.5
Combined with the change to add a soft goal in the previous commit,
the achieves a decent performance improvement on the garbage
benchmark:
name old time/op new time/op delta
Garbage/benchmem-MB=1024-12 2.40ms ± 4% 2.22ms ± 2% -7.40% (p=0.000 n=19+18)
Garbage/benchmem-MB=64-12 2.23ms ± 1% 2.21ms ± 2% -1.06% (p=0.000 n=19+18)
HTTP-12 12.5µs ± 1% 12.6µs ± 1% ~ (p=0.330 n=20+17)
JSON-12 11.1ms ± 1% 11.3ms ± 1% +1.87% (p=0.000 n=16+18)
https://perf.golang.org/search?q=upload:20171030.6
Change-Id: If04ddb57e1e58ef2fb9eec54c290eb4ae4bea121
Reviewed-on: https://go-review.googlesource.com/59971
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, GC pacing is based on a single hard heap limit computed
based on GOGC. In order to achieve this hard limit, assist pacing
makes the conservative assumption that the entire heap is live.
However, in the steady state (with GOGC=100), only half of the heap is
live. As a result, the garbage collector works twice as hard as
necessary and finishes half way between the trigger and the goal.
Since this is a stable state for the trigger controller, this repeats
from cycle to cycle. Matters are even worse if GOGC is higher. For
example, if GOGC=200, only a third of the heap is live in steady
state, so the GC will work three times harder than necessary and
finish only a third of the way between the trigger and the goal.
Since this causes the garbage collector to consume ~50% of the
available CPU during marking instead of the intended 25%, about 25% of
the CPU goes to mutator assists. This high mutator assist cost causes
high mutator latency variability.
This commit improves the situation by separating the heap goal into
two goals: a soft goal and a hard goal. The soft goal is set based on
GOGC, just like the current goal is, and the hard goal is set at a 10%
larger heap than the soft goal. Prior to the soft goal, assist pacing
assumes the heap is in steady state (e.g., only half of it is live).
Between the soft goal and the hard goal, assist pacing switches to the
current conservative assumption that the entire heap is live.
In benchmarks, this nearly eliminates mutator assists. However, since
background marking is fixed at 25% CPU, this causes the trigger
controller to saturate, which leads to somewhat higher variability in
heap size. The next commit will address this.
The lower CPU usage of course leads to longer mark cycles, though
really it means the mark cycles are as long as they should have been
in the first place. This does, however, lead to two potential
down-sides compared to the current pacing policy: 1. the total
overhead of the write barrier is higher because it's enabled more of
the time and 2. the heap size may be larger because there's more
floating garbage. We addressed 1 by significantly improving the
performance of the write barrier in the preceding commits. 2 can be
demonstrated in intense GC benchmarks, but doesn't seem to be a
problem in any real applications.
Updates #14951.
Updates #14812 (fixes?).
Fixes#18534.
This has no significant effect on the throughput of the
github.com/dr2chase/bent benchmarks-50.
This has little overall throughput effect on the go1 benchmarks:
name old time/op new time/op delta
BinaryTree17-12 2.41s ± 0% 2.40s ± 0% -0.22% (p=0.007 n=20+18)
Fannkuch11-12 2.95s ± 0% 2.95s ± 0% +0.07% (p=0.003 n=17+18)
FmtFprintfEmpty-12 41.7ns ± 3% 42.2ns ± 0% +1.17% (p=0.002 n=20+15)
FmtFprintfString-12 66.5ns ± 0% 67.9ns ± 2% +2.16% (p=0.000 n=16+20)
FmtFprintfInt-12 77.6ns ± 2% 75.6ns ± 3% -2.55% (p=0.000 n=19+19)
FmtFprintfIntInt-12 124ns ± 1% 123ns ± 1% -0.98% (p=0.000 n=18+17)
FmtFprintfPrefixedInt-12 151ns ± 1% 148ns ± 1% -1.75% (p=0.000 n=19+20)
FmtFprintfFloat-12 210ns ± 1% 212ns ± 0% +0.75% (p=0.000 n=19+16)
FmtManyArgs-12 501ns ± 1% 499ns ± 1% -0.30% (p=0.041 n=17+19)
GobDecode-12 6.50ms ± 1% 6.49ms ± 1% ~ (p=0.234 n=19+19)
GobEncode-12 5.43ms ± 0% 5.47ms ± 0% +0.75% (p=0.000 n=20+19)
Gzip-12 216ms ± 1% 220ms ± 1% +1.71% (p=0.000 n=19+20)
Gunzip-12 38.6ms ± 0% 38.8ms ± 0% +0.66% (p=0.000 n=18+19)
HTTPClientServer-12 78.1µs ± 1% 78.5µs ± 1% +0.49% (p=0.035 n=20+20)
JSONEncode-12 12.1ms ± 0% 12.2ms ± 0% +1.05% (p=0.000 n=18+17)
JSONDecode-12 53.0ms ± 0% 52.3ms ± 0% -1.27% (p=0.000 n=19+19)
Mandelbrot200-12 3.74ms ± 0% 3.69ms ± 0% -1.17% (p=0.000 n=18+19)
GoParse-12 3.17ms ± 1% 3.17ms ± 1% ~ (p=0.569 n=19+20)
RegexpMatchEasy0_32-12 73.2ns ± 1% 73.7ns ± 0% +0.76% (p=0.000 n=18+17)
RegexpMatchEasy0_1K-12 239ns ± 0% 238ns ± 0% -0.27% (p=0.000 n=13+17)
RegexpMatchEasy1_32-12 69.0ns ± 2% 69.1ns ± 1% ~ (p=0.404 n=19+19)
RegexpMatchEasy1_1K-12 367ns ± 1% 365ns ± 1% -0.60% (p=0.000 n=19+19)
RegexpMatchMedium_32-12 105ns ± 1% 104ns ± 1% -1.24% (p=0.000 n=19+16)
RegexpMatchMedium_1K-12 34.1µs ± 2% 33.6µs ± 3% -1.60% (p=0.000 n=20+20)
RegexpMatchHard_32-12 1.62µs ± 1% 1.67µs ± 1% +2.75% (p=0.000 n=18+18)
RegexpMatchHard_1K-12 48.8µs ± 1% 50.3µs ± 2% +3.07% (p=0.000 n=20+19)
Revcomp-12 386ms ± 0% 384ms ± 0% -0.57% (p=0.000 n=20+19)
Template-12 59.9ms ± 1% 61.1ms ± 1% +2.01% (p=0.000 n=20+19)
TimeParse-12 301ns ± 2% 307ns ± 0% +2.11% (p=0.000 n=20+19)
TimeFormat-12 323ns ± 0% 323ns ± 0% ~ (all samples are equal)
[Geo mean] 47.0µs 47.1µs +0.23%
https://perf.golang.org/search?q=upload:20171030.1
Likewise, the throughput effect on the x/benchmarks is minimal (and
reasonably positive on the garbage benchmark with a large heap):
name old time/op new time/op delta
Garbage/benchmem-MB=1024-12 2.40ms ± 4% 2.29ms ± 3% -4.57% (p=0.000 n=19+18)
Garbage/benchmem-MB=64-12 2.23ms ± 1% 2.24ms ± 2% +0.59% (p=0.016 n=19+18)
HTTP-12 12.5µs ± 1% 12.6µs ± 1% ~ (p=0.326 n=20+19)
JSON-12 11.1ms ± 1% 11.3ms ± 2% +2.15% (p=0.000 n=16+17)
It does increase the heap size of the garbage benchmarks, but seems to
have relatively little impact on more realistic programs. Also, we'll
gain some of this back with the next commit.
name old peak-RSS-bytes new peak-RSS-bytes delta
Garbage/benchmem-MB=1024-12 1.21G ± 1% 1.88G ± 2% +55.59% (p=0.000 n=19+20)
Garbage/benchmem-MB=64-12 168M ± 3% 248M ± 8% +48.08% (p=0.000 n=18+20)
HTTP-12 45.6M ± 9% 47.0M ±27% ~ (p=0.925 n=20+20)
JSON-12 193M ±11% 206M ±11% +7.06% (p=0.001 n=20+20)
https://perf.golang.org/search?q=upload:20171030.2
Change-Id: Ic78904135f832b4d64056cbe734ab979f5ad9736
Reviewed-on: https://go-review.googlesource.com/59970
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Previously some of the AuxInt are uint32, which may not fit into
int32. This CL convert them to int32. This does not change the
generated code, but make ssacheck happy.
Pass "toolstash -cmp" for std cmd on ARM.
Fixes#22499.
Change-Id: Ib072d3c14962388bfeb0766c861995d00b4fa7c4
Reviewed-on: https://go-review.googlesource.com/74770
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
All of these had a return or break in the else body, so flipping the
condition means we can unindent and simplify.
Change-Id: If93e97504480d18a0dac3f2c8ffe57ab8bcb929c
Reviewed-on: https://go-review.googlesource.com/74190
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, anytime we exported a function or method declaration
(which includes methods for every type transitively exported), we
included the inline function bodies, if any. However, in many cases,
it's impossible (or at least very unlikely) for the importing package
to call the method.
For example:
package p
type T int
func (t T) M() { t.u() }
func (t T) u() {}
func (t T) v() {}
T.M and T.u are inlineable, and they're both reachable through calls
to T.M, which is exported. However, t.v is also inlineable, but cannot
be reached.
Exception: if p.T is embedded in another type q.U, p.T.v will be
promoted to q.U.v, and the generated wrapper function could have
inlined the call to p.T.v. However, in practice, this doesn't happen,
and a missed inlining opportunity doesn't affect correctness.
To implement this, this CL introduces an extra flood fill pass before
exporting to mark inline bodies that are actually reachable, so the
exporter can skip over methods like t.v.
This reduces Kubernetes build time (as measured by "time go build -a
k8s.io/kubernetes/cmd/...") on an HP Z620 measurably:
== before ==
real 0m44.658s
user 11m19.136s
sys 0m53.844s
== after ==
real 0m41.702s
user 10m29.732s
sys 0m50.908s
It also significantly cuts down the cost of enabling mid-stack
inlining (-l=4):
== before (-l=4) ==
real 1m19.236s
user 20m6.528s
sys 1m17.328s
== after (-l=4) ==
real 0m59.100s
user 13m12.808s
sys 0m58.776s
Updates #19348.
Change-Id: Iade58233ca42af823a1630517a53848b5d3c7a7e
Reviewed-on: https://go-review.googlesource.com/74110
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The test was skipped because it did not work on AMD64 with
frame pointer enabled, and accidentally skipped on other
architectures. Now frame pointer is the default on AMD64.
Update the test to work with frame pointer. Now the test
is skipped only when frame pointer is NOT enabled on AMD64.
Fixes#18317.
Change-Id: I724cb6874e562f16e67ce5f389a1d032a2003115
Reviewed-on: https://go-review.googlesource.com/68610
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Since copy function can figure out how many bytes of data to copy when
two slices have different length, it is not necessary to check how many
bytes need to copy each time before copying the data.
Change-Id: I5151ddfe46af5575566fe9c9a2648e111575ec3d
Reviewed-on: https://go-review.googlesource.com/71090
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On PPC64 (and a few other architectures), accessing global
requires multiple instructions and use of temp register.
The compiler emits a single MOV prog, and the assembler
expands it to multiple instructions. If globals are accessed
multiple times, each time it generates a reload of the temp
register. As this is done by the assembler, the compiler
cannot optimize it.
This CL makes the compiler not fold address of global into load
and store. If a global is accessed multiple times, or multiple
fields of a struct are accessed, the compiler can CSE the
address. Currently, this doesn't help the case where different
globals are accessed, even though they may be close to each
other in the address space (which we don't know at compile time).
It helps a little bit in go1 benchmark:
name old time/op new time/op delta
BinaryTree17-2 4.84s ± 1% 4.84s ± 1% ~ (p=0.796 n=10+10)
Fannkuch11-2 4.10s ± 0% 4.08s ± 0% -0.58% (p=0.000 n=9+8)
FmtFprintfEmpty-2 97.9ns ± 1% 96.8ns ± 1% -1.08% (p=0.000 n=10+10)
FmtFprintfString-2 147ns ± 0% 147ns ± 1% ~ (p=0.129 n=9+10)
FmtFprintfInt-2 152ns ± 0% 152ns ± 0% ~ (p=0.294 n=10+8)
FmtFprintfIntInt-2 218ns ± 1% 217ns ± 0% -0.64% (p=0.000 n=10+8)
FmtFprintfPrefixedInt-2 263ns ± 1% 256ns ± 0% -2.77% (p=0.000 n=10+8)
FmtFprintfFloat-2 375ns ± 1% 368ns ± 0% -1.95% (p=0.000 n=10+7)
FmtManyArgs-2 849ns ± 0% 850ns ± 0% ~ (p=0.621 n=8+9)
GobDecode-2 12.3ms ± 1% 12.2ms ± 1% -0.94% (p=0.003 n=10+10)
GobEncode-2 10.3ms ± 1% 10.5ms ± 1% +2.03% (p=0.000 n=10+10)
Gzip-2 414ms ± 1% 414ms ± 0% ~ (p=0.842 n=9+10)
Gunzip-2 66.3ms ± 0% 66.4ms ± 0% ~ (p=0.077 n=9+9)
HTTPClientServer-2 66.3µs ± 5% 66.4µs ± 1% ~ (p=0.661 n=10+9)
JSONEncode-2 23.9ms ± 1% 23.9ms ± 1% ~ (p=0.905 n=10+9)
JSONDecode-2 119ms ± 1% 116ms ± 0% -2.65% (p=0.000 n=10+10)
Mandelbrot200-2 5.11ms ± 0% 4.92ms ± 0% -3.71% (p=0.000 n=10+10)
GoParse-2 5.81ms ± 1% 5.84ms ± 1% ~ (p=0.052 n=10+10)
RegexpMatchEasy0_32-2 315ns ± 0% 317ns ± 0% +0.67% (p=0.000 n=10+10)
RegexpMatchEasy0_1K-2 658ns ± 0% 638ns ± 0% -3.01% (p=0.000 n=9+9)
RegexpMatchEasy1_32-2 315ns ± 1% 317ns ± 0% +0.56% (p=0.000 n=9+9)
RegexpMatchEasy1_1K-2 935ns ± 0% 926ns ± 0% -0.96% (p=0.000 n=9+9)
RegexpMatchMedium_32-2 394ns ± 0% 396ns ± 1% +0.46% (p=0.001 n=10+10)
RegexpMatchMedium_1K-2 65.1µs ± 0% 64.5µs ± 0% -0.90% (p=0.000 n=9+9)
RegexpMatchHard_32-2 3.16µs ± 0% 3.17µs ± 0% +0.35% (p=0.000 n=10+9)
RegexpMatchHard_1K-2 89.4µs ± 0% 89.3µs ± 0% ~ (p=0.136 n=9+9)
Revcomp-2 703ms ± 2% 694ms ± 2% -1.41% (p=0.009 n=10+10)
Template-2 107ms ± 1% 107ms ± 1% ~ (p=0.053 n=9+10)
TimeParse-2 526ns ± 0% 524ns ± 0% -0.34% (p=0.002 n=9+9)
TimeFormat-2 534ns ± 0% 504ns ± 1% -5.51% (p=0.000 n=10+10)
[Geo mean] 93.8µs 93.1µs -0.70%
It also helps in the case mentioned in issue #17110, main.main
in package math's test. Now it generates 4 loads of R31 instead
of 10, for the same piece of code.
This causes a slight increase of binary size: cmd/go increases
0.66%.
If this is a good idea, we should do it on other architectures
where accessing global is expensive.
Updates #17110.
Change-Id: I2687af6eafc04f2a57c19781ec300c33567094b6
Reviewed-on: https://go-review.googlesource.com/68250
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The new RoundToEven function can be implemented as a single FIDBR
instruction on s390x.
name old time/op new time/op delta
RoundToEven 5.32ns ± 1% 0.86ns ± 1% -83.86% (p=0.000 n=10+10)
Change-Id: Iaf597e57a0d1085961701e3c75ff4f6f6dcebb5f
Reviewed-on: https://go-review.googlesource.com/74350
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Noted in CL 73212 review by crawshaw.
Neglected to update CL 73212 before submitting.
Also fix printing of target goos/goarch for cross-compile build.
Change-Id: If702f23071a4456810f1de6abb9115b38933c5c1
Reviewed-on: https://go-review.googlesource.com/74631
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Every time I see an error that begins `missing argument for Fprintf("%s")`
my mental type-checker goes off, since obviously "%s" is not a valid first
argument to Fprintf. Writing Printf("%s") to report an error in Printf("hello %s")
is almost as confusing.
This CL rewords the errors reported by vet's printf check to be more
consistent with each other, avoid placing context like "in printf call"
in the middle of the message, and to avoid the imprecisions above by
not quoting the format string at all.
Before:
bad.go:9: no formatting directive in Printf call
bad.go:10: missing argument for Printf("%s"): format reads arg 1, have only 0 args
bad.go:11: wrong number of args for format in Printf call: 1 needed but 2 args
bad.go:12: bad syntax for printf argument index: [1]
bad.go:13: index value [0] for Printf("%[0]s"); indexes start at 1
bad.go:14: missing argument for Printf("%[2]s"): format reads arg 2, have only 1 args
bad.go:15: bad syntax for printf argument index: [abc]
bad.go:16: unrecognized printf verb 'z'
bad.go:17: arg "hello" for * in printf format not of type int
bad.go:18: arg fmt.Sprint in printf call is a function value, not a function call
bad.go:19: arg fmt.Sprint in Print call is a function value, not a function call
bad.go:20: arg "world" for printf verb %d of wrong type: string
bad.go:21: missing argument for Printf("%q"): format reads arg 2, have only 1 args
bad.go:22: first argument to Print is os.Stderr
bad.go:23: Println call ends with newline
bad.go:32: arg r in Sprint call causes recursive call to String method
bad.go:34: arg r for printf causes recursive call to String method
After:
bad.go:9: Printf call has arguments but no formatting directives
bad.go:10: Printf format %s reads arg #1, but have only 0 args
bad.go:11: Printf call needs 1 args but has 2 args
bad.go:12: Printf format %[1 is missing closing ]
bad.go:13: Printf format has invalid argument index [0]
bad.go:14: Printf format has invalid argument index [2]
bad.go:15: Printf format has invalid argument index [abc]
bad.go:16: Printf format %.234z has unknown verb z
bad.go:17: Printf format %.*s uses non-int "hello" as argument of *
bad.go:18: Printf format %s arg fmt.Sprint is a func value, not called
bad.go:19: Print arg fmt.Sprint is a func value, not called
bad.go:20: Printf format %d has arg "world" of wrong type string
bad.go:21: Printf format %q reads arg #2, but have only 1 args
bad.go:22: Print does not take io.Writer but has first arg os.Stderr
bad.go:23: Println args end with redundant newline
bad.go:32: Sprint arg r causes recursive call to String method
bad.go:34: Sprintf format %s with arg r causes recursive String method call
Change-Id: I5719f0fb9f2cd84df8ad4c7754ab9b79c691b060
Reviewed-on: https://go-review.googlesource.com/74352
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The support in this CL assumes that something at a higher level than
the toolchain-specific importers is taking care of converting imports
in source code into canonical import paths before invoking the
toolchain-specific importers. That kind of "what does an import mean"
as opposed to "find me the import data for this specific path"
should be provided by higher-level layers.
That's a different layering than the default behavior but matches the
current layering in the compiler and linker and works with the metadata
planned for generation by the go command for package management.
It should also eventually allow the importer code to stop concerning
itself with source directories and vendor import translation and maybe
deprecate ImporterFrom in favor of Importer once again. But that's all
in the future. For now, just make non-nil lookups work, and test that.
Fixes#13847.
Adds #22550.
Change-Id: I048c6a384492e634988a7317942667689ae680ff
Reviewed-on: https://go-review.googlesource.com/74354
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #9346#22135 explicitly state under layout constants
that they are not valid time values for Parse. Also add
examples of parsing valid RFC3339 values and the layout
to the example for time.Parse.
Fix capitalisation of time.Parse and Time.Format.
For #20869 include RFC3339 in the list of layouts that do
not accept all the time formats allowed by RFCs (lowercase z).
This does not fully address #20869.
Fixes#9346Fixes#22135
Change-Id: Ia4c13e5745de583db5ef7d5b1688d7768bc42c1b
Reviewed-on: https://go-review.googlesource.com/74231
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The compiler's instrumentation pass has some out-of-date comments
about the write barrier and some confusing comments about
typedslicecopy. Update these comments and add a comment to
typedslicecopy explaining why it's manually instrumented while none of
the other operations are.
Change-Id: I024e5361d53f1c3c122db0c85155368a30cabd6b
Reviewed-on: https://go-review.googlesource.com/74430
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When run `go doc -u http.connectMethod`, the whole table is treated as
a single long line. This commit inserts `\t` at the begining of each line,
so the table can be displayed properly in `go doc`.
Change-Id: I6408efd31f84c113e81167d62e1791643000d629
Reviewed-on: https://go-review.googlesource.com/74651
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Hide in the source code instead of in the separate whitelist.
Removes the only printf false positive in the standard library.
Change-Id: I99285e67588c7c93bd56d59ee768a03be7c301e7
Reviewed-on: https://go-review.googlesource.com/74590
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The httpresponse.go module wants to be able to tell if a particular type t
is net/http.Response (and also net/http.Client). It does this by importing
net/http, looking up Response, and then comparing that saved type against
each t.
Instead of doing an eager import of net/http, wait until we have a type t
to ask a question about, and then just look to see if that t is http.Response.
This kind of lazy check does not require assuming that net/http is available
or will be important (perhaps the check is disabled in this run, or perhaps
other conditions that lead to the comparison are not satisfied).
Not loading these kinds of types at startup time will scale better.
Change-Id: Ibb00623901a96e725a4ff6f231e6d15127979dfd
Reviewed-on: https://go-review.googlesource.com/74353
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The signal-to-noise ratio is too low.
Stop printing the name of every package.
Can still get the old output with make.bash -v.
Change-Id: Ib2c82e037166e6d2ddc31ae2a4d29af5becce574
Reviewed-on: https://go-review.googlesource.com/74351
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This cuts 6 seconds off all.bash with the new go command.
Not a ton, but also an easy 6 seconds to grab.
The -tags=use_go_run in the misc/cgo tests is just some
go command flag that will make run.go use go run,
but without making everything look stale.
(Those tests have relative imports,
so go tool compile+link is not enough.)
Change-Id: I43bf4bb661d3adde2b2d4aad5e8f64b97bc69ba9
Reviewed-on: https://go-review.googlesource.com/73994
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The content-based staleness code means that
go run -gcflags=-l helloworld.go
recompiles all of helloworld.go's dependencies with -gcflags=-l,
whereas before it would have assumed installed packages were
up-to-date. In this test, that means every race iteration rebuilds
the runtime and maybe a few other packages. Instead, install them
to a temporary location for reuse.
This speeds the test from 17s to 9s on my MacBook Pro.
Change-Id: Ied136ce72650261083bb19cc7dee38dac0ad05ca
Reviewed-on: https://go-review.googlesource.com/73992
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We can't make all.bash faster if we can't measure it.
Measure it.
Change-Id: Ia5da791d4cfbfa1fd9a8e905b3188f63819ade73
Reviewed-on: https://go-review.googlesource.com/73990
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL changes the go command to base all its rebuilding decisions
on the content of the files being processed and not their file system
modification times. It also eliminates the special handling of release
toolchains, which were previously considered always up-to-date
because modification time order could not be trusted when unpacking
a pre-built release.
The go command previously tracked "build IDs" as a backup to
modification times, to catch changes not reflected in modification times.
For example, if you remove one .go file in a package with multiple .go
files, there is no modification time remaining in the system that indicates
that the installed package is out of date. The old build ID was the hash
of a list of file names and a few other factors, expected to change if
those factors changed.
This CL moves to using this kind of build ID as the only way to
detect staleness, making sure that the build ID hash includes all
possible factors that need to influence the rebuild decision.
One such factor is the compiler flags. As of this CL, if you run
go build -gcflags -N cmd/gofmt
you will get a gofmt where every package is built with -N,
regardless of what may or may not be installed already.
Another such factor is the linker flags. As of this CL, if you run
go install myprog
go install -ldflags=-s myprog
the second go install will now correctly build a new myprog with
the updated linker flags. (Previously the installed myprog appeared
up-to-date, because the ldflags were not included in the build ID.)
Because we have more precise information we can also validate whether
the target of a "go test -c" operation is already the right binary and
therefore can avoid a rebuild.
This CL sets us up for having a more general build artifact cache,
maybe even a step toward not having a pkg directory with .a files,
but this CL does not take that step. For now the result of go install
is the same as it ever was; we just do a better job of what needs to
be installed.
This CL does slow down builds a small amount by reading all the
dependent source files in full. (The go command already read the
beginning of every dependent source file to discover build tags
and imports.) On my MacBook Pro, before this CL all.bash takes
3m58s, while after this CL and a few optimizations stacked above it
all.bash takes 4m28s. Given that CL 73850 cut 1m43s off the all.bash
time earlier today, we can afford adding 30s back for now.
More optimizations are planned that should make the go command
more efficient than it was even before this CL.
Fixes#15799.
Fixes#18369.
Fixes#19340.
Fixes#21477.
Change-Id: I10d7ca0e31ca3f58aabb9b1f11e2e3d9d18f0bc9
Reviewed-on: https://go-review.googlesource.com/73212
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In the new content-based staleness world, setting -gcflags like this
recompiles all the packages involved in running the program, not just
the "stale" ones. So go run -gcflags=-d=ssa/check/on recompiles
runtime with those flags too, which is not what the test is trying
to check.
Change-Id: I4dbd5bf2970c3a622c01de84bd8aa9d5e9ec5239
Reviewed-on: https://go-review.googlesource.com/74570
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If the go install doesn't use the same flags as the main build
it can overwrite the installed standard library, leading to
flakiness and slow future tests.
Force uses of 'go install' etc to propagate $GO_GCFLAGS
or disable them entirely, to avoid problems.
As I understand it, the main place this happens is the ssacheck builder.
If there are other uses that need to run some of the now-disabled
tests we can reenable fixed tests in followup CLs.
Change-Id: Ib860a253539f402f8a96a3c00ec34f0bbf137c9a
Reviewed-on: https://go-review.googlesource.com/74470
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Allows code that operates on a FlagSet to know the name and error
handling behavior of the FlagSet without having to call FlagSet.Init.
Fixes#17628Fixes#21888
Change-Id: Ib0fe4c8885f9ccdacf5a7fb761d5ecb23f3bb055
Reviewed-on: https://go-review.googlesource.com/70391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Len method is a linear operation. CL 73090 used Len to iterate over
a ring, resulting in a quadratic time operation.
Change-Id: Ib69c19190ba648311e6c345d8cb26292b50121ee
Reviewed-on: https://go-review.googlesource.com/74390
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adds the following s390x test under mask (immediate) instructions:
TMHH
TMHL
TMLH
TMLL
These are useful for testing bits and are already used in the math package.
Change-Id: Idffb3f83b238dba76ac1e42ac6b0bf7f1d11bea2
Reviewed-on: https://go-review.googlesource.com/41092
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This change adds three new instructions:
- LPDFR: load positive (math.Abs(x))
- LNDFR: load negative (-math.Abs(x))
- CPSDR: copy sign (math.Copysign(x, y))
By making use of GPR <-> FPR moves we can now compile math.Abs and
math.Copysign to these instructions using SSA rules.
This CL also adds new rules to merge address generation into combined
load operations. This makes GPR <-> FPR move matching more reliable.
name old time/op new time/op delta
Copysign 1.85ns ± 0% 1.40ns ± 1% -24.65% (p=0.000 n=8+10)
Abs 1.58ns ± 1% 0.73ns ± 1% -53.64% (p=0.000 n=10+10)
The geo mean improvement for all math package benchmarks was 4.6%.
Change-Id: I0cec35c5c1b3fb45243bf666b56b57faca981bc9
Reviewed-on: https://go-review.googlesource.com/73950
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
When compiling a package that defines a type T with method T.M, we
already compile and emit the wrapper method (*T).M. There's no need
for every package that uses T to do the same.
Change-Id: I3ca2659029907570f8b98d66111686435fad7ed0
Reviewed-on: https://go-review.googlesource.com/74412
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When doing resolvePath, if there are multiple leading slashes in the
target, preserve them. This prevents an issue where the Go http.Client
cleans up multiple leading slashes in the Location header in a
redirect, resulting in a redirection to the incorrect target.
Fixes#21158.
Change-Id: I6a21ea61ca3bc7033f3c8a6ccc21ecaa3e996fa8
Reviewed-on: https://go-review.googlesource.com/51050
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
The test for #18902 reads the assembly stream to be sure
that the line number does not change too often (this is an
indication that debugging the code will be unpleasant and
that the compiler is probably getting line numbers "wrong").
It checks that it is getting "enough" input, but the
compiler has gotten enough better since the test was written
that it now fails for lack of enough input. The old
threshould was 200 instructions, the new one is 150 (the
minimum observed input is on arm64 with 184 instructions).
Fixes#22494.
Change-Id: Ibba7e9ff4ab6a7be369e5dd5859d150b7db94653
Reviewed-on: https://go-review.googlesource.com/74357
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
KeepAlive needs to introduce a use of the spill of the
value it is keeping alive. Without that, we don't guarantee
that the spill dominates the KeepAlive.
This bug was probably introduced with the code to move spills
down to the dominator of the restores, instead of always spilling
just after the value itself (CL 34822).
Fixes#22458.
Change-Id: I94955a21960448ffdacc4df775fe1213967b1d4c
Reviewed-on: https://go-review.googlesource.com/74210
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
If the compiler has a non-devel version it will report that version
to the go command for use as the "compiler ID" instead of using
the content ID of the binary. This in turn allows the go command
to see the compiled-for-amd64 arm compiler and the compiled-for-arm
arm compiler as having the same ID, so that packages cross-compiled
from amd64 look up-to-date when copied to the arm system
during the linux-arm buildlets and trybots.
Change-Id: I76cbf129303941f8e31bdb100e263478159ddaa5
Reviewed-on: https://go-review.googlesource.com/74360
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
By calculating dim directly, rather than calling max, we can simplify
the generated code significantly. The compiler now reports that dim
is easily inlineable, but it can't be inlined because there is still
an assembly stub for Dim.
Since dim is now very simple I no longer think it is worth having
assembly implementations of it. I have therefore removed the s390x
assembly. Removing the other assembly for Dim is #21913.
name old time/op new time/op delta
Dim 4.29ns ± 0% 3.53ns ± 0% -17.62% (p=0.000 n=9+8)
Change-Id: Ic38a6b51603cbc661dcdb868ecf2b1947e9f399e
Reviewed-on: https://go-review.googlesource.com/64194
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This modifies bulkBarrierPreWrite to use the buffered write barrier
instead of the eager write barrier. This reduces the number of system
stack switches and sanity checks by a factor of the buffer size
(currently 256). This affects both typedmemmove and typedmemclr.
Since this is purely a runtime change, it applies to all arches
(unlike the pointer write barrier).
name old time/op new time/op delta
BulkWriteBarrier-12 7.33ns ± 6% 4.46ns ± 9% -39.10% (p=0.000 n=20+19)
Updates #22460.
Change-Id: I6a686a63bbf08be02b9b97250e37163c5a90cdd8
Reviewed-on: https://go-review.googlesource.com/73832
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, typedslicecopy meticulously performs a typedmemmove on
every element of the slice. This probably used to be necessary because
we only had an individual element's type, but now we use the heap
bitmap, so we only need to know whether the type has any pointers and
how big it is. Hence, this CL rewrites typedslicecopy to simply
perform one bulk barrier and one memmove.
This also has a side-effect of eliminating two unnecessary write
barriers per slice element that were coming from updates to dstp and
srcp, which were stored in the parent stack frame. However, most of
the win comes from eliminating the loops.
name old time/op new time/op delta
BulkWriteBarrier-12 7.83ns ±10% 7.33ns ± 6% -6.45% (p=0.000 n=20+20)
Updates #22460.
Change-Id: Id3450e9f36cc8e0892f268319b136f0d8f5464b8
Reviewed-on: https://go-review.googlesource.com/73831
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This implements runtime support for buffered write barriers on amd64.
The buffered write barrier has a fast path that simply enqueues
pointers in a per-P buffer. Unlike the current write barrier, this
fast path is *not* a normal Go call and does not require the compiler
to spill general-purpose registers or put arguments on the stack. When
the buffer fills up, the write barrier takes the slow path, which
spills all general purpose registers and flushes the buffer. We don't
allow safe-points or stack splits while this frame is active, so it
doesn't matter that we have no type information for the spilled
registers in this frame.
One minor complication is cgocheck=2 mode, which uses the write
barrier to detect Go pointers being written to non-Go memory. We
obviously can't buffer this, so instead we set the buffer to its
minimum size, forcing the write barrier into the slow path on every
call. For this specific case, we pass additional information as
arguments to the flush function. This also requires enabling the cgo
write barrier slightly later during runtime initialization, after Ps
(and the per-P write barrier buffers) have been initialized.
The code in this CL is not yet active. The next CL will modify the
compiler to generate calls to the new write barrier.
This reduces the average cost of the write barrier by roughly a factor
of 4, which will pay for the cost of having it enabled more of the
time after we make the GC pacer less aggressive. (Benchmarks will be
in the next CL.)
Updates #14951.
Updates #22460.
Change-Id: I396b5b0e2c5e5c4acfd761a3235fd15abadc6cb1
Reviewed-on: https://go-review.googlesource.com/73711
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently systemstack always calls its argument, even if we're already
on the system stack. Unfortunately, traceback with _TraceJump stops at
the first systemstack it sees, which often cuts off runtime stacks
early in profiles.
Fix this by performing a tail call if we're already on the system
stack. This eliminates it from the traceback entirely, so it won't
stop prematurely (or all get mushed into a single node in the profile
graph).
Change-Id: Ibc69e8765e899f8d3806078517b8c7314da196f4
Reviewed-on: https://go-review.googlesource.com/74050
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This adds support for math Abs, Copysign to be instrinsics on ppc64x.
New instruction FCPSGN is added to generate fcpsgn. Some new
rules are added to improve the int<->float conversions that are
generated mainly due to the Float64bits and Float64frombits in
the math package. PPC64.rules is also modified as suggested
in the review for CL 63290.
Improvements:
benchmark old ns/op new ns/op delta
BenchmarkAbs-16 1.12 0.69 -38.39%
BenchmarkCopysign-16 1.30 0.93 -28.46%
BenchmarkNextafter32-16 9.34 8.05 -13.81%
BenchmarkFrexp-16 8.81 7.60 -13.73%
Others that used Copysign also saw smaller improvements.
I attempted to make this work using rules since that
seems to be preferred, but due to the use of Float64bits and
Float64frombits in these functions, several rules had to be added and
even then not all cases were matched. Using rules became too
complicated and seemed too fragile for these.
Updates #21390
Change-Id: Ia265da9a18355e08000818a4fba1a40e9e031995
Reviewed-on: https://go-review.googlesource.com/67130
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Errors occur in runtime test testCgoPprofPIE when the test
is built by passing -pie to the external linker with code
that was not built as PIC. This occurs on ppc64le because
non-PIC is the default, and fails only on newer distros
where the address range used for programs is high enough
to cause relocation overflow. This test should be built
with -buildmode=pie since that correctly generates PIC
with -pie.
Related issues are #21954 and #22126.
Updates #22459
Change-Id: Ib641440bc9f94ad2b97efcda14a4b482647be8f7
Reviewed-on: https://go-review.googlesource.com/73970
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This pragma is not actually honored by the compiler.
The tests implicitly relied on the inliner being unable
to inline closures with captured variables, which will
soon change.
Fixes#22208
Change-Id: I13abc9c930b9156d43ec216f8efb768952a29439
Reviewed-on: https://go-review.googlesource.com/73211
Reviewed-by: Michael Munday <mike.munday@ibm.com>
If runtime.GOROOT() and the os.Executable method for finding GOROOT
find the same directory but with different spellings, prefer the spelling
returned by runtime.GOROOT().
This avoids an inconsistency if "pwd" returns one spelling but a
different spelling is used in $PATH (and therefore in os.Executable()).
make.bash runs with GOROOT=$(cd .. && pwd); the goal is to allow
the resulting toolchain to use that default setting (unless moved)
even if the directory spelling is different in $PATH.
Change-Id: If96b28b9e8697f4888f153a400b40bbf58a9128b
Reviewed-on: https://go-review.googlesource.com/74250
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
recordspan has two remaining write barriers from writing to the
pointer to the backing store of h.allspans. However, h.allspans is
always backed by off-heap memory, so let the compiler know this.
Unfortunately, this isn't quite as clean as most go:notinheap uses
because we can't directly name the backing store of a slice, but we
can get it done with some judicious casting.
For #22460.
Change-Id: I296f92fa41cf2cb6ae572b35749af23967533877
Reviewed-on: https://go-review.googlesource.com/73414
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently copy and append for types containing only scalars and
notinheap pointers still get compiled to have write barriers, even
though those write barriers are unnecessary. Fix these to use
HasHeapPointer instead of just Haspointer so that they elide write
barriers when possible.
This fixes the unnecessary write barrier in runtime.recordspan when it
grows the h.allspans slice. This is important because recordspan gets
called (*very* indirectly) from (*gcWork).tryGet, which is
go:nowritebarrierrec. Unfortunately, the compiler's analysis has no
hope of seeing this because it goes through the indirect call
fixalloc.first, but I saw it happen.
Change-Id: Ieba3abc555a45f573705eab780debcfe5c4f5dd1
Reviewed-on: https://go-review.googlesource.com/73413
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently (*Type).HasHeapPointer only ignores pointers go:notinheap
types if the type itself is a pointer to a go:notinheap type. However,
if it's some other type that contains pointers where all of those
pointers are go:notinheap, it will conservatively return true. As a
result, we'll use write barriers where they aren't needed, for example
calling typedmemmove instead of just memmove on structs that contain
only go:notinheap pointers.
Fix this by making HasHeapPointer walk the whole type looking for
pointers that aren't marked go:notinheap.
Change-Id: Ib8c6abf6f7a20f34969d1d402c5498e0b990be59
Reviewed-on: https://go-review.googlesource.com/73412
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Most write barrier calls are inserted by SSA, but copy and append are
lowered to runtime.typedslicecopy during walk. Fix these to set
Func.WBPos and emit the "write barrier" warning, as done for the write
barriers inserted by SSA. As part of this, we refactor setting WBPos
and emitting this warning into the frontend so it can be shared by
both walk and SSA.
Change-Id: I5fe9997d9bdb55e03e01dd58aee28908c35f606b
Reviewed-on: https://go-review.googlesource.com/73411
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The crypto.Signer interface takes pre-hased messages for ECDSA and RSA,
but the argument in the implementations was called “msg”, not “digest”,
which is confusing.
This change renames them to help clarify the intended use.
Change-Id: Ie2fb8753ca5280e493810d211c7c66223f94af88
Reviewed-on: https://go-review.googlesource.com/70950
Reviewed-by: Filippo Valsorda <hi@filippo.io>
The current go:nowritebarrierrec checker has two problems that limit
its coverage:
1. It doesn't understand that systemstack calls its argument, which
means there are several cases where we fail to detect prohibited write
barriers.
2. It only observes calls in the AST, so calls constructed during
lowering by SSA aren't followed.
This CL completely rewrites this checker to address these issues.
The current checker runs entirely after walk and uses visitBottomUp,
which introduces several problems for checking across systemstack.
First, visitBottomUp itself doesn't understand systemstack calls, so
the callee may be ordered after the caller, causing the checker to
fail to propagate constraints. Second, many systemstack calls are
passed a closure, which is quite difficult to resolve back to the
function definition after transformclosure and walk have run. Third,
visitBottomUp works exclusively on the AST, so it can't observe calls
created by SSA.
To address these problems, this commit splits the check into two
phases and rewrites it to use a call graph generated during SSA
lowering. The first phase runs before transformclosure/walk and simply
records systemstack arguments when they're easy to get. Then, it
modifies genssa to record static call edges at the point where we're
lowering to Progs (which is the latest point at which position
information is conveniently available). Finally, the second phase runs
after all functions have been lowered and uses a direct BFS walk of
the call graph (combining systemstack calls with static calls) to find
prohibited write barriers and construct nice error messages.
Fixes#22384.
For #22460.
Change-Id: I39668f7f2366ab3c1ab1a71eaf25484d25349540
Reviewed-on: https://go-review.googlesource.com/72773
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We're about to start tracking nowritebarrierrec through systemstack
calls, which detects that we're calling markroot (which has write
barriers) from gchelper, which is called from the scheduler during STW
apparently without a P.
But it turns out that func helpgc, which wakes up blocked Ms to run
gchelper, installs a P for gchelper to use. This means there *is* a P
when gchelper runs, so it is allowed to have write barriers. Tell the
compiler this by marking gchelper go:yeswritebarrierrec. Also,
document the call to gchelper so I don't have to spend another half a
day puzzling over how on earth this could possibly work before
discovering the spooky action-at-a-distance in helpgc.
Updates #22384.
For #22460.
Change-Id: I7394c9b4871745575f87a2d4fbbc5b8e54d669f7
Reviewed-on: https://go-review.googlesource.com/72772
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
We're about to start tracking nowritebarrierrec through systemstack
calls, which will reveal write barriers in persistentalloc prohibited
by various callers.
The pointers manipulated by persistentalloc are always to off-heap
memory, so this removes these write barriers statically by introducing
a new go:notinheap type to represent generic off-heap memory.
Updates #22384.
For #22460.
Change-Id: Id449d9ebf145b14d55476a833e7f076b0d261d57
Reviewed-on: https://go-review.googlesource.com/72771
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
We're about to start tracking nowritebarrierrec through systemstack
calls, which will reveal write barriers in startpanic_m prohibited by
various callers.
We actually can allow write barriers here because the write barrier is
a no-op when we're panicking. Let the compiler know.
Updates #22384.
For #22460.
Change-Id: Ifb3a38d3dd9a4125c278c3680f8648f987a5b0b8
Reviewed-on: https://go-review.googlesource.com/72770
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently most of these are marked go:nowritebarrier as a hint, but
it's actually important that these not invoke write barriers
recursively. The danger is that some gcWork method would invoke the
write barrier while the gcWork is in an inconsistent state and that
the write barrier would in turn invoke some other gcWork method, which
would crash or permanently corrupt the gcWork. Simply marking the
write barrier itself as go:nowritebarrierrec isn't sufficient to
prevent this if the write barrier doesn't use the outer method.
Thankfully, this doesn't cause any build failures, so we were getting
this right. :)
For #22460.
Change-Id: I35a7292a584200eb35a49507cd3fe359ba2206f6
Reviewed-on: https://go-review.googlesource.com/72554
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, newstack and gogo have write barriers for maintaining the
context register saved in g.sched.ctxt. This is troublesome, because
newstack can be called from go:nowritebarrierrec places that can't
allow write barriers. It happens to be benign because g.sched.ctxt
will always be nil on entry to newstack *and* it so happens the
incoming ctxt will also always be nil in these contexts (I
think/hope), but this is playing with fire. It's also desirable to
mark newstack go:nowritebarrierrec to prevent any other, non-benign
write barriers from creeping in, but we can't do that right now
because of this one write barrier.
Fix all of this by observing that g.sched.ctxt is really just a saved
live pointer register. Hence, we can shade it when we scan g's stack
and otherwise move it back and forth between the actual context
register and g.sched.ctxt without write barriers. This means we can
save it in morestack along with all of the other g.sched, eliminate
the save from newstack along with its troublesome write barrier, and
eliminate the shenanigans in gogo to invoke the write barrier when
restoring it.
Once we've done all of this, we can mark newstack
go:nowritebarrierrec.
Fixes#22385.
For #22460.
Change-Id: I43c24958e3f6785b53c1350e1e83c2844e0d1522
Reviewed-on: https://go-review.googlesource.com/72553
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In case of a failed/cancelled build, src/cmd/dist/dist might be left in
place.
Change-Id: Id81b5d663476a880101a2eed54fa051c40b0b0bc
Reviewed-on: https://go-review.googlesource.com/74150
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is ugly but needed on the builders, because they do not set
PWD/GOROOT consistently, and the new content-based staleness
understands that the setting of GOROOT influences the content in
the linker outputs.
Change-Id: I0606f2c70b719619b188864ad3ae1b34432140cb
Reviewed-on: https://go-review.googlesource.com/74070
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Header.WriteSubset uses a sync.Pool but wouldn't Put the sorter back in
the pool if there was an error writing to the io.Writer
I'm not really sure why the sorter is returned to begin with. The
comment says "for possible return to headerSorterCache".
This also doesn't address potential panics that might occur, but the
overhead of doing the Put in a defer would likely be too great.
Change-Id: If3c45a4c3e11f6ec65d187e25b63455b0142d4e3
Reviewed-on: https://go-review.googlesource.com/73910
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
New relocation flavor R_DWARFFILEREF, to be applied to DWARF attribute
values that correspond to file references (ex: DW_AT_decl_file,
DW_AT_call_file). The LSym for this relocation is the file itself; the
linker replaces the relocation target with the index of the specified
file in the line table's file section.
Note: for testing purposes this patch changes the DWARF function
subprogram DIE abbrev to include DW_AT_decl_file (allowed by DWARF
but not especially useful) so as to have a way to test this
functionality. This attribute will be removed once there are other
file reference attributes (coming as part of inlining support).
Change-Id: Icf676beb60fcc33f06d78e747ef717532daaa3ba
Reviewed-on: https://go-review.googlesource.com/73330
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The compiler depends on the way heap and sort break ties
in some cases. Instead of trying to find them all, bundle
those packages into the bootstrap compiler builds.
The overall goal is that Go1.4 building cmd/compile during the
bootstrap process produces a semantically equivalent compiler
to cmd/compile compiling itself. After this CL, that property is true,
at least for the compiler compiling itself and the other tools.
A test for this property will be in CL 73212.
Change-Id: Icc1ba7cbe828f5673e8198ebacb18c7c01f3a735
Reviewed-on: https://go-review.googlesource.com/73952
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This will let us build the latest sort when bootstrapping the compiler.
The compiler depends on the precise tie-breaks used by sort in
some cases, and it's easier to bring sort along than require checking
every sort call ever added to the compiler.
Change-Id: Idc622f89aedbb40d848708c76650fc28779d0c3c
Reviewed-on: https://go-review.googlesource.com/73951
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Don't pass -gdwarf-2 to the external linker when external linkage is
requested. The Go compiler is now emitting DWARF version 4, so this
doesn't seem needed any more.
Fixes#22455
Change-Id: Ic4122c55e946619a266430f2d26f06d6803dd232
Reviewed-on: https://go-review.googlesource.com/73672
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
env.MkEnv was computing the full gcc command line to report as
$GOGCCFLAGS in "go env" output, which meant running gcc (or clang)
multiple times to discern which flags are available.
We also set $GOGCCFLAGS in the environment, but nothing actually uses
that as far as I can tell - it was always intended only for debugging.
Move GOGCCFLAGS to env.ExtraEnvVars, which displayed in "go env"
output but not set in child processes and not computed nearly as
often.
The effect is that trivial commands like "go help" or "go env GOARCH"
or "go tool -n compile" now run in about 0.01s instead of 0.1s,
because they no longer run gcc 4 times each.
go test -short cmd/go drops from 81s to 44s (and needs more trimming).
The $GOROOT/test suite drops from 92s to 33s, because the number of
gcc invocation drops from 13,336 to 0.
Overall, all.bash drops from 5m53s to 4m07s wall time.
Change-Id: Ia85abc89e1e2bb126b933aff3bf7c5f6c0984cd5
Reviewed-on: https://go-review.googlesource.com/73850
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Function sqDiff is called multiple times in the hot path (x, y loops) of
drawPaletted from the image/draw package; number of sqDiff calls is
between 4×width×height and 4×width×height×len(palette) for each
drawPaletted call.
Simplify this function by removing arguments comparison and relying
instead on signed to unsigned integer conversion rules and properties of
unsigned integer values operations guaranteed by the spec:
> For unsigned integer values, the operations +, -, *, and << are
> computed modulo 2n, where n is the bit width of the unsigned integer's
> type. Loosely speaking, these unsigned integer operations discard high
> bits upon overflow, and programs may rely on ``wrap around''.
image/gif package benchmark that depends on the code updated shows
throughput improvements:
name old time/op new time/op delta
QuantizedEncode-4 788ms ± 2% 468ms ± 9% -40.58% (p=0.000 n=9+10)
name old speed new speed delta
QuantizedEncode-4 1.56MB/s ± 2% 2.63MB/s ± 8% +68.47% (p=0.000 n=9+10)
Closes#22375.
Change-Id: Ic9a540e39ceb21e7741d308af1cfbe61b4ac347b
Reviewed-on: https://go-review.googlesource.com/72373
Reviewed-by: Nigel Tao <nigeltao@golang.org>
1. Move AXXX constants (A-enumeration) from "a.out.go" to "aenum.go"
2. Move VEX-encoded optabs from "asm6.go" to "vex_optabs.go"
Also run "go generate" over aenum.go. This explains diff in "anames.go".
Initialization of opindex is split into 2 loops:
one for `vexOptab`, second for `optab`.
Rationale:
when VEX instructions are generated with current structure,
asm6.go is modified, which can lead to merge conflicts and
larger diffs than desired. Same for a.out.go.
This change makes x86avxgen usage possible:
https://go-review.googlesource.com/c/arch/+/66972
Change-Id: Id9eefcf5ccf0a89440e5d01bcb80926a8163b41d
Reviewed-on: https://go-review.googlesource.com/70630
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TestParallelRWMutexReaders has a non-preemptible loop in it that can
deadlock if GC triggers. "Fix" it like we've fixed similar tests.
Updates #10958.
Change-Id: I13618f522f5ef0c864e7171ad2f655edececacd7
Reviewed-on: https://go-review.googlesource.com/73710
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both the linker and the plugin package were inconsistent
about when they applied the path encoding defined in
objabi.PathToPrefix. As a result, only some symbols from
a package path that required encoding were being found.
So always encoding the path.
Fixes#22295
Change-Id: Ife86c79ca20b2e9307008ed83885e193d32b7dc4
Reviewed-on: https://go-review.googlesource.com/72390
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
...because that's an illegal addressing mode.
I double-checked handling of this code, and 387 is the only
place where this check is missing.
Fixes#22429
Change-Id: I2284fe729ea86251c6af2f04076ddf7a5e66367c
Reviewed-on: https://go-review.googlesource.com/73551
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
drawPaletted has to discover R,G,B,A color values of each source image
pixel in a given rectangle. Doing that by calling image.Image.At()
method returning color.Color interface is quite taxing allocation-wise
since interface values go through heap. Introduce special cases for some
concrete source types by fetching color values using type-specific
methods.
name old time/op new time/op delta
Paletted-4 7.62ms ± 4% 3.72ms ± 3% -51.20% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
Paletted-4 480kB ± 0% 0kB ± 0% -99.99% (p=0.000 n=4+5)
name old allocs/op new allocs/op delta
Paletted-4 120k ± 0% 0k ± 0% -100.00% (p=0.008 n=5+5)
Updates #15759.
Change-Id: I0ce1770ff600ac80599541aaad4c2c826855c8fb
Reviewed-on: https://go-review.googlesource.com/72370
Reviewed-by: Nigel Tao <nigeltao@golang.org>
A method expression is of the form T.m where T is a type and m
is a method of that type. The spec restricted T essentially to
a type name. Both cmd/compile and go/types accepted any type
syntactically, and a method expression was really just a form
of a selector expression x.f where x denotes a type.
This CL removes the spec syntax restriction from MethodExpr
to match the actual implementation. It also moves MethodExpr
from Operand to PrimaryExpr, because that's what it is.
It still keeps the separate notion of MethodExpr even though
it looks just like a selector expresion, since a MethodExpr
must start with a type rather than a value, and the spec's
syntax expresses this bit of semantics via distinct productions
(e.g., conversions look like calls but also must start with
a type).
Fixes#9060.
Change-Id: Idd84655b5b4f85d7ee53ebf749f73f0414a05f4a
Reviewed-on: https://go-review.googlesource.com/73233
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 39570 added support for automatically setting flag bit 11 to
indicate that the filename and comment fields are encoded in UTF-8,
which is (conventionally) the encoding using for most Go strings.
However, the detection added is too lose for two reasons:
* We need to ensure both fields are at least possibly UTF-8.
That is, if any field is definitely not UTF-8, then we can't set the bit.
* The utf8.ValidRune returns true for utf8.RuneError, which iterating
over a Go string automatically returns for invalid UTF-8.
Thus, we manually check for that value.
Updates #22367
Updates #10741
Change-Id: Ie8aae388432e546e44c6bebd06a00434373ca99e
Reviewed-on: https://go-review.googlesource.com/72791
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 40112 intended to allow full flag processing in go vet, but missed
vet's -shift flag; this corrects the omission.
Fixes#22442
Change-Id: I47525018306bd8b9aa452fb378d0d45319f8cf11
Reviewed-on: https://go-review.googlesource.com/73553
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test was previously disabled when external linking was
unsupported on ppc64le. It should still be disabled on ppc64
since there is no cgo or external linking there, but I removed
the if test for GOARCH=ppc64 since the initial test for cgo
enabled will cause it to be skipped on ppc64.
Fixes#22360
Change-Id: I5a0e3e4a1bd71ac7bf0ed0c792f7b78fb4a5e100
Reviewed-on: https://go-review.googlesource.com/73510
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds the syscall.Conn interface to Listener types, with the caveat that only RawConn.Control is supported. Custom socket options can now be set safely.
Updates #19435Fixes#22065
Change-Id: I7e74780d00318dc54a923d1c628a18a36009acab
Reviewed-on: https://go-review.googlesource.com/71651
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously scanning time.Time into a *time.Time required reflection.
Now it does not. Scanning already checked if the source value was of
type time.Time. The only addition was checking the destination was
of type *time.Time.
Existing tests already scan time.Time into *time.Time, so no new
tests were added. Linked issue has performance justification.
Fixes#22300
Change-Id: I4eea461c78fad71ce76e7677c8503a1919666931
Reviewed-on: https://go-review.googlesource.com/73232
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Russ pointed out in a previous CL golang.org/cl/65731 that not only
was the locking incomplete, previous changes did not correctly
lock driver calls in other sections. After inspecting
driverConn, driverStmt, driverResult, Tx, and Rows structs
where driver interfaces are stored, I discovered a few more places
that failed to lock driver calls. The largest of these
was the parameter type converter "driverArgs".
driverArgs was typically called right before another call to the
driver in a locked region, so I made the entire driverArgs expect
a locked driver mutex and combined the region. This should not
be a problem because the connection is pulled out of the connection
pool either way so there shouldn't be contention.
Fixes#21117
Change-Id: I88d46f74dca25fb11a30f0bf8e79785a73133d23
Reviewed-on: https://go-review.googlesource.com/71433
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Otherwise low-res timers cause problems at call sites that expect to
be able to use 0 as meaning "no time set" and therefore expect that
nanotime never returns 0 itself. For example, sched.lastpoll == 0
means no last poll.
Fixes#22394.
Change-Id: Iea28acfddfff6f46bc90f041ec173e0fea591285
Reviewed-on: https://go-review.googlesource.com/73410
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The new pagezero_size introduced by CL 72730 breaks
on 32-bit systems, since it is 2³². Restrict the change to
darwin/arm64, since it is intended for iOS only.
We could plausibly allow GOARCH=amd64 as well, but
without a compelling reason, changing the zero page size
doesn't seem worth the risk.
Change-Id: I5d6adcbaff8d0e5b169ff13512f188332cc7ed9a
Reviewed-on: https://go-review.googlesource.com/73250
Run-TryBot: Russ Cox <rsc@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The record delimiter (not configurable by user) is "\r\n" or "\n".
It is insensible for the user to set Comma or Comment delimiters
to be some character that conflicts with the record delimiter.
Furthermore, it is insensible for Comma or Comment to be the same rune.
Allowing this leaks implementation details to the user in regards to
the evaluation order of which rune is checked for first.
Fixes#22404
Change-Id: I31e86abc9b3a8fb4584e090477795587740970ae
Reviewed-on: https://go-review.googlesource.com/72793
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL expands the job of "dist bootstrap" to be "finish make.bash".
I need to change that logic in upcoming CLs related to cmd/go
changes, and I'd rather not change it in three places in three different
shell script languages.
Change-Id: I545dc215e408289e4d0b28f7c2ffcd849d89ad3b
Reviewed-on: https://go-review.googlesource.com/72870
Reviewed-by: David Crawshaw <crawshaw@golang.org>
There is some stuff I don't understand very well involved in SSUB, better words
for the documentation gratefully accepted.
As this is the last use of a bit in SMASK, kill that off too.
Change-Id: Iddff1c9b2af02c9dfb12ac8e668d004e4642f997
Reviewed-on: https://go-review.googlesource.com/42026
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rounding ties to even is statistically useful for some applications.
This implementation completes IEEE float64 rounding mode support (in
addition to Round, Ceil, Floor, Trunc).
This function avoids subtle faults found in ad-hoc implementations, and
is simple enough to be inlined by the compiler.
Fixes#21748
Change-Id: I09415df2e42435f9e7dabe3bdc0148e9b9ebd609
Reviewed-on: https://go-review.googlesource.com/61211
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A single database connection ususally maps to a single session.
A connection pool is logically also a session pool. Most
sessions have a way to reset the session state which is desirable
to prevent one bad query from poisoning another later query with
temp table name conflicts or other persistent session resources.
It also lets drivers provide users with better error messages from
queryies when the underlying transport or query method fails.
Internally the driver connection should now be marked as bad, but
return the actual connection. When ResetSession is called on the
connection it should return driver.ErrBadConn to remove it from
the connection pool. Previously drivers had to choose between
meaningful error messages or poisoning the connection pool.
Lastly update TestPoolExhaustOnCancel from relying on a
WAIT query fixing a flaky timeout issue exposed by this
change.
Fixes#22049Fixes#20807
Change-Id: I2b5df6d954a38d0ad93bf1922ec16e74c827274c
Reviewed-on: https://go-review.googlesource.com/73033
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Instead of the hand-written control flow analysis in debug info
generation, use a reverse postorder traversal, which is basically the
same thing. It should be slightly faster.
More importantly, the previous version simply gave up in the case of
non-reducible functions, and produced output that caused a later stage
to crash. It turns out that there's a non-reducible function in
compress/flate, so that wasn't a theoretical issue.
With this change, all blocks will be visited, even for non-reducible
functions.
Change-Id: Id47536764ee93203c6b4105a1a3013fe3265aa12
Reviewed-on: https://go-review.googlesource.com/73110
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
A single database connection ususally maps to a single session.
A connection pool is logically also a session pool. Most
sessions have a way to reset the session state which is desirable
to prevent one bad query from poisoning another later query with
temp table name conflicts or other persistent session resources.
It also lets drivers provide users with better error messages from
queryies when the underlying transport or query method fails.
Internally the driver connection should now be marked as bad, but
return the actual connection. When ResetSession is called on the
connection it should return driver.ErrBadConn to remove it from
the connection pool. Previously drivers had to choose between
meaningful error messages or poisoning the connection pool.
Lastly update TestPoolExhaustOnCancel from relying on a
WAIT query fixing a flaky timeout issue exposed by this
change.
Fixes#22049Fixes#20807
Change-Id: Idffa1a7ca9ccfe633257c4a3ae299b864f46c5b6
Reviewed-on: https://go-review.googlesource.com/67630
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Drivers shouldn't need to implement both Queryer and QueryerContext,
they should just implement QueryerContext. Same with Execer and
ExecerContext. This CL tests for QueryContext and ExecerContext
first so drivers do not need to implement Queryer and Execer
with an empty definition.
Fixes#21663
Change-Id: Ifbaa71da669f4bc60f8da8c41a04a4afed699a9f
Reviewed-on: https://go-review.googlesource.com/65733
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change modifies go to create iOS arm64 binaries that pass iTunes
upload validation. Tested with xcode 9.0.1 macOS 10.13.
Fixes#22402.
Change-Id: I3f14c6ac85065e2da88d06edc8682947f6f1cd47
Reviewed-on: https://go-review.googlesource.com/72730
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Also includes all derived values as well as
vendored packages.
Generated by running
UNICODE_VERSION=10.0.0 go generate
in golang.org/x/text
and modified by hand to add the tests and
entries in next.txt for new script and properties.
Closes Issue #21471
Change-Id: I1d10ee3887bd1fd3d5a756ee0d04bd6ec2814ba1
Reviewed-on: https://go-review.googlesource.com/63953
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
The ErrQuote variable is only returned when a parsing error
occurs within a quoted string. Make that clear in the message.
Change-Id: I06ad5a9edb41afedde193c4f8b93551bb8342bbb
Reviewed-on: https://go-review.googlesource.com/72794
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We should be referring to ParseError.Err, which is the underlying error,
not ParseError.Error, which is the error method.
Change-Id: Ic3cef5ecbe1ada5fa14b9573222f29da8fc9a8d5
Reviewed-on: https://go-review.googlesource.com/72450
Reviewed-by: Tim Cooper <tim.cooper@layeh.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Make netpollopen return what Windows GetLastError API returns.
It is probably copy / paste error from long time ago.
Change-Id: I28f78718c15fef3e8b5f5d11a259533d7e9c6185
Reviewed-on: https://go-review.googlesource.com/72592
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
If n.Type==nil after typechecking, then we should have already
reported a more useful error somewhere else. Just return 0 in
evalunsafe without trying to do anything else that's likely to cause
problems.
Also, further split out issue7525.go into more test files, because
cmd/compile reports at most one typechecking loop per compilation
unit.
Fixes#22351.
Change-Id: I3ebf505f72c48fcbfef5ec915606224406026597
Reviewed-on: https://go-review.googlesource.com/72251
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
decoder.decode() was defering close of lzw.decoders created for each
frame in a loop, thus increasing heap usage (referenced object + defered
function) until decode() returns. Memory increased proportionally to the
number of frames. Fix this by moving the sImageDescriptor case block
into its own method.
Fixes#22237
Change-Id: I819617ea7e539e13c04bc11112f339645391ddb9
Reviewed-on: https://go-review.googlesource.com/70370
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
When enhanced DWARF location list generation is enabled (via internal
option -dwarflocationlists), variable entries were missing for "large"
(non-decomposable) locals and formals. From the debugging perspective,
this makes it appear that the variable doesn't exist, which is
probably not what we want. This change insures that a formal/local DIE
is created for these vars (with correct type, line, etc) but with a
conservative ("no info") location.
Change-Id: I10b2e9a51a60c7b4c748e987cdec5f2d8b2837d5
Reviewed-on: https://go-review.googlesource.com/72630
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The addressing mode of global variable was missing, whereas the
compiler may make use of it, causing "illegal combination" error.
This CL adds support of that addressing mode.
Fixes#22390.
Change-Id: Ic8eade31aba73e6fb895f758ee7f277f8f1832ef
Reviewed-on: https://go-review.googlesource.com/72610
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
* replace a copy of IsMethod with a call of it.
* a few more switches where they simplify the code.
* prefer composite literals over "n := new(...); n.x = y; ...".
* use defers to get rid of three goto labels.
* rewrite updateHasCall into two funcs to remove gotos.
Passes toolstash-check on std cmd.
Change-Id: Icb5442a89a87319ef4b640bbc5faebf41b193ef1
Reviewed-on: https://go-review.googlesource.com/72070
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, benchmarking compile performance under -l=4 is confounded
by -l=2 enabling eager typechecking of unused inline function bodies
for debugging. This isn't logically an "inlining aggressiveness"
level, so instead move this logic under the -d umbrella flag.
Change-Id: I713f68952efbe25b6941d3ebc2f3707ccbbd6240
Reviewed-on: https://go-review.googlesource.com/72253
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Increasing the map size with the benchmark iteration count
introduced non-linearities and made benchmark runs slow when
increasing benchtime.
Rework the benchmark to use a map size independent of the
iteration count and instead re-fill it when it becomes empty.
Fixes#21546
Change-Id: Iafb6eb225e81830263f30b3aba0d449c361aec32
Reviewed-on: https://go-review.googlesource.com/57650
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Running test.bash goes from 30s to 10s on a linux workstation.
(The coming pkg cache work in cmd/go would presumably do the same thing,
but this makes all.bash faster today.)
Change-Id: I8c9b0400071a412fce55b386e939906bb1c1d84d
Reviewed-on: https://go-review.googlesource.com/72330
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 72150 fixes#22352 by reverting the problematic parts of that CL
where the line number and column number were inconsistent with each other.
This CL adds back functionality to address the issue that CL 72150
was trying to solve in the first place. That is, it reports the starting
line of the record, so that users have a frame of reference to start with
when debugging what went wrong.
In the event of gnarly CSV files with multiline quoted strings, a parse
failure likely occurs somewhere between the start of the record and
the point where the parser finally detected an error.
Since ParserError.{Line,Column} reports where the *error* occurs, we
add a RecordLine field to report where the record starts.
Also take this time to cleanup and modernize TestRead.
Fixes#19019Fixes#22352
Change-Id: I16cebf0b81922c35f75804c7073e9cddbfd11a04
Reviewed-on: https://go-review.googlesource.com/72310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
windows version of Pipe function is implemented by calling
syscall.Pipe which returns handles inheritable by client process,
and then adjusting returned handles with syscall.CloseOnExec.
Just create non-inheritable handles in the first place.
Now that we don't have a race window in the code, drop use
of syscall.ForkLock.
Change-Id: Ie325da7c2397b5995db4a5ddb0117e2ce1745187
Reviewed-on: https://go-review.googlesource.com/72010
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
NewEncoder returns an io.Writer that writes all incoming bytes as
hexadecimal characters to the underlying io.Writer. NewDecoder returns an
io.Reader that does the inverse.
Fixes#21590
Change-Id: Iebe0813faf365b42598f19a9aa41768f571dc0a8
Reviewed-on: https://go-review.googlesource.com/70210
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Reader implementation is slow because it operates on a rune-by-rune
basis via bufio.Reader.ReadRune. We speed this up by operating on entire
lines that we read from bufio.Reader.ReadSlice.
In order to ensure that we read the full line, we augment ReadSlice
in our Reader.readLine method to automatically expand the slice if
bufio.ErrBufferFull is every hit.
This change happens to fix#19410 because it no longer relies on
rune-by-rune parsing and only searches for the relevant delimiter rune.
In order to keep column accounting simple and consistent, this change
reverts parts of CL 52830.
This CL is an alternative to CL 36270 and builds on some of the ideas
from that change by Diogo Pinela.
name old time/op new time/op delta
Read-8 3.12µs ± 1% 2.54µs ± 2% -18.76% (p=0.000 n=10+9)
ReadWithFieldsPerRecord-8 3.12µs ± 1% 2.53µs ± 1% -18.91% (p=0.000 n=9+9)
ReadWithoutFieldsPerRecord-8 3.13µs ± 0% 2.57µs ± 3% -18.07% (p=0.000 n=10+10)
ReadLargeFields-8 52.3µs ± 1% 5.3µs ± 2% -89.93% (p=0.000 n=10+9)
ReadReuseRecord-8 2.05µs ± 1% 1.40µs ± 1% -31.48% (p=0.000 n=10+9)
ReadReuseRecordWithFieldsPerRecord-8 2.05µs ± 1% 1.41µs ± 0% -31.03% (p=0.000 n=10+9)
ReadReuseRecordWithoutFieldsPerRecord-8 2.06µs ± 1% 1.40µs ± 1% -31.70% (p=0.000 n=9+10)
ReadReuseRecordLargeFields-8 50.9µs ± 0% 4.1µs ± 3% -92.01% (p=0.000 n=10+10)
name old alloc/op new alloc/op
Read-8 664B ± 0% 664B ± 0%
ReadWithFieldsPerRecord-8 664B ± 0% 664B ± 0%
ReadWithoutFieldsPerRecord-8 664B ± 0% 664B ± 0%
ReadLargeFields-8 3.94kB ± 0% 3.94kB ± 0%
ReadReuseRecord-8 24.0B ± 0% 24.0B ± 0%
ReadReuseRecordWithFieldsPerRecord-8 24.0B ± 0% 24.0B ± 0%
ReadReuseRecordWithoutFieldsPerRecord-8 24.0B ± 0% 24.0B ± 0%
ReadReuseRecordLargeFields-8 2.98kB ± 0% 2.98kB ± 0%
name old allocs/op new allocs/op
Read-8 18.0 ± 0% 18.0 ± 0%
ReadWithFieldsPerRecord-8 18.0 ± 0% 18.0 ± 0%
ReadWithoutFieldsPerRecord-8 18.0 ± 0% 18.0 ± 0%
ReadLargeFields-8 24.0 ± 0% 24.0 ± 0%
ReadReuseRecord-8 8.00 ± 0% 8.00 ± 0%
ReadReuseRecordWithFieldsPerRecord-8 8.00 ± 0% 8.00 ± 0%
ReadReuseRecordWithoutFieldsPerRecord-8 8.00 ± 0% 8.00 ± 0%
ReadReuseRecordLargeFields-8 12.0 ± 0% 12.0 ± 0%
Updates #22352
Updates #19019Fixes#16791Fixes#19410
Change-Id: I31c27cfcc56880e6abac262f36c947179b550bbf
Reviewed-on: https://go-review.googlesource.com/72150
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On systems that use kqueue, we always register descriptors for both
EVFILT_READ and EVFILT_WRITE. On at least FreeBSD and OpenBSD, when
the write end of a pipe is registered for EVFILT_READ and EVFILT_WRITE
events, and the read end of the pipe is closed, kqueue reports an
EVFILT_READ event with EV_EOF set, but does not report an EVFILT_WRITE
event. Since the write to the pipe is waiting for an EVFILT_WRITE
event, closing the read end of a pipe can cause the write end to hang
rather than attempt another write which will fail with EPIPE.
Fix this by treating EVFILT_READ with EV_EOF set as making both reads
and writes ready to proceed.
The real test for this is in CL 71770, which tests using various
timeouts with pipes.
Updates #22114
Change-Id: Ib23fbaaddbccd8eee77bdf18f27a7f0aa50e2742
Reviewed-on: https://go-review.googlesource.com/71973
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Since inlining budget calculation is fixed in CL 70151
runtime.nextFreeFast is no longer inlineable on MIPS64x because
it does not support Ctz64 as intrinsic. Skip the test.
Updates #22239.
Change-Id: Id00d55628ddb4b48d27aebfa10377a896765d569
Reviewed-on: https://go-review.googlesource.com/72271
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This hack existed because cmd/go used to install (write) and then run
cmd/cgo in the same invocation, and writing and then running a program
is a no-no in modern multithreaded Unix programs (see #22315).
As of CL 68338, cmd/go no longer installs any programs that it then
tries to use. It never did this for any program other than cgo, and
CL 68338 removed that special case for cgo.
Now this special case, added for #3001 long ago, can be removed too.
Change-Id: I338f1f8665e9aca823e33ef7dda9d19f665e4281
Reviewed-on: https://go-review.googlesource.com/71571
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It uses the build ID, which is soon to be internal to package work.
Luckily it is also only called from package work.
Change-Id: I5e6662cfe667bdc9190f086be733105ad65a3191
Reviewed-on: https://go-review.googlesource.com/70670
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Where GCC says "unrecognized command line option", clang says "unknown
argument". This distinction usually doesn't matter because the
compiler will also exit with a non-zero status, but clang 3.4
reportedly exits with a zero status after reporting an unknown argument.
Change-Id: Ieb69ea352a8de0cd4171a1c26708dfe523421cfa
Reviewed-on: https://go-review.googlesource.com/72151
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
When traceviewer encounters a failure of json trace import
due to data error, onImportFail tried to access an error variable
which was not yet defined.
Change-Id: I431be03f179aafacaf1fd3c62a6337e8b5bd18fb
Reviewed-on: https://go-review.googlesource.com/71970
Reviewed-by: Austin Clements <austin@google.com>
The test already contained logic to do this however it did not match
the error "cannot find 'ld'" which appears to be how gcc fails when
ld.gold is missing.
Fixes#22340.
Change-Id: I841248cc489b8fa72bc00a95000ad405f9ef8a4f
Reviewed-on: https://go-review.googlesource.com/72111
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A 1XX, 204, or 304 response may not include a response body according
to RFC 7230, section 3.3.3. If a buggy server returns a 204 or 304
response with a body that is chunked encoded, the invalid body is
currently made readable in the Response. This can lead to data races due
to the transport connection's read loop which does not wait for the body
EOF when the response status is 204 or 304.
The correct behavior is to ignore the body on a 204 or 304 response, and
treat the body data as the beginning of the next request on the
connection.
Updates #22330.
Change-Id: I89a457ceb783b6f66136d5bf9be0a9b0a04fa955
Reviewed-on: https://go-review.googlesource.com/71910
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Tom Bergan <tombergan@google.com>
https://golang.org/cl/71750 specifies iota values as indices,
thus making them independent from nested constant declarations.
This CL removes some of the comments in the examples that were
still referring to the old notion of iotas being incremented
and reset.
As an aside, please note that the spec still permits the use
of iota in a nested function (like before). Specifically, the
following cases are permitted by the spec (as before):
1) const _ = len([iota]int{})
2) const _ = unsafe.Sizeof(func(){ _ = iota })
For #15550.
Change-Id: I9e5fec75daf7b628b1e08d970512397e9c348923
Reviewed-on: https://go-review.googlesource.com/71912
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
racewalk's "foreach" function applies a function to all of a Node's
immediate children, but with a non-idiomatic signature.
This CL reworks it to recursively iterate over the entire subtree
rooted at Node and provides a way to short-circuit iteration.
Passes toolstash -cmp for std cmd with -race.
Change-Id: I738b73953d608709802c97945b7e0f4e4940d3f4
Reviewed-on: https://go-review.googlesource.com/71911
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
On modern Unix systems it is basically impossible for a multithreaded
program to open a binary for write, close it, and then fork+exec that
same binary. So don't write the binary if we're going to fork+exec it.
This fixes the ETXTBSY flakes.
Fixes#22220.
See also #22315.
Change-Id: I6be4802fa174726ef2a93d5b2f09f708da897cdb
Reviewed-on: https://go-review.googlesource.com/71570
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Issue #15550 is clearly an esoteric case but the spec was silent
about it and we had diverging implementations. By making `iota`
and index that is relative to the respective constant declaration,
nested const declarations won't affect outer values of `iota`.
cmd/compile and go/types already follow this semantics.
Fixes#15550.
Change-Id: If138189e3ea4373f8ba50ac6fb1d219b481f8698
Reviewed-on: https://go-review.googlesource.com/71750
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
golang.org/cl/37258 was committed to fix issue #16146.
This patch seemed intent to allow at most one dangling byte. But, as
implemented, many more bytes may actually slip through. This is because
the LZW layer creates a bufio.Reader which will itself consume data
beyond the end of the LZW stream, and this isn't accounted for anywhere.
This change means to avoid the allocation of the bufio.Reader by making
blockReader implement io.ByteReader. Further, it adds a close() method
which detects extra data in the block sequence. To avoid any
regressions with poorly encoded GIFs which may have worked accidentally,
there are no restrictions on how many extra bytes may exist in the final
full sub-block that contained LZW data. If the end of the LZW stream
happened to align with the end of a sub-block, at most one more
sub-block with a length of 1 byte may exist before the block terminator.
This change aims to be at least as performant as the prior
implementation. But the primary gain is avoiding the allocation of a
bufio.Reader per frame:
name old time/op new time/op delta
Decode-8 276µs ± 0% 275µs ± 2% ~ (p=0.690 n=5+5)
name old speed new speed delta
Decode-8 55.9MB/s ± 0% 56.3MB/s ± 2% ~ (p=0.690 n=5+5)
name old alloc/op new alloc/op delta
Decode-8 49.2kB ± 0% 44.8kB ± 0% -9.10% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Decode-8 269 ± 0% 267 ± 0% -0.74% (p=0.008 n=5+5)
Change-Id: Iec4f9b895561ad52266313fbc73ec82c070c3349
Reviewed-on: https://go-review.googlesource.com/68350
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
When building test binaries, we build one archive with all of the test
sources and a second archive with the generated test package main and
link them together. If the test sources are themselves in package main
and the test was compiled with non-default compiler flags, then both
archives will contain a go.cuinfo.producer.main symbol, leading to a
duplicate symbol failure.
This has been causing test build failures on darwin-arm-a1428ios,
darwin-arm64-a1549ios, linux-amd64-noopt, android-arm-wiko-fever, and
android-arm64-wiko-fever since CL 71430 added this symbol. This CL
should fix the build.
Change-Id: I69051c846e7c0d97395a865a361cae07f411f9ad
Reviewed-on: https://go-review.googlesource.com/71771
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
No test because at present it is never called in a way that fails.
When #22114 is implemented, failure will be possible. Not including this
change in that work because this change is separable and clearly correct.
Updates #22114
Change-Id: I81eb9eec8800e8082d918c0e5fb71282f538267e
Reviewed-on: https://go-review.googlesource.com/71751
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
StructField.ByteSize is almost always unset; document that Type.Size()
is the place to look.
The dwarf package doesn't spend much effort teaching you DWARF, so I
don't know what level of handholding is appropriate. Still, no harm in a
little comment.
Closes#21093
Change-Id: I0ed8cad2fa18e10a47d264ff16c176d603d6033c
Reviewed-on: https://go-review.googlesource.com/71671
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This adds a whitelisted subset of compiler flags to the DW_AT_producer
DWARF attribute of each package compilation unit DIE. This is common
practice in DWARF and can help debuggers determine the quality of the
produced debugging information.
Fixes#22168.
Change-Id: I1b994ef2262aa9b88b68eb6e883695d1103acc58
Reviewed-on: https://go-review.googlesource.com/71430
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently mmap returns an unsafe.Pointer that encodes OS errors as
values less than 4096. In practice this is okay, but it borders on
being really unsafe: for example, the value has to be checked
immediately after return and if stack copying were ever to observe
such a value, it would panic. It's also not remotely idiomatic.
Fix this by making mmap return a separate pointer value and error,
like a normal Go function.
Updates #22218.
Change-Id: Iefd965095ffc82cc91118872753a5d39d785c3a6
Reviewed-on: https://go-review.googlesource.com/71270
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Set DW_AT_variable_parameter on DW_TAG_formal_parameters that are
actually return values. variable_parameter is supposed to indicate inout
parameters, but Go doesn't really have those, and DWARF doesn't have
explicit support for multiple return values. This seems to be the best
compromise, especially since the implementation of the two is very
similar -- both are stack slots.
Fixes#21100
Change-Id: Icebabc92b7b397e0aa00a7237478cce84ad1a670
Reviewed-on: https://go-review.googlesource.com/71670
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Fixes Darwin 386 build. It turns out that the Darwin pthread_create
function saves the SSE registers, and therefore requires an aligned stack.
This worked before https://golang.org/cl/70530 because the stack sizes
were chosen to leave the stack aligned.
Change-Id: I911a9e8dcde4e41e595d5ef9b9a1ca733e154de6
Reviewed-on: https://go-review.googlesource.com/71432
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
More generally I'm concerned about these tests using
$GOROOT/src/cmd/go as scratch space, especially
combined wtih tg.parallel() - it's easy to believe some other
test might inadvertently also try to write x.exe about the
same time. This CL only solves the "didn't clean up x.exe"
problem and leaves for another day the "probably shouldn't
write to cmd/go at all" problem.
Fixes#22266.
Change-Id: I651534d70e2d360138e0373fb4a316081872550b
Reviewed-on: https://go-review.googlesource.com/71410
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixed an error that occurred in atomic mode. cover adds a global
variable declaration that forces sync/atomic to be used. fixDirectives
was confused by this declaration since it has an invalid
position. These declarations are now skipped.
Fixes#22309
Change-Id: I84f5fec13ef847fca35ad49f7704fb93b60503e0
Reviewed-on: https://go-review.googlesource.com/71351
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When an opening "{" of a block is missing and after advancing we
find a closing "}", it's likely better to assume the end of the
block. Fixed and removed TODO.
Change-Id: I20c9b4ecca798933a7cd4cbf21185bd4ca04f5f7
Reviewed-on: https://go-review.googlesource.com/71291
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Current suffix check is based on instruction, which is not very
accurate. For example, "MOVW.S R1, R2" is valid, but
"MOVW.S $0xaaaaaaaa, R1" and "MOVW.P CPSR, R9" are not.
This patch fixes the above kinds of issues by checking suffix
based on []optab. And also more test cases are added.
fixes#20509
Change-Id: Ibad91be72c78eefa719412a83b4d44370d2202a8
Reviewed-on: https://go-review.googlesource.com/70910
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 46037 and CL 46038 implemented termination of
locked OS threads when the goroutine exits.
However, this behavior leads to crashes of Go programs
using runtime.LockOSThread on Plan 9. This is notably
the case of the os/exec and net packages.
This change disables termination of locked OS threads
on Plan 9.
Updates #22227.
Change-Id: If9fa241bff1c0b68e7e9e321e06e5203b3923212
Reviewed-on: https://go-review.googlesource.com/71230
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 46033 added a "template thread" mechanism to
allow creation of thread with a known-good state
from a thread of unknown state.
However, we are experiencing issues on Plan 9
with programs using the os/exec and net package.
These package are relying on runtime.LockOSThread.
Updates #22227.
Change-Id: I85b71580a41df9fe8b24bd8623c064b6773288b0
Reviewed-on: https://go-review.googlesource.com/70231
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Unify the 386 entry point code as much as possible.
The main function could not be unified because on Windows 386 it is
called _main. Putting main in asm_386.s caused multiple definition
errors when using the external linker.
Add the _lib entry point to various operating systems. A future CL
will enable c-archive/c-shared mode for those targets.
Fix _rt0_386_windows_lib_go--it was passing arguments as though it
were amd64.
Change-Id: Ic73f1c95cdbcbea87f633f4a29bbc218a5db4f58
Reviewed-on: https://go-review.googlesource.com/70530
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Also fix 64-bit DWARF to read a 64-bit abbrev offset in the
compilation unit.
Change-Id: Idc22e59ffb354d58e9973b62fdbd342acf695859
Reviewed-on: https://go-review.googlesource.com/71171
Reviewed-by: Austin Clements <austin@google.com>
Adds the two range control actions "break" and "continue". They act the
same as the Go keywords break and continue, but are simplified in that
only the innermost range statement can be broken out of or continued.
Fixes#20531
Change-Id: I4412b3bbfd4dadb0ab74ae718e308c1ac7a0a1e9
Reviewed-on: https://go-review.googlesource.com/66410
Reviewed-by: Rob Pike <r@golang.org>
Previously, cover printed directives (//go: comments) near the top of
the file unless they were in doc comments. However, directives
frequently apply to specific definitions, and they are not written in
doc comments to prevent godoc from printing them. Moving all
directives to the top of the file affected semantics of tests.
With this change, directives are kept together with the following
top-level declarations. Only directives that occur after all top-level
declarations are moved.
Fixes#22022
Change-Id: Ic5c61c4d3969996e4ed5abccba0989163789254c
Reviewed-on: https://go-review.googlesource.com/69630
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Use TEXT pseudo-instruction to adjust SP instead of a SUB instruction
so that the assembler knows how to fill in the pcsp table and the frame
description entry correctly.
Updates #21569
Change-Id: I436c840b2af99bbb3042ecd38a7d7c1ab4d7372a
Reviewed-on: https://go-review.googlesource.com/70937
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The write barrier insertion has moved to the SSA backend's
writebarrier pass. There is still needwritebarrier function
left in the frontend. This function is used in two places:
- fncall, which is called in ascompatet, which is called in
walking OAS2FUNC. For OAS2FUNC, in order pass we've already
created temporaries, and there is no write barrier for the
assignments of these temporaries.
- updateHasCall, which updates the HasCall flag of a node. the
HasCall flag is then used in
- fncall, mentioned above.
- ascompatet. As mentioned above, this is an assignment to
a temporary, no write barrier.
- reorder1, which is always called with a list produced by
ascompatte, which is a list of assignments to stack, which
have no write barrier.
- vmatch1, which is called in oaslit with r.Op as OSTRUCTLIT,
OARRAYLIT, OSLICELIT, or OMAPLIT. There is no write barrier
in those literals.
Therefore, the needwritebarrier function is unnecessary. This
CL removes it.
Passes "toolstash -cmp" on std cmd.
Updates #17583.
Change-Id: I4b87ba8363d6583e4282a9e607a9ec8ce3ab124a
Reviewed-on: https://go-review.googlesource.com/43640
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On ARM, STREX does not permit the same register used as both the
source and the destination. Reject the bad instruction.
The assembler also accepted special cases
STREX R0, (R1) as STREX R0, (R1), R0
STREX (R1), R0 as STREX R0, (R1), R0
both are illegal. Remove this special case as well.
For STREXD, check that the destination is not source, and not
source+1. Also check that the source register is even numbered,
as required by the architecture's manual.
Fixes#22268.
Change-Id: I6bfde86ae692d8f1d35bd0bd7aac0f8a11ce8e22
Reviewed-on: https://go-review.googlesource.com/71190
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In golang.org/cl/61130, I removed the need for setting Xoffset on
OXCASE Nodes, but missed this assignment.
Passes toolstash-check.
Change-Id: I90ab05add14981b89ee18e73e1cdf2f13e9f9934
Reviewed-on: https://go-review.googlesource.com/66934
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
If the client sends a request with a custom Host header and receives
a relative redirect in response, the second request should use the
same Host header as the first request. However, if the response is
an abolute redirect, the Host header should not be preserved. See
further discussion on the issue tracker.
Fixes#22233
Change-Id: I8796e2fbc1c89b3445e651f739d5d0c82e727c14
Reviewed-on: https://go-review.googlesource.com/70792
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Instead of repeating the same list parsing pattern for parenthesized
of braced comma or semicolon-separated lists, introduce a single list
parsing function that can be parametrized and which takes a closure
to parse list elements.
This ensures the same error handling and recovery logic is used across
all lists and simplifies the code.
No semantic change.
Change-Id: Ia738d354d6c2e0c3d84a5f1c7269a6eb95685edc
Reviewed-on: https://go-review.googlesource.com/70492
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
No semantic change. Move functionality not related to argument
out of the argument parsing function, and thus match parameter
parsing. Also, use a better function name.
Change-Id: Ic550875251d64e6fe1ebf91c11d33a9e4aec9fdd
Reviewed-on: https://go-review.googlesource.com/70491
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
STREX does not permit using the same register for the value to store
and the place where the result is returned. Also the code was wrong
anyhow if the first store failed.
Fixes#22248
Change-Id: I96013497410058514ffcb771c76c86faa1ec559b
Reviewed-on: https://go-review.googlesource.com/70911
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reduce the scope of some. Also remove vars that were simply the index or
the value in a range statement. While at it, remove a var that was
exactly the length of a slice.
Also replaced 'bad' with a more clear 'errored' of type bool, and
renamed a single-char name with a comment to a name that is
self-explanatory.
And removed a few unnecessary Index calls within loops.
Passes toolstash -cmp on std cmd.
Change-Id: I26eee5f04e8f7e5418e43e25dca34f89cca5c80a
Reviewed-on: https://go-review.googlesource.com/70930
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The complainant is confused by the ambiguity of 'next' in the
phrase 'next operand'. It seems clear enough to me that things
are always read left to right when formatting, but to calm the
waters we add a clarifying parenthetical.
Fixes#22275
Change-Id: I82418c1e987db736f4bee0faa53fe715c9cde8f5
Reviewed-on: https://go-review.googlesource.com/71010
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
ANSI X9.62 specifies that Unmarshal should fail if the a given coordinate is
not smaller than the prime of the elliptic curve. This change makes Unmarshal
ANSI X9.62 compliant and explicitly documents that the Marshal/Unmarshal only
supports uncompressed points.
Fixes#20482
Change-Id: I161a73da8279cae505c9ba0b3022021709fe8145
Reviewed-on: https://go-review.googlesource.com/44312
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The indexed bitmap of a frame is encoded into a GIF by first LZW
compression, and then packaged by a simple block mechanism. Each block
of up-to-256 bytes starts with one byte, which indicates the size of the
block (0x01-0xff). The sequence of blocks is terminated by a 0x00.
While the format supports it, there is no good reason why any particular
image should be anything but a sequence of 255-byte blocks with one last
block less than 255-bytes.
The old blockWriter implementation would not buffer between Write()s,
meaning if the lzw Writer needs to flush more than one chunk of data via
a Write, multiple short blocks might exist in the middle of a stream.
Separate but related, the old implementation also forces lzw.NewWriter
to allocate a bufio.Writer because the blockWriter is not an
io.ByteWriter itself. But, even though it doesn't effectively buffer
data between Writes, it does make extra copies of sub-blocks during the
course of writing them to the GIF's writer.
Now, the blockWriter shall continue to use the encoder's [256]byte buf,
but use it to effectively buffer a series of WriteByte calls from the
lzw Writer. Once a WriteByte fills the buffer, the staged block is
Write()n to the underlying GIF writer. After the lzw Writer is Closed,
the blockWriter should also be closed, which will flush any remaining
block along with the block terminator.
BenchmarkEncode indicates slight improvements:
name old time/op new time/op delta
Encode-8 7.71ms ± 0% 7.38ms ± 0% -4.27% (p=0.008 n=5+5)
name old speed new speed delta
Encode-8 159MB/s ± 0% 167MB/s ± 0% +4.46% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
Encode-8 84.1kB ± 0% 80.0kB ± 0% -4.94% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Encode-8 9.00 ± 0% 7.00 ± 0% -22.22% (p=0.008 n=5+5)
Change-Id: I9eb9367d41d7c3d4d7f0adc9b720fc24fb50006a
Reviewed-on: https://go-review.googlesource.com/68351
Reviewed-by: Nigel Tao <nigeltao@golang.org>
After we detect errors, the AST is in a precarious state and more
likely to trip useless ICE failures. Instead let the user fix any
existing errors and see if the ICE persists. This makes Fatalf more
consistent with how panics are handled by hidePanic.
While here, also fix detection for release versions: release version
strings begin with "go" ("go1.8", "go1.9.1", etc), not "release".
Fixes#22252.
Change-Id: I1c400af62fb49dd979b96e1bf0fb295a81c8b336
Reviewed-on: https://go-review.googlesource.com/70850
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Consolidate the signature and hash fields (SignatureAndHashAlgorithm in
TLS 1.2) into a single uint16 (SignatureScheme in TLS 1.3 draft 21).
This makes it easier to add RSASSA-PSS for TLS 1.2 in the future.
Fields were named like "signatureAlgorithm" rather than
"signatureScheme" since that name is also used throughout the 1.3 draft.
The only new public symbol is ECDSAWithSHA1, other than that this is an
internal change with no new functionality.
Change-Id: Iba63d262ab1af895420583ac9e302d9705a7e0f0
Reviewed-on: https://go-review.googlesource.com/62210
Reviewed-by: Adam Langley <agl@golang.org>
Currently only a single P can run a fractional mark worker at a time.
This doesn't let us spread out the load, so it gets concentrated on
whatever unlucky P picks up the token to run a fractional worker. This
can significantly delay goroutines on that P.
This commit changes this scheduling rule so each P separately
schedules fractional workers. This can significantly reduce the load
on any individual P and allows workers to self-preempt earlier. It
does have the downside that it's possible for all Ps to be in
fractional workers simultaneously (an effect STW).
Updates #21698.
Change-Id: Ia1e300c422043fa62bb4e3dd23c6232d81e4419c
Reviewed-on: https://go-review.googlesource.com/68574
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently fractional workers run until preempted by the scheduler,
which means they typically run for 20ms. During this time, all other
goroutines on that P are blocked, which can introduce significant
latency variance.
This modifies fractional workers to self-preempt shortly after
achieving the fractional utilization goal. In practice this means they
preempt much sooner, and the scale of their preemption is on the order
of how often the user goroutine block (so, if the application is
compute-bound, the fractional workers will also run for long times,
but if the application blocks frequently, the fractional workers will
also preempt quickly).
Fixes#21698.
Updates #18534.
Change-Id: I03a5ab195dae93154a46c32083c4bb52415d2017
Reviewed-on: https://go-review.googlesource.com/68573
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
When GOMAXPROCS is not small, fractional workers don't add much to
throughput, but they do add to the latency of individual goroutines.
In this case, it makes sense to just use dedicated workers, even if we
can't exactly hit the 25% CPU goal with dedicated workers.
This implements this logic by computing the number of dedicated mark
workers that will us closest to the 25% target. We only fall back to
fractional workers if that would be more than 30% off of the target
(less than 17.5% or more than 32.5%, which in practice happens for
GOMAXPROCS <= 3 and GOMAXPROCS == 6).
Updates #21698.
Change-Id: I484063adeeaa1190200e4ef210193a20e635d552
Reviewed-on: https://go-review.googlesource.com/68571
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently these are the same constant, but are separate concepts.
Split them into two constants for easier experimentation and better
documentation.
Change-Id: I121854d4fd1a4a827f727c8e5153160c24aacda7
Reviewed-on: https://go-review.googlesource.com/68570
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
https://golang.org/cl/67270 wasn't `go fmt`ed correctly, according to
the current `go fmt`. However, what `go fmt` did looked odd, so this
change tweaks the test to use a more standard layout.
Whitespace-only; no semantic change.
Change-Id: Id820352e7c9e68189ee485c8a9bfece75ca4f9cb
Reviewed-on: https://go-review.googlesource.com/69031
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
Database drivers should be called from a single goroutine to ease
driver's design. If a driver chooses to handle context
cancels internally it may do so.
The sql package violated this agreement when calling Next or
NextResultSet. It was possible for a concurrent rollback
triggered from a context cancel to call a Tx.Rollback (which
takes a driver connection lock) while a Rows.Next is in progress
(which does not tack the driver connection lock).
The current internal design of the sql package is each call takes
roughly two locks: a closemu lock which prevents an disposing of
internal resources (assigning nil or removing from lists)
and a driver connection lock that prevents calling driver code from
multiple goroutines.
Fixes#21117
Change-Id: Ie340dc752a503089c27f57ffd43e191534829360
Reviewed-on: https://go-review.googlesource.com/65731
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 69370 introduced a hasmain field to moduledata after the
modulehashes slice. However that code was relying on the zeroing
code after it to cover modulehashes if len(Shlibs) == 0. The
hasmain field gets in the way of that. So clear modulehashes
explicitly in that case.
Found when looking at #22250. Not sure if it's related.
Change-Id: I81050cb4554cd49e9f245d261ef422f97d026df4
Reviewed-on: https://go-review.googlesource.com/70730
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In https://golang.org/cl/66334, the test was changed so that the second
Listen would also be closed. However, it shouldn't have reused the same
ln variable, as that can lead to a data race with the background loop
that accepts connections.
Simply define a new Listener, since we don't need to overwrite the first
variable.
I was able to reproduce the data race report locally about 10% of the
time by reducing the sleep from a millisecond to a nanosecond. After the
fix, it's entirely gone after 1000 runs.
Fixes#22226.
Change-Id: I7c639f9f2ee5098eac951a45f42f97758654eacd
Reviewed-on: https://go-review.googlesource.com/70230
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds support for accelerating time.Now by using
the __vdso_clock_gettime fast-path via the vDSO on linux/386
if it is available.
When the vDSO path to the clocks is available, it is typically
5x-10x faster than the syscall path (see benchmark extract
below). Two such calls are made for each time.Now() call
on most platforms as of go 1.9.
- Add vdso_linux_386.go, containing the ELF32 definitions
for use by vdso_linux.go, the maximum array size, and
the symbols to be located in the vDSO.
- Modify runtime.walltime and runtime.nanotime to check for
and use the vDSO fast-path if available, or fall back to
the existing syscall path.
- Reduce the stack reservations for runtime.walltime and
runtime.monotime from 32 to 16 bytes. It appears the syscall
path actually only needed 8 bytes, but 16 is now needed to
cover the syscall and vDSO paths.
- Remove clearing DX from the syscall paths as clock_gettime
only takes 2 args (BX, CX in syscall calling convention),
so there should be no need to clear DX.
The included BenchmarkTimeNow was run with -cpu=1 -count=20
on an "Intel(R) Celeron(R) CPU J1900 @ 1.99GHz", comparing
released go 1.9.1 vs this change. This shows a gain in
performance on linux/386 (6.89x), and that no regression
occurred on linux/amd64 due to this change.
Kernel: linux/i686, GOOS=linux GOARCH=386
name old time/op new time/op delta
TimeNow 978ns ± 0% 142ns ± 0% -85.48% (p=0.000 n=16+20)
Kernel: linux/x86_64, GOOS=linux GOARCH=amd64
name old time/op new time/op delta
TimeNow 125ns ± 0% 125ns ± 0% ~ (all equal)
Gains are more dramatic in virtualized environments,
presumably due to the overhead of virtualizing the syscall.
Fixes#22190
Change-Id: I2f83ce60cb1b8b310c9ced0706bb463c1b3aedf8
Reviewed-on: https://go-review.googlesource.com/69390
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
syscall.Select uses SYS_PSELECT6 on arm64 and mipx64x, however this
syscall expects its 5th argument to be of type Timespec (with seconds
and nanoseconds) instead of type Timeval (with seconds and microseconds)
This leads to the timeout being too short by a factor of 1000.
This CL fixes this by adjusting the timeout argument accordingly,
similarly to how glibc does it for architectures where neither
SYS_SELECT nor SYS__NEWSELECT are available.
Fixes#22246
Change-Id: I33a183b0b87c2dae4a77a2d00f8615169fad48dd
Reviewed-on: https://go-review.googlesource.com/70590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some ARM64-specific instructions (such as SIMD instructions) are not supported.
This patch adds support for the following:
1. Extended register, e.g.:
ADD Rm.<ext>[<<amount], Rn, Rd
<ext> can have the following values:
UXTB, UXTH, UXTW, UXTX, SXTB, SXTH, SXTW and SXTX
2. Arrangement for SIMD instructions, e.g.:
VADDP Vm.<T>, Vn.<T>, Vd.<T>
<T> can have the following values:
B8, B16, H4, H8, S2, S4 and D2
3. Width specifier and element index for SIMD instructions, e.g.:
VMOV Vn.<T>[index], Rd // MOV(to general register)
<T> can have the following values:
S and D
4. Register List, e.g.:
VLD1 (Rn), [Vt1.<T>, Vt2.<T>, Vt3.<T>]
5. Register offset variant, e.g.:
VLD1.P (Rn)(Rm), [Vt1.<T>, Vt2.<T>] // Rm is the post-index register
6. Go assembly for ARM64 reference manual
new added instructions are required to have according explanation items in
the manual and items for existed instructions will be added incrementally
For more information about the refinement background, please refer to the
discussion (https://groups.google.com/forum/#!topic/golang-dev/rWgDxCrL4GU)
This patch only adds syntax and doesn't break any assembly that already exists.
Change-Id: I34e90b7faae032820593a0e417022c354a882008
Reviewed-on: https://go-review.googlesource.com/41654
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The GIF format allows for an image to contain a global color table which
might be used for some or every frame in an animated GIF. This palette
contains 24-bit opaque RGB values. An individual frame may use the
global palette and enable transparency by picking one number to be
transparent, instead of the color value in the palette.
image/gif decodes a GIF, which contains an []*image.Paletted that holds
each frame. When decoded, if a frame has a transparent color and uses
the global palette, a copy of the global []color.Color is made, and the
transparency color index is replaced with color.RGBA{}.
When encoding a GIF, each frame's palette is encoded to the form it
might exist in a GIF, up to 768 bytes "RGBRGBRGBRGB...". If a frame's
encoded palette is equal to the encoded global color table, the frame
will be encoded with the flag set to use the global color table,
otherwise the frame's palette will be included.
So, if the color in the global color table that matches the transparent
index of one frame wasn't black (and it frequently is not), reencoding a
GIF will likely result in a larger file because each frame's palette
will have to be encoded inline.
This commit takes a frame's transparent color index into account when
comparing an individual image.Paletted's encoded color table to the
global color table.
Fixes#22137
Change-Id: I5460021da6e4d7ce19198d5f94a8ce714815bc08
Reviewed-on: https://go-review.googlesource.com/68313
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Excluded when -short because it still runs relatively long,
but deflaked.
Removed timeouts from normal path and ensured that they were
not needed and that reference files did not change.
Use "tbreak" instead of "break" with gdb to reduce chance
of multiple hits on main.main. (Seems not enough, but a
move in the right direction).
By default, testing ignores repeated lines that occur when
nexting. This appears to sometimes be timing-dependent and
is the observed source of flakiness in testing so far.
Note that these can also be signs of a bug in the generated
debugging output, but it is one of the less-confusing bugs
that can occur.
By default, testing with gdb uses compilation with
inlining disabled to prevent dependence on library code
(it's a bug that library code is seen while Nexting, but
the bug is current behavior).
Also by default exclude all source files outside /testdata
to prevent accidental dependence on library code. Note that
this is currently only applicable to dlv because (for the
debugging information we produce) gdb does not indicate a
change in the source file for inlined code.
Added flags -i and -r to make gdb testing compile with
inlining and be sensitive to repeats in the next stream.
This is for developer-testing and so we can describe these
problems in bug reports.
Updates #22206.
Change-Id: I9a30ebbc65aa0153fe77b1858cf19743bdc985e4
Reviewed-on: https://go-review.googlesource.com/69930
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a preparation step for adding vDSO support on linux/386.
This change relocates the elf64 and amd64 specifics from
vdso_linux.go to a new vdso_linux_amd64.go.
This should enable vdso_linux.go to be used for vDSO
support on linux architectures other than amd64.
- Relocate the elf64X structure definitions appropriate to amd64,
and change their names to elfX so that the code in vdso_linux.go
is ELFnn-agnostic.
- Relocate the sym_keys and corresponding __vdso_* variables
appropriate to amd64.
- Provide an amd64-specific constant for the maximum byte size of
an array, and use this in vdso_linux.go to compute constants for
sizing the elf structure arrays traversed in the loaded vDSO.
Change-Id: I1edb4e4ec9f2d79b7533aa95fbd09f771fa4edef
Reviewed-on: https://go-review.googlesource.com/69391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently we look to see if the main.main symbol address is in the
module data text range. This requires access to the main.main
symbol, which usually the runtime has, but does not when building
a plugin.
To avoid a dynamic relocation to main.main (which I haven't worked
out how to have the linker generate on darwin), stop using the
symbol. Instead record a boolean in the moduledata if the module
has the main function.
Fixes#22175
Change-Id: If313a118f17ab499d0a760bbc2519771ed654530
Reviewed-on: https://go-review.googlesource.com/69370
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow CL 41477 and add two more line position tests for yyerror calls
in the typechecker which are currently not tested.
Update #19683
Change-Id: Iacd865195a3bfba87d8c22655382af267aba47a9
Reviewed-on: https://go-review.googlesource.com/70251
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
When we split separate packages into separate compilation units, we
lost PC range information because it was no longer contiguous. This
brings it back by constructing proper per-package PC range tables.
Change-Id: Id0ab5187e08ac5d13b3d3794977bfc857a56224f
Reviewed-on: https://go-review.googlesource.com/69974
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, the linker generates one huge DWARF compilation unit for
the entire Go binary. This commit creates a separate compilation unit
and line table per Go package.
We temporarily lose compilation unit PC range information, since it's
now discontiguous, so harder to emit. We'll bring it back in the next
commit.
Beyond being "more traditional", this has various technical
advantages:
* It should speed up line table lookup, since that requires a
sequential scan of the line table. With this change, a debugger can
first locate the per-package line table and then scan only that line
table.
* Once we emit compilation unit PC ranges again, this should also
speed up various other debugger reverse PC lookups.
* It puts us in a good position to move more DWARF generation into the
compiler, which could produce at least the CU header, per-function
line table fragments, and per-function frame unwinding info that the
linker could simply paste together.
* It will let us record a per-package compiler command-line flags
(#22168).
Change-Id: Ibac642890984636b3ef1d4b37fe97f4453c2cc84
Reviewed-on: https://go-review.googlesource.com/69973
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The DWARF code currently clears all section relocations every time it
creates a section. This is unnecessary and confusing, so don't do it.
This dates back to
https://codereview.appspot.com/7891044/diff/26001/src/cmd/ld/dwarf.c.
At the time, this was only done for one symbol and that symbol was
used solely for collecting relocations (which is why it made sense to
clear the relocations but not the actual data). Furthermore, DWARF
generation potentially required two passes, so it was important to
clear the state from the first pass. None of this is true now, but
this pattern had been cargo-culted all over the dwarf.go.
Change-Id: I87d4ff8ccd5c807796241559be46168ce3ccb49a
Reviewed-on: https://go-review.googlesource.com/70312
Run-TryBot: Austin Clements <austin@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The .debug_aranges section is an odd vestige of DWARF, since its
contents are easy and efficient for a debugger to reconstruct from the
attributes of the top-level compilation unit DIEs. Neither GCC nor
clang emit it by default these days. GDB and Delve ignore it entirely.
LLDB will use it if present, but is happy to construct the index from
the compilation unit attributes (and, indeed, a remarkable variety of
other ways if those aren't available either).
We're about to split up the compilation units by package, which means
they'll have discontiguous PC ranges, which is going to make
.debug_aranges harder to construct (and larger).
Rather than try to maintain this essentially unused code, let's
simplify things and remove it.
Change-Id: I8e0ccc033b583b5b8908cbb2c879b2f2d5f9a50b
Reviewed-on: https://go-review.googlesource.com/69972
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
During Mach-O linking, dsymutil takes the DWARF from individual object
files and combines it into a debug archive. Because it's content-aware,
it doesn't need our help to do its job. Nonetheless, it does try to
honor relocations that are present in its input.
When dsymutil encounters a relocation, it uses the value of that
relocation as an index into the debug map to find its final location.
When it does that, it's assuming that the value is an address in the
object file. But DWARF references are section-relative. So when it
processes a relocation for a DWARF reference, it gets confused,
and if the value happens to match the address of a function or
data symbol, it will rewrite it incorrectly.
Since the relocations don't help, and can hurt, drop them when
externally linking a Mach-O binary.
Fixes#22068
Change-Id: I8ec36da626575d9f6c8d0e7a0b76eab8ba22d62c
Reviewed-on: https://go-review.googlesource.com/68330
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The alternative signal stack doesn't work on ios, so the setup of
the alternative stack was skipped. The corresponding unminitSignals
was effectively a no-op on ios until CL 70130. Skip unminitSignals
on ios to restore the previous behaviour.
For the ios builders.
Change-Id: I5692ca7f5997e6b9d10cc5f2383a5a37c42b133c
Reviewed-on: https://go-review.googlesource.com/70270
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
CL 36799 made SetFileCompletionNotificationModes to be called for
file handles. I don't think it is correct. Revert that change.
Fixes#22024Fixes#22207
Change-Id: I26260e8a727131cffbf60958d79eca2457495554
Reviewed-on: https://go-review.googlesource.com/69871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Current code assumes that SetFileCompletionNotificationModes
is safe to call even if we know that it is not safe to use
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag. It appears (see issue #22149),
SetFileCompletionNotificationModes crashes when we call it without
FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag.
Do not call SetFileCompletionNotificationModes in that situation.
We are allowed to do that, because SetFileCompletionNotificationModes
is just an optimisation.
Fixes#22149
Change-Id: I0ad3aff4eabd8c27739417a62c286b1819ae166a
Reviewed-on: https://go-review.googlesource.com/69870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Decode decodes entire GIF image and returns the first frame as an
image.Image. There's no need for it to keep every decoded frame in
memory except for the one it returns.
Fixes#22199
Change-Id: I76b4bd31608ebc76a1a3df02e85c20eb80df7877
Reviewed-on: https://go-review.googlesource.com/69890
Reviewed-by: Nigel Tao <nigeltao@golang.org>
CL 69292 unified the amd64 entry-points, but Dragonfly doesn't follow
the same entry-point argument conventions as most other amd64
platforms. Fix the Dragonfly entry point.
Change-Id: I0f84e2e4101ce68217af185ee9baaf455b8b6dad
Reviewed-on: https://go-review.googlesource.com/70212
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since CL 46037, the runtime is crashing after calling
exitThread on Plan 9.
The exitThread function shouldn't be called on
Plan 9, because the system manages thread stacks.
Fixes#22221.
Change-Id: I5d61c9660a87dc27e4cfcb3ca3ddcb4b752f2397
Reviewed-on: https://go-review.googlesource.com/70190
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Previously, we were treating cross-package function calls as free for
inlining budgeting.
In theory, we should be able to recompute InlCost from the
exported/reimported function bodies. However, that process mutates the
structure of the Node AST enough that it doesn't preserve InlCost. To
avoid unexpected issues, just record and restore InlCost in the export
data.
Fixes#19261.
Change-Id: Iac2bc0d32d4f948b64524aca657051f9fc96d92d
Reviewed-on: https://go-review.googlesource.com/70151
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Noticed while reading some code that the two branches in this loop body
shared the last statements. Rewrite it in a way that they are not
duplicated.
Passes toolstash -cmp on std.
Change-Id: I3356ca9fa37c32eee496e221d7830bfc581dade1
Reviewed-on: https://go-review.googlesource.com/66470
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Calls to a closure held in a local, non-escaping,
variable can be inlined, provided the closure body
can be inlined and the variable is never written to.
The current implementation has the following limitations:
- closures with captured variables are not inlined because
doing so naively triggers invariant violation in the SSA
phase
- re-assignment check is currently approximated by checking
the Addrtaken property of the variable which should be safe
but may miss optimization opportunities if the address is
not used for a write before the invocation
Updates #15561
Change-Id: I508cad5d28f027bd7e933b1f793c14dcfef8b5a1
Reviewed-on: https://go-review.googlesource.com/65071
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Android's libc creates a signal stack for every thread it creates. In
Go, minitSignalStack picks up this existing signal stack and puts it
in m.gsignal.stack. However, if we later try to exit a thread (because
a locked goroutine is exiting), we'll attempt to stackfree this
libc-allocated signal stack and panic.
Fix this by clearing gsignal.stack when we unminitSignals in such a
situation.
This should fix the Android build, which is currently broken.
Change-Id: Ieea8d72ef063d22741c54c9daddd8bb84926a488
Reviewed-on: https://go-review.googlesource.com/70130
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In #10909, it was decided that "Deprecated:" is a magic string for
tools (e.g., #17056 for godoc) to detect deprecated identifiers.
Use those convention instead of custom written prose.
Change-Id: Ia514fc3c88fc502e86c6e3de361c435f4cb80b22
Reviewed-on: https://go-review.googlesource.com/70110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
In order to improve the line numbering for debuggers,
it's necessary to trace lines through compilation.
This makes it (much) easier to follow.
The format of the last column of the ssa.html output was
also changed to reduce the spamminess of the file name,
which is usually the same and makes it far harder to read
instructions and line numbers, and to make it wider and also
able to break words when wrapping (long path names still
can push off the end otherwise; side-to-side scrolling was
tried but was more annoying than the occasional wrapped
line).
Sample output now, where [...] is elision for sake of making
the CL character-counter happy -- and the (##) line numbers
are rendered in italics and a smaller font (11 point) under
control of a CSS class "line-number".
genssa
# /Users/drchase/[...]/ssa/testdata/hist.go
00000 (35) TEXT "".main(SB)
00001 (35) FUNCDATA $0, gclocals·7be4bb[...]1e8b(SB)
00002 (35) FUNCDATA $1, gclocals·9ab98a[...]4568(SB)
v920 00003 (36) LEAQ ""..autotmp_31-640(SP), DI
v858 00004 (36) XORPS X0, X0
v6 00005 (36) LEAQ -48(DI), DI
v6 00006 (36) DUFFZERO $277
v576 00007 (36) LEAQ ""..autotmp_31-640(SP), AX
v10 00008 (36) TESTB AX, (AX)
b1 00009 (36) JMP 10
and from an earlier phase:
b18: ← b17
v242 (47) = Copy <mem> v238
v243 (47) = VarKill <mem> {.autotmp_16} v242
v244 (48) = Addr <**bufio.Scanner> {scanner} v2
v245 (48) = Load <*bufio.Scanner> v244 v243
[...]
v279 (49) = Store <mem> {int64} v277 v276 v278
v280 (49) = Addr <*error> {.autotmp_18} v2
v281 (49) = Load <error> v280 v279
v282 (49) = Addr <*error> {err} v2
v283 (49) = VarDef <mem> {err} v279
v284 (49) = Store <mem> {error} v282 v281 v283
v285 (47) = VarKill <mem> {.autotmp_18} v284
v286 (47) = VarKill <mem> {.autotmp_17} v285
v287 (50) = Addr <*error> {err} v2
v288 (50) = Load <error> v287 v286
v289 (50) = NeqInter <bool> v288 v51
If v289 → b21 b22 (line 50)
Change-Id: I3f46310918f965761f59e6f03ea53067237c28a8
Reviewed-on: https://go-review.googlesource.com/69591
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This adds the _lib entry point to various GOOS_amd64.s files.
A future CL will enable c-archive/c-shared mode for those targets.
As far as I can tell, the newosproc0 function in os_darwin.go was
passing the wrong arguments to bsdthread_create. The newosproc0
function is never called in the current testsuite.
Change-Id: Ie7c1c2e326cec87013e0fea84f751091b0ea7f51
Reviewed-on: https://go-review.googlesource.com/69711
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Starting in gcc 6, -pie is passed to the linker by default
on some platforms, including ppc64le. If the objects
being linked are not built for -pie then in some cases the
executable could be in error. To avoid that problem, -no-pie
should be used with gcc to override the default -pie option
and generate a correct executable that can be run without error.
Fixes#22126
Change-Id: I4a052bba8b9b3bd6706f5d27ca9a7cebcb504c95
Reviewed-on: https://go-review.googlesource.com/70072
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are two places in DWARF generation that create symbols when they
really just want to get the symbol if it exists. writeranges, in
particular, will create a DWARF range symbol for every single textp
symbol (though they won't get linked into any list, so they don't
affect the binary).
Fix these to use ROLookup instead of Lookup.
Change-Id: I401eadf22890e296bd08bccaa6ba2fd8fac800cd
Reviewed-on: https://go-review.googlesource.com/69971
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
In the distant past, Pipe was implemented with channels and a
long running pipe.run goroutine (see CL 994043).
This approach of having all communication serialized through the
run method was error prone giving Pipe a history of deadlocks
and race conditions.
After the introduction of sync.Cond, the implementation was rewritten
(see CL 4252057) to use condition variables and avoid the
long running pipe.run goroutine. While this implementation is superior
to the previous one, this implementation is strange in that the
p.data field is always set immediately prior to signaling the other
goroutine with Cond.Signal, effectively making the combination of the
two a channel-like operation. Inferior to a channel, however, this still
requires explicit locking around the p.data field.
The data+rwait can be effectively be replaced by a "chan []byte" to
inform a reader that there is data available.
The data+wwait can be effectively be replaced by a "chan int" to
inform a writer of how many bytes were read.
This implementation is a simplified from net.Pipe in CL 37402.
Change-Id: Ia5b26320b0525934fd87a3b69a091c787167f5aa
Reviewed-on: https://go-review.googlesource.com/65330
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Implement deadline functionality on Pipe so that it properly implements
the semantics of the Conn interface. This aids usages of Pipe (often in
unit tests) with a more realistic and complete implementation.
The new implementation avoids a dependency on a io.Pipe since it is
impossible to keep the prior semantics of synchronous reads and writes
while also trying to implement cancelation over an io.{Reader,Writer}
that fundamentally has no cancelation support.
The fact that net.Pipe is synchronous (and documented as such)
is unfortunate because no realistic network connection is synchronous.
Instead real networks introduces a read and write buffer of some sort.
However, we do not change the semantics for backwards compatibility.
The approach taken does not leave any long-running goroutines,
meaning that tests that never call Close will not cause a resource leak.
Fixes#18170
Change-Id: I5140b1f289a0a49fb2d485f031b5aa0ee99ecc30
Reviewed-on: https://go-review.googlesource.com/37402
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The content ID will be needed for content-based staleness
determination. It is defined as the SHA256 hash of the file
in which it appears, with occurrences of the build+content IDs
changed to zeros during the hashing operation.
Storing the content ID in the archives is a little tricky
but it means that later builds need not rehash the archives
each time they are referenced, so under the assumption
that each package is imported at least once after being
compiled, hashing at build time is a win. (Also the whole
file is more likely to be in cache at build time,
since we just wrote it.)
In my unscientific tests, the time for "go build -a std cmd"
rises from about 14.3s to 14.5s on my laptop, or under 2%.
Change-Id: Ia3d4dc657d003e8295631f73363868bd92ebf96a
Reviewed-on: https://go-review.googlesource.com/69054
Reviewed-by: David Crawshaw <crawshaw@golang.org>
If the stack frame is too large, abort immediately.
We used to generate code first, then abort.
In issue 22200, generating code raised a panic
so we got an ICE instead of an error message.
Change the max frame size to 1GB (from 2GB).
Stack frames between 1.1GB and 2GB didn't used to work anyway,
the pcln table generation would have failed and generated an ICE.
Fixes#22200
Change-Id: I1d918ab27ba6ebf5c87ec65d1bccf973f8c8541e
Reviewed-on: https://go-review.googlesource.com/69810
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL does a few things.
1. It moves the existing "read a build ID" code out of the go command
and into cmd/internal/buildid.
2. It adds new code there to "write a build ID".
3. It adds better tests.
4. It encapsulates cmd/internal/buildid into a new standalone program
"go tool buildid".
The go command is going to use the new "write a build ID" functionality
in a future CL. Adding the separate "go tool buildid" gives "go build -x"
a printable command to explain what it is doing in that new step.
(This is similar to the go command printing "go tool pack" commands
equivalent to the actions it is taking, even though it's not invoking pack
directly.) Keeping go build -x honest means that other build systems can
potentially keep up with the go command.
Change-Id: I01c0a66e30a80fa7254e3f2879283d3cd7aa03b4
Reviewed-on: https://go-review.googlesource.com/69053
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This makes it more obvious which of the two builds is failing by
putting "dbg" or "opt" directly in the test name. It also makes it
possible for them to fail independently, so a failure in "dbg" doesn't
mask a failure in "opt", and to visibly skip the opt test when run
with an unoptimized runtime.
Change-Id: I3403a7fd3c1a13ad51a938bb95dfe54c320bb58e
Reviewed-on: https://go-review.googlesource.com/69970
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Right now users have to infer why they would want LockOSThread and
when it may or may not be appropriate to call UnlockOSThread. This
requires some understanding of Go's internal thread pool
implementation, which is unfortunate.
Improve the situation by making the documentation on these functions
more prescriptive so users can figure out when to use them even if
they don't know about the scheduler.
Change-Id: Ide221791e37cb5106dd8a172f89fbc5b3b98fe32
Reviewed-on: https://go-review.googlesource.com/52871
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
runtime.LockOSThread is sometimes used when the caller intends to put
the OS thread into an unusual state. In this case, we never want to
return this thread to the runtime thread pool. However, currently
exiting the goroutine implicitly unlocks its OS thread.
Fix this by terminating the locked OS thread when its goroutine exits,
rather than simply returning it to the pool.
Fixes#20395.
Change-Id: I3dcec63b200957709965f7240dc216fa84b62ad9
Reviewed-on: https://go-review.googlesource.com/46038
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, threads created by the runtime exist until the whole
program exits. For #14592 and #20395, we want to be able to exit and
clean up threads created by the runtime. This commit implements that
mechanism.
The main difficulty is how to clean up the g0 stack. In cgo mode and
on Solaris and Windows where the OS manages thread stacks, we simply
arrange to return from mstart and let the system clean up the thread.
If the runtime allocated the g0 stack, then we use a new exitThread
syscall wrapper that arranges to clear a flag in the M once the stack
can safely be reaped and call the thread termination syscall.
exitThread is based on the existing exit1 wrapper, which was always
meant to terminate the calling thread. However, exit1 has never been
used since it was introduced 9 years ago, so it was broken on several
platforms. exitThread also has the additional complication of having
to flag that the stack is unused, which requires some tricks on
platforms that use the stack for syscalls.
This still leaves the problem of how to reap the unused g0 stacks. For
this, we move the M from allm to a new freem list as part of the M
exiting. Later, allocm scans the freem list, finds Ms that are marked
as done with their stack, removes these from the list and frees their
g0 stacks. This also allows these Ms to be garbage collected.
This CL does not yet use any of this functionality. Follow-up CLs
will. Likewise, there are no new tests in this CL because we'll need
follow-up functionality to test it.
Change-Id: Ic851ee74227b6d39c6fc1219fc71b45d3004bc63
Reviewed-on: https://go-review.googlesource.com/46037
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Every cmd/thing is 'go tool thing' except for go and gofmt.
But the table in cmd/go enumerates all the things instead of
saying that go and gofmt are the exceptions.
Change that, so that when adding new tools it's not
necessary to update this table.
Change-Id: Ia6fef41b4d967249b19971a0d03e5acb0317ea82
Reviewed-on: https://go-review.googlesource.com/69052
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Currently, since Ms never exit, the number of Ms, the number of Ms
ever created, and the ID of the next M are all the same and must be
small. That's about to change, so rename sched.mcount to sched.mnext
to make it clear it's the number of Ms ever created (and the ID of the
next M), change its type to int64, and use mcount() for the number of
Ms. In the next commit, mcount() will become slightly less trivial.
For #20395.
Change-Id: I9af34d36bd72416b5656555d16e8085076f1b196
Reviewed-on: https://go-review.googlesource.com/68750
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Today they happen during the build phase; they should happen
during the load phase instead, along with the C check.
Change-Id: I6074a995b8e29275549aafa574511b735642d85b
Reviewed-on: https://go-review.googlesource.com/69051
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
mstart is the entry point for new threads, so it certainly can't
interact with GC enough to have write barriers. We move the one small
piece that is allowed to have write barriers out into its own
function.
Change-Id: Id9c31d6ffac31d0051fab7db15eb428c11cadbad
Reviewed-on: https://go-review.googlesource.com/46035
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Logically the build needs to start treating a.Package as immutable,
since we might want to build a.Package multiple ways.
Record the built target in a.built instead.
Right now a.built is predictable ahead of time, but we want to
move toward satisfying some builds from a cache directory,
in which case a.built will point into the cache directory
and not be determined until action execution time.
There is probably more to do with shared libraries, but this
does not break what's there.
Change-Id: I941988b520bee2f664fd8cabccf389e1dc29628b
Reviewed-on: https://go-review.googlesource.com/69050
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Everything got a bit tangled together in b.action1.
Try to tease things apart again.
In general this is a refactoring of the existing code, with limited
changes to the effect of the code.
The main additional change is to complete a.Deps for link actions.
That list now directly contains all the inputs the linker will attempt
to read, eliminating the need for a transitive traversal of the entire
action graph to find those. The comepleteness of a.Deps will be
important when we eventually use it to decide whether an cached
action output can be reused.
all.bash passes, but it's possible I've broken some subtety of
buildmode=shared again. Certainly that code took the longest
to get working.
Change-Id: I34e849eda446dca45a9cfce02b07bec6edb6d0d4
Reviewed-on: https://go-review.googlesource.com/69831
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Applications that need to manipulate kernel thread state are currently
on thin ice in Go: they can use LockOSThread to prevent other
goroutines from running on the manipulated thread, but Go may clone
this manipulated state into a new thread that's put into the runtime's
thread pool along with other threads.
Fix this by never starting a new thread from a locked thread or a
thread that may have been started by C. Instead, the runtime starts a
"template thread" with a known-good state. If it then needs to start a
new thread but doesn't know that the current thread is in a good
state, it forwards the thread creation to the template thread.
Fixes#20676.
Change-Id: I798137a56e04b7723d55997e9c5c085d1d910643
Reviewed-on: https://go-review.googlesource.com/46033
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
To the extent that invoking the compiler and invoking the linker
have different dependency requirements, representing both steps
by a single action node leads to confusion.
If we move to having separate .a and .x (import metadata) files
in the standard builds, then the .a is a link dependency but not
a compile dependency, and vice versa for .x.
Today, in shared library builds, the .a is a compile dependency
and a link dependency, while the .so is only a link dependency.
Also in this CL: change the gccgo link step to extract _cgo_flags
into root.Objdir, which is private to the link step, instead of into
b.WorkDir, which is shared by all the link steps that could possibly
be running in parallel. And attempt to handle the -n and -x flags
when loading _cgo_flags, instead of dying attempting to read
an archive that wasn't written.
Also in this CL: create a.Objdir before running a.Func, to avoid
duplicating the Mkdir(a.Objdir) in every a.Func.
A future CL will update the link action's Deps to be accurate.
(Right now the link steps search out the true Deps by walking
the entire action graph.)
Change-Id: I15128ce2bd064887f98abc3a4cf204241f518631
Reviewed-on: https://go-review.googlesource.com/69830
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This error was not used when using git because nested git is permitted.
Add test using Mercurial, so that at least we have a test, even though
the test is not run by default.
Fixes#22157Fixes#22201
Change-Id: If521f3c09b0754e00e56fa3cd0364764a57a43ad
Reviewed-on: https://go-review.googlesource.com/69670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is a preparation step for adding vDSO support on linux/386.
In a follow-on change, the vDSO ELF symbol lookup code in this
file will be refactored so it can be used on multiple architectures.
First, move the file to an architecture-neutral file name so that
the change history is preserved. Build tags are added so that the
build behaves as it did before.
vdso_linux_amd64.go will be recreated later, just containing the
amd64 specifics.
If the move and refactor were combined in a single change, then the
history to date would be lost because git would see the existing code
as a new file.
Change-Id: Iddb5da0d7faf141fd7cc835fe6a80c80153897e9
Reviewed-on: https://go-review.googlesource.com/69710
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
OTYPESW Op comment says
// List = Left.(type)
this seems to be wrong. Adding
fmt.Printf("n: %v\n", cond)
fmt.Printf(" n.List: %v\n", cond.List)
fmt.Printf(" n.Left: %v\n", cond.Left)
fmt.Printf(" n.Right: %v\n", cond.Right)
to (s *typeSwitch) walk(sw *Node), and compiling the following code
snippet
var y interface{}
switch x := y.(type) {
default:
println(x)
}
prints
n: <node TYPESW>
n.List:
n.Left: x
n.Right: y
The correct OTYPESW Node field positions are
// Left = Right.(type)
This is confirmed by the fact that, further in the code,
typeSwitch.walk() checks that Right (and not Left) is of type
interface:
cond.Right = walkexpr(cond.Right, &sw.Ninit)
if !cond.Right.Type.IsInterface() {
yyerror("type switch must be on an interface")
return
}
This patch fixes the OTYPESW comment.
Change-Id: Ief1e409cfabb7640d7f7b0d4faabbcffaf605450
Reviewed-on: https://go-review.googlesource.com/69112
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This re-enables functionality that inadvertently was disabled in the
(long) past.
Also, don't perform branch checks if we had errors in a function
to avoid spurious errors or (worst-case) crashes.
Slightly modified test/fixedbugs/issue14006.go to make sure the
test still reports invalid label errors (the surrounding function
must be syntactically correct).
Change-Id: Id5642930877d7cf3400649094ec75c753b5084b7
Reviewed-on: https://go-review.googlesource.com/69770
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 59230 changed Writer.WriteHeader to ignore the ChangeTime and AccessTime
fields when considering using the USTAR format when the format is unspecified.
This policy is confusing and leads to unexpected behavior where some files
have ModTime only, while others have ModTime+AccessTime+ChangeTime if the
format became PAX for some unrelated reason (e.g., long pathname).
Change the policy to simply always ignore ChangeTime, AccessTime, and
sub-second time resolutions unless the user explicitly specifies a format.
This is a safe policy change since WriteHeader had no support for the
above features in any Go release.
Support for ChangeTime and AccessTime was added in CL 55570.
Support for sub-second times was added in CL 55552.
Both CLs landed after the latest Go release (i.e., Go1.9), which was
cut from the master branch around August 6th, 2017.
Change-Id: Ib82baa1bf9dd4573ed4f674b7d55d15f733a4843
Reviewed-on: https://go-review.googlesource.com/69296
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The USTAR format says:
<<<
Implementors should be aware that the previous file format did not include
a mechanism to archive directory type files.
For this reason, the convention of using a filename ending with
<slash> was adopted to specify a directory on the archive.
>>>
In light of this suggestion, make the following changes:
* Writer.WriteHeader refuses to encode a header where a file that
is obviously a file-type has a trailing slash in the name.
* formatter.formatString avoids encoding a trailing slash in the event
that the string is truncated (the full string will be encoded elsewhere,
so stripping the slash is safe).
* Reader.Next treats a TypeRegA (which is the zero value of Typeflag)
as a TypeDir if the name has a trailing slash.
Change-Id: Ibf27aa8234cce2032d92e5e5b28546c2f2ae5ef6
Reviewed-on: https://go-review.googlesource.com/69293
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
mkinlcall1 already guards against recursively inlining functions into
themselves, so there's no need to clear and restore fn.Func.Inl during
recursive inlining.
Passes toolstash-check.
Change-Id: I8bf0c8dea8788d94d3ea5670610b4acb1d26d2fb
Reviewed-on: https://go-review.googlesource.com/69310
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This should make parallel execution a bit clearer.
With -p=1 it should make the execution completely unambiguous.
Fixes#19280.
Change-Id: Ib48cdfe96896d01b0d8f98ccb2fab614407a7d92
Reviewed-on: https://go-review.googlesource.com/49430
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before, -1 meant a node being nil or not an OLITERAL, and 0 meant an
OLITERAL missing a Val.
However, the use of this value was confusing and led to some issues,
such as swt.go checking for < 0 instead of <= 0, causing panics.
We never need to differentiate these two cases, so collapse both into 0.
To make it clear that negative values can no longer happen, make Ctype
an uint8.
With this change, we can now get rid of the two n.Type == nil checks
in swt.go added to fix a couple of these panics.
Thanks to Matthew Dempsky for spotting this inconsistency.
Fixes#22001.
Change-Id: I51c65a76f38a3e16788b6a3b57932dad3436dc7e
Reviewed-on: https://go-review.googlesource.com/69510
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ADDconst op is no longer used for addresses, as we lower Addr to
MOVDaddr. There is no rule that produces ADDconst with a non-nil
sym. So we can remove the sym aux field in ADDconst and limit its
use for adding constant (not offset to symbol).
Passes "toolstash -cmp" on std cmd for GOARCH=ppc64 and ppc64le.
Change-Id: Icee35cdb34d8d121ad7035076dfd07595c7ff809
Reviewed-on: https://go-review.googlesource.com/69450
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
In https://golang.org/cl/9390 I messed up and put the critical extension
test in the wrong function. Thus it only triggered for leaf certificates
and not for intermediates or roots.
In practice, this is not expected to have a security impact in the web
PKI.
Change-Id: I4f2464ef2fb71b5865389901f293062ba1327702
Reviewed-on: https://go-review.googlesource.com/69294
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL 68490 reworked the way the panicmem function is exposed to the
C mach expection catcher. However, //go:cgo_export_static isn't enough:
the underlying assembly functions must not start with the middle dot.
Without the middle dot, the panicmem function's exported name is
not prefixed with its package; rename it to xx_cgo_panicmem to decrease
the chance of a symbol name clash.
Finally, mark the overridden C symbol weak to avoid duplicate symbol
errors from the host linker.
For the ios builders.
Change-Id: Ib87789fecec9314e398cf1bd8c04ba0b3a6642af
Reviewed-on: https://go-review.googlesource.com/69113
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This will be useful for debugging but is intentionally
undocumented and not guaranteed to persist in any
particular form.
Change-Id: I60710a1e94cfc2ce31fe91fc268c51985060f8df
Reviewed-on: https://go-review.googlesource.com/69330
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The core dump reader would like a bunch of ideal int
constants to be available in dwarf.
Makes the go binary 0.9% bigger.
Update #14517
Change-Id: I00cdfc7f53bcdc56fccba576c1d33010f03bdd95
Reviewed-on: https://go-review.googlesource.com/69270
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
CL50610 broke the build for noopt (different inlining
behavior) and clang (no gdb) so it needs to catch those
cases and skip.
The run/no-run logic was slightly cleaned up,
the name of gdb on OSX was made more robust (tries gdb
first, then ggdb), and the file names were canonicalized
before loggging instead of in comparison to reduce
gratuitous noise in diffs when things aren't otherwise
equal.
This probably doesn't fix problems on Alpine, but it should
provide a cleaner and less confusing failure.
Change-Id: I26c65bff5a8d3d60f1cd6ae02a282558c53dda67
Reviewed-on: https://go-review.googlesource.com/69371
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The '*' character is not allowed in ASN.1 PrintableString. However, due
to wide-spread use, we permit it so that we can parse many certificates
with wildcards. However, that also meant that generic strings with
asterisks in would be encoded as PrintableString.
This change makes the default for such strings to be UTF8String. Thus,
while the code PrintableStrings containing '*', it will not generate
them unless the string type was specified in the struct field tag.
Change-Id: I2d458da36649427352eeaa50a1b6020108b2ccbd
Reviewed-on: https://go-review.googlesource.com/68990
Reviewed-by: Adam Langley <agl@golang.org>
The old code was seriously broken: It assumed that a constant
declaration without a type would always inherit the type of
the previous declaration, but in fact it only inherits the
type of the previous declaration when there's no type and no
constant value.
While fixing this bug, found that the result was not sorted
deterministically in all situations due to a poor choice of
order value (which led to spurious test failures since the
tests assume deterministic outputs). Fixed that as well.
Added new test cases and fixed some old (broken) tests.
Fixes#16153.
Change-Id: I95b480e019b0fd3538638caba02fe651c69e0513
Reviewed-on: https://go-review.googlesource.com/68730
Reviewed-by: Alan Donovan <adonovan@google.com>
The //go:nosplit directive was visible in GoDoc because the function
that it preceeded (Gosched) is exported. This change moves the directive
above the documentation, hiding it from the output.
Change-Id: I281fd7573f11d977487809f74c9cc16b2af0dc88
Reviewed-on: https://go-review.googlesource.com/69120
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing logic for whether the left and right parts of an assignment
were equal only checked that the gofmt representation of the two was
equal. This only checks that the ASTs were equal.
However, that method is flawed. For example, if either of the
expressions contains a function call, the expressions may actually be
different even if their ASTs are the same. An obvious case is a func
call to math/rand to get a random integer, such as the one added in the
test.
If either of the expressions may have side effects, simply skip the
check. Reuse the logic from bool.go's hasSideEffects.
Fixes#22174.
Change-Id: Ied7f7543dc2bb8852e817230756c6d23bc801d90
Reviewed-on: https://go-review.googlesource.com/69116
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This attempts to choose better values for values that are
rematerialized (uses the XPos of the consumer, not the
original) and for unconditional branches (uses the last
assigned XPos in the block).
The JMP branches seem to sometimes end up with a PC in the
destination block, I think because of register movement
or rematerialization that gets placed in predecessor blocks.
This may be acceptable because (eyeball-empirically) that is
often the line number of the target block, so the line number
flow is correct.
Added proper test, that checks both -N -l and regular compilation.
The test is also capable (for gdb, delve soon) of tracking
variable printing based on comments in the source code.
There's substantial room for improvement in debugger behavior.
Updates #21098.
Change-Id: I13abd48a39141583b85576a015f561065819afd0
Reviewed-on: https://go-review.googlesource.com/50610
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Move some local declarations closer to their use, reducing their
respective lifetimes, also improve few error messages.
Follow up of CL 67370.
Updates #22095
Change-Id: I6131159ae8de571015ef5459b33d5c186e543a37
Reviewed-on: https://go-review.googlesource.com/69110
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also add -V=full to print a unique identifier of the specific tool being invoked.
This will be used for content-based staleness.
Also sort and clean up a few of the flag doc comments.
Change-Id: I786fe50be0b8e5f77af809d8d2dab721185c2abd
Reviewed-on: https://go-review.googlesource.com/68590
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The BadCBCPadding255 test from bogo failed because at most 255 trailing
bytes were checked, but for a padding of 255 there are 255 padding bytes
plus 1 length byte with value 255.
Change-Id: I7dd237c013d2c7c8599067246e31b7ba93106cf7
Reviewed-on: https://go-review.googlesource.com/68070
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Increase MaxBase from 36 to 62 and extend the conversion
alphabet with the upper-case letters 'A' to 'Z'. For int
conversions with bases <= 36, the letters 'A' to 'Z' have
the same values (10 to 35) as the corresponding lower-case
letters. For conversion bases > 36 up to 62, the upper-case
letters have the values 36 to 61.
Added MaxBase to api/except.txt: Clients should not make
assumptions about the value of MaxBase being constant.
The core of the change is in natconv.go. The remaining
changes are adjusted tests and documentation.
Fixes#21558.
Change-Id: I5f74da633caafca03993e13f32ac9546c572cc84
Reviewed-on: https://go-review.googlesource.com/65970
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
From a compact specification of control flow graphs,
generate complete set of possible assignment patterns to
output y, and also generate an interpretable specification.
Compiles (hoping for crash, or not) and then runs, where
the run checks function output against interpreted output
for various inputs observed to terminate in the interpreter.
In ssa_test.go, added ability to generate a test and run
(compile and run) the generated test, possibly with
modified environment variables. The generated test is
compiled including the -D=ssa/check/on flag, and if the
interpreter terminates in a small number of steps, then it
is also run to check the result.
Change-Id: I392c828e36c543411b7733ca0799628452733276
Reviewed-on: https://go-review.googlesource.com/22751
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Keep left-to-right order when referring to the number of
variables and values involved.
Fixes#22159.
Change-Id: Iccca12d3222f9d5e049939a9ccec07513c393faa
Reviewed-on: https://go-review.googlesource.com/68690
Reviewed-by: Russ Cox <rsc@golang.org>
"VEX.vvvv" field (VSR, VEX-specified-register) made explicit
in Optab encoding.
vexNDS, vexNDD, vexDDS and vexNOVSR do nothing,
this change does not produce any noticeable effect.
Rationale behind this change:
- keep more information inside optab entries
- make encodings match SDM more closely
- one less special rule to keep in mind
Pvex optabs are updated based on the Intel SDM descriptions.
Unused VEX combinations are removed;
it is problematic to choose VSR combinations for them
without actual Optabs that use them.
The origin of this idea can be found in:
https://go-review.googlesource.com/#/c/arch/+/66972/
Change-Id: I54634a72b44d61f4b924a1e45f2240aab7384dc2
Reviewed-on: https://go-review.googlesource.com/67890
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Adds last missing SSE4 instruction.
Also introduces additional ytab set 'yextractps'.
See https://golang.org/cl/57470 that adds other SSE4 instructions
but skips this one due to 'yextractps'.
To make EXTRACTPS less "sloppy", Yu2 oclass added to forbid
usage of invalid offset values in immediate operand.
Part of the mission to add missing amd64 SSE4 instructions to Go asm.
Change-Id: I0e67e3497054f53257dd8eb4c6268da5118b4853
Reviewed-on: https://go-review.googlesource.com/57490
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This CL optimizes assembly for len() or cap() division
by a power of 2 constants:
func lenDiv(s []int) int {
return len(s) / 16
}
amd64 assembly before the CL:
MOVQ "".s+16(SP), AX
MOVQ AX, CX
SARQ $63, AX
SHRQ $60, AX
ADDQ CX, AX
SARQ $4, AX
MOVQ AX, "".~r1+32(SP)
RET
amd64 assembly after the CL:
MOVQ "".s+16(SP), AX
SHRQ $4, AX
MOVQ AX, "".~r1+32(SP)
RET
The CL relies on the fact that len() and cap() result cannot
be negative.
Trigger stats for the added SSA rules on linux/amd64 when running
make.bash:
46 Div64
12 Mod64
The added SSA rules may trigger on more cases in the future
when SSA values will be populated with the info on their
lower bounds.
For instance:
func f(i int16) int16 {
if i < 3 {
return -1
}
// Lower bound of i is 3 here -> i is non-negative,
// so unsigned arithmetics may be used here.
return i % 16
}
Change-Id: I8bc6be5a03e71157ced533c01416451ff6f1a7f0
Reviewed-on: https://go-review.googlesource.com/65530
Reviewed-by: Keith Randall <khr@golang.org>
amd64 and 386 have rules to reduce multiplication by a positive power
of two, but a more general reduction (both for positive and negative
powers of two) is already performed by generic rules that were added
in CL 36323 to replace walkmul (see lines 166:173 in generic.rules).
The x86 and amd64 rules are never triggered during all.bash and can be
removed, reducing rules duplication.
The change also adds a few code generation tests for amd64 and 386.
Change-Id: I566d48186643bd722a4c0137fe94e513b8b20e36
Reviewed-on: https://go-review.googlesource.com/68450
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TestUnexportedSymbols requires dup2 that
my gcc installation does not have.
TestSignalHandlersWithNotify fails with:
undefined: syscall.SIGIO.
TestSignalHandlers fails with:
sched.h: No such file or directory.
TestExportedSymbolsWithDynamicLoad fails with:
dlfcn.h: No such file or directory.
Also add t.Helper calls to better error messages.
Updates #11058
Change-Id: I7eb514968464256b8337e45f57fcb7d7fe0e4693
Reviewed-on: https://go-review.googlesource.com/68410
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ORETJMP doesn't need an ONAME if we just set the target method on Sym
instead of Left. Conveniently, this is where fmt.go was looking for it
anyway.
Change the iface parameter and global compiling_wrappers to bool.
Passes toolstash-check.
Change-Id: I5333f8bcb4e06bf8161808041125eb95c439aafe
Reviewed-on: https://go-review.googlesource.com/68252
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
C_PPAUTO was matching offsets that is a multiple 8. But this
condition is dropped in CL 55610, causing unaligned offset
between 256 and 504 mistakenly matched to some classes, e.g.
C_UAUTO8K. This CL restores this condition, also fixes an
error that C_PPAUTO shouldn't match C_PSAUTO, because the
latter is not guaranteed to be multiple of 8. C_PPAUTO_8 is
unnecessary, removed.
Fixes#21992.
Change-Id: I75d5a0e5f5dc3dae335721fbec1bbcd4a3b862f2
Reviewed-on: https://go-review.googlesource.com/65730
Reviewed-by: David Chase <drchase@google.com>
exit1 calls the bsdthread_terminate system call on Darwin. Currently
it passes no arguments on 386, arm, and arm64, and an exit status on
amd64. None of these are right. The signature of bsdthread_terminate
is:
int bsdthread_terminate(user_addr_t stackaddr, size_t freesize, uint32_t port, uint32_t sem);
Fix all of the Darwin exit1 implementations to call
bsdthread_terminate with 0 for all of these arguments so it doesn't
try to unmap some random memory, free some random port, or signal a
random semaphore.
This isn't a problem in practice because exit1 is never called.
However, we're about to start using exit1.
Change-Id: Idc534d196e3104e5253fc399553f21eb608693d7
Reviewed-on: https://go-review.googlesource.com/46036
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The core dump reader wants to know the layout of this type.
No variable has this type, so it wasn't previously dumped
to DWARF output.
Change-Id: I982040b81bff202976743edc7fe53247533a9d81
Reviewed-on: https://go-review.googlesource.com/68312
Reviewed-by: Austin Clements <austin@google.com>
Currently, there is a single bit for LockOSThread, so two calls to
LockOSThread followed by one call to UnlockOSThread will unlock the
thread. There's evidence (#20458) that this is almost never what
people want or expect and it makes these APIs very hard to use
correctly or reliably.
Change this so LockOSThread/UnlockOSThread can be nested and the
calling goroutine will not be unwired until UnlockOSThread has been
called as many times as LockOSThread has. This should fix the vast
majority of incorrect uses while having no effect on the vast majority
of correct uses.
Fixes#20458.
Change-Id: I1464e5e9a0ea4208fbb83638ee9847f929a2bacb
Reviewed-on: https://go-review.googlesource.com/45752
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The primary build tools cmd/asm, cmd/compile, and cmd/link are
built during cmd/dist bootstrap and then assumed by cmd/go to
be available for any future builds.
The only tool invoked by cmd/go during a build and not in this list
is cmd/cgo; instead of being built during cmd/dist and assumed by
cmd/go, cmd/go arranges to build cmd/cgo if needed as part of
the regular build. We got here because at the time cmd/go was written,
cmd/cgo was the only build tool written in Go (the others were in C),
and so it made some sense to put cmd/dist in charge of building
the C tools and to have custom code in cmd/go to build cmd/cgo
just in time for it to be used by a particular build.
This custom code has historically been quite subtle, though, because
the build of cmd/cgo inherits whatever build flags apply to the
build that wants to use cmd/cgo. If you're not careful,
"go install -race strings" might under the wrong circumstances
also install a race-enabled cmd/cgo binary, which is unexpected
at the least.
The custom code is only going to get more problematic as we
move toward more precise analysis of whether dependencies are
up-to-date. In that case, "go build -race strings" will check to
see if there is not just a cmd/cgo already but a race-enabled
cmd/cgo, which makes no sense.
Instead of perpetuating the special case, treat cgo like all the
other build tools: build it first in cmd/dist, and then assume it is present.
This simplifies cmd/go.
Building cmd/cgo during bootstrap also allows the default
build of cmd/cgo to be built using cgo, which may be necessary
on future essentially-cgo-only systems.
Change-Id: I414e22c10c9920f4e98f97fa35ff22058c0f143d
Reviewed-on: https://go-review.googlesource.com/68338
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The loop finder doesn't return good information if it
encounters an irreducible loop. Make a start on improving
this, and set a function-level flag to indicate when there
is such a loop (and the returned information might be flaky).
Use that flag to prevent the loop rotater from getting
confused; the existing code seems to depend on artifacts
of the previous loop-finding algorithm. (There is one
irreducible loop in the go library, in "inflate.go").
Change-Id: If6e26feab38d9b009d2252d556e1470c803bde40
Reviewed-on: https://go-review.googlesource.com/42150
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Init functions are problematic because we want cmd/link to be
able to insert an import of runtime/cgo for external linking.
For all the other systems that just means putting runtime/cgo into
the binary. The linker is not set up to generate calls to init functions,
and luckily this one can be avoided entirely.
This means people don't have to import _ "runtime/cgo" in their
iOS programs anymore. The linker's default import is now enough.
This CL also adjusts cmd/go to record the linker's default import,
now that the explicit import is gone.
Change-Id: I81d23476663e03664f90d531c24db2e4f2e6c66b
Reviewed-on: https://go-review.googlesource.com/68490
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Historically, gc optimistically parsed the left-hand side of
assignments as expressions. Later, if it discovered a ":=" assignment,
it rewrote the parsed expressions as declarations.
This failed in the presence of dot imports though, because we lost
information about whether an imported object was named via a bare
identifier "Foo" or a normal qualified "pkg.Foo".
This CL fixes the issue by specially noding the left-hand side of ":="
assignments.
Fixes#22076.
Change-Id: I18190ecdb863112e7d009e1687e6112eec559921
Reviewed-on: https://go-review.googlesource.com/66810
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This applies the amd64-specific changes from CL 42611 to the s390x P256
implementation. The s390x implementation was disabled in CL 62292 and
this CL re-enables it.
Adam Langley's commit message from CL 42611:
The optimised P-256 includes a CombinedMult function, which doesn't do
dual-scalar multiplication, but does avoid an affine conversion for
ECDSA verification.
However, it currently uses an assembly point addition function that
doesn't handle exceptional cases.
Fixes#20215.
Change-Id: I2f6b532f495e85b8903475b4f64cc32a3b2f6769
Reviewed-on: https://go-review.googlesource.com/64290
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We're going to start building cmd/cgo as part of the bootstrap,
and with it debug/elf, so the copy here needs to work with Go 1.4.
It does except for the use of the new io.SeekStart etc constants,
so remove that use.
Change-Id: Ib7fcf46e1e9060f96d2bacaaf349c9b0df347550
Reviewed-on: https://go-review.googlesource.com/68337
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This shortens the args lists but also sets up better for
the content-based staleness changes.
While we're here, delete the now-unused Pkgpath method.
Change-Id: Ic60fa03efbc37a7c7fe9758a1cfa5dddef1a4151
Reviewed-on: https://go-review.googlesource.com/68335
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The following instructions were introduced in ARMv6, and the compiler
can do more optimization with them.
1. "MOVBS Rm@>i, Rd": rotates Rm 0/8/16/24 bits, does signed
byte extension to word, and writes the result to Rd.
2. "MOVHS Rm@>i, Rd": rotates Rm 0/8/16/24 bits, does signed
halfword extension to word, and writes the result to Rd.
3. "MOVBU Rm@>i, Rd": rotates Rm 0/8/16/24 bits, does unsigned
byte extension to word, and writes the result to Rd.
4. "MOVHU Rm@>i, Rd": rotates Rm 0/8/16/24 bits, does unsigned
half-word extension to word, and writes the result to Rd.
5. "XTAB Rm@>i, Rn, Rd": rotates Rm 0/8/16/24 bits, does signed
byte extension to word, adds Rn, and writes the result to Rd.
6. "XTAH Rm@>i, Rn, Rd": rotates Rm 0/8/16/24 bits, does signed
half-word extension to word, adds Rn, and writes the result to Rd.
7. "XTABU Rm@>i, Rn, Rd": rotates Rm 0/8/16/24 bits, does unsigned
byte extension to word, adds Rn, and writes the result to Rd.
8. "XTAHU Rm@>i, Rn, Rd": rotates Rm 0/8/16/24 bits, does unsigned
half-word extension to word, adds Rn, and writes the result to Rd.
Change-Id: I4306d7ebac93015d7e2e40d307f2c4271c03f466
Reviewed-on: https://go-review.googlesource.com/65790
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Moves type symbol name mangling out of the object reader
and into a separate pass. Requires some care, as changing
the name of a type may require dealing with duplicate
symbols for the first time.
Disables DWARF for both plugins and programs that use plugin.Open,
because type manging is currently incompatible with the go.info.*
symbol generator in cmd/link. (It relies on the symbol names to
find type information.) A future fix for this would be moving the
go.info.* generation into the compiler, with the logic we use
for generating the type.* symbols.
Fixes#19529
Change-Id: I75615f8bdda86ff9e767e536d9aa36e15c194098
Reviewed-on: https://go-review.googlesource.com/67312
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is no cache here yet. This CL defines ActionID, Hash, and HashFile,
which the new content-based staleness code can use. Eventually we'll
put a real cache implementation here, but it's not necessary yet.
Change-Id: Ide433cb449f4dbe658694453f348c947642df79b
Reviewed-on: https://go-review.googlesource.com/67311
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
(*sigctxt).fault() currently returns either uintptr, uint32, or uint64
depending on the platform. Make them all return uintptr.
For #10958 (but a nice change on its own).
Change-Id: I7813e779d0edcba112dd47fda776f4ce6e50e227
Reviewed-on: https://go-review.googlesource.com/68015
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently the linker figures out where runtime-gdb.py should be by
looking for the path to runtime/debug.go. However, debug.go contains
only a few symbols and can easily get dead-code eliminated entirely,
especially from simple binaries. When this happens, the resulting
binary lacks a reference to runtime-gdb.py, so the GDB helpers don't
get loaded.
Fix this by instead sniffing for runtime/proc.go. This contains
runtime.main and the scheduler, so it's not going anywhere.
Change-Id: Ie3380c77c840d28614fada68b8c5861625f2aff5
Reviewed-on: https://go-review.googlesource.com/68019
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Before CL 62530 fastrand always returned non-zero value, and one
condition in sema.go depends on this behavior.
fastrand is used to generate random weight for treap of sudog, and
it is checked against zero to verify sudog were inserted into treap or
wait queue.
Since its precision is not very important for correctness, lets just
always set its lowest bit in this place.
Updates #22047
Updates #21806
Change-Id: Iba0b56d81054e6ef9c49ffd293fc5d92a6a31e9b
Reviewed-on: https://go-review.googlesource.com/68050
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
PlainAuth originally refused to send passwords to non-TLS servers
and was documented as such.
In 2013, issue #5184 was filed objecting to the TLS requirement,
despite the fact that it is spelled out clearly in RFC 4954.
The only possibly legitimate use case raised was using PLAIN auth
for connections to localhost, and the suggested fix was to let the
server decide: if it advertises that PLAIN auth is OK, believe it.
That approach was adopted in CL 8279043 and released in Go 1.1.
Unfortunately, this is exactly wrong. The whole point of the TLS
requirement is to make sure not to send the password to the wrong
server or to a man-in-the-middle. Instead of implementing this rule,
CL 8279043 blindly trusts the server, so that if a man-in-the-middle
says "it's OK, you can send me your password," PlainAuth does.
And the documentation was not updated to reflect any of this.
This CL restores the original TLS check, as required by RFC 4954
and as promised in the documentation for PlainAuth.
It then carves out a documented exception for connections made
to localhost (defined as "localhost", "127.0.0.1", or "::1").
Change-Id: I1d3729bbd33aa2f11a03f4c000e6bb473164957b
Reviewed-on: https://go-review.googlesource.com/68170
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This removes some of the []byte/string conversions currently
existing in the (un)marshaling methods of Int and Rat.
For Int we introduce a new function (*Int).setFromScanner() essentially
implementing the SetString method being given an io.ByteScanner instead
of a string. So we can handle the string case in (*Int).SetString with
a *strings.Reader and the []byte case in (*Int).UnmarshalText() with a
*bytes.Reader now avoiding the []byte/string conversion here.
For Rat we introduce a new function (*Rat).marshal() essentially
implementing the String method outputting []byte instead of string.
Using this new function and the same formatting rules as in
(*Rat).RatString we can implement (*Rat).MarshalText() without
the []byte/string conversion it used to have.
Change-Id: Ic5ef246c1582c428a40f214b95a16671ef0a06d9
Reviewed-on: https://go-review.googlesource.com/65950
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also reduce the passed context from *Link to *sys.Arch, so fewer
data dependencies need to be wired through all the code dealing
with symbols.
For #22095
Change-Id: I50969405d6562c5152bd1a3c443b72413e9b70bc
Reviewed-on: https://go-review.googlesource.com/67313
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
All current darwin architectures seem to take at least 100ms to dial a closed port,
and that was making the all.bash script fail.
Fixes#22062
Change-Id: Ib79c4b7a5db2373c95ce5d993cdcbee55cc0667f
Reviewed-on: https://go-review.googlesource.com/67350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Begin passing coutbuf by as a parameter. To make the initial plumbing
pass easier, it is also a field in the standard ctxt parameter.
Consolidate the byte writing functions into the OutBuf object.
The result is less architecture-dependent initialization.
To avoid plumbing out everywhere we want to report an error, move
handling of out file deletion to an AtExit function.
For #22095
Change-Id: I0863695241562e0662ae3669666c7922b8c846f9
Reviewed-on: https://go-review.googlesource.com/67318
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Latest macOS High Sierra changed how the wall time information
is exported into the commpage. Backward compatibility was partly
preserved, that is previous Go versions are basically forced to
go through a syscall which is much slower and is not able to
get nanosecond precision.
Implement the new commpage layout and wall time computation,
using a version check to fallback to the previous code on
older operating systems.
Fixes#22037
Change-Id: I8c2176eaca83a5d7be23443946a6b4c653ec7f68
Reviewed-on: https://go-review.googlesource.com/67332
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/cgo is special among the build tools because it is (re)built on demand
when needed for a package using cgo, to avoid additional bootstrap logic
elsewhere. (This is in contrast to cmd/compile, cmd/link, and so on, which
must be specially built before even invoking the go command.)
When the go command starts using content-based decisions about staleness,
it is important that the build of cmd/cgo never use -linkmode=external,
because that depends on runtime/cgo, which in turn depends on cmd/cgo.
Change-Id: I72a2be748606d1ed4b93a54f2a5c7084e87d5fbc
Reviewed-on: https://go-review.googlesource.com/67310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is an intermediate step toward not being able to predict
the final generated file name for a package build, so that
parent builds can refer directly to cache files.
Change-Id: I4dea5e8d8b80e6b995b3d9dc1d8c6f0ac9b88d72
Reviewed-on: https://go-review.googlesource.com/56285
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These are rarely used and can be computed on demand,
to make clear that they are never out of sync with the
lists in the non-internal Package fields.
Change-Id: I8c621dceaff1aeb39a3ed83f18e848adf14d7106
Reviewed-on: https://go-review.googlesource.com/56284
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Actually execute topological sort to get those special dependencies right.
Mistake introduced in CL 67650.
Change-Id: I22fd6efb4f033deaf7f191431c0401b59b8a97d0
Reviewed-on: https://go-review.googlesource.com/67870
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When variables need to be spilled to the stack, they usually get their
own stack slot. Local variables have a slot allocated if they need one,
and arguments start out on the stack. Before this CL, the debug
information made the assumption that this was always the case, and so
didn't bother storing an actual stack offset during SSA analysis.
There's at least one case where this isn't true: variables that alias
arguments. Since the argument is the source of the variable, the
variable will begin its life on the stack in the argument's stack slot,
not its own. Therefore the debug info needs to track the actual stack
slot for each location entry.
No detectable performance change, despite the O(N) loop in getHomeSlot.
Change-Id: I2701adb7eddee17d4524336cb7aa6786e8f32b46
Reviewed-on: https://go-review.googlesource.com/67231
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Some tests in misc/cgo/test are run with various options including
'-linkmode=external "-extldflags=-pie"'. On ppc64x passing -pie to
the external linker with code that was not compiled as position
independent is incorrect. This works by luck in many cases but is
not guaranteed to work. I suspect it is an issue on other targets
as well.
This will now run the tests using -buildmode=pie for the platforms
that support that buildmode option.
Fixes#21954
Change-Id: I25fc7573f2d3cb5b0d1c691a0ac91aef7715404f
Reviewed-on: https://go-review.googlesource.com/66870
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, only the empty interface could be formatted to print on a
single line. This behaviour made short one-method interfaces in function
definitions and type assertions more verbose than they had to be.
For example, the following type assertion:
if c, ok := v.(interface {
Close() error
}); ok {
}
Can now be formatted as:
if c, ok := v.(interface{ Close() error }); ok {
}
Fixes#21952
Change-Id: I896f796c5a30b9f4da2be3fe67cb6fea5871b835
Reviewed-on: https://go-review.googlesource.com/66130
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
High Sierra has a new commpage layout (this is issue #3188), so
we need to adjust the code to handle multiple versions of the
layout.
In preparation for this change, we rename the existing offset
macros with a prefix that identifies the commpage version they
refer to.
Updates #22037
Change-Id: Idca4b7a855a2ff6dbc434cd12453fc3194707aa8
Reviewed-on: https://go-review.googlesource.com/67331
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Loading location data from tzdata files was only supported
from default paths on android. This change enables support on
all OS via the ZONEINFO environment variable and reduces the
amount of android specific code significantly.
Furthermore, unsuccessful calls to LoadLocation now return the
first error encountered, including errors from attempting to
load a location from the source specified by ZONEINFO.
Errors indicating that the source or location was not found are
ignored until all possible sources have been traversed.
Change-Id: I45bc23b92253c9447f12f95f3ca29a7e613ed995
Reviewed-on: https://go-review.googlesource.com/67170
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The lldb child process is killed if a test runs too long. Also
kill it when the setup times out (and is retried).
Might help with builder flakes where all 5 attempts to start up
lldb fail even though the tests before and after the timeouts
succeed. For example:
...
ok vendor/golang_org/x/net/route 37.797s
lldb setup error: command timeout (lldb start for 17s)
start timeout, trying again
lldb setup error: command timeout (lldb start for 17s)
start timeout, trying again
lldb setup error: command timeout (lldb start for 17s)
start timeout, trying again
lldb setup error: command timeout (lldb start for 17s)
start timeout, trying again
lldb setup error: command timeout (lldb start for 17s)
go_darwin_arm_exec: failed to start test harness (retry attempted)
FAIL vendor/golang_org/x/text/transform 115.185s
ok vendor/golang_org/x/text/unicode/norm 122.773s
...
Change-Id: I6638860522896491dccfa12f1e520c0f23df6d66
Reviewed-on: https://go-review.googlesource.com/67791
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The point of this code is to print a warning about repeated go test
invocations rebuilding the same packages over and over.
The new cache will eliminate this failure mode and with it
the need for the warning and this field.
Change-Id: Ied79b3ca67d51a61f44629de6ae4974e6c8dd5a9
Reviewed-on: https://go-review.googlesource.com/56282
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Mistake introduced just before submitting CL 67650 that somehow
did not break a final pre-submit all.bash on my laptop.
Not sure why all.bash passes locally when mkdeps.go doesn't build.
I guess the test only runs on builders?
Change-Id: I18fb91ada47605035345ba4b2f5e360a5c4b7f6e
Reviewed-on: https://go-review.googlesource.com/67850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
In addition to the obvious formatting change, this also drops
from deps.go any indirect dependencies, so that when you add
a new import to one package, the resulting diff only affects that
one package, not every package that imports that package
directly or indirectly. That makes the file a bit easier to understand,
if you need to debug it or deal with a possible merge conflict.
The code to trim the import lists (but not too much) was more
than I wanted to do in shell, so I rewrote mkdeps in Go.
The shell script is left behind for backwards-compatibility with
people who have learned to run ./mkdeps.bash (or documentation
suggesting the same).
Change-Id: I0bf27b5b27d0440e11ea830b00735c73f58eae03
Reviewed-on: https://go-review.googlesource.com/67650
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This method indicates whether a type contains any *heap* pointers, not
just whether it contains any pointers. Rename the method to make this
clear.
Change-Id: Ifff143e2f02a820444ac26b84250495c0098cb33
Reviewed-on: https://go-review.googlesource.com/67690
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A new testcase TestSelectFairness was recently added, and
since then the ppc64le build tests have intermittently failed.
This adds a change to skip this test on ppc64le using
SkipFlaky to help determine if the problem is with the
test or something else with that commit.
Updates #22047
Change-Id: Idfef72ed791c5bd45c42ff180947fea3df280ea7
Reviewed-on: https://go-review.googlesource.com/67631
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use entire inlining call stack to decide whether two panic calls
can be merged. We used to merge panic calls when only the leaf
line numbers matched, but that leads to places higher up the call
stack being merged incorrectly.
Fixes#22083
Change-Id: Ia41400a80de4b6ecf3e5089abce0c42b65e9b38a
Reviewed-on: https://go-review.googlesource.com/67632
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
After switching to an iPhone 5 for the darwin/arm builds,
TestStoreLoadRelAcq32 started to timeout on every builder run.
Adding the same memory barriers as armLoadUint64 and armStoreUint64
makes the test complete successfully.
Fixes sync/atomic tests on the darwin/arm builder.
Change-Id: Id73de31679304e259bdbd7f2f94383ae7fd70ee4
Reviewed-on: https://go-review.googlesource.com/67390
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
A new switch case for converting the source string type into a
destination RawBytes type avoids the reflection based conversion.
Speed up from old ~61.7ns/op down to ~49ns/op.
A second new switch case allows to convert and assign a source time.Time
type into a destination sql.RawBytes type. This switch case appends
the time to the reset RawBytes slice. This allows the reuse of RawBytes
and avoids allocations.
Fixes#20746
Change-Id: Ib0563fd5c5c7cb6d9d0acaa1d9aa7b2927f1329c
Reviewed-on: https://go-review.googlesource.com/66830
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Previously, any “explicit” and/or “tag” decorations on a RawValue would
be ignored when unmarshaling. The RawValue would swallow whatever
element was encountered.
This change causes these decorations to be respected. Thus a field like:
Foo asn1.RawValue `asn1:"explicit,tag:1,optional"`
will only match if an explicit tag with value one is encountered.
Otherwise the RawValue will get the default value and parsing will move
onto the next element.
Thanks to Martin Kreichgauer for reporting the issue.
Change-Id: If6c4488685b9bd039cb5e352d6d75744f98dbb1f
Reviewed-on: https://go-review.googlesource.com/34503
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Now that we have -importcfg, there's no need for the
temporary directory trees that mirror the import path structure,
and we can drop a bunch of complex code that was building
and maintaining that structure.
This should fix "file name too long" errors on systems with low limits.
(For example #10651 and #17070, although we fixed those by
adding code to deal with very long file names on Windows instead.)
Change-Id: I11e221c6c1edeb81c3b2f1d89988f5235aa2bbb9
Reviewed-on: https://go-review.googlesource.com/56280
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Until now the subdirectories under $WORK have had predictable
names, so it was OK to strip just $WORK from the file names that
end up in object files. In the future, those predictable names would
cause predictable collisions when compiling one package in two
different ways, so we're moving toward arbitrary, unpredictable
subdirectory names instead. When we do that, if the names appear
in the object files we won't get reproducible builds.
Take the subdirectory names out now, to make the later change safe.
Change-Id: I8057d1cc73f6e35c98b7718c9789c161dcbd87c0
Reviewed-on: https://go-review.googlesource.com/67251
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 64793 removed the collect step, which took all
the generated .o files and merged them into a single _all.o.
Now the generated .o files all go directly into the final .a.
The only property of the _all.o approach that was lost
in CL 64793 was that before we could be sure that the
one name we used was "ar-compatible", that is, short
enough not to be truncated.
Now that the generated .o files are being kept directly,
this CL gives them guaranteed ar-compatible names.
This doesn't matter for nearly all uses today, but for some
future processing it might help not to lose the .o suffix
or not to end up with two identical entries with truncated
names.
I might not have bothered with this except that it's what's
leftover after syncing my own CL disabling _all.o
(necessary for reproducible builds on macOS) against
Ian's CL 64793, which landed first.
Change-Id: Ic86ed2a51432a5a4c58dc523e092a86d341f1997
Reviewed-on: https://go-review.googlesource.com/67250
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I don't know why these tests must import runtime/cgo
in _testmain.go, but if they must, they must also tell the
rest of the go command that they are doing so.
Should fix the newly-broken darwin/arm and darwin/arm64 builders.
Change-Id: I9b183f8c84c6f403bf3a90cbfc838d6ef428e16f
Reviewed-on: https://go-review.googlesource.com/67230
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Modifying the input slice broke the new test for whether gccgo
supports -fgo-importcfg, as the test passed a slice of the argument
slice it was in the process of building.
Fixes#22089
Change-Id: I45444a82673223c46be0c8579da3e31a74c32d73
Reviewed-on: https://go-review.googlesource.com/67191
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
nilcheckelim2 cleans up by copying b.Values in a loop, omitting
OpUnknowns. However, the common case is that there are no OpUnknowns,
in which case we can skip a lot of work.
So we track the first nilcheck which was eliminated, if any, and only
start copying from there. If no nilcheck was eliminated we won't copy at all.
Fixes#20964
Change-Id: Icd44194cf8ac81ce6485ce257b4d33e093003a40
Reviewed-on: https://go-review.googlesource.com/65651
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Implement importcfg on behalf of gccgo by writing out a
tree of symbolic links. In addition to keeping gccgo working
with the latest changes, this also fixes a precedence bug in
gccgo's cmd/go vendor support (the vendor equivalent of #14271).
Change-Id: I0e5645116e1c84c957936baf22e3126ba6b0d46e
Reviewed-on: https://go-review.googlesource.com/61731
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is a step toward using cached build artifacts: the importcfg
will direct the compiler and linker to read them right from the cache
if necessary. However, this CL does not have a cache yet, so it still
reads them from the usual install location or build location.
Even so, this fixes a long-standing issue that -I and -L (no longer used)
are not expressive enough to describe complex GOPATH setups.
Shared libraries are handled enough that all.bash passes, but
there may still be more work to do here. If so, tests and fixes
can be added in follow-up CLs.
Gccgo will need updating to support -importcfg as well.
Fixes#14271.
Change-Id: I5c52a0a5df0ffbf7436e1130c74e9e24fceff80f
Reviewed-on: https://go-review.googlesource.com/56279
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, a multi-line flag usage string would not be indented with the
rest of the usage strings. This made long usage strings difficult to read.
For example, the usage for flag.String("A", "", "1\n2\n3") would be printed
as:
-A 1
2
3
But will now be printed as:
-A 1
2
3
Also fixes a slight error in the FlagSet.PrintDefaults documentation.
Fixes#20799
Change-Id: I4379c6b7590fdb93a2809a01046a0f6ae32c3e5d
Reviewed-on: https://go-review.googlesource.com/66711
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Remove an unused type, a few redundant returns and replace a few slice
append loops with a single append.
Change-Id: If07248180bae5631b5b152c6051d9635889997d5
Reviewed-on: https://go-review.googlesource.com/66851
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The information that's used to generate DWARF location lists is very
ssa.Value centric; it uses Values as start and end coordinates to define
ranges. That mostly works fine, but control flow instructions don't come
from Values, so the ranges couldn't cover them.
Control flow instructions are generated when the SSA representation is
converted to assembly, so that's the best place to extend the ranges
to cover them. (Before that, there's nothing to refer to, and afterward
the boundaries between blocks have been lost.) That requires block
information in the debugInfo type, which then flows down to make
everything else awkward. On the plus side, there's a little less copying
slices around than there used to be, so it should be a little faster.
Previously, the ranges for empty blocks were not very meaningful. That
was fine, because they had no Values to cover, so no debug information
was generated for them. But they do have control flow instructions
(that's why they exist) and so now it's important that the information
be correct. Introduce two sentinel values, BlockStart and BlockEnd, that
denote the boundary of a block, even if the block is empty. BlockEnd
replaces the previous SurvivedBlock flag.
There's one more problem: the last instruction in the function will be a
control flow instruction, so any live ranges need to be extended past
it. But there's no instruction after it to use as the end of the range.
Instead, leave the EndProg field of those ranges as nil and fix it up to
point to past the end of the assembled text at the very last moment.
Change-Id: I81f884020ff36fd6fe8d7888fc57c99412c4245b
Reviewed-on: https://go-review.googlesource.com/63010
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, methods are sorted by name. This happens to guarantee that
exported ASCII methods appear before non-exported ASCII methods, but
this breaks down when Unicode method names are considered.
Type.Method already accounts for this by always indexing into the
slice returned by exportedMethods. This CL makes Value.Method do the
same.
Fixes#22073.
Change-Id: I9bfc6bbfb7353e0bd3c439a15d1c3da60d16d209
Reviewed-on: https://go-review.googlesource.com/66770
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Very similar fix to the one made in golang.org/cl/65655. This time it's
for switches on interface values, as we look for duplicates in a
different manner to keep types in mind.
As before, add a small regression test.
Updates #22001.
Fixes#22063.
Change-Id: I9a55d08999aeca262ad276b4649b51848a627b02
Reviewed-on: https://go-review.googlesource.com/66450
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Combined the Split and Join call with a Replace. This simplifies
the code as well as makes it fast.
Micro-benchmarks show good improvements -
func BenchmarkJoinSplit(b *testing.B) {
for n := 0; n < b.N; n++ {
strings.Join(strings.Split("this string has some spaces", " "), "")
}
}
func BenchmarkReplace(b *testing.B) {
for n := 0; n < b.N; n++ {
strings.Replace("this string has some spaces", " ", "", -1)
}
}
name old time/op new time/op delta
JoinSplit-4 308ns ± 2% 192ns ± 4% -37.60% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
JoinSplit-4 144B ± 0% 64B ± 0% -55.56% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
JoinSplit-4 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.008 n=5+5)
Change-Id: I1dc32105ae7a0be5a43ab0bedde992cefbed5d7d
Reviewed-on: https://go-review.googlesource.com/66590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The reflect API normally grants only read-only access to non-exported
fields, but it specially handles non-exported embedded fields so that
users can still fully access promoted fields and methods. For example,
if v.Field(i) refers to a non-exported embedded field, it would be
limited to RO access. But if v.Field(i).Field(j) is an exported field,
then the resulting Value will have full access.
However, the way this was implemented allowed other operations to be
interspersed between the Field calls, which could grant inappropriate
access.
Relatedly, Elem() is safe to use on pointer-embeddings, but it was
also being allowed on embeddings of interface types. This is
inappropriate because it could allow accessing methods of the dynamic
value's complete method set, not just those that were promoted via the
interface embedding.
Fixes#22031.
Fixes#22053.
Change-Id: I9db9be88583f1c1d80c1b4705a76f23a4379182f
Reviewed-on: https://go-review.googlesource.com/66331
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently the FreeBSD CPU affinity code assumes that the maximum
GOMAXPROCS is 256, but we just removed that limit.
This commit rewrites the FreeBSD CPU affinity code to raise the CPU
count limit to 65,536, like the Linux CPU affinity code, and to
degrade more gracefully if we do somehow go over that.
Change-Id: Ic4ca7f88bd8b9448aae4dbd43ef21a6c1b8fea63
Reviewed-on: https://go-review.googlesource.com/66291
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
allp now has length gomaxprocs, which means none of allp[i] are nil or
in state _Pdead. This lets replace several different styles of loops
over allp with normal range loops.
for i := 0; i < gomaxprocs; i++ { ... } loops can simply range over
allp. Likewise, range loops over allp[:gomaxprocs] can just range over
allp.
Loops that check for p == nil || p.state == _Pdead don't need to check
this any more.
Loops that check for p == nil don't have to check this *if* dead Ps
don't affect them. I checked that all such loops are, in fact,
unaffected by dead Ps. One loop was potentially affected, which this
fixes by zeroing p.gcAssistTime in procresize.
Updates #15131.
Change-Id: Ifa1c2a86ed59892eca0610360a75bb613bc6dcee
Reviewed-on: https://go-review.googlesource.com/45575
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Correcting values is allowed per the syscall package rules, so update
these constants to their correct value on ppc64/ppc64le. The values now
match the corresponding constants in x/sys/unix.
Update #19560Fixes#22000
Change-Id: I1d358de345766ec96e15dfcc8911fe2f39fb0ddb
Reviewed-on: https://go-review.googlesource.com/66510
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Loading and testing timezones is currently implemented using several,
partly redundant, OS specific data structures and functions. This
change merges most of that code into OS independent implementations.
Change-Id: Iae2877c5f48d1e4a9de9ce55d0530d52e24cf96e
Reviewed-on: https://go-review.googlesource.com/64391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds the ability to parse
group into email address. The information about
group name and group members is lost for
backwards compatibility. According to this rule address
`Group: Test <text@example.com>;` would be parsed into
`Test <test@example.com>`.
Fixes#22014
Change-Id: I6e804a62f3ede04f555a1b82500b8ca030eeb431
Reviewed-on: https://go-review.googlesource.com/66250
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On an iPhone 6 running iOS 11, the TestDialerDualStackFDLeak test
started failing with dial durations just above the limit:
FAIL: TestDialerDualStackFDLeak (0.21s)
dial_test.go:90: got 101.154ms; want <= 95ms
Bump the timeout on iOS.
For the iOS builder.
Change-Id: Id42b471e7cf7d0c84f6e83ed04b395fa1a2d449d
Reviewed-on: https://go-review.googlesource.com/66491
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
syscall.Exit and runtime.exit do the same thing.
Why duplicate code?
CL 45115 fixed bug where windows runtime.exit was correct,
but syscall.Exit was broken. So CL 45115 fixed windows
syscall.Exit by calling runtime.exit.
Austin suggested that all OSes should do the same, and
this CL implements his idea.
While making changes, I discovered that nacl syscall.Exit
returned error
func Exit(code int) (err error)
and I changed it into
func Exit(code int)
like all other OSes. I assumed it was a mistake and it
is OK to do because cmd/api does not complain about it.
Also I changed plan9 runtime.exit to accept int32 just
like all other OSes do.
Change-Id: I12f6022ad81406566cf9befcc6edc382eebd413b
Reviewed-on: https://go-review.googlesource.com/66170
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
bytes.IndexByte can be used wherever the second argument to
strings.Index is exactly one byte long, so we do that with this change.
This avoids generating unnecessary string symbols/converison and saves
a few calls to bytes.Index.
Change-Id: If31c775790e01edfece1169e398ad6a754fb4428
Reviewed-on: https://go-review.googlesource.com/66373
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
strings.LastIndexByte was introduced in go1.5 and it can be used
effectively wherever the second argument to strings.LastIndex is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.LastIndex.
Change-Id: I7b5679d616197b055cffe6882a8675d24a98b574
Reviewed-on: https://go-review.googlesource.com/66372
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Transport.Proxy is documented as only supporting the http and socks5
schemes. If one tries to use it for https URLs, they end up with a
cryptic error like:
http: TLS handshake error from [...]: tls: oversized record received with length 20037
This is because Transport simply skips TLS if Proxy is non-nil, since it
knows it doesn't support Proxy with https.
However, that error is very confusing and it can take a while to figure
out what's going on. Instead, error if Proxy is used and it returns an
unsupported scheme.
Updates #19493.
Change-Id: Ia036357011752f45bb9b8282a4ab5e31bc8d1a69
Reviewed-on: https://go-review.googlesource.com/66010
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Currently, the priority of checks in (gcTrigger).test() puts the
gcpercent<0 test above gcTriggerCycle, which is used for runtime.GC().
This is an unintentional change from 1.8 and before, where
runtime.GC() triggered a GC even if GOGC=off.
Fix this by rearranging the priority so the gcTriggerCycle test
executes even if gcpercent < 0.
Fixes#22023.
Change-Id: I109328d7b643b6824eb9d79061a9e775f0149575
Reviewed-on: https://go-review.googlesource.com/65994
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This permits the program to reliably know that when the Close method
returns, the descriptor has definitely been closed. This matters at
least for listeners.
Fixes#21856
Updates #7970
Change-Id: I1fd0cfd2333649e6e67c6ae956e19fdff3a35a83
Reviewed-on: https://go-review.googlesource.com/66150
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <joetsai@google.com>
The previous comment of nextSample didn't mention Poisson processes,
which is the reason why it needed to create an exponential
distribution, so it was hard to follow the reasoning for people
not highly familiar with statistics.
Since we're at it, we also make it clear that we are just creating
a random number with exponential distribution by moving the
bulk of the function into a new fastexprand().
No functional changes.
Change-Id: I9c275e87edb3418ee0974257af64c73465028ad7
Reviewed-on: https://go-review.googlesource.com/65657
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If we have
y = <int16> (MOVBQSX x)
z = <int32> (MOVWQSX y)
We used to use this rewrite rule:
(MOVWQSX x:(MOVBQSX _)) -> x
But that resulted in replacing z with a value whose type
is only int16. Then if z is spilled and restored, it gets
zero extended instead of sign extended.
Instead use the rule
(MOVWQSX (MOVBQSX x)) -> (MOVBQSX x)
The result is has the correct type, so it can be spilled
and restored correctly. It might mean that a few more extension
ops might not be eliminated, but that's the price for correctness.
Fixes#21963
Change-Id: I6ec82c3d2dbe43cc1fee6fb2bd6b3a72fca3af00
Reviewed-on: https://go-review.googlesource.com/65290
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The previous implementation forced all Unix socket to have a name
strictly shorter than len(sa.raw.Path) to allow a terminating NULL
byte to be added. This requirement does not apply to abstract socket
names under Linux, so for this case we allow the full length.
Fixes#21965
Change-Id: I1d1f58b6b6172d589428c7230cfeae984de78b4b
Reviewed-on: https://go-review.googlesource.com/66190
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The internal linker doesn't know how to handle multiple TOC sections
in internal linking mode. This used to work because before CL 64793 we
invoked ld -r on multiple objects, and that merged the TOC sections
for us.
Updates #21961
Change-Id: I48260a7195be660016f2f358ebc8cb79652210ab
Reviewed-on: https://go-review.googlesource.com/66270
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When a MOVDstorezero (8 bytes) is used the offset field
in the instruction must be a multiple of 4. This situation
had been corrected in the rules for other types of stores
but not for the zero case.
This also removes some of the special MOVDstorezero cases since
they can be handled by the general LowerZero case.
Updates made to the ssa test for lowering zero moves to
include cases where the target is not aligned to at least 4.
Fixes#21947
Change-Id: I7cceceb1be4898c77cd3b5e78b58dce0a7e28edd
Reviewed-on: https://go-review.googlesource.com/64970
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
internal/poll package assumes that only net sockets use runtime
netpoller on windows. We get memory corruption if other file
handles are passed into runtime poller. Make FD.Init receive
and use useNetpoller argument, so FD.Init caller is explicit
about using runtime netpoller.
Fixes#21172
Change-Id: I60e2bfedf9dda9b341eb7a3e5221035db29f5739
Reviewed-on: https://go-review.googlesource.com/65810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The interfaces for io.Reader and io.Writer permit calling Read/Write
with an empty buffer. However, this condition is often not well tested
and can lead to bugs in various implementations of io.Reader and io.Writer.
For example, see #22028 for buggy io.Reader in the bzip2 package.
We reduce the likelihood of hitting these bugs by adjusting
regFileReader.Read and regFileWriter.Write to avoid performing
Read and Write calls when the buffer is known to be empty.
Fixes#22029
Change-Id: Ie4a26be53cf87bc4d2abd951fa005db5871cc75c
Reviewed-on: https://go-review.googlesource.com/66111
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously, the read method checked whether the current block
was fully consumed or not based on whether the buffer could be filled
with a non-zero number of bytes. This check is problematic because
zero bytes could be read if the provided buffer is empty.
We fix this case by simply checking for whether the input buffer
provided by the user was empty or not. If empty, we assume that
we could not read any bytes because the buffer was too small,
rather than indicating that the current block was fully exhausted.
This check causes bzip2.Reader to be unable to make progress
on the next block unless a non-empty buffer is provided.
However, that is an entirely reasonable expectation since a
non-empty buffer needs to be provided eventually anyways to
read the actual contents of subsequent blocks.
Fixes#22028
Change-Id: I2bb1b2d54e78567baf2bf7b490a272c0853d7bfe
Reviewed-on: https://go-review.googlesource.com/66110
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is based on a list that Austin Clements provided in mid-2016. It is
mostly untouched, except for the fact that the wbufptr funcs were
removed from the runtime thus removed from the lits here too.
Add a section for these GC funcs, since there are quite a lot of them
and the runtime has tons of funcs that we want to inline. As before,
sort this section too.
Also place some of these funcs out of the GC section, as they are not
directly related to the GC.
Updates #21851.
Change-Id: I35eb777a4c50b5f655618920dc2bc568c7c30ff5
Reviewed-on: https://go-review.googlesource.com/65654
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
When static maps are large, we try to initialize them
by iterating over an array of key/value pairs.
Currently this optimization only works if the keys and values
are of primitive type. This CL improves this optimization
by allowing any static composite literals as well.
Fixes#22010
Change-Id: Ie493e02ab8b8a228a3472b5c6025a33f7b92daf3
Reviewed-on: https://go-review.googlesource.com/66050
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before this change, if Walk encounters an unreadable directory,
it will call walkFn with this directory twice. Argument err in
the first call is nil, and the second is the permission error.
This change removes the former call and makes Walk call walkFn
with permission error.
Fixes#21758
Change-Id: I21e57c67f3c5a8370fc80a43db3c8009fbce6439
Reviewed-on: https://go-review.googlesource.com/63994
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change removes the check of len(chars) > 0 inside the Index and
IndexAny functions which was redundant.
Change-Id: Ic4bf8b8a37d7f040d3ebd81b4fc45fcb386b639a
Reviewed-on: https://go-review.googlesource.com/65851
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
strings.IndexByte was introduced in go1.2 and it can be used
effectively wherever the second argument to strings.Index is
exactly one byte long.
This avoids generating unnecessary string symbols and saves
a few calls to strings.Index.
Change-Id: I1ab5edb7c4ee9058084cfa57cbcc267c2597e793
Reviewed-on: https://go-review.googlesource.com/65930
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Under certain circumstances involving shifts, go/types didn't verify
that untyped constant values were representable by the relevant type,
leading to the acceptance of incorrect programs (see the issue).
Fixing this code exposed another problem with int-to-string conversions
which suddenly failed because now the type-checker complained that a
(constant) integer argument wasn't representable as a string. Fixed that
as well.
Added many additional tests covering the various scenarious.
Found two cmd/compile bugs in the process (#21979, #21981) and filed
a go/types TODO (#21982).
Fixes#21727.
Change-Id: If443ee0230979cd7d45d2fc669e623648caa70da
Reviewed-on: https://go-review.googlesource.com/65370
Reviewed-by: Alan Donovan <adonovan@google.com>
In golang.org/cl/42813, a test was added in the bytes package to check
if a Buffer method was being inlined, using 'go tool nm'.
Now that we have a compiler test that verifies that certain funcs are
inlineable, merge it there. Knowing whether the funcs are inlineable is
also more reliable than whether or not their symbol appears in the
binary, too. For example, under some circumstances, inlineable funcs
can't be inlined, such as if closures are used.
While at it, add a few more bytes.Buffer methods that are currently
inlined and should clearly stay that way.
Updates #21851.
Change-Id: I62066e32ef5542d37908bd64f90bda51276da4de
Reviewed-on: https://go-review.googlesource.com/65658
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The ones in racewalk.go are almost all useless, since they were just
breaks.
typecheck.go wasn't trivial, but still doable with an if/else chain.
Also remove a single silly goto in const.go, while at it.
Change-Id: I776a78df6bb3b6bd4f7e5feec546c772baf4e02e
Reviewed-on: https://go-review.googlesource.com/65652
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation doesn't handle
comment constructions in email address.
So addresses that are consistent with RFC 5322
don't parse at all.
Fixes#21257
Change-Id: Iae3ba951dfb26b7cf0e1885a680bbceb9123d6d5
Reviewed-on: https://go-review.googlesource.com/53550
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
They were in Do, which is the method that actually starts the build.
However, we can already run these checks in Init, since we already have
all the information necessary to do the checks.
More importantly, some work happens between Init and Do, namely package
loading. That may exit with an error, meaning that in some cases the
user gets a confusing error instead of the correct one.
For example, using a GOOS typo, before showed:
$ GOOS=windwos go build
can't load package: package p: build constraints exclude all Go files in ...
And now:
$ GOOS=windwos go build
cmd/go: unsupported GOOS/GOARCH pair windwos/amd64
Also had to tweak TestGoEnv to modify GOOS as well as GOARCH. Otherwise,
on windows this would result in the invalid GOOS/GOARCH pair
windows/arm, which would error given that we now check that in non-build
commands such as "go env".
Fixes#21999.
Change-Id: Iff9890dea472bff0179a9d703d6f698a0e3187c1
Reviewed-on: https://go-review.googlesource.com/65656
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Replace the work "session" with "connection" in docs. Fix
The ErrConnDone documentation. Clarify what the context is used
for in StmtContext.
Change-Id: I2f07e58d0cd6321b386a73b038cf6070cb8e2572
Reviewed-on: https://go-review.googlesource.com/65732
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a regression introduced by myself in golang.org/cl/41852,
confirmed by the program that reproduces the crash that can be seen in
the added test.
Fixes#21988.
Change-Id: I18d5b2b3de63ced84db705b18490b00b16b59e02
Reviewed-on: https://go-review.googlesource.com/65655
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
go command refuses to use GOPATH with empty path elements
(like %GOPATH%=C:\go;). But environment variable change dialog
on Windows 10 produces strings ending with ; (see issue #21928
for a picture). Just accept GOPATH with empty path elements,
and ignore all empty path elements.
Fixes#21928
Change-Id: I1d3c3a19274ed69204d29ae06c3e8ff8c57c1ca0
Reviewed-on: https://go-review.googlesource.com/65151
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current Open method limits the ability for driver maintainers
to expose options for their drivers by forcing all the configuration
to pass through the DSN in order to create a *DB.
This CL allows driver maintainers to write their own initialization
functions that return a *DB making configuration of the underlying
drivers easier.
Fixes#20268
Change-Id: Ib10b794f36a201bbb92c23999c8351815d38eedb
Reviewed-on: https://go-review.googlesource.com/53430
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The reason why adjustctxt wasn't being inlined was reported as:
function too complex: cost 92 exceeds budget 80
However, after tweaking the code to be under the budget limit, we see
the real blocker:
non-leaf function
There is little we can do about this one in particular at the moment.
Create a section with funcs that will need mid-stack inlining to be
inlineable, since this will likely come up again in other cases.
Change-Id: I3a8eb1546b289a060ac896506a007b0496946e84
Reviewed-on: https://go-review.googlesource.com/65650
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 60410 fixes the compiler such that reflect.StructField.PkgPath
is non-empty if and only if the field is unexported.
Given that property, we can cleanup the logic in the json encoder
to avoid parsing the field name to detect export properties.
Updates #21122
Change-Id: Ic01b9c4ca76386774846b742b0c1b9b948f53e7c
Reviewed-on: https://go-review.googlesource.com/65550
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The compiler generates wrapper methods to forward interface method
calls (which are always pointer-based) to value methods. These
wrappers appear in the call stack even though they are an
implementation detail. This leaves ugly "<autogenerated>" functions in
stack traces and can throw off skip counts for stack traces.
Fix this by considering these runtime frames in printed stack traces
so they will only be printed if runtime frames are being printed, and
by eliding them from the call stack expansion used by CallersFrames
and Caller.
This removes the test for issue 4388 since that was checking that
"<autogenerated>" appeared in the stack trace instead of something
even weirder. We replace it with various runtime package tests.
Fixes#16723.
Change-Id: Ice3f118c66f254bb71478a664d62ab3fc7125819
Reviewed-on: https://go-review.googlesource.com/45412
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
panicwrap currently uses runtime.Callers and runtime.CallersFrames to
find the name of its caller. Simplify this by using getcallerpc.
This will be important for #16723, since to fix that we're going to
make CallersFrames skip the wrapper method, which is exactly what
panicwrap needs to see.
Change-Id: Icb0776d399966e31595f3ee44f980290827e32a6
Reviewed-on: https://go-review.googlesource.com/45411
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that getcallerpc is a compiler intrinsic on x86 and non-x86
platforms don't need the argument, we can drop it.
Sadly, this doesn't let us remove any dummy arguments since all of
those cases also use getcallersp, which still takes the argument
pointer, but this is at least an improvement.
Change-Id: I9c34a41cf2c18cba57f59938390bf9491efb22d2
Reviewed-on: https://go-review.googlesource.com/65474
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
CL 31148 added code to protect again simultaneous calls to Close and
Wait when using the standard input pipe, to fix the race condition
described in issue #9307. That issue is a special case of the race
between Close and Write described by issue #7970. Since issue #7970
was not fixed, CL 31148 fixed the problem specific to os/exec.
Since then, issue #7970 has been fixed, so the specific fix in os/exec
is no longer necessary. Remove it, effectively reverting CL 31148 and
followup CL 33298.
Updates #7970
Updates #9307
Updates #17647
Change-Id: Ic0b62569cb0aba44b32153cf5f9632bd1f1b411a
Reviewed-on: https://go-review.googlesource.com/65490
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Miguel Bernabeu <miguelbernadi@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Joe Tsai <joetsai@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This no longer appears to be reproducible on windows/386. Try putting
it back and we'll see if the builders still don't like it.
Fixes#19319.
Change-Id: Ia47b034e18d0a5a1951125c00542b021aacd5e8d
Reviewed-on: https://go-review.googlesource.com/47936
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
First step towards removing the mandatory argument for
getcallerpc, which solves certain problems for the runtime.
This might also slightly improve performance.
Intrinsic enabled on 386, amd64, amd64p32,
runtime asm implementation removed on those architectures.
Now-superfluous argument remains in getcallerpc signature
(for a future CL; non-386/amd64 asm funcs ignore it).
Added getcallerpc to the "not a real function" test
in dcl.go, that story is a little odd with respect to
unexported functions but that is not this CL.
Fixes#17327.
Change-Id: I5df1ad91f27ee9ac1f0dd88fa48f1329d6306c3e
Reviewed-on: https://go-review.googlesource.com/31851
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
For a trivial benchmark with a do-nothing cgo call:
name old time/op new time/op delta
Call-4 64.5ns ± 7% 63.0ns ± 6% -2.25% (p=0.027 n=20+16)
Because Windows uses the cgocall mechanism to make system calls,
and passes arguments in a struct held in the m,
we need to do the lockOSThread/unlockOSThread in that code.
Because deferreturn was getting a nosplit stack overflow error,
change it to avoid calling typedmemmove.
Updates #21827.
Change-Id: I9b1d61434c44faeb29805b46b409c812c9acadc2
Reviewed-on: https://go-review.googlesource.com/64070
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is based from a list that Keith Randall provided in mid-2016. These
are all funcs that, at the time, were important and small enough that
they should be clearly inlined.
The runtime has changed a bit since then. Ctz16 and Ctz8 were removed,
so don't add them. stringtoslicebytetmp was moved to the backend, so
it's no longer a Go function. And itabhash was moved to itabHashFunc.
The only other outlier is adjustctxt, which is not inlineable at the
moment. I've added a TODO and will address it myself in a separate
commit.
While at it, error if any funcs in the input table are duplicated.
They're never useful and typos could lead to unintentionally thinking a
function is inlineable when it actually isn't.
And, since the lists are getting long, start sorting alphabetically.
Finally, rotl_31 is only defined on 64-bit architectures, and the added
runtime/internal/sys funcs are assembly on 386 and thus non-inlineable
in that case.
Updates #21851.
Change-Id: Ib99ab53d777860270e8fd4aefc41adb448f13662
Reviewed-on: https://go-review.googlesource.com/65351
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Rework the logic to remove them. These were the low hanging fruit,
with labels that were used only once and logic that was fairly
straightforward.
Change-Id: I02a01c59c247b8b2972d8d73ff23f96f271de038
Reviewed-on: https://go-review.googlesource.com/63410
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 60871 added TestSparseFiles. This test is succeeding
on Plan 9 when executed on the ramfs file system, but
is failing when executed on the Fossil file system.
This may be due to an issue in the handling of sparse
files in the Fossil file system on Plan 9 that should
be investigated.
Updates #21977.
Change-Id: I177afff519b862a5c548e094203c219504852006
Reviewed-on: https://go-review.googlesource.com/65352
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Do the low-hanging fruit - tiny Less functions that are used exactly
once. This reduces the amount of code and puts the logic in a single
place.
Change-Id: I9d4544cd68de5a95e55019bdad1fca0a1dbfae9c
Reviewed-on: https://go-review.googlesource.com/63171
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we use -gcflags='-m -m', the compiler should give us a reason why a
func couldn't be inlined. Add the extra -m necessary for that extra info
and use it to give better test failures. For example, for the func in
the TODO:
--- FAIL: TestIntendedInlining (1.53s)
inl_test.go:104: runtime.nextFreeFast was not inlined: function too complex
We might increase the number of -m flags to get more information at some
later point, such as getting details on how close the func was to the
inlining budget.
Also started using regexes, as the output parsing is getting a bit too
complex for manual string handling.
While at it, also refactored the test to not buffer the entire output
into memory. This is fine in practice, but it won't scale well as we add
more packages or we depend more on the compiler's debugging output.
For example, "go build -a -gcflags='-m -m' std" prints nearly 40MB of
plaintext - and we only need to see the output line by line anyway.
Updates #21851.
Change-Id: I00986ff360eb56e4e9737b65a6be749ef8540643
Reviewed-on: https://go-review.googlesource.com/63810
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The test for hole-detection is heavily dependent on whether the
OS and underlying FS provides support for it.
Even on Linux, which has support for SEEK_HOLE and SEEK_DATA,
the underlying filesystem may not have support for it.
In order to avoid an ever-changing game of whack-a-mole,
we whitelist the specific builders that we expect the test to pass on.
Updates #21964
Change-Id: I7334e8532c96cc346ea83aabbb81b719685ad7e5
Reviewed-on: https://go-review.googlesource.com/65270
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some methods that were used to implement various `io` interfaces in the
Reader were documented, whereas others were not. This change adds
documentation to all the missing methods used to implement these
interfaces.
Change-Id: I2dac6e328542de3cd87e89510651cd6ba74a7b7d
Reviewed-on: https://go-review.googlesource.com/65231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On most Unix OSes, lseek reports EINVAL when lacking SEEK_HOLE support.
However, there are reports that ENOTTY is reported instead.
Rather than tracking down every possible errno that may be used to
represent "not supported", just treat any non-nil error as meaning
that there is no support. This is the same strategy taken by the
GNU and BSD tar tools.
Fixes#21958
Change-Id: Iae68afdc934042f52fa914fca45f0ca89220c383
Reviewed-on: https://go-review.googlesource.com/65191
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Docs of WithDeadline refers to variable "d" which does not exist
in the docs.
This commit renames the time argument to "d" to make the doc work.
Change-Id: Ifd2c1be7d2e3f7dfb21cd9bb8ff7fc5039c8d3bd
Reviewed-on: https://go-review.googlesource.com/65130
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use a counter, instead of a loop, to see whether there are more
writebarrier ops in the current block that need to be rewritten.
No visible change in normal compiler speed benchmarks.
Passes toolstash -cmp on std cmd.
Fixes#20416.
Change-Id: Ifbbde23611cd668c35b8a4a3e9a92726bfe19956
Reviewed-on: https://go-review.googlesource.com/60310
Reviewed-by: David Chase <drchase@google.com>
onebitwalktype1 no longer appears to be a bottleneck for the mentioned
test case. In fact, we appear to compile it significantly faster now
than Go 1.4 did (~1.8s vs ~3s).
Fixes#21951.
Change-Id: I315313e906092a7d6ff4ff60a918d80a4cff7a7f
Reviewed-on: https://go-review.googlesource.com/65110
Reviewed-by: Keith Randall <khr@golang.org>
To support the detection and creation of sparse files,
add two new methods:
func Header.DetectSparseHoles(*os.File) error
func Header.PunchSparseHoles(*os.File) error
DetectSparseHoles is intended to be used after FileInfoHeader
prior to serializing the Header with WriteHeader.
For each OS, it uses specialized logic to detect
the location of sparse holes. On most Unix systems, it uses
SEEK_HOLE and SEEK_DATA to query for the holes.
On Windows, it uses a specialized the FSCTL_QUERY_ALLOCATED_RANGES
syscall to query for all the holes.
PunchSparseHoles is intended to be used after Reader.Next
prior to populating the file with Reader.WriteTo.
On Windows, this uses the FSCTL_SET_ZERO_DATA syscall.
On other operating systems it simply truncates the file
to the end-offset of SparseHoles.
DetectSparseHoles and PunchSparseHoles are added as methods on
Header because they are heavily tied to the operating system,
for which there is already an existing precedence for
(since FileInfoHeader makes uses of OS-specific details).
Fixes#13548
Change-Id: I98a321dd1ce0165f3d143d4edadfda5e7db67746
Reviewed-on: https://go-review.googlesource.com/60871
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
- using FMA and AVX instructions if available to speed-up
Exp calculation on amd64
- using a data table instead of #define'ed constants because
these instructions do not support loading floating point immediates.
One has to use a memory operand / register.
- Benchmark results on Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz:
Original vs New (non-FMA path)
name old time/op new time/op delta
Exp 16.0ns ± 1% 16.1ns ± 3% ~ (p=0.308 n=9+10)
Original vs New (FMA path)
name old time/op new time/op delta
Exp 16.0ns ± 1% 13.7ns ± 2% -14.80% (p=0.000 n=9+10)
Change-Id: I3d8986925d82b39b95ee979ae06f59d7e591d02e
Reviewed-on: https://go-review.googlesource.com/62590
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When debugging inliner with -m -m print cost of complex functions,
instead of simple "function too complex". This helps to understand,
how close to inlining is this particular function.
Change-Id: I6871f69b5b914d23fd0b43a24d7c6fc928f4b716
Reviewed-on: https://go-review.googlesource.com/63330
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
https://golang.org/cl/5822049 introduced the idea of linking together
all the cgo objects with -r, while also linking against -lgcc. This
was to fix http://golang.org/issue/3261: cgo code that requires libgcc
would break when using internal linking.
This approach introduced https://golang.org/issue/9510: multiple
different cgo packages could include the same libgcc object, leading
to a multiple definition error during the final link. That problem was
fixed by https://golang.org/cl/16741, as modified by
https://golang.org/cl/16993, which did the link against libgcc only
during the final link.
After https://golang.org/cl/16741, and, on Windows, the later
https://golang.org/cl/26670, ld -r no longer does anything useful.
So, remove it.
Doing this revealed that running ld -r on Darwin simplifies some
relocs by making them specific to a symbol rather than a section.
Correct the handling of unsigned relocations in internal linking mode
by offsetting by the symbol value. This only really comes up when
using the internal linker with C code that initializes a variable to
the address of a local constant, such as a C string (as in const char
*s = "str";). This change does not affect the normal case of external
linking, where the Add field is ignored. The test case is
misc/cgo/test/issue6612.go in internal linking mode.
The cmd/internal/goobj test can now see an external object with no
symbol table; fix it to not crash in that case.
Change-Id: I15e5b7b5a8f48136bc14bf4e1c4c473d5eb58062
Reviewed-on: https://go-review.googlesource.com/64793
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When rewriting loads and stores accessing global variables to use the
GOT we were making use of REGTMP (R10). Unfortunately loads and stores
with large offsets (larger than 20-bits) were also using REGTMP,
causing it to be clobbered and subsequently a segmentation fault.
This can be fixed by using REGTMP2 (R11) for the rewrite. This is fine
because REGTMP2 only has a couple of uses in the assembler (division,
high multiplication and storage-to-storage instructions). We didn't
use REGTMP2 originally because it used to be used more frequently,
in particular for stores of constants to memory. However we have now
eliminated those uses.
This was found while writing a test case for CL 63030. That test case
is included in this CL.
Change-Id: I13956f1f3ca258a7c8a7ff0a7570d2848adf7f68
Reviewed-on: https://go-review.googlesource.com/65011
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing logic tried to advance the offset for each variable's
width, but then tried to undo this logic with the array and struct
handling code. It can all be much simpler by only worrying about
computing offsets within the array and struct code.
While here, include a short-circuit for zero-width arrays to fix a
pedantic compiler failure case.
Passes toolstash-check.
Fixes#20739.
Change-Id: I98af9bb512a33e3efe82b8bf1803199edb480640
Reviewed-on: https://go-review.googlesource.com/64471
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The previous code seems to have an off-by-1 in it somewhere, the
consequence being that we didn't properly preserve all of the old
buffer contents that we intended to.
After spending a while looking at the existing window-shifting logic,
I wasn't able to understand exactly how it was supposed to work or
where the issue was, so I rewrote it to be (at least IMO) more
obviously correct.
Fixes#21938.
Change-Id: I1ed7bbc1e1751a52ab5f7cf0411ae289586dc345
Reviewed-on: https://go-review.googlesource.com/64830
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We used to backup symbol declarations using complete Syms, but this
was unnecessary: very few of Sym's fields were actually needed. Also,
to restore a symbol, we had to re-Lookup the Sym in its Pkg.
By introducing a new dedicated dsym type for this purpose, we can
address both of these deficiencies.
Passes toolstash-check.
Change-Id: I39f3d672b301f84a3a62b9b34b4b2770cb25df79
Reviewed-on: https://go-review.googlesource.com/64811
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Rematerializable ops can be inserted after the flagalloc phase,
they must therefore not clobber flags. This CL adds a check to
ensure this doesn't happen and fixes the instances where it
does currently.
amd64: ADDQconst and ADDLconst were recently changed to be
rematerializable in CL 54393 (only in tip, not 1.9). That change
has been reverted.
s390x: MOVDaddr could clobber flags when using dynamic linking due
to a ADD with immediate instruction. Change the code generation to
use LA/LAY instead.
Fixes#21080.
Change-Id: Ia85c882afa2a820a309e93775354b3169ec6d034
Reviewed-on: https://go-review.googlesource.com/63030
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
These were previously only relevant for recording scoping level so
that invalid 'fallthrough' statements could be rejected. However,
that's handled differently since CL 61130 (in particular, there's no
use of types.Block anymore), so these calls can be safely removed.
Passes toolstash-check.
Change-Id: I8631b156594df85b8d39f57acad3ebcf099d52f9
Reviewed-on: https://go-review.googlesource.com/64810
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL improves the readability of the tests in the bytes package by
naming the `data` test variable `testString`, using the same convention
as its counterpart, `testBytes`.
It additionally removes some type casting which was unnecessary.
Change-Id: If38b5606ce8bda0306bae24498f21cb8dbbb6377
Reviewed-on: https://go-review.googlesource.com/64931
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (9).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
Change-Id: I9247433d7d07a2c99d15b0a4d23164bcbc042768
Reviewed-on: https://go-review.googlesource.com/61015
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ceil, Floor and Trunc are pre-existing intrinsics. Round is a new
function and has been added as an intrinsic in this CL. All of the
functions can be implemented as a single 'LOAD FP INTEGER'
instruction, FIDBR, on s390x.
name old time/op new time/op delta
Ceil 2.34ns ± 0% 0.85ns ± 0% -63.74% (p=0.000 n=5+4)
Floor 2.33ns ± 0% 0.85ns ± 1% -63.35% (p=0.008 n=5+5)
Round 4.23ns ± 0% 0.85ns ± 0% -79.89% (p=0.000 n=5+4)
Trunc 2.35ns ± 0% 0.85ns ± 0% -63.83% (p=0.029 n=4+4)
Change-Id: Idee7ba24a2899d12bf9afee4eedd6b4aaad3c510
Reviewed-on: https://go-review.googlesource.com/63890
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This allows io.WriteString to make use of WriteString method
implemented by pp when writing a string to fmt.State.
Fixes#20786
Change-Id: Ice7a92bf303127ad87f05562217fa076f5c589ad
Reviewed-on: https://go-review.googlesource.com/61430
Reviewed-by: Rob Pike <r@golang.org>
In general, there are no guarantee that `go` command exist on $PATH.
This CL tries to get `go` command from $GOROOT/bin instead.
There are three kinds of code we should handle:
For normal code, the CL implements goCmd() or goCmdName().
For unit tests, the CL uses testenv.GoTool() or testenv.GoToolPath().
For integration tests, the CL sets PATH=$GOROOT/bin:$PATH in cmd/dist.
Note that make.bash sets PATH=$GOROOT/bin:$PATH in the build process.
So this change is only useful when we use toolchain manually.
Updates #21875
Change-Id: I963b9f22ea732dd735363ececde4cf94a5db5ca2
Reviewed-on: https://go-review.googlesource.com/64650
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (8).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I2d5a071eb8e14690325612271432fdc5f43b108b
Reviewed-on: https://go-review.googlesource.com/61014
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Check all associated templates in the set for an existing reference
to the given Tree in AddParseTree before assigning that reference
to a new or existing template. This prevents multiple html/template
Templates from referencing and modifying the same underlying Tree.
While there, fix a few existing unit tests so that they terminate
upon encountering unrecoverable failures.
Fixes#21844
Change-Id: I6b4f6996cf5467113ef94f7b91a6933dbbc21839
Reviewed-on: https://go-review.googlesource.com/64770
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (7).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: Ia3c33ef060b4baaef354b729ba82ed0b28e52857
Reviewed-on: https://go-review.googlesource.com/61013
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We used to have {Arg,Auto,Extern}Symbol structs with which we wrapped
a *gc.Node or *obj.LSym before storing them in the Aux field
of an ssa.Value. This let the SSA part of the compiler distinguish
between autos and args, for example. We no longer need the wrappers
as we can query the underlying objects directly.
There was also some sloppy usage, where VarDef had a *gc.Node
directly in its Aux field, whereas the use of that variable had
that *gc.Node wrapped in an AutoSymbol. Thus the Aux fields didn't
match (using ==) when they probably should.
This sloppy usage cleanup is the only thing in the CL that changes the
generated code - we can get rid of some more unused auto variables if
the matching happens reliably.
Removing this wrapper also lets us get rid of the varsyms cache
(which was used to prevent wrapping the same *gc.Node twice).
Change-Id: I0dedf8f82f84bfee413d310342b777316bd1d478
Reviewed-on: https://go-review.googlesource.com/64452
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If a function with nonzero frame but zero-sized return value is
Call'd, we may write a past-the-end pointer in preparing the
return Values. Fix by return the zero value for zero-sized
return value.
Fixes#21717.
Change-Id: I5351cd86d898467170a888b4c3fc9392f0e7aa3b
Reviewed-on: https://go-review.googlesource.com/60811
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
There was unprotected access to Logger.flag in log.Output which
could lead to data race in cases when log.SetFlags called simultaneously.
For example, "hot" switching on/off debug-mode for Logger by log.SetFlags
while application still writing logs.
Fixes#21935
Change-Id: I36be25f23cad44cde62ed1af28a30d276400e1b8
Reviewed-on: https://go-review.googlesource.com/64710
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously, after inlining a call, we made a second pass to rewrite
the AST's position information to record the inlined stack frame. The
call arguments were part of this AST, but it would be incorrect to
rewrite them too, so extra effort was made to temporarily remove them
while the position rewriting was done.
However, this extra logic was only done for regular arguments: it was
not done for receiver arguments. Consequently if m was inlined in
"f().m(g(), h())", g and h would have correct call frames, but f would
appear to be called by m.
The fix taken by this CL is to merge setpos into inlsubst and only
rewrite position information for nodes that were actually copied from
the original function AST body. As a side benefit, this eliminates an
extra AST pass and some AST walking code.
Fixes#21879.
Change-Id: I22b25c208313fc25c358d3a2eebfc9b012400084
Reviewed-on: https://go-review.googlesource.com/64470
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We previously used bare strings, which made it difficult to see (and
to cross-reference) the set of allowed context values.
This change is purely cosmetic, but makes it easier for me to
understand how to address #21878.
updates #21878
Change-Id: I9027d94fd5997a0fe857c0055dea8719e1511f03
Reviewed-on: https://go-review.googlesource.com/63830
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, we used OXFALL vs OFALL to distinguish fallthrough
statements that had been validated. Because in the Node AST we flatten
statement blocks, OXCASE and OXFALL needed to keep track of their
block scopes for this purpose.
Now that we have an AST that keeps these separate, we can just perform
the validation earlier.
Passes toolstash-check.
Fixes#14540.
Change-Id: I8421eaba16c2b3b72c9c5483b5cf20b14261385e
Reviewed-on: https://go-review.googlesource.com/61130
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When we introduced the distinction between "defined" and "alias" types
we retained the notion of a "named" type (any type with a name). The
predeclared types (which all have names) simply remained named types.
This CL clarifies the spec by stating excplicitly which predeclared
types are defined types (or at least "act" like defined types), and
which ones are alias types.
Fixes#21785.
Change-Id: Ia8ae133509eb5d738e6757b3442c9992355e3535
Reviewed-on: https://go-review.googlesource.com/64591
Reviewed-by: Russ Cox <rsc@golang.org>
This, in turn, to make it work with x/text’s
go generate.
Also eliminates need to manually update version
string in maketables.go.
Change-Id: Id5a8b8e27bdce5b1b5920eb9223a2d27b889149a
Reviewed-on: https://go-review.googlesource.com/63952
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
By setting both a valid size and alignment for broken recursive types,
we can appease some more safety checks and prevent compiler crashes.
Fixes#21882.
Change-Id: Ibaa137d8aa2c2a9d521462f144d7016c4abfd6e7
Reviewed-on: https://go-review.googlesource.com/64430
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Expand documentation in of the internal urlFilter function
to explain why URLs with schemes other than "http", "https",
and "mailto" are filtered out.
Fixes#20586
Change-Id: I1f65ff6e15fc4cd325489327c40f8c141904bf5c
Reviewed-on: https://go-review.googlesource.com/52853
Reviewed-by: Mike Samuel <mikesamuel@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To support the efficient packing and extracting of sparse files,
add two new methods:
func Reader.WriteTo(io.Writer) (int64, error)
func Writer.ReadFrom(io.Reader) (int64, error)
If the current archive entry is sparse and the provided io.{Reader,Writer}
is also an io.Seeker, then use Seek to skip past the holes.
If the last region in a file entry is a hole, then we seek to 1 byte
before the EOF:
* for Reader.WriteTo to write a single byte
to ensure that the resulting filesize is correct.
* for Writer.ReadFrom to read a single byte
to verify that the input filesize is correct.
The downside of this approach is when the last region in the sparse file
is a hole. In the case of Reader.WriteTo, the 1-byte write will cause
the last fragment to have a single chunk allocated.
However, the goal of ReadFrom/WriteTo is *not* the ability to
exactly reproduce sparse files (in terms of the location of sparse holes),
but rather to provide an efficient way to create them.
File systems already impose their own restrictions on how the sparse file
will be created. Some filesystems (e.g., HFS+) don't support sparseness and
seeking forward simply causes the FS to write zeros. Other filesystems
have different chunk sizes, which will cause chunk allocations at boundaries
different from what was in the original sparse file. In either case,
it should not be a normal expectation of users that the location of holes
in sparse files exactly matches the source.
For users that really desire to have exact reproduction of sparse holes,
they can wrap os.File with their own io.WriteSeeker that discards the
final 1-byte write and uses File.Truncate to resize the file to the
correct size.
Other reasons we choose this approach over special-casing *os.File because:
* The Reader already has special-case logic for io.Seeker
* As much as possible, we want to decouple OS-specific logic from
Reader and Writer.
* This allows other abstractions over *os.File to also benefit from
the "skip past holes" logic.
* It is easier to test, since it is harder to mock an *os.File.
Updates #13548
Change-Id: I0a4f293bd53d13d154a946bc4a2ade28a6646f6a
Reviewed-on: https://go-review.googlesource.com/60872
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These are the last instructions missing to complete SSE3 support.
For reference what was missing was found by a tool [1]:
$ x86db-gogen list --extension SSE3 --not-known
ADDSUBPD xmmreg,xmmrm [rm: 66 0f d0 /r] PRESCOTT,SSE3,SO
ADDSUBPS xmmreg,xmmrm [rm: f2 0f d0 /r] PRESCOTT,SSE3,SO
[1] https://github.com/dlespiau/x86dbFixes#20293
Change-Id: Ib5a91bf64dcc5282cdb60eae740ae52b4db16ebd
Reviewed-on: https://go-review.googlesource.com/42990
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
The current generator is a simple LSFR, which showed strong
correlation in higher bits, as manifested by fastrandn().
Change it with xorshift64+, which is slightly more complex,
has a larger state, but has a period of 2^64-1 and is much better
at statistical tests. The version used here is capable of
passing Diehard and even SmallCrush.
Speed is slightly worse but is probably insignificant:
name old time/op new time/op delta
Fastrand-4 0.77ns ±12% 0.91ns ±21% +17.31% (p=0.048 n=5+5)
FastrandHashiter-4 13.6ns ±21% 15.2ns ±17% ~ (p=0.160 n=6+5)
Fastrandn/2-4 2.30ns ± 5% 2.45ns ±15% ~ (p=0.222 n=5+5)
Fastrandn/3-4 2.36ns ± 7% 2.45ns ± 6% ~ (p=0.222 n=5+5)
Fastrandn/4-4 2.33ns ± 8% 2.61ns ±30% ~ (p=0.126 n=6+5)
Fastrandn/5-4 2.33ns ± 5% 2.48ns ± 9% ~ (p=0.052 n=6+5)
Fixes#21806
Change-Id: I013bb37b463fdfc229a7f324df8fe2da8d286f33
Reviewed-on: https://go-review.googlesource.com/62530
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Improves test coverage of the rules added in CL 63795 and would have
detected the bug fixed by CL 63950.
Change-Id: I107ee8d8e0b6684ce85b2446bd5018c5a03d608a
Reviewed-on: https://go-review.googlesource.com/64130
Reviewed-by: Keith Randall <khr@golang.org>
This change makes it easier to express instructions
with arbitrary number of operands.
Rationale: previous approach with operand "hiding" does
not scale well, AVX and especially AVX512 have many
instructions with 3+ operands.
x86 asm backend is updated to handle up to 6 explicit operands.
It also fixes issue with 4-th immediate operand type checks.
All `ytab` tables are updated accordingly.
Changes to non-x86 backends only include these patterns:
`p.From3 = X` => `p.SetFrom3(X)`
`p.From3.X = Y` => `p.GetFrom3().X = Y`
Over time, other backends can adapt Prog.RestArgs
and reduce the amount of workarounds.
-- Performance --
x/benchmark/build:
$ benchstat upstream.bench patched.bench
name old time/op new time/op delta
Build-48 21.7s ± 2% 21.8s ± 2% ~ (p=0.218 n=10+10)
name old binary-size new binary-size delta
Build-48 10.3M ± 0% 10.3M ± 0% ~ (all equal)
name old build-time/op new build-time/op delta
Build-48 21.7s ± 2% 21.8s ± 2% ~ (p=0.218 n=10+10)
name old build-peak-RSS-bytes new build-peak-RSS-bytes delta
Build-48 145MB ± 5% 148MB ± 5% ~ (p=0.218 n=10+10)
name old build-user+sys-time/op new build-user+sys-time/op delta
Build-48 21.0s ± 2% 21.2s ± 2% ~ (p=0.075 n=10+10)
Microbenchmark shows a slight slowdown.
name old time/op new time/op delta
AMD64asm-4 49.5ms ± 1% 49.9ms ± 1% +0.67% (p=0.001 n=23+15)
func BenchmarkAMD64asm(b *testing.B) {
for i := 0; i < b.N; i++ {
TestAMD64EndToEnd(nil)
TestAMD64Encoder(nil)
}
}
Change-Id: I4f1d37b5c2c966da3f2127705ccac9bff0038183
Reviewed-on: https://go-review.googlesource.com/63490
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Variables captured by a closure were always assigned to the root scope
in their declaration function. Using decl.Name.Defn.Pos will result in
the correct scope for both the declaration function and the capturing
function.
Fixes#21515
Change-Id: I3960aface3c4fc97e15b36191a74a7bed5b5ebc1
Reviewed-on: https://go-review.googlesource.com/56830
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Return early from deltimer, with false as the result,
to indicate that we couldn't delete the timer since its
timersBucket was nil(not set) in the first place.
That happens in such a case where a user created
the timer from a Ticker with:
t := time.Ticker{C: c}
The above usage skips the entire setup of assigning
the appropriate underlying runtimeTimer and timersBucket,
steps that are done for us by time.NewTicker.
CL 34784 introduced this bug with an optimization, by changing
stopTimer to retrieve the timersBucket from the timer itself
(which is unset with the mentioned usage pattern above),
whereas the old behavior relied on indexing
by goroutine ID into the global slice of runtime
timers, to retrieve the appropriate timersBucket.
Fixes#21874
Change-Id: Ie9ccc6bdee685414b2430dc4aa74ef618cea2b33
Reviewed-on: https://go-review.googlesource.com/63970
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change has no real effect in itself. This is to prepare for a
followup change that will call lockOSThread during a cgo callback when
there is no p assigned, and therefore when lockOSThread can not use a
write barrier.
Change-Id: Ia122d41acf54191864bcb68f393f2ed3b2f87abc
Reviewed-on: https://go-review.googlesource.com/63630
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The compiler replaces any path of the form /path/to/goroot/src/net/port.go
with GOROOT/src/net/port.go so that the same object file is
produced if the GOROOT is moved. It was skipping this transformation
for any absolute path into the GOROOT that came from //line directives,
such as those generated by cmd/cgo.
Fixes#21373Fixes#21720Fixes#21825
Change-Id: I2784c701b4391cfb92e23efbcb091a84957d61dd
Reviewed-on: https://go-review.googlesource.com/63693
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, if CGO_ENABLED=0 was set when building
with -msan, the error message printed was:
-race requires cgo; enable cgo by setting CGO_ENABLED=1
yet the instrumentation flag passed in was -msan. This CL
fixes that message to correctly report that -msan needed
CGO_ENABLED=1, and likewise if -race, report -race needed it.
Fixes#21895
Change-Id: If423d520daae7847fb38cc97c3192ada5d960f9d
Reviewed-on: https://go-review.googlesource.com/63930
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Add generic rules to propagate floating point constants through
comparisons and integer conversions. These new rules seldom trigger
in the standard library so there is no performance change, however
I think it is worth adding them anyway for completeness.
Change-Id: I9db5222746508a2996f1cafb72f4e0cf2541de07
Reviewed-on: https://go-review.googlesource.com/63795
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The functions Float64bits and Float64frombits perform
poorly on ppc64x because the int<->float conversions
often result in load and store sequences to handle the
type change. This patch adds more rules to recognize
those sequences and use register to register moves
and avoid unnecessary loads and stores where possible.
There were some existing rules to improve these conversions,
but this provides additional improvements. Included here:
- New instruction FCFIDS to improve on conversion to 32 bit
- Rename Xf2i64 and Xi2f64 as MTVSRD, MFVSRD, to match the asm
- Add rules to lower some of the load/store sequences for
- Added new go asm to ppc64.s testcase.
conversions
Improvements:
BenchmarkAbs-16 2.16 0.93 -56.94%
BenchmarkCopysign-16 2.66 1.18 -55.64%
BenchmarkRound-16 4.82 2.69 -44.19%
BenchmarkSignbit-16 1.71 1.14 -33.33%
BenchmarkFrexp-16 11.4 7.94 -30.35%
BenchmarkLogb-16 10.4 7.34 -29.42%
BenchmarkLdexp-16 15.7 11.2 -28.66%
BenchmarkIlogb-16 10.2 7.32 -28.24%
BenchmarkPowInt-16 69.6 55.9 -19.68%
BenchmarkModf-16 10.1 8.19 -18.91%
BenchmarkLog2-16 17.4 14.3 -17.82%
BenchmarkCbrt-16 45.0 37.3 -17.11%
BenchmarkAtanh-16 57.6 48.3 -16.15%
BenchmarkRemainder-16 76.6 65.4 -14.62%
BenchmarkGamma-16 26.0 22.5 -13.46%
BenchmarkPowFrac-16 197 174 -11.68%
BenchmarkMod-16 112 99.8 -10.89%
BenchmarkAsinh-16 59.9 53.7 -10.35%
BenchmarkAcosh-16 44.8 40.3 -10.04%
Updates #21390
Change-Id: I56cc991fc2e55249d69518d4e1ba76cc23904e35
Reviewed-on: https://go-review.googlesource.com/63290
Reviewed-by: Michael Munday <mike.munday@ibm.com>
Rework the test to work with any number of std packages. This was done
to include a few funcs from unicode/utf8. Adding more will be much
simpler too.
While at it, add more runtime funcs by searching for "inlined" or
"inlining" in the git log of its directory. These are: addb, subtractb,
fastrand and noescape.
Updates #21851.
Change-Id: I4fb2bd8aa6a5054218f9b36cb19d897ac533710e
Reviewed-on: https://go-review.googlesource.com/63611
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If the Go packages with enough source files,it will cause EMFILE/ENFILE error,
Fix this by limiting the number of simultaneously opened files.
Fixes#21621
Change-Id: I8555d79242d2f90771e37e073b7540fc7194a64a
Reviewed-on: https://go-review.googlesource.com/57751
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shuffle panics if n < 0, not n <= 0. The comment for the (*Rand).Shuffle
function is already accurate.
Change-Id: I073049310bca9632e50e9ca3ff79eec402122793
Reviewed-on: https://go-review.googlesource.com/63750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
rune has a well-defined size, but C.int is implementation-specified.
Using one as the other should require an explicit conversion.
updates #13467
Change-Id: I53ab2478427dca790efdcc197f6b8d9fbfbd1847
Reviewed-on: https://go-review.googlesource.com/63730
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I had passed 1 instead of 2 to the SplitAfterN call in
errorstest.check, so all of the cases were erroneously falling through
to the non-regexp case (and passing even if the actual error didn't
match).
Now, we use bytes.HasSuffix to check for the non-regexp case, so we
will not incorrectly match a regexp comment to the non-regexp case.
updates #13467
Change-Id: Ia6be928a495425f2b7bae5001bd01346e115dcfa
Reviewed-on: https://go-review.googlesource.com/63692
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These two special cases are unnecessary:
1) "~b%d" references only appear during walk, to handle "return"
statements implicitly assigning to blank result parameters. Even if
they could appear, the "inlined and customized version" accidentally
diverged from p.sym in golang.org/cl/33911.
2) The Vargen case is already identical to the default case, and it
never overlaps with the remaining "T.method" case.
Passes toolstash-check.
Change-Id: I03f7e5b75b707b43afc8ed6eb90f43ba93ed17ae
Reviewed-on: https://go-review.googlesource.com/63272
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Extract device major/minor number on all the BSDs and set Devmajor and
Devminor in FileInfoHeader. Code based on the corresponding Major/Minor
implementations in golang.org/x/sys/unix.
Change-Id: Ieffa7ce0cdbe6481950de666b2f5f88407a32382
Reviewed-on: https://go-review.googlesource.com/63470
Reviewed-by: Joe Tsai <joetsai@google.com>
We only export packages that typechecked successfully, and OTYPE nodes
will always have their Type field set.
Changes the package export format, but only in the compiler-specific
section. No version bump necessary.
Change-Id: I722f5827e73948fceb0432bc8b3b22471fea8f61
Reviewed-on: https://go-review.googlesource.com/63273
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Move it from the runtime package, as we will soon add more packages and
functions for it to check.
The test used the testEnv func, which cleaned certain environment
variables from a command, so it was moved to internal/testenv under a
more descriptive (and less ambiguous) name. Add a simple godoc to it
too.
For #21851.
Change-Id: I6f39c1f23b45377718355fafe66ffd87047d8ab6
Reviewed-on: https://go-review.googlesource.com/63550
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
This makes the test easier to run in isolation and easier to change,
and simplifies the code to run the tests in parallel.
updates #13467
Change-Id: I5622b5cc98276970347da18e95d071dbca3c5cc1
Reviewed-on: https://go-review.googlesource.com/63276
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I modified verify() to fail every time to test the change. Before adding
t.Helper() (line 37 is in verify()):
/.../go/src/container/heap/heap_test.go:37: forced failure
FAIL
Afer adding t.Helper() (line 67 is where verify() is called):
/.../go/src/container/heap/heap_test.go:67: forced failure
FAIL
Fixes#21863
Change-Id: I46f0c8ec413cc664358c568fc53e48bb4a1d03d0
Reviewed-on: https://go-review.googlesource.com/63570
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Found with staticcheck. Not terribly important since the test would
likely fail anyway, but at least it will fail with a better explanation
now.
Change-Id: Ic3f9a94a2152404b7873cc8cd47b6db79d78c2e6
Reviewed-on: https://go-review.googlesource.com/62990
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes it easier to deduce from the field names which overflow
field corresponds to h.buckets and which to h.oldbuckets by aligning
the naming with the buckets fields in hmap.
Change-Id: I8d6a729229a190db0212bac012ead1a3c13cf5d0
Reviewed-on: https://go-review.googlesource.com/62411
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Move the check near the code in evacuate that relies on
the relation evacuateX+1 == evacuateY.
If the relation is fullfilled the check is known to be true
at compile time and removed by the compiler.
Change-Id: I711b75e09047bf347819ccaeec41d244a5883867
Reviewed-on: https://go-review.googlesource.com/62410
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Current implementation doesn't recognize parentheses that may appear in flags
of assembly function as shown below:
TEXT ·makeFuncStub(SB),(NOSPLIT|WRAPPER),$24
It results in vet reporting false positives and a lot of whitelists are added
for suppressing the false alarms.
This CL fixes the issue and eliminates the redundant whitelists.
Change-Id: Idbc1b42965b31cea8ee7c23d1a6f62feb68e844c
Reviewed-on: https://go-review.googlesource.com/62850
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Previously, test7978 failed if the user did not invoke it with
GOTRACEBACK=2 already set in their environment. Environment-sensitive
test are awkward, and in this case there is a very simple workaround:
set the traceback level to the necessary value explicitly.
Change-Id: I7d576f24138aa8a41392148eae11bbeaef558573
Reviewed-on: https://go-review.googlesource.com/63275
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Avoid division in common case. There are 5438 ranges in unicode/tables.go
4110 of them have stride 1.
Stride 1 case got significantly faster. Other stride is a bit slower.
Measured by
import (
"testing"
"unicode"
)
func BenchmarkDiv1(b *testing.B) {
rtb := &unicode.RangeTable{
R16: []unicode.Range16{
{0xa800, 0xdfff, 1}, // or 3
},
}
for i := 0; i < b.N; i++ {
unicode.Is(rtb, rune(0xc700))
}
}
Div1-6 15.6ns ± 1% 9.9ns ± 1% -36.54% (p=0.000 n=10+10)
Div3-6 15.5ns ± 1% 16.1ns ± 1% +3.67% (p=0.000 n=10+10)
Helps a bit with xml parsing from issue #21823
XMLsax-6 30.9s ± 0% 29.6s ± 0% -4.15% (p=0.000 n=10+9)
Change-Id: Ibac1a91d7b9474d0c134b0add83e56caa62daa20
Reviewed-on: https://go-review.googlesource.com/63390
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This label was added automatically by grind to remove gotos. As of
today, it's completely useless, as none of its uses need a label to
begin with.
While at it, remove all the redundant breaks too. Leave those that are
the single statement in a case clause body, as that's the style used
throughout std and cmd to clarify when cases are empty.
Change-Id: I3e20068b66b759614e903beab1cc9b2709b31063
Reviewed-on: https://go-review.googlesource.com/62950
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use constants directly, instead of loading address to e. g. AX
and using (AX). Shouldn't affect performance, but makes code a bit
nicer.
Change-Id: Ifa138e54d3d2b2f4ad71e4ef4b9368ea79eb30f4
Reviewed-on: https://go-review.googlesource.com/62010
Reviewed-by: Adam Langley <agl@golang.org>
Unify colons (outside of <strong></strong>) and add a missing space in
the list of groups of diagnostics solutions.
Change-Id: Icbcd94427d4905dd88c4ea82aaa5dbf064c00990
Reviewed-on: https://go-review.googlesource.com/63111
Reviewed-by: JBD <jbd@google.com>
After the number of lost extra events are written to the the cpuprof log,
the number of lost extra events should be set to zero, or else, the next
time time addExtra is logged, lostExtra will be overcounted. This change
resets lostExtra after its value is written to the log.
Fixes#21836
Change-Id: I8a6ac9c61e579e7a5ca7bdb0f3463f8ae8b9f863
Reviewed-on: https://go-review.googlesource.com/63270
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Skip the ones that have multiple uses for now. Also had to rename the
importComment variable as it shadowed the top-level func by the same
name.
Change-Id: I796285aa7b4fdf2c39e652666390427d37b063ee
Reviewed-on: https://go-review.googlesource.com/63150
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It doesn't change the outcome. It might have been useful at some point
to avoid Replace from doing work or allocating. However, nowadays the
func returns early without doing any work if Count returns 0.
Change-Id: Id69dc74042a6e39672b405016484db8b50f43d58
Reviewed-on: https://go-review.googlesource.com/62991
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Refactor walkrange to treat "for _ = range a" as "for range a".
This avoids generating some later discarded nodes in the compiler.
Passes toolstash -cmp.
Change-Id: Ifb2e1ca3b8519cbb67e8ad5aad514af9d18f1ec4
Reviewed-on: https://go-review.googlesource.com/61017
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Calling response.Body.Close() early would generarate a race before this.
Since closing would return early before the main code path had a chance
to reset the request canceler. Having a non-nil request canceler at the
start of the next request would cause a "request canceled" error.
Here we simply wait for the eofc channel to be closed before returning
from earlyCloseFn, ensuring that the caller won't be re-using that
Request object before we have a chance to reset the request canceler to
nil.
Fixes#21838
Change-Id: I641815526c6ac63d1816c9b6ad49d73715f7a5cb
Reviewed-on: https://go-review.googlesource.com/62891
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
These were likely written in C or added by an automated tool. Either
way, they're unnecessary now. Clean up the code.
Change-Id: I56de2c7bb60ebab8c500803a8b6586bdf4bf75c7
Reviewed-on: https://go-review.googlesource.com/62951
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This adds rules to match the code in math/bits RotateLeft,
RotateLeft32, and RotateLef64 to allow them to be inlined.
The rules are complicated because the code in these function
use different types, and the non-const version of these
shifts generate Mask and Carry instructions that become
subexpressions during the match process.
Also adds a testcase to asm_test.go.
Improvement in math/bits:
BenchmarkRotateLeft-16 1.57 1.32 -15.92%
BenchmarkRotateLeft32-16 1.60 1.37 -14.37%
BenchmarkRotateLeft64-16 1.57 1.32 -15.92%
Updates #21390
Change-Id: Ib6f17669ecc9cab54f18d690be27e2225ca654a4
Reviewed-on: https://go-review.googlesource.com/59932
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The regular expression "A-za-z" is most likely a typo and
the intent seems to be "A-Za-z" instead.
Using "A-z" matches certain characters like: [\]^_`
Updates #10010
Change-Id: If2d064c56ef613f2e46285d8d4e5998e83aed43a
Reviewed-on: https://go-review.googlesource.com/62910
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
The optimised P-256 includes a CombinedMult function, which doesn't do
dual-scalar multiplication, but does avoid an affine conversion for
ECDSA verification.
However, it currently uses an assembly point addition function that
doesn't handle exceptional cases.
Fixes#20215.
Change-Id: I4ba2ca1a546d883364a9bb6bf0bdbc7f7b44c94a
Reviewed-on: https://go-review.googlesource.com/42611
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
On ppc64le, functions compiled with -shared expect r12 to
hold the function's address for indirect calls. Previously
this was enforced by generating a move instruction if the
address wasn't already in r12. This change avoids that extra
move by requesting r12 in the CALL ops that do indirect calls.
As a result of adding support for plugins on ppc64le, it was
discovered that there would be more cases where this extra
move was needed, so this seemed like a better solution.
Updates #20756
Change-Id: I6770885a46990f78c6d2902a715dcdaa822192a1
Reviewed-on: https://go-review.googlesource.com/62890
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 62593 broken TestExportedSymbols and TestUnexportedSymbols
because it started executing android test binary on host.
Make them run on android.
Hopefully fixes android build.
Change-Id: Ic0bb9f0cbbefca23828574282caa33a03ef72431
Reviewed-on: https://go-review.googlesource.com/62830
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
While some map literals were marked non-escaping that information
was lost when creating the corresponding OMAKE node which made map
literals always heap allocated.
Copying the escape information to the corresponding OMAKE node allows
stack allocation of hmap and a map bucket for non escaping map literals.
Fixes#21830
Change-Id: Ife0b020fffbc513f1ac009352f2ecb110d6889c9
Reviewed-on: https://go-review.googlesource.com/62790
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The noopt builder sets GO_GCFLAGS when building the standard library.
Set it when building plugins to ensure the -shared packages built for it
have the same inlining in the export data (and thus the same package
version).
Tested locally with GO_GCFLAGS="-N -l" ./all.bash
Fixes#17937
Change-Id: Id037cfbf4af744c05c47bdc58eea60a5dba69533
Reviewed-on: https://go-review.googlesource.com/62511
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
1. remove broken verification
The runtime check assumes that no-pcln symbol entry have zero value,
but the linker emit no entries if the symbol is no-pcln.
As a result, if there are no-pcln symbols at the very end of pcln
table, it will panic.
2. correct condition of export
Handle special chracters in pluginpath correcty.
Export "go.itab.*", so different plugins can share the same itab.
Fixes#18190
Change-Id: Ia4f9c51d83ce8488a9470520f1ee9432802cfc1d
Reviewed-on: https://go-review.googlesource.com/61091
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Current code always uses a C compilers for checking compiler flags even
for non-C compilers. This CL solves the issue.
Fixes#21736
Change-Id: I5eaddd5fe7d5df699eb2384518b21e6064ca31cf
Reviewed-on: https://go-review.googlesource.com/61270
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The Ldate doc refers to all the constants.
Note that I changed "Bits or'ed" to "Bits are or'ed".
Fixes#21810
Change-Id: I82a66b589689e29063a39aa6d56000e00a5ed150
Reviewed-on: https://go-review.googlesource.com/62671
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is already a table of signature algorithm details so the code
should use it for the name too. This avoids mismatches.
Change-Id: I0d4befbae721ec43db9f87cd93173ec12749e4c8
Reviewed-on: https://go-review.googlesource.com/57210
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
signatureAlgorithmDetails already knows the hash function for each
signature algorithm so there's no point in duplicating that. Also, check
that the public key type of the signature algorithm actually matches the
given public key.
Change-Id: I7aab4ea71691fb815d67ba790b721ce02de11b85
Reviewed-on: https://go-review.googlesource.com/57211
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It was causing mysterious fuzzing failure because it affects the
unmarshaling of the secureNegotiationSupported field.
Change-Id: Id396b84eab90a3b22fb6e306b10bdd7e39707012
Reviewed-on: https://go-review.googlesource.com/60912
Run-TryBot: Filippo Valsorda <hi@filippo.io>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TestGetClientCertificate had disabled verification, and was only passing
because it was mistakenly checking for empty verifiedChains.
Change-Id: Iea0ddbdbbdf8ac34b499569820a2e4ce543a69c7
Reviewed-on: https://go-review.googlesource.com/47430
Run-TryBot: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
As of CL 42533, cmd/go will recompute its GOROOT based on the
location of its own executable. This CL plumbs that computed GOROOT
into every binary it builds using the linker -X flag. This
means binaries built with a moved cmd/go will report the GOROOT
they were built in from runtime.GOROOT().
Fixes#21313
Change-Id: I6c2c559f40f2a0c867ab60cf47c6dbc73ae5e28a
Reviewed-on: https://go-review.googlesource.com/61310
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 62250 makes constant folding a bit more aggressive and these
benchmarks were optimized away. This CL adds some indirection to
the function arguments to stop them being folded.
The Copysign benchmark is a bit faster because I've left one
argument as a constant and it can be partially folded.
old CL 62250 this CL
Copysign 1.24ns ± 0% 0.34ns ± 2% 1.02ns ± 2%
Abs 0.67ns ± 0% 0.35ns ± 3% 0.67ns ± 0%
Signbit 0.87ns ± 0% 0.35ns ± 2% 0.87ns ± 1%
Change-Id: I9604465a87d7aa29f4bd6009839c8ee354be3cd7
Reviewed-on: https://go-review.googlesource.com/62450
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Along the way, track bad modules. Make sure they don't end up on
the active modules list, and aren't accidentally reprocessed as
new plugins.
Fixes#19004
Change-Id: I8a5e7bb11f572f7b657a97d521a7f84822a35c07
Reviewed-on: https://go-review.googlesource.com/61171
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It is common to have multiple plugins built from ephemeral
source files all with the same name:
# generate main.go
go build -buildmode=plugin -o=p1.so main.go
# rm main.go, generate new main.go
go build -buildmode=plugin -o=p2.so main.go
...
These different plugins currently have the same build ID,
and hence the same package path. This means only one can be
loaded.
To remove this restriction, this commit adds the contents of the
main package source files to the plugin hash.
Fixes#19358
Change-Id: Icd42024b085feb29c09c2771aaecb85f8b528dd3
Reviewed-on: https://go-review.googlesource.com/61170
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The binary export data format includes escaping to prevent "\n$$" from
appearing internally, but not "\n!\n". This could result in a false
positive when cmd/pack searched for "\n!\n" as the delimiter between
package definition and linker object.
To address this, this CL changes cmd/pack to also be aware of the
"\n$$" markers, and to ignore "\n!\n" within the export data.
Fixes#21703.
Change-Id: I71ea8ba49dbd066c7afb7717ddc0190e38fe5649
Reviewed-on: https://go-review.googlesource.com/60773
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (6).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I1c49e3427079194210a6416057100a7e94a37619
Reviewed-on: https://go-review.googlesource.com/61012
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (5).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I0efd1271b6a70bb9248d82f8a4d869556f4a557e
Reviewed-on: https://go-review.googlesource.com/61011
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (4).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I5e163f89a518f074e58bf2d44597e553c918d7e6
Reviewed-on: https://go-review.googlesource.com/61010
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (3).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I7612bbc3939e6fca3bee4b8e92c528178dd46cd7
Reviewed-on: https://go-review.googlesource.com/61023
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The behavior was changed unintentionally during the conversion from C to Go.
Reviewed-on: https://go-review.googlesource.com/2470
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (2).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I53373c7211b35ed68da485c55e510871bfb81267
Reviewed-on: https://go-review.googlesource.com/61022
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This belongs to a series of clean-up changes (see below) for cmd/dist.
This is change (1).
These changes include:
(1) apply minor fixes
(2) restore behavior of branchtag
(3) unleash bootstrap optimization for windows
(4) use standard generated code header
(5) remove trivial variables + functions
(6) move functions for the better
(7) simplify code segments
(8) use bytes.Buffer for code generation
(9) rename variables + functions
(10) remove doc.go
Change-Id: I49e5f2a9b6146e2b60a067da5bac31434ffc9aaf
Reviewed-on: https://go-review.googlesource.com/60650
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Diagnostics guide lists various dimensions of
diagnostics tools and libraries available in Go.
As a follow-up, I will add an entry section where
we navigate user to the right tool depending on
the type of problem they are willing to improve
or understand better.
Change-Id: I4e94b4b834014f51c988103457da84200c7827d9
Reviewed-on: https://go-review.googlesource.com/61693
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This CL adds generic SSA rules to propagate constants through raw bits
conversions between floats and integers. This allows constants to
propagate through some math functions. For example, math.Copysign(0, -1)
is now constant folded to a load of -0.0.
Requires a fix to the ARM assembler which loaded -0.0 as +0.0.
Change-Id: I52649a4691077c7414f19d17bb599a6743c23ac2
Reviewed-on: https://go-review.googlesource.com/62250
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Perm and Shuffle are fundamentally doing the same work.
This change makes Perm's algorithm match Shuffle's.
In addition to allowing developers to switch more
easily between the two methods, it affords a nice speed-up:
name old time/op new time/op delta
Perm3-8 75.7ns ± 1% 51.8ns ± 1% -31.59% (p=0.000 n=9+8)
Perm30-8 610ns ± 1% 405ns ± 1% -33.67% (p=0.000 n=9+9)
This change alters the output from Perm,
given the same Source and seed.
This is a change from Go 1.0 behavior.
This necessitates updating the regression test.
This also changes the number of calls made to the Source
during Perm, which changes the output of the math/rand examples.
This also slightly perturbs the output of Perm,
nudging it out of the range currently accepted by TestUniformFactorial.
However, it is complete unclear that the helpers relied on
by TestUniformFactorial are correct. That is #21211.
This change updates checkSimilarDistribution to respect
closeEnough for standard deviations, which makes the test pass.
The whole situation is muddy; see #21211 for details.
There is an alternative implementation of Perm
that avoids initializing m, which is more similar
to the existing implementation, plus some optimizations:
func (r *Rand) Perm(n int) []int {
m := make([]int, n)
max31 := n
if n > 1<<31-1-1 {
max31 = 1<<31 - 1 - 1
}
i := 1
for ; i < max31; i++ {
j := r.int31n(int32(i + 1))
m[i] = m[j]
m[j] = i
}
for ; i < n; i++ {
j := r.Int63n(int64(i + 1))
m[i] = m[j]
m[j] = i
}
return m
}
This is a tiny bit faster than the implementation
actually used in this change:
name old time/op new time/op delta
Perm3-8 51.8ns ± 1% 50.3ns ± 1% -2.83% (p=0.000 n=8+9)
Perm30-8 405ns ± 1% 394ns ± 1% -2.66% (p=0.000 n=9+8)
However, 3% in performance doesn't seem worth
having the two algorithms diverge,
nor the reduced readability of this alternative.
Updates #16213.
Change-Id: I11a7441ff8837ee9c241b4c88f7aa905348be781
Reviewed-on: https://go-review.googlesource.com/55972
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Shuffle uses the Fisher-Yates algorithm.
Since this is new API, it affords us the opportunity
to use a much faster Int31n implementation that mostly avoids division.
As a result, BenchmarkPerm30ViaShuffle is
about 30% faster than BenchmarkPerm30,
despite requiring a separate initialization loop
and using function calls to swap elements.
Fixes#20480
Updates #16213
Updates #21211
Change-Id: Ib8956c4bebed9d84f193eb98282ec16ee7c2b2d5
Reviewed-on: https://go-review.googlesource.com/51891
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ensure that the implicitly created redirect
for
"/route"
after
"/route/"
has been registered doesn't lose the query string information.
A previous attempt (https://golang.org/cl/43779) changed http.Redirect, however, that change broke direct calls to http.Redirect.
To avoid that problem, this change touches ServeMux.Handler only.
Fixes#17841
Change-Id: I303c1b1824615304ae68147e254bb41b0ea339be
Reviewed-on: https://go-review.googlesource.com/61210
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Change "yshl" and "yshb" immediate oclass from Yi32 to Yu8.
This forbids:
- negative shift counts
- shift counts that not fit into 8bit
Affects:
RCL{B,L,Q,W}
RCR{B,L,Q,W}
ROL{B,L,Q,W}
ROR{B,L,Q,W}
SAL{B,L,Q,W}
SAR{B,L,Q,W}
SHL{B,L,Q,W}
SHR{B,L,Q,W}
Issue #21528 has some additional context about this change.
Change-Id: I60884cb2b41a860820889fcd878ca6f564006b4a
Reviewed-on: https://go-review.googlesource.com/62190
Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The lexer keeps the byte offset and the line for the rune it's currently
on. This was simple enough up until whitespace trimming was introduced.
With whitespace trimming, we might skip over newlines. In that case, the
lexer wasn't properly updating the line counter. Fix it.
Also, TestPos now checks that the line is correct too, which it was
ignoring before. This was necessary to test this scenario in the lexer.
Fixes#21778.
Change-Id: I3880f3adf02662eac8f818d5caa6935cca9cb33b
Reviewed-on: https://go-review.googlesource.com/61870
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The isStar and directory function parameters have been unused ever since
they were introduced. Remove them.
While at it, apply some other minor simplifications, such as simplifying
a HasPrefix if and using an early continue to unindent many lines of
code.
Change-Id: I8d57353e9ec10cdb59c5388cf6152ce0ec17bdba
Reviewed-on: https://go-review.googlesource.com/62030
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
There shouldn't be any problems setting error's "Orig" (underlying)
type to a separate anonymous interface, as this is already how
go/types defines it.
Change-Id: I44e9c4048ffe362ce329e8306632e38b5ccfecff
Reviewed-on: https://go-review.googlesource.com/61790
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Alan Donovan <adonovan@google.com>
This adds the VFMADD[213|231]SD, VFNMADD[213|231]SD,
VADDSD, VSUBSD instructions
This will allow us to write a fast path for exp_amd64.s where
these optimizations can be applied in a lot of places.
Change-Id: Ide292107ab887bd1e225a1ad60880235b5ed7c61
Reviewed-on: https://go-review.googlesource.com/61810
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now that all functions have a DW_AT_frame_base defined we can use
DW_OP_fbreg to specify the location of variables and formal parameters,
instead of the DW_OP_call_frame_cfa/DW_OP_consts/DW_OP_plus, saving 2
bytes for every variable and 2 bytes for every formal parameter after
the first one.
Change-Id: I2c7395b67e4a814a0131ab1520df11ca48ff9327
Reviewed-on: https://go-review.googlesource.com/60550
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
DWARF version 4 allows DW_AT_high_pc to be represented as a constant
offset from DW_AT_low_pc, this can help save up to 7 bytes per
function/lexical scope.
Change-Id: I93638d83638ecad4d0d1bfe27348eae6139820c9
Reviewed-on: https://go-review.googlesource.com/60530
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This is the last instruction I found missing in SSE2 set.
It does not reuse 'yprefetch' ytabs due to differences in
operands SRC/DST roles:
- PREFETCHx: ModRM:r/m(r) -> FROM
- CLFLUSH: ModRM:r/m(w) -> TO
unaryDst map is extended accordingly.
Change-Id: I89e34ebb81cc0ee5f9ebbb1301bad417f7ee437f
Reviewed-on: https://go-review.googlesource.com/56833
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Functions like NewCBCDecrypter, NewCBCEncrypter, NewCFBDecrypter,
NewCFBEncrypter and NewCTR all panic when IV length does not equal block size.
This commit changes NewOFB to panic too, instead of returning nil silently.
Change-Id: Ic4d3ebfad79bb0cf4759fa1c1a400c1a8d043490
Reviewed-on: https://go-review.googlesource.com/61850
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Run-TryBot: Filippo Valsorda <hi@filippo.io>
TryBot-Result: Gobot Gobot <gobot@golang.org>
runtime.makemap will allocate map buckets on the heap for hints larger
than the number of elements a single map bucket can hold.
Do not allocate any map bucket on the stack if it is known at compile time
that hint is larger than the number of elements one map bucket can hold.
This avoids zeroing and reserving memory on the stack that will not be used.
Change-Id: I1a5ab853fb16f6a18d67674a77701bf0cf29b550
Reviewed-on: https://go-review.googlesource.com/60450
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The compiler and reflect already zero hiter before mapiterinit.
While here expand the documentation for mapiterinit.
Change-Id: I78b05d4d14bf78e8091e5353cdac80ffed30ca1e
Reviewed-on: https://go-review.googlesource.com/60673
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Remove the runtime ismapkey check from makemap and
add a check that the map key type supports comparison
to the hmap construction in the compiler.
Move the ismapkey check for the reflect code path
into reflect_makemap.
Change-Id: I718f79b0670c05b63ef31721e72408f59ec4ae86
Reviewed-on: https://go-review.googlesource.com/61035
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Move memclr to a separate file to make it consistent
with other platforms asm function to file organization.
Remove nacl from the memmove filename as the implementation
is generic for the amd64p32 platform even if currently only
nacl is supported for amd64p32.
Change-Id: I8930b76da430a5cf2664801974e4f5185fc0f82f
Reviewed-on: https://go-review.googlesource.com/61031
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, we handle "x op= y" by rewriting as "x = x op y", while
ensuring that any calls or receive operations in 'x' are only
evaluated once. Notably, pointer indirection, indexing operations,
etc. are left alone as it's typically safe to re-evaluate those.
However, those operations were interleaved with evaluating 'y', which
could include function calls that might cause re-evaluation to yield
different memory addresses.
As a fix, simply ensure that we order side-effecting operations in 'y'
before either evaluation of 'x'.
Fixes#21687.
Change-Id: Ib14e77760fda9c828e394e8e362dc9e5319a84b2
Reviewed-on: https://go-review.googlesource.com/60091
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This function avoids subtle faults found in many ad-hoc implementations,
and is simple enough to be inlined by the compiler.
Fixes#20100
Change-Id: Ib320254e9b1f1f798c6ef906b116f63bc29e8d08
Reviewed-on: https://go-review.googlesource.com/43652
Reviewed-by: Robert Griesemer <gri@golang.org>
overLoadFactor wasn't really doing what it says it does.
It was reporting overOrEqualToLoadFactor. That's actually what we
want when adding an entry to a map, but it isn't what we want when
constructing a map in the first place.
The impetus for this change is that if you make a map with a hint
of exactly 8 (which happens, for example, with the unitMap in
time/format.go), we allocate 2 buckets for it instead of 1.
Instead, make overLoadFactor really report when it is > the max
allowed load factor, not >=. Adjust the callers who want to ensure
that the map is no more than the max load factor after an insertion
by adding a +1 to the current (pre-addition) size.
Change-Id: Ie8d85344800a9a870036b637b1031ddd9e4b93f9
Reviewed-on: https://go-review.googlesource.com/61053
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Currently we only use 1 and 4 as a scale for indexed 4-byte load.
In code generated in #20711 we can use indexed load with scale=8,
to improve performance:
name old time/op new time/op delta
GM-6 108µs ± 0% 95µs ± 0% -12.06% (p=0.000 n=10+10)
So add new ops and combine loadidx1(shift 3..).. into loadidx8,
same for stores.
Change-Id: I5ed1c250ac40960e20606580cf9de221e75b72f1
Reviewed-on: https://go-review.googlesource.com/46134
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When compiling a plugin, package main gets a new name so as not to
conflict with the main package in the host binary, or any other
plugins. It is already defined by cmd/go, and used by cmd/link when
filling out the "" package placeholder in symbols.
With this CL, the plugin-specific name for main is also passed to
cmd/compile's -p flag. This is used to fill out the pkgpath field
of types, and ensures that two types defined in two different plugin
mains with the same name will not be mistaken for one another at
runtime.
Fixes#21386
Change-Id: I8a646d8d7451caff533fe0007343ea8b8e1704ed
Reviewed-on: https://go-review.googlesource.com/60910
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The spec is not conclusive about whether a non-constant shift of
certain untyped constant left operands is valid when the shift
expression appears as an index in an index or slice expression,
or as a size in a `make` function call.
Despite identical spec rules in all these cases, cmd/compile accepts
make([]byte, 1.0 << s)
but pronounces an error for
a[1.0 << s]
(go/types accepts both).
This change clarifies the spec by explicitly stating that an
untyped constant left operand in a non-constant shift (1.0 in
the above examples) will be given type `int` in these contexts.
A separate issue #21693 addresses the cmd/compile bug.
Fixes#14844.
Change-Id: I4b52125e487a607fae377fcbed55463cdce9836c
Reviewed-on: https://go-review.googlesource.com/60230
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Packages of dot imports don't appear in the Info.Implicits map
since they are already taken care of by the Info.Defs map. Fix
documentation.
Implicitly dot-imported objects of a package shouldn't appear
in the Info.Implicits map because the documentation never said
so and there's no way to map multiple objects to the same
*ast.ImportSpec with the current data structure.
Added missing test for Info.Implicits.
The fix is a trivial one-line deletion, the rest is documentation
and test.
Fixes#21591.
Change-Id: I12a37dab85c531911c9363ec3d58daa095c7eb24
Reviewed-on: https://go-review.googlesource.com/60672
Reviewed-by: Alan Donovan <adonovan@google.com>
The "build flags" mentioned in the documentation are only those
that apply to analyzing packages and executing the tool.
Fixes#21711.
Change-Id: Ie7b2a354f1e30c928b40888c51fc68e599a5444a
Reviewed-on: https://go-review.googlesource.com/60830
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The approach of https://golang.org/cl/43476 turned out incorrect.
The problem is that the sniff introduced by the CL only work for simple
expression. And when it fails it fallback to uint64, not int64, which
breaks backward compatibility.
In this CL, we use DWARF for guessing kind instead. That should be more
reliable than previous approach. And importanly, it fallbacks to int64 even
if it fails to guess kind.
Fixes#21708
Change-Id: I39a18cb2efbe4faa9becdcf53d5ac68dba180d46
Reviewed-on: https://go-review.googlesource.com/60510
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On OpenBSD -current, clang is available/installed as 'cc'. This means that
the existing clang check fails and the clang related flags are not enabled.
Fix this by enabling the clang flags if the compiler claims to support them.
Change-Id: I84d124d2409a10f87002c6cbfdb69b4c9a55981a
Reviewed-on: https://go-review.googlesource.com/60750
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Simplify the DWARF representation of structs by emitting field offsets
as constants rather than location descriptions.
This was not explicitly mentioned as an option in DWARF2. It is
mentioned in DWARF4, but isn't listed in the changes, so it's not clear
if this was always intended to work or is an undocumented change. Either
way, it should be valid DWARF4.
Change-Id: Idf7fdd397a21c8f8745673ecc77ef65afa3ffe1c
Reviewed-on: https://go-review.googlesource.com/51611
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When we added a Stat call to determine the initial buffer size in
https://golang.org/cl/163069, we included an arbitrary 1e9-byte limit
"just in case". That interacts badly with power-of-2 resizing in
*bytes.Buffer: it causes buffers reading from very large files to
consume up to twice the necessary space.
The documentation for (os.FileInfo).Size says that it reports "length
in bytes for regular files; system-dependent for others", but the
"system dependent" cases overwhelmingly return either a small number
(e.g., the length of the target path for a symlink) or a non-positive
number (e.g., for a file in /proc under Linux). It should be
appropriate to use the number reported by Size as an approximate lower
bound, even if it is large.
fixes#21455
Change-Id: I609c72519b7b87428c24d0b22db46eede30e0e54
Reviewed-on: https://go-review.googlesource.com/55870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes sure that the go/types package still builds even if
the hilbert test generated its test file in the go/types package
(when run as: go test -run Hilbert -out=h.go).
Change-Id: I60ecbaaa1537de14cfa95e2e6fc8ebedff651baf
Reviewed-on: https://go-review.googlesource.com/60531
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Some constants were added to flate that seem to be an experimental
attempt at increasing the window size. However, according to RFC1951,
the largest window size is 32KiB, so these constants are non-standard.
Delete them.
Fixes#18458
Change-Id: Ia94989637ca031a56bce2548624fa48044caa7b9
Reviewed-on: https://go-review.googlesource.com/60490
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change added support "end of central directory record comemnt" to the Writer.
There is a new exported field Writer.Comment in this change.
If invalid size of comment was set, Close returns error without closing resources.
Fixes#21634
Change-Id: Ifb62bc6c7f81b9257ac83eb570ad9915de727f8c
Reviewed-on: https://go-review.googlesource.com/59310
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Normal shift rules plus constant folding are enough to generate
efficient shift-by-constant instructions.
Add test to make sure we don't generate comparisons for constant
shifts.
TODO: there are still constant shift rules on PPC64. If they
are removed, the constant folding rules are not enough to remove
all the test and mask stuff for constant shifts. Leave them in
for now.
Fixes#20663.
Change-Id: I724cc324aa8607762d0c8aacf9bfa641bda5c2a1
Reviewed-on: https://go-review.googlesource.com/60330
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Between go1.7 and go1.8, a performance regression was introduced in some of the
BenchmarkCompareBytes benchmarks.
Go1.7 vs Go1.8:
BenchmarkCompareBytesToNil-8 7.44 8.44 +13.44%
BenchmarkCompareBytesIdentical-8 6.96 11.5 +65.23%
BenchmarkCompareBytesBigIdentical-8 6.65 47112 +708351.13%
This change fixes the problem by optimizing the case where the byte slices being
compared are equal:
Go1.9 vs current:
BenchmarkCompareBytesToNil-8 7.35 7.00 -4.76%
BenchmarkCompareBytesIdentical-8 11.4 6.81 -40.26%
BenchmarkCompareBytesBigIdentical-8 48396 9.26 -99.98%
runtime.cmpstring can benefit from the same approach and is also changed.
Change-Id: I3cb25f59d8b940a83a2cf687eea764cfeff90688
Reviewed-on: https://go-review.googlesource.com/59650
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Currently, cgo supports only macros which can be reduced to constants
or variables. The CL addresses remaining parts, macros which can be
represented as niladic functions.
The basic idea is simple:
1. make a thin wrapper function per macros.
2. replace macro expansions with function calls.
Fixes#10715Fixes#18720
Change-Id: I150b4fb48e9dc4cc34466ef6417c04ac93d4bc1a
Reviewed-on: https://go-review.googlesource.com/43970
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Nearly every Header obtained from FileInfoHeader via the FS has
timestamps with sub-second resolution and the AccessTime
and ChangeTime fields populated. This forces the PAX format
to almost always be used, which has the following problems:
* PAX is still not as widely supported compared to USTAR
* The PAX headers will occupy at minimum 1KiB for every entry
The old behavior of tar Writer had no support for sub-second resolution
nor any support for AccessTime or ChangeTime, so had neither problem.
Instead the Writer would just truncate sub-second information and
ignore the AccessTime and ChangeTime fields.
In this CL, we preserve the behavior such that the *default* behavior
would output a USTAR header for most cases by truncating sub-second
time measurements and ignoring AccessTime and ChangeTime.
To use either of the features, users will need to explicitly specify
that the format is PAX or GNU.
The exact policy chosen is this:
* USTAR and GNU may still be chosen even if sub-second measurements
are present; they simply truncate the timestamp to the nearest second.
As before, PAX uses sub-second resolutions.
* If the Format is unspecified, then WriteHeader ignores AccessTime
and ChangeTime when using the USTAR format.
This ensures that USTAR may still be chosen for a vast majority of
file entries obtained through FileInfoHeader.
Updates #11171
Updates #17876
Change-Id: Icc5274d4245922924498fd79b8d3ae94d5717271
Reviewed-on: https://go-review.googlesource.com/59230
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, the suggested code would result in the following golint warning:
“should drop = 0 from declaration of var errorsOnlyKey; it is the zero value”
Change-Id: I1a302c1e40ca89acbc76897e39097ecd04865460
Reviewed-on: https://go-review.googlesource.com/60290
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some instructions operating on <= 32 bits also zero out upper 32bits.
Remove zeroextensions of such values. Triggers a few times during
all.bash. Also removes ugly code like:
MOVL CX,CX
Change-Id: I66a46c190dd6929b7e3c52f3fe6b967768d00638
Reviewed-on: https://go-review.googlesource.com/58090
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The last sentence in the section on slice expressions could be read
as if it might apply to strings. Changed the sentence a bit to
emphasize its applicability to slices only. See also the issue for
more background.
Fixes#19220.
Change-Id: I8551f34230e4ed93f951e7b871cc81f54a5874a9
Reviewed-on: https://go-review.googlesource.com/59890
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes the name of the function to construct the map bucket type
consistent with runtimes naming and the existing hmap function.
Change-Id: If4d8b4a54c92ab914d4adcb96022b48d8b5db631
Reviewed-on: https://go-review.googlesource.com/59915
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Padding needed for map buckets is dependent on the types used to
construct the map bucket. In case of indirect keys or values pointers
are used in the map bucket to the keys or values.
Change the map bucket padding calculation to take the alignment of
the key and value types used to construct the map bucket into account
instead of the original key and value type.
Since pointers are always 32bit aligned on amd64p32 this prevents
adding unneeded padding in case the key or value would have needed
64bit alignment without indirect referencing.
Change-Id: I7943448e882d269b5cff7e921a2a6f3430c50878
Reviewed-on: https://go-review.googlesource.com/60030
Reviewed-by: Keith Randall <khr@golang.org>
Check map invariants, type size and alignments during compile time.
Keep runtime checks for reflect by adding them to reflect_makemap.
Change-Id: Ia28610626591bf7fafb7d5a1ca318da272e54879
Reviewed-on: https://go-review.googlesource.com/59914
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
* rename to emitPcln because I'd like to skip not only container types,
but also something like "go.buildid" in the future.
* return bool instead of int.
Change-Id: I029adb81292f7dd2fe98e69f3877c5c27f32ec30
Reviewed-on: https://go-review.googlesource.com/59415
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
We take a best-effort approach since information for these fields
are not well supported on all platforms.
user.LookupId+user.LookupGroupId is currently 15x slower than os.Stat.
For performance reasons, we perpetually cache username and groupname
with a sync.Map. As a result, this function will not be updated whenever
the user or group names are renamed in the OS. However, this is a better
situation than before, where those fields were not populated at all.
Change-Id: I3cec8291aed7675dea89ee1cbda92bd493c8831f
Reviewed-on: https://go-review.googlesource.com/59531
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit relaxes SendmsgN behavior of introducing a dummy 1-byte
payload when sending ancillary-only messages.
The fake payload is not needed for SOCK_DGRAM type sockets, and actually
breaks interoperability with other fd-passing software (journald is one
known example). This introduces an additional check to avoid injecting
dummy payload in such case.
Full reference at https:/golang.org/issue/6476#issue-51285243
Fixes#6476
Change-Id: I19a974b4e7920e002bd0556259ab766572358520
Reviewed-on: https://go-review.googlesource.com/45872
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* extract pkgname() and findlib() from the function for #18190.
* rename const pkgname to const pkgdef to avoid confliction.
Change-Id: Ie62509bfbddcf19cf92b5b12b598679a069e6e74
Reviewed-on: https://go-review.googlesource.com/59417
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Right now we only kind of sort of trace GC STW events. We emit events
around mark termination, but those start well after stopping the world
and end before starting it again, and we don't emit any events for
sweep termination.
Fix this by generalizing EvGCScanStart/EvGCScanDone. These were
already re-purposed to indicate mark termination (despite the names).
This commit renames them to EvGCSTWStart/EvGCSTWDone, adds an argument
to indicate the STW reason, and shuffles the runtime to generate them
right before stopping the world and right after starting the world,
respectively.
These events will make it possible to generate precise minimum mutator
utilization (MMU) graphs and could be useful in detecting
non-preemptible goroutines (e.g., #20792).
Change-Id: If95783f370781d8ef66addd94886028103a7c26f
Reviewed-on: https://go-review.googlesource.com/55411
Reviewed-by: Rick Hudson <rlh@golang.org>
Found with mvdan.cc/unindent. It skipped the cases where parentheses
would need to be added, where comments would have to be moved elsewhere,
or where actions and simple logic would mix.
One of them was of the form "err != nil && err == io.EOF", so the first
part was removed.
Change-Id: Ie504c2b03a2c87d10ecbca1b9270069be1171b91
Reviewed-on: https://go-review.googlesource.com/57690
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some custom usage functions call it for clarity; others rely on the default
behavior, which makes an explicit call redundant. Document that it's
safe to be explicit.
Fixes#21671.
Change-Id: I08e9f47265582821cfd35995dff0c589cd85809d
Reviewed-on: https://go-review.googlesource.com/59792
Reviewed-by: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 57291 broke on solaris because it depends on signal forwarding
working for signals raised by dieFromSignal.
Call sigtrampgo instead of sighandler directly, like the other
unix platforms.
Fixes the solaris builders.
Change-Id: I6bf314c436d1edeaecc4b03f15a9155270919524
Reviewed-on: https://go-review.googlesource.com/59811
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Saying that they return t unchanged is misleading, because they return
a modified t, stripped of any monotonic clock reading, as of Go 1.9.
Fixes#21485.
Change-Id: Icddf8813aed3d687fcefcd2fe542829438be6a0a
Reviewed-on: https://go-review.googlesource.com/56690
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit adds an example to the runtime/trace package
on how to use the trace.Start and trace.Stop functions
to trace the execution of a Go program and write
its trace output to a file.
Change-Id: Idf920398f1c3b9d185af9df5ce9293f2361db022
Reviewed-on: https://go-review.googlesource.com/51170
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This change could improve the hit rate on itabTable during growth.
While we are here patch comments to refer to existing functions.
Change-Id: I76f81c860a3d6107e077e7e3932550858a8b7651
Reviewed-on: https://go-review.googlesource.com/55912
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This change adds new ppc64 instructions from the POWER9 ISA. This includes
compares, loads, maths, register moves and the new random number generator and
copy/paste facilities.
Change-Id: Ife3720b90f5af184ff115bbcdcbce5c1302d39b6
Reviewed-on: https://go-review.googlesource.com/53930
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
According to CL 31817, fmt cannot invoke String or Error methods
on unexported struct fields.
Fixes#17798.
Change-Id: I0d516577298bc36daa9a94313c3874d64dc079e6
Reviewed-on: https://go-review.googlesource.com/44831
Reviewed-by: Rob Pike <r@golang.org>
CL 49590 made it possible for external signal handlers to catch
signals from a crashing Go process. This CL extends that support
to handlers registered after the Go runtime has initialized.
Updates #20392 (and possibly fix it).
Change-Id: I18eccd5e958a505f4d1782a7fc51c16bd3a4ff9c
Reviewed-on: https://go-review.googlesource.com/57291
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Current code uses names like "x" and "s" which can conflict with user's
code easily. Use cryptographic names.
Fixes#21668
Change-Id: Ib6d3d6327aa5b92d95c71503d42e3a79d96c8e15
Reviewed-on: https://go-review.googlesource.com/59710
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When given one argument, as in
go doc binary.BigEndian
doc would search for the package, but when given two, as in
go doc binary BigEndian
it would not. Fix the inconsistency.
Fixes#18697Fixes#18664
Change-Id: Ib59dc483e8d4f91e6061c77a5ec24d0a50e115f0
Reviewed-on: https://go-review.googlesource.com/59413
Reviewed-by: Aliaksandr Valialkin <valyala@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The assembler barfs on large offsets. Make sure that all the
instructions that need to have their offsets in an int32
1) check on any rule that computes offsets for such instructions
2) change their aux fields so the check builder checks it.
The assembler also silently misassembled offsets between 1<<31
and 1<<32. Add a check in the assembler to barf on those as well.
Fixes#21655
Change-Id: Iebf24bf10f9f37b3ea819ceb7d588251c0f46d7d
Reviewed-on: https://go-review.googlesource.com/59630
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is useful when debugging the tool.
Some tweaks on logging: log the webserver address, log.Print instead
of log.Printf when possible.
Change-Id: Iaf71b6523b40dc13795511784d48eacf0f5a396a
Reviewed-on: https://go-review.googlesource.com/59570
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
The newly added routines are exact copies of the generic routines,
except for the function names and that growWork_fastX calls evacuate_fastX.
Actual optimization will happen in subsequent CLs.
This is intended to ease reviewing.
Change-Id: I52ef7dd40b2bdfc9cba2496544c0604e6e71cf7f
Reviewed-on: https://go-review.googlesource.com/59130
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
We can rematerialize only ops that have SP or SB as their only argument.
There are some ADDQconst(SP) that can be rematerialized, but are spilled/filled instead,
so mark addconst as rematerializeable. This shaves ~1kb from go tool.
Change-Id: Ib4cf4fe5f2ec9d3d7e5f0f77f1193eba66ca2f08
Reviewed-on: https://go-review.googlesource.com/54393
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When running multiple iOS builds on the same host, GOIOS_DEVICE_ID
is used to distinguish the devices. To improve support,
- Only restart the particular device when invoking iostest.bash
with the -restart flag.
- Make the exec wrapper lock file per-device.
For the iOS builder.
Change-Id: Id6f222981f25036399a43c3202a393dba89d87cb
Reviewed-on: https://go-review.googlesource.com/57970
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The SSA compiler currently generates MOVOstore instructions
to optimize 16 bytes moves on AMD64 architecture.
However, we can't use the MOVOstore instruction on Plan 9,
because floating point operations are not allowed in the
note handler.
We rely on the useSSE flag to disable the use of the
MOVOstore instruction on Plan 9 and replace it by two
MOVQstore instructions.
Fixes#21625
Change-Id: Idfefcceadccafe1752b059b5fe113ce566c0e71c
Reviewed-on: https://go-review.googlesource.com/59171
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Current documentation lacks simple examples for functions Regexp.Expand
and Regexp.ExpandString whose usage is unclear from description alone.
This commit adds examples that demonstrate usage in practical way.
Fixes#21649
Change-Id: I7b2c06c8ab747f69a6578f0595bf0f3c742ac479
Reviewed-on: https://go-review.googlesource.com/59470
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Most of these are return values that were part of a receiving parameter,
so they're still accessible.
A few others are not, but those have never had a use.
Found with github.com/mvdan/unparam, after Kevin Burke's suggestion that
the tool should also warn about unused result parameters.
Change-Id: Id8b5ed89912a99db22027703a88bd94d0b292b8b
Reviewed-on: https://go-review.googlesource.com/55910
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This has been supported since Go 1 and there's even a test for it.
The documentation was missing.
Fixes#21409.
Change-Id: I5813488f6a98c1b4506c239e968d43344b91be12
Reviewed-on: https://go-review.googlesource.com/59412
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The IsMetaPackage function was made exported when it was moved from
cmd/go to cmd/go/internal/load in CL 36196. Its documentation wasn't
updated accordingly. This change fixes that, resolving a golint issue.
Updates #18653.
Change-Id: Icf89461000754d0f09e6617b11c838e4c050d5a6
Reviewed-on: https://go-review.googlesource.com/59430
Reviewed-by: Dave Cheney <dave@cheney.net>
Many aspects of the package is woefully undocumented.
With the recent flurry of improvements, the package is now at feature
parity with the GNU and TAR tools. Thoroughly all of the public API
and perform some minor stylistic cleanup in some code segments.
Change-Id: Ic892fd72c587f30dfe91d1b25b88c9c8048cc389
Reviewed-on: https://go-review.googlesource.com/59210
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The PAX specification says the following:
<<<
'g' represents global extended header records for the following files in the archive.
The format of these extended header records shall be as described in pax Extended Header.
Each value shall affect all subsequent files that do not override that value
in their own extended header record and until another global extended header record
is reached that provides another value for the same field.
>>>
This CL adds support for parsing and composing global PAX records,
but intentionally does not provide support for automatically
persisting the global state across files.
Changes made:
* When Reader encounters a TypeXGlobalRecord header, it parses the
PAX records and returns them to the user ad-verbatim. Reader does not
store them in its state, ensuring it has no effect on future Next calls.
* When Writer receives a TypeXGlobalRecord header, it writes the
PAX records to the archive ad-verbatim. It does not store them in
its state, ensuring it has no effect on future WriteHeader calls.
* The restriction regarding empty record values is lifted since this
value is used to represent deletion in global headers.
Why provide raw support only:
* Some archives in the wild have a global header section (often empty)
and it is the user's responsibility to manually read and discard it's body.
The logic added here allows users to more easily skip over these sections.
* For users that do care about global headers, having access to the raw
records allows them to implement the functionality of global headers themselves
and manually persist the global state across files.
* We can still upgrade to a full implementation in the future.
Why we don't provide full support:
* Even though the PAX specification describes their operation in detail,
both the GNU and BSD tar tools (which are the most common implementations)
do not have a consistent interpretation of many details.
* Global headers were a controversial feature in PAX, by admission of the
specification itself:
<<<
The concept of a global extended header (typeflag g) was controversial.
The typeflag g global headers should not be used with interchange media that
could suffer partial data loss in transporting the archive.
>>>
* Having state persist from entry-to-entry complicates the implementation
for a feature that is not widely used and not well supported.
Change-Id: I1d904cacc2623ddcaa91525a5470b7dbe226c7e8
Reviewed-on: https://go-review.googlesource.com/59190
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Otherwise, if there are any parallel tests, it will hang and panic with
"all goroutines are asleep - deadlock!".
Do not use flag.Uint to handle the error for us because we also want to
error on N==0, and because it would make setting the default to
GOMAXPROCS(0) more difficult, since it's an int.
Check for it right after flag.Parse, and mimic flag errors by printing
the usage and returning exit code 2.
Fixes#20542.
Change-Id: I0c9d4587f83d406a8f5e42ed74e40be46d639ffb
Reviewed-on: https://go-review.googlesource.com/54150
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This addresses the case of a -timeout panic, but not the more
general case of a signal arriving. See CL 48370 and CL 44352
for recent difficulties in that area.
"-timeout" here means flag usage to distinguish from the
default timeout termination which uses signals.
Fixes#19394
Change-Id: I5452d5422c0c080e940cbcc8c6606049975268c6
Reviewed-on: https://go-review.googlesource.com/48491
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL adds the following new publicly visible API:
type Header struct { ...; PAXRecords map[string]string }
The new Header.PAXRecords field is a map of all PAX extended header records.
We suggest (but do not enforce) that users use VENDOR-prefixed keys
according to the following in the PAX specification:
<<<
The standard developers have reserved keyword name space for vendor extensions.
It is suggested that the format to be used is:
VENDOR.keyword
where VENDOR is the name of the vendor or organization in all uppercase letters.
>>>
When reading, the Header.PAXRecords is populated with all PAX records
encountered so far, including basic ones (e.g., "path", "mtime", etc).
When writing, the fields of Header will be merged into PAXRecords,
overwriting any records that may conflict.
Since PAXRecords is a more expressive feature than Xattrs and
is entirely a superset of Xattrs, we mark Xattrs as deprecated,
and steer users towards the new PAXRecords API.
The issue has a discussion about adding a Header.SetPAXRecord method
to help validate records and keep the Header fields in sync.
However, we do not include that in this CL since that helper
method can always be added in the future.
There is no support for global records.
Fixes#14472
Change-Id: If285a52749acc733476cf75a2c7ad15bc1542071
Reviewed-on: https://go-review.googlesource.com/58390
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If Less(a, b) returns true when a is less than b, the correct way to
check if a is greater than b is to use Less(b, a). It is wrong to use
!Less(a, b) because that checks if a is greater than *or equal to* b.
1. The decreasingDistance function in Example_sortKeys makes this
mistake. Fix it.
2. The documentation of multiSorter.Less says it loops along the less
functions until it finds a comparison "that is either Less or
!Less". This is nonsense, because (Less(a, b) or !Less(a, b)) is
always true. Fix the documentation to say that it finds a
comparison "that discriminates between the two items (one is less
than the other)". The implementation already does this correctly.
Change-Id: If52b79f68e4fdb0d1095edf29bdecdf154a61b8d
Reviewed-on: https://go-review.googlesource.com/57752
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current code treats the type of SIMD&FP register as C_REG incorrectly.
The fix code converts C_REG type into C_FREG type.
Uncomment fcsels/fcseld test cases.
Fixes#21582
Change-Id: I754c51f72a0418bd352cbc0f7740f14cc599c72d
Reviewed-on: https://go-review.googlesource.com/58350
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix two small but serious bugs in the DWARF location list code that
should have been caught by the automated tests I didn't write.
After emitting debug information for a user variable, mark it as done
so that it doesn't get emitted again. Otherwise it would be written once
per slot it was decomposed into.
Correct a merge error in CL 44350: the location list abbreviations need
to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish.
Change-Id: I6ab4b8b32b7870981dac80eadf0ebfc4015ccb01
Reviewed-on: https://go-review.googlesource.com/59070
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Sometimes (often for calls) we generate code like this:
MOVQ (addr),AX
MOVQ 8(addr),BX
MOVQ AX,(otheraddr)
MOVQ BX,8(otheraddr)
Replace it with
MOVUPS (addr),X0
MOVUPS X0,(otheraddr)
For completeness do the same for 8,16,32-bit loads/stores too.
Shaves 1% from code sections of go tool.
/localdisk/itocar/golang/bin/go 10293917
go_old 10334877 [40960 bytes]
read-only data = 682 bytes (0.040769%)
global text (code) = 38961 bytes (1.036503%)
Total difference 39643 bytes (0.674628%)
Updates #6853
Change-Id: I1f0d2f60273a63a079b58927cd1c4e3429d2e7ae
Reviewed-on: https://go-review.googlesource.com/57130
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Throughout the spec we use the notion of a constant x being
representable by a value of type T. While intuitively clear,
at least for floating-point and complex constants types, the
concept was not well-defined. In the section on Conversions
there was an extra rule for floating-point types only and it
missed the case of floating-point values overflowing to an
infinity after rounding.
Since the concept is important to Go, and a compiler most
certainly will have a function to test "representability",
it seems warranted to define the term explicitly in the spec.
This change introduces a new entry "Representability" under
the section on "Properties of types and values", and defines
the term explicitly, together with examples.
The phrase used is "representable by" rather than "representable as"
because the former use is prevalent in the spec.
Additionally, it clarifies that a floating-point constant
that overflows to an infinity after rounding is never
representable by a value of a floating-point type, even though
infinities are valid values of IEEE floating point types.
This is required because there are not infinite value constants
in the language (like there is also no -0.0) and representability
also matters for constant conversions. This is not a language
change, and type-checkers have been following this rule before.
The change also introduces links throughout the spec to the new
section as appropriate and removes duplicate text and examples
elsewhere (Constants and Conversions sections), leading to
simplifications in the relevant paragraphs.
Fixes#15389.
Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
Reviewed-on: https://go-review.googlesource.com/57530
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Prior to this change, we use typedmemmove to write the key
value to its new location in mapassign_fast32 and mapassign_fast64.
(The use of typedmemmove was a last-minute fix in the 1.9 cycle;
see #21297 and CL 53414.)
This is significantly less inefficient than direct assignment or
calling writebarrierptr directly.
Fortunately, there aren't many cases to consider.
On systems with 32 bit pointers:
* A 32 bit AMEM value either is a single pointer or has no pointers.
* A 64 bit AMEM value may contain a pointer at the beginning,
a pointer at 32 bits, or two pointers.
On systems with 64 bit pointers:
* A 32 bit AMEM value contains no pointers.
* A 64 bit AMEM value either is a single pointer or has no pointers.
All combinations except the 32 bit pointers / 64 bit AMEM value are
cheap and easy to handle, and the problematic case is likely rare.
The most popular map keys appear to be ints and pointers.
So we handle them exhaustively. The sys.PtrSize checks are constant branches
and are eliminated by the compiler.
An alternative fix would be to return a pointer to the key,
and have the calling code do the assignment, at which point the compiler
would have full type information.
Initial tests suggest that the performance difference between these
strategies is negligible, and this fix is considerably simpler,
and has much less impact on binary size.
Fixes#21321
Change-Id: Ib03200e89e2324dd3c76d041131447df66f22bfe
Reviewed-on: https://go-review.googlesource.com/59110
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Implement int reg <-> fp reg moves on amd64.
If we see a load to int reg followed by an int->fp move, then we can just
load to the fp reg instead. Same for stores.
math.Abs is now:
MOVQ "".x+8(SP), AX
SHLQ $1, AX
SHRQ $1, AX
MOVQ AX, "".~r1+16(SP)
math.Copysign is now:
MOVQ "".x+8(SP), AX
SHLQ $1, AX
SHRQ $1, AX
MOVQ "".y+16(SP), CX
SHRQ $63, CX
SHLQ $63, CX
ORQ CX, AX
MOVQ AX, "".~r2+24(SP)
math.Float64bits is now:
MOVSD "".x+8(SP), X0
MOVSD X0, "".~r1+16(SP)
(it would be nicer to use a non-SSE reg for this, nothing is perfect)
And due to the fix for #21440, the inlined version of these improve as well.
name old time/op new time/op delta
Abs 1.38ns ± 5% 0.89ns ±10% -35.54% (p=0.000 n=10+10)
Copysign 1.56ns ± 7% 1.35ns ± 6% -13.77% (p=0.000 n=9+10)
Fixes#13095
Change-Id: Ibd7f2792412a6668608780b0688a77062e1f1499
Reviewed-on: https://go-review.googlesource.com/58732
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
CL 36428 changed the way nanotime works so on Darwin and Windows it
now depends on runtime.startNano, which is computed at runtime.init
time. Unfortunately, the `runtimeInitTime = nanotime()` initialization
happened *before* runtime.init, so on these platforms runtimeInitTime
is set incorrectly. The one (and only) consequence of this is that the
start time printed in gctrace lines is bogus:
gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P
To fix this, this commit moves the runtimeInitTime initialization to
shortly after runtime.init, at which point nanotime is safe to use.
This also requires changing the condition in newproc1 that currently
uses runtimeInitTime != 0 simply to detect whether or not the main M
has started. Since runtimeInitTime could genuinely be 0 now, this
introduces a separate flag to newproc1.
Fixes#21554.
Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b
Reviewed-on: https://go-review.googlesource.com/58690
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since golang.org/cl/31670, we've stopped using the 'embedded' function
for handling struct embeddings within package export data. Now the
only remaining use is for Go source files, which allows for some
substantial simplifications:
1. CenterDot never appears within Go source files, so that logic can
simply be removed.
2. The field name will always be declared in the local package.
Passes toolstash-check.
Change-Id: I59505f62824206dd5de0782918f98fbef6e93224
Reviewed-on: https://go-review.googlesource.com/58790
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The enumeration of numeric types missed the complex types.
Clarify by removing the explicit enumeration and referring
to numeric types instead.
Fixes#21579.
Change-Id: If36c2421f8501eeec82a07f442ac2e16a35927ba
Reviewed-on: https://go-review.googlesource.com/58491
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Discovered while debugging CL 53644.
No test case because these are purely internal conversions that should
never end up resulting in compiler warnings or even generated code.
Updates #19683.
Change-Id: I0d9333ef2c963fa22eb9b5335bb022bcc9b25708
Reviewed-on: https://go-review.googlesource.com/58190
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There are some major problems with TestAdversary (based on "A Killer
Adversary for Quicksort"[1] by M. D. McIlroy). See #21581 for details.
Rewrite the test to closely match the version in the paper so it can
be verified as correct by virtue of similarity.
The only major difference between this new version and the version in
the paper is that this version swaps the values directly instead of
permuting an array of indices because we don't need to recover the
original permutation.
This new version also counts the number of calls to Less() and fails
the test if there are too many.
Fixes#21581.
[1]: http://www.cs.dartmouth.edu/~doug/mdmspe.pdf
Change-Id: Ia94b5b6d288b8fa3805a5fa27661cebbc5bad9a7
Reviewed-on: https://go-review.googlesource.com/58330
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 54410 and CL 56250 recently added use of the MOVOstore
instruction to improve performance.
However, we can't use the MOVOstore instruction on Plan 9,
because floating point operations are not allowed in the
note handler.
This change adds a configuration flag useSSE to enable the
use of SSE instructions for non-floating point operations.
This flag is enabled by default and disabled on Plan 9.
When this flag is disabled, the MOVOstore instruction is
not used and the MOVQstoreconst instruction is used instead.
Fixes#21599
Change-Id: Ie609e5d9b82ec0092ae874bab4ce01caa5bc8fb8
Reviewed-on: https://go-review.googlesource.com/58850
Reviewed-by: Keith Randall <khr@golang.org>
This change also added the same check in make.bash to make.rc,
which makes sure $GOROOT_BOOTSTRAP != $GOROOT.
Fixes#14339
Change-Id: I2758f4a845bae42ace02492fc6a911f6d6247d26
Reviewed-on: https://go-review.googlesource.com/57753
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
WriteHeader may fail to encode a header for any number of reasons,
which can be frustrating for the user when trying to create a tar archive.
As we validate the Header, we generate an informative error message
intended for human consumption and return that if and only if no
format can be selected.
This allows WriteHeader to return informative errors like:
tar: cannot encode header: invalid PAX record: "linkpath = \x00hello"
tar: cannot encode header: invalid PAX record: "SCHILY.xattr.foo=bar = baz"
tar: cannot encode header: Format specifies GNU; and only PAX supports Xattrs
tar: cannot encode header: Format specifies GNU; and GNU cannot encode ModTime=1969-12-31 15:59:59.0000005 -0800 PST
tar: cannot encode header: Format specifies GNU; and GNU supports sparse files only with TypeGNUSparse
tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode ModTime=292277026596-12-04 07:30:07 -0800 PST
tar: cannot encode header: Format specifies USTAR; and USTAR does not support sparse files
tar: cannot encode header: Format specifies PAX; and only GNU supports TypeGNUSparse
Updates #18710
Change-Id: I82a498d6f29d02c4e73bce47b768eb578da8499c
Reviewed-on: https://go-review.googlesource.com/58310
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For code like the following (where x escapes):
x := []int{1}
We're currently generating a nil check. The line above is really 3 operations:
t := new([1]int)
t[0] = 1
x := t[:]
We remove the nil check for t[0] = 1, but not for t[:].
Our current nil check removal rule is too strict about the possible
memory arguments of the nil check. Unlike zeroing or storing to the
result of runtime.newobject, the nilness of runtime.newobject is
always false, even after other stores have happened in the meantime.
Change-Id: I95fad4e3a59c27effdb37c43ea215e18f30b1e5f
Reviewed-on: https://go-review.googlesource.com/58711
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In writelines the linker uses various auxiliary information about a
function to create its line table entries. (It also does some unrelated
stuff, but never mind.) There's no reason to do this for non-Go
functions, so it bails out if the symbol has no FuncInfo.
However, it does so *after* it looks up (and implicitly creates!) the
go.info symbol for the function, which doesn't make sense and risks
creating duplicate symbols for static C functions. Move the check up so
that it doesn't do that.
Since non-Go functions can't reference Go types, there shouldn't be any
relocations to type info DIEs that need to be built, so there should be
no harm not doing that.
I wanted to change the Lookup to an ROLookup but that broke the
shared-mode tests with an inscrutable error.
No test. It seems too specific to worry about, but if someone disagrees
I can figure something out.
Fixes#21566
Change-Id: I61f03b7c504a3bf1c4245a8811795b6303469e91
Reviewed-on: https://go-review.googlesource.com/58630
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This eliminates a nil check of b while evaluating b.tophash,
which is in the inner loop of many hot map functions.
It also makes the code a bit clearer.
Also remove some gotos in favor of labeled breaks.
On non-x86 architectures, this change introduces a pointless reg-reg move,
although the cause is well-understood (#21572).
Change-Id: Ib7ee58b59ea5463b92e1590c8b8f5c0ef87d410a
Reviewed-on: https://go-review.googlesource.com/58372
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Otherwise the default computation in symalign kicked in, setting the
alignment to be too high. This didn't matter with GNU ld, which put
each loadable note into a separate PT_NOTE segment, but it did matter
with gold which accumulated them all into a single PT_NOTE segment,
respecting the requested alignment. In the single PT_NOTE segment
generated by gold, the incorrect section alignment made the notes
unreadable.
Fixes#21564
Change-Id: I15eb408bb04a2566c9fdfb6828e14188d9ef2280
Reviewed-on: https://go-review.googlesource.com/58290
Reviewed-by: Russ Cox <rsc@golang.org>
This is a crude compiler pass to eliminate stores to auto variables
that are only ever written to.
Eliminates an unnecessary store to x from the following code:
func f() int {
var x := 1
return *(&x)
}
Fixes#19765.
Change-Id: If2c63a8ae67b8c590b6e0cc98a9610939a3eeffa
Reviewed-on: https://go-review.googlesource.com/38746
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This prevents unnecessary reg-reg moves during pointer arithmetic.
This change reduces the size of the full hello world binary by 0.4%.
Updates #21572
Change-Id: Ia0427021e5c94545a0dbd83a6801815806e5b12d
Reviewed-on: https://go-review.googlesource.com/58371
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
On 386 the below code triggered an infinite loop in growslice:
x = make([]byte, 1<<30-1, 1<<30-1)
x = append(x, x...)
Check for overflow when calculating the new slice capacity
and set the new capacity to the requested capacity when an overflow
is detected to avoid an infinite loop.
No automatic test added due to requiring to allocate 1GB of memory
on a 32bit plaform before use of append is able to trigger the
overflow check.
Fixes#21441
Change-Id: Ia871cc9f88479dacf2c7044531b233f83d2fcedf
Reviewed-on: https://go-review.googlesource.com/57950
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Currently all package tests are executed once
with Parallel tests executed in parallel.
Then this process is repeated count*cpu times.
Tests are not parallelized over count*cpu.
Parallelizing over cpu is not possible as
GOMAXPROCS is a global setting. But it is
possible for count.
Parallelize over count.
Brings down testing of my package with -count=100
form 10s to 0.3s.
Change-Id: I76d8322adeb8c5c6e70b99af690291fd69d6402a
Reviewed-on: https://go-review.googlesource.com/44830
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This slightly improves the generated code on x86 architectures,
including on many hot paths.
It is a no-op on other architectures.
Change-Id: I86336fd846bc5805a27bbec572e8c73dcbd0d567
Reviewed-on: https://go-review.googlesource.com/57411
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is necessary when you aren't actively changing the runtime. Oops.
Also, run the tests on the builders, to avoid silent failures (#17472).
Change-Id: I1fc03790cdbddddb07026a772137a79919dcaac7
Reviewed-on: https://go-review.googlesource.com/58050
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Reader and Writer are now at feature parity,
meaning that everything that can be parsed by the Reader,
can also be composed by the Writer.
This position enables us to support selection of the format
in a backwards compatible way, since it ensures that everything
that can be read can also be round-trip written.
As such, we add the following new API:
type Format int
const FormatUnknown Format = 0 ...
type Header struct { ...; Format Format }
The new Header.Format field is populated by the Reader on the
best guess on what the format is. Note that the Reader is very liberal
in what it permits, so a hybrid TAR file using aspects of multiple
formats can still be decoded, but will be reported as FormatUnknown.
Even though Reader has full support for V7 and basic support for STAR,
it will still report those formats as unknown (and the constants for
those formats are not even exported). The reasons for this is because
the Writer has no support for V7 or STAR. Leaving it as unknown allows
the Writer to choose a format usually USTAR or GNU that can encode
the equivalent Header.
When writing, the Header.allowedFormats will take the Format field
into consideration if it is a known format.
Fixes#18710
Change-Id: I00980c475d067c6969d3414e1ff0224fdd89cd49
Reviewed-on: https://go-review.googlesource.com/58230
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The method Method expects index to be an index of exported fields,
but, before this change, the index used by MethodByName could
take into account unexported fields if those happened sort
before the exported one.
Fixes#21177
Change-Id: I90bb64a47b23e2e43fdd2b8a1e0a2c9a8a63ded2
Reviewed-on: https://go-review.googlesource.com/51810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL is the second step (of two; part1 is CL/56771) for adding
sparse file support to the Writer.
There are no new identifiers exported in this CL, but this does make
use of Header.SparseHoles added in part1. If the Typeflag is set to
TypeGNUSparse or len(SparseHoles) > 0, then the Writer will emit an
sparse file, where the holes must be written by the user as zeros.
If TypeGNUSparse is set, then the output file must use the GNU format.
Otherwise, it must use the PAX format (with GNU-defined PAX keys).
A future CL may export Reader.Discard and Writer.FillZeros,
but those methods are currently unexported, and only used by the
tests for efficiency reasons.
Calling Discard or FillZeros on a hole 10GiB in size does take
time, even if it is essentially a memcopy.
Updates #13548
Change-Id: Id586d9178c227c0577f796f731ae2cbb72355601
Reviewed-on: https://go-review.googlesource.com/57212
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For those tests there won't be enough permissions in containers.
I decided to go this way instead of just skipping os.IsPermission errors because
many of those tests were specifically written to check false positive permission
errors.
Fixes#21379
Change-Id: Ie25e1d6d47f85bb6b570352638440f3ac1e18e03
Reviewed-on: https://go-review.googlesource.com/58170
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current code treats floating-point constant as integer
and does not treat fcmp/fcmpe as the comparison instrucitons
that requires special handling.
The fix corrects the type of immediate arguments and adds fcmp/fcmpe
in the special handing.
Uncomment the fcmp/fcmpe cases.
Fixes#21567
Change-Id: I6782520e2770f6ce70270b667dd5e68f71e2d5ad
Reviewed-on: https://go-review.googlesource.com/57852
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When deleting entries from a map, only clear the key and value
if they contain pointers. And use memclrHasPointers to do so.
While we're here, specialize key clearing in mapdelete_faststr,
and fix another missed usage of add in mapdelete.
Benchmarking impeded by #21546.
Change-Id: I3f6f924f738d6b899b722d6438e9e63f52359b84
Reviewed-on: https://go-review.googlesource.com/57630
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Move the tophash checks after the equality/length checks.
For fast32/fast64, since we've done a full equality check already,
just check whether tophash is empty instead of checking tophash.
This is cheaper and allows us to skip calculating tophash.
These changes are modeled on the changes in CL 57590,
which were polished based on benchmarking.
Benchmarking directly is impeded by #21546.
Change-Id: I0e17163028e34720310d1bf8f95c5ef42d223e00
Reviewed-on: https://go-review.googlesource.com/57611
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
During rebase of golang.org/cl/55152 the bucket argument
which was removed in golang.org/cl/56290 from makemap
was not removed from the argument list of makemap64.
This did lead to "pointer in unallocated span" errors
on 32bit platforms since the compiler did only generate
calls to makemap64 without the bucket argument.
Fixes#21568
Change-Id: Ia964a3c285837cd901297f4e16e40402148f8c1c
Reviewed-on: https://go-review.googlesource.com/57990
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The intent is to allow more aggressive refactoring
in the runtime without silent performance changes.
The test would be useful for many functions.
I've seeded it with the runtime functions tophash and add;
it will grow organically (or wither!) from here.
Updates #21536 and #17566
Change-Id: Ib26d9cfd395e7a8844150224da0856add7bedc42
Reviewed-on: https://go-review.googlesource.com/57410
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
mkcall is used to construct calls to builtin functions.
Instead of silently ignoring any additional arguments to mkcall
abort compilation with an error.
This protects against accidentally supplying too many arguments to mkcall
when compiler changes are made.
Change appendslice and copyany to construct calls to
slicestringcopy and slicecopy explicitly instead of
relying on the old behavior as a feature.
Change-Id: I3cfe815a57d454a129e3c08aac824f6107779a42
Reviewed-on: https://go-review.googlesource.com/57770
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Where possible generate calls to runtime makemap with int hint argument
during compile time instead of makemap with int64 hint argument.
This eliminates converting the hint argument for calls to makemap with
int64 hint argument for platforms where int64 values do not fit into
an argument of type int.
A similar optimization for makeslice was introduced in CL
golang.org/cl/27851.
386:
name old time/op new time/op delta
NewEmptyMap 53.5ns ± 5% 41.9ns ± 5% -21.56% (p=0.000 n=10+10)
NewSmallMap 182ns ± 1% 165ns ± 1% -8.92% (p=0.000 n=10+10)
Change-Id: Ibd2b4c57b36f171b173bf7a0602b3a59771e6e44
Reviewed-on: https://go-review.googlesource.com/55142
Reviewed-by: Keith Randall <khr@golang.org>
golang.org/cl/36941 enabled loading of all trusted certs on darwin
for the non-cgo execSecurityRoots.
The corresponding cgo version golang.org/cl/36942 for systemRootsPool
has not been merged yet.
This tests fails reliably on some darwin systems:
--- FAIL: TestSystemRoots (1.28s)
root_darwin_test.go:31: cgo sys roots: 353.552363ms
root_darwin_test.go:32: non-cgo sys roots: 921.85297ms
root_darwin_test.go:44: got 169 roots
root_darwin_test.go:44: got 455 roots
root_darwin_test.go:73: insufficient overlap between cgo and non-cgo roots; want at least 227, have 168
FAIL
FAIL crypto/x509 2.445s
Updates #16532
Updates #21416
Change-Id: I52c2c847651fb3621fdb6ab858ebe8e28894c201
Reviewed-on: https://go-review.googlesource.com/57830
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This change adds to the code-generation harness in asm_test.go support
for the use of a '$' placeholder name for test functions.
A few of uninformative function names are also changed to use the
placeholder, to confirm that the change works as expected.
Fixes#21500
Change-Id: Iba168bd85efc9822253305d003b06682cf8a6c5c
Reviewed-on: https://go-review.googlesource.com/57292
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Some debuggers use the declaration line to avoid showing variables
before they're declared. Emit them for local variables and function
parameters.
DW_AT_decl_file would be nice too, but since its value is an index
into a table built by the linker, that's dramatically harder. In
practice, with inlining disabled it's safe to assume that all a
function's variables are declared in the same file, so this should still
be pretty useful.
Change-Id: I8105818c8940cd71bc5473ec98797cce2f3f9872
Reviewed-on: https://go-review.googlesource.com/44350
Reviewed-by: David Chase <drchase@google.com>
eqstring is only called for strings with equal lengths.
Instead of pushing a pointer and length for each argument string
on the stack we can omit pushing one of the lengths on the stack.
Changing eqstrings signature to eqstring(*uint8, *uint8, int) bool
to implement the above optimization would make it very similar to the
existing memequal(*any, *any, uintptr) bool function.
Since string lengths are positive we can avoid code redundancy and
use memequal instead of using eqstring with an optimized signature.
go command binary size reduced by 4128 bytes on amd64.
name old time/op new time/op delta
CompareStringEqual 6.03ns ± 1% 5.71ns ± 1% -5.23% (p=0.000 n=19+18)
CompareStringIdentical 2.88ns ± 1% 3.22ns ± 7% +11.86% (p=0.000 n=20+20)
CompareStringSameLength 4.31ns ± 1% 4.01ns ± 1% -7.17% (p=0.000 n=19+19)
CompareStringDifferentLength 0.29ns ± 2% 0.29ns ± 2% ~ (p=1.000 n=20+20)
CompareStringBigUnaligned 64.3µs ± 2% 64.1µs ± 3% ~ (p=0.164 n=20+19)
CompareStringBig 61.9µs ± 1% 61.6µs ± 2% -0.46% (p=0.033 n=20+19)
Change-Id: Ice15f3b937c981f0d3bc8479a9ea0d10658ac8df
Reviewed-on: https://go-review.googlesource.com/53650
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If an error was already printed during LHS conversion step, we don't reprint
the "cannot convert" error.
In particular, this prevents `_ = int("1")` (and all similar casts) from
resulting in multiple identical error messages being printed.
Fixes#20812.
Change-Id: If6e52c59eab438599d641ecf6f110ebafca740a9
Reviewed-on: https://go-review.googlesource.com/46912
Reviewed-by: Robert Griesemer <gri@golang.org>
The current code gets shift arguments value from prog.From3.Offset.
But prog.From3.Offset is not assigned the shift arguments value in
instructions assemble process.
The fix calls movcon() function to get the correct value.
Uncomment the movk/movkw cases.
Fixes#21398
Change-Id: I78d40c33c24bd4e3688a04622e4af7ddb5333fa6
Reviewed-on: https://go-review.googlesource.com/54990
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Previously, go/doc would only consider functions that return types of
T or any number of pointers to T: *T, **T, etc. This change expands
the definition of a constructor to also include functions that return
slices of a type (or pointer to that type) in its first return.
With this change, the following return types classify a function
as a constructor of type T:
T
*T
**T (and so on)
[]T
[]*T
[]**T (and so on)
Fixes#18063.
Change-Id: I9a1a689933e13c6b8eb80b74ceec85bd4cab236d
Reviewed-on: https://go-review.googlesource.com/54971
Reviewed-by: Robert Griesemer <gri@golang.org>
BFX extracts given bits from the source register, sign extends them
to 32-bit, and writes to destination register. BFXU does the similar
operation with zero extention.
They were introduced in ARMv6T2.
Change-Id: I6822ebf663497a87a662d3645eddd7c611de2b1e
Reviewed-on: https://go-review.googlesource.com/56071
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
On arm64, all boolean-generating instructions (CSET, etc.) set the upper
63 bits of the destination register to zero, so there is no need
to zero-extend the lower 8 bits again.
Fixes#21445
Change-Id: I3b176baab706eb684105400bacbaa24175f721f3
Reviewed-on: https://go-review.googlesource.com/55671
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If there are no pointers, then clearing memory doesn't help GC,
and the memory is otherwise dead, so don't bother clearing it.
Change-Id: I953f4a3264939f2825e82292030eda2e835cbb97
Reviewed-on: https://go-review.googlesource.com/57350
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
The testcshared test.bash was rewritten in Go, but the rewritten script
broke on Android. Make the tests run on Android again by:
- Restoring the LD_LIBRARY_PATH path (.).
- Restoring the Android specific C flags (-pie -fuse-ld=gold).
- Adding runExe to run test executables. All other commands must run on
the host.
Fixes#21513.
Change-Id: I3ea617a943c686b15437cc5c118e9802a913d93a
Reviewed-on: https://go-review.googlesource.com/57290
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Ask whether the issue reproduces with the latest release.
'go bug' places the version and system details last,
in part because they're automatically filled.
I'd like to do the same here, but I worry
that they'll get ignored.
Change-Id: Iec636a27e6e36d61dca421deaf24ed6fe35d4b11
Reviewed-on: https://go-review.googlesource.com/50931
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Avelino <t@avelino.xxx>
This CL is the first step (of two) for adding sparse file support
to the Writer. This CL only refactors the logic of sparse-file handling
in the Reader so that common logic can be easily shared by the Writer.
As a result of this CL, there are some new publicly visible API changes:
type SparseEntry struct { Offset, Length int64 }
type Header struct { ...; SparseHoles []SparseEntry }
A new type is defined to represent a sparse fragment and a new field
Header.SparseHoles is added to represent the sparse holes in a file.
The API intentionally represent sparse files using hole fragments,
rather than data fragments so that the zero value of SparseHoles
naturally represents a normal file (i.e., a file without any holes).
The Reader now populates SparseHoles for sparse files.
It is necessary to export the sparse hole information, otherwise it would
be impossible for the Writer to specify that it is trying to encode
a sparse file, and what it looks like.
Some unexported helper functions were added to common.go:
func validateSparseEntries(sp []SparseEntry, size int64) bool
func alignSparseEntries(src []SparseEntry, size int64) []SparseEntry
func invertSparseEntries(src []SparseEntry, size int64) []SparseEntry
The validation logic that used to be in newSparseFileReader is now moved
to validateSparseEntries so that the Writer can use it in the future.
alignSparseEntries is currently unused by the Reader, but will be used
by the Writer in the future. Since TAR represents sparse files by
only recording the data fragments, we add the invertSparseEntries
function to convert a list of data fragments to a normalized list
of hole fragments (and vice-versa).
Some other high-level changes:
* skipUnread is deleted, where most of it's logic is moved to the
Discard methods on regFileReader and sparseFileReader.
* readGNUSparsePAXHeaders was rewritten to be simpler.
* regFileReader and sparseFileReader were completely rewritten
in simpler and easier to understand logic.
* A bug was fixed in sparseFileReader.Read where it failed to
report an error if the logical size of the file ends before
consuming all of the underlying data.
* The tests for sparse-file support was completely rewritten.
Updates #13548
Change-Id: Ic1233ae5daf3b3f4278fe1115d34a90c4aeaf0c2
Reviewed-on: https://go-review.googlesource.com/56771
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Because profile labels are copied from the goroutine into the tag
buffer by the signal handler, there's a carefully-crafted set of race
detector annotations to create the necessary happens-before edges
between setting a goroutine's profile label and retrieving it from the
profile tag buffer.
Given the constraints of the signal handler, we have to approximate
the true synchronization behavior. Currently, that approximation is
too weak.
Ideally, runtime_setProfLabel would perform a store-release on
&getg().labels and copying each label into the profile would perform a
load-acquire on &getg().labels. This would create the necessary
happens-before edges through each individual g.labels object.
Since we can't do this in the signal handler, we instead synchronize
on a "labelSync" global. The problem occurs with the following
sequence:
1. Goroutine 1 calls setProfLabel, which does a store-release on
labelSync.
2. Goroutine 2 calls setProfLabel, which does a store-release on
labelSync.
3. Goroutine 3 reads the profile, which does a load-acquire on
labelSync.
The problem is that the load-acquire only synchronizes with the *most
recent* store-release to labelSync, and the two store-releases don't
synchronize with each other. So, once goroutine 3 touches the label
set by goroutine 1, we report a race.
The solution is to use racereleasemerge. This is like a
read-modify-write, rather than just a store-release. Each RMW of
labelSync in runtime_setProfLabel synchronizes with the previous RMW
of labelSync, and this ultimately carries forward to the load-acquire,
so it synchronizes with *all* setProfLabel operations, not just the
most recent.
Change-Id: Iab58329b156122002fff12cfe64fbeacb31c9613
Reviewed-on: https://go-review.googlesource.com/56670
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
We can add a constant to loaction in memory with 1 instruction,
as opposed to load+add+store, so add a new op and relevent ssa rules.
Triggers in e. g. encoding/json isValidNumber:
NumberIsValid-6 36.4ns ± 0% 35.2ns ± 1% -3.32% (p=0.000 n=6+10)
Shaves ~2.5 kb from go tool.
Change-Id: I7ba576676c2522432360f77b290cecb9574a93c3
Reviewed-on: https://go-review.googlesource.com/54431
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Since oldbucket == h.nevacuate, we can just increment h.nevacuate here.
This removes oldbucket from scope, which will be useful shortly.
Change-Id: I70f81ec3995f17845ebf5d77ccd20ea4338f23e6
Reviewed-on: https://go-review.googlesource.com/56932
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The new code is not quite equivalent to the old,
in that if newbit was very large it might have altered the new tophash.
The old behavior is unnecessary and probably undesirable.
Change-Id: I7fb3222520cb61081a857adcddfbb9078ead7122
Reviewed-on: https://go-review.googlesource.com/56930
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Clean-up changes in no particular order:
- use uint8 instead of int for readOp
- remove duplicated code in ReadFrom()
- introduce (*Buffer).empty()
- remove naked returns
Change-Id: Ie6e673c20c398f980f8be0448969a36ad4778804
Reviewed-on: https://go-review.googlesource.com/42816
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Normally 64-bit div/mod is turned into runtime calls on 32-bit
arch, but the front end leaves power-of-two constant division
and hopes the SSA backend turns into a shift or AND. The SSA rule is
(Mod64u <t> n (Const64 [c])) && isPowerOfTwo(c) -> (And64 n (Const64 <t> [c-1]))
But isPowerOfTwo returns true only for positive int64, which leaves
out 1<<63 unhandled. Add a special case for 1<<63.
Fixes#21517.
Change-Id: I02d27dc7177d4af0ee8d7f5533714edecddf8c95
Reviewed-on: https://go-review.googlesource.com/56890
Reviewed-by: Keith Randall <khr@golang.org>
I'm writing a matching implementation of the time package and missed
the "add one day in a leap year" block. This test would have caught my
error.
I understand we can't add test cases for every Date but it seems like
"tripped up someone attempting to reimplement this" is a good
indicator it may trip up people in the future.
Change-Id: I4c3b51e52e269215ec0e52199afe604482326edb
Reviewed-on: https://go-review.googlesource.com/56490
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
After the key and value arrays, we have an overflow pointer.
So there's no way a past-the-end key or value pointer could point
past the end of the containing bucket.
So we don't need this additional protection.
Update #21459
Change-Id: I7726140033b06b187f7a7d566b3af8cdcaeab0b0
Reviewed-on: https://go-review.googlesource.com/56772
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Avelino <t@avelino.xxx>
Package.Internal.Imports is enough in nearly all cases,
and not maintaining a separate Package.Internal.Deps
avoids the two lists ending up out of sync.
(In some synthesized packages created during go test,
only Internal.Imports is initialized.)
Change-Id: I83f6a3ec6e6cbd75382f1fa0e439d31feec32d5a
Reviewed-on: https://go-review.googlesource.com/56278
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before it was obj, but if you don't have everything paged in
that sounds a bit like an object file. Use objdir, which is more
clearly a directory and also matches the Action.Objdir struct field.
Change-Id: I268042800f9ca05721814d7f18c728acb4831232
Reviewed-on: https://go-review.googlesource.com/56277
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ImportPaths is also the name of a top-level function.
It is confusing to have a capitalized local variable.
Change-Id: I1313e05ade4934d4ee250a67e5af6d1bd6229aca
Reviewed-on: https://go-review.googlesource.com/56275
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we make the go command pay attention to content
instead of time, we want this test to continue working.
Change-Id: Ib7d9d0d62bfe87810d71bdfc4f29561a8c70eccc
Reviewed-on: https://go-review.googlesource.com/56273
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Using a fake CC fails today if runtime/cgo is stale, because the
build will try to rebuild runtime/cgo using the fake CC, and the
fake CC is not a working C compiler.
Worse, in the future, when the go command is sensitive to details like
the fact that different CCs produce different outputs, putting in
the fake CC will make runtime/cgo look stale even if it was
formerly up-to-date.
Fix both problems by not overriding CC and instead looking at
the command being run to make sure the flags are quoted as expected.
Change-Id: I4417e35cfab33a07546cc90748ddb6119d8fdb2d
Reviewed-on: https://go-review.googlesource.com/56272
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Updates #13745
Recognize z.Mul(x, x) as squaring for Floats and use
the internal z.sqr(x) method for nat on the mantissa.
Change-Id: I0f792157bad93a13cae1aecc4c10bd20c6397693
Reviewed-on: https://go-review.googlesource.com/56774
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
updates #13745
A squared rational is always positive and can not
be reduced since the numerator and denominator had
no previous common factors. The nat multiplication
can be performed using the internal sqr method.
Change-Id: I558f5b38e379bfd26ff163c9489006d7e5a9cfaa
Reviewed-on: https://go-review.googlesource.com/56776
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use mallogc instead of newarray to save some overhead since
makechan already checks for _MaxMem constraints.
Flattens the if else construct that determines if buf and hchan struct
should be allocated in one mallocgc call and where buf should point to.
Uses maxSliceCap to avoid divisions similar to makeslice.
name old time/op new time/op delta
MakeChan/Byte 82.0ns ± 8% 81.4ns ± 7% ~ (p=0.643 n=10+10)
MakeChan/Int 97.9ns ± 2% 96.6ns ± 2% -1.40% (p=0.009 n=10+10)
MakeChan/Ptr 128ns ± 3% 120ns ± 1% -6.63% (p=0.000 n=10+10)
MakeChan/Struct/0 66.7ns ± 4% 66.4ns ± 2% ~ (p=0.697 n=10+10)
MakeChan/Struct/32 136ns ± 1% 130ns ± 0% -4.42% (p=0.000 n=10+10)
MakeChan/Struct/40 150ns ± 1% 150ns ± 1% ~ (p=0.725 n=10+10)
Change-Id: Ibb5675d0843a072aae2bfa58ecd39cf4cd926533
Reviewed-on: https://go-review.googlesource.com/55132
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Stack allocated hmap structs are explicitly zeroed before being
passed by pointer to makemap.
Heap allocated hmap structs are created with newobject
which also zeroes on allocation.
Therefore, setting the hmap fields to 0 or nil is redundant
since they will have been zeroed when hmap was allocated.
Change-Id: I5fc55b75e9dc5ba69f5e3588d6c746f53b45ba66
Reviewed-on: https://go-review.googlesource.com/56291
Reviewed-by: Keith Randall <khr@golang.org>
We're making two extra round-trips to C to malloc and free strings
that originate in Go and don't escape. Skip those round-trips by
allocating null-terminated slices in Go memory instead.
Change-Id: I9e4c5ad999a7924ba50b82293c52073ec75518be
Reviewed-on: https://go-review.googlesource.com/56530
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We already combine const stores up-to MOVQstoreconst.
Combine 2 64-bit stores of const zero into 1 sse store of 128-bit zero.
Shaves significant (>1%) amount of code from go tool:
/localdisk/itocar/golang/bin/go 10334877
go_old 10388125 [53248 bytes]
global text (code) = 51041 bytes (1.343944%)
read-only data = 663 bytes (0.039617%)
Total difference 51704 bytes (0.873981%)
Change-Id: I7bc40968023c3a69f379b10fbb433cdb11364f1b
Reviewed-on: https://go-review.googlesource.com/56250
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Keith Randall <khr@golang.org>
Instructions are implemented in the following revisions:
PCMPESTRI - https://golang.org/cl/22337
PHMINPOSUW - https://golang.org/cl/18853
It is unknown when x86test will be updated/re-run, but tests are useful
to check which x86 instructions are not yet supported.
As an example of tool that uses this information, there is Damien
Lespiau x86db.
Part of the mission to add missing amd64 SSE4 instructions to Go asm.
Change-Id: I512ff26040f47a0976b3e37000fb1f37eac5b762
Reviewed-on: https://go-review.googlesource.com/55830
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
This makes it much easier to run individual failing subtests.
Use $(go env CC) instead of always defaulting to clang; this makes it
easier to test with other compilers.
Run C binaries to detect incompatible compiler/kernel pairings instead
of sniffing versions.
updates #21196
Change-Id: I0debb3cc4a4244df44b825157ffdc97b5c09338d
Reviewed-on: https://go-review.googlesource.com/52910
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation is translated from C, which uses a
polynomial coefficient very close to 1/6. If the function uses
1/6 as this coeffient, the result of Exp(1) will be more accurate.
And this change doesn't introduce more error to Exp function.
Fixes#20319
Change-Id: I94c236a18cf95570ebb69f7fb99884b0d7cf5f6e
Reviewed-on: https://go-review.googlesource.com/49294
Reviewed-by: Robert Griesemer <gri@golang.org>
Prioritized the chunks of code with 8 or more levels of indentation.
Basically early breaks/returns and joining nested ifs.
Change-Id: I6817df1303226acf2eb904a29f2db720e4f7427a
Reviewed-on: https://go-review.googlesource.com/55630
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Current code detect runtime/cgo iff the package or sub packages imports
runtime/cgo directly. However, when we are using linkshared, imported
shared libraries might have already included runtime/cgo.
This CL handles later case by looking an actual runtime/cgo symbol.
Change-Id: I35e7dfdb5e1a939eafc95a0259ee1af9782bc864
Reviewed-on: https://go-review.googlesource.com/56310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
While LoadCmdDylib represents LC_LOAD_DYLIB,
LoadCmdDylinker represents LC_ID_DYLINKER.
This is confusing because there is another command called LC_LOAD_DYLINKER.
LC_ID_DYLINKER is not included in normal binary, it is only used for
/usr/lib/dyld as far as I know. So, perhaps this is a mistake.
Change-Id: I6ea61664a26998962742914af5688e094a233541
Reviewed-on: https://go-review.googlesource.com/56330
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, we have a workaround for solaris that enforce aboslute
addressing for external symbols. However, We don't want to use the
workaround for darwin.
This CL also refactors code a little bit, because the original function
name is not appropriate now.
Updates #17490
Change-Id: Id21f9cdf33dca6a40647226be49010c2c324ee24
Reviewed-on: https://go-review.googlesource.com/54871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* group load command structs.
* use hex literal for LoadCommand.
Decimal number is not a proper representation for some commands.
(e.g. LC_RPATH = 0x8000001c)
* move Symbol struct from macho.go to file.go.
Symbol is a high level representation, not in Mach-O.
Change-Id: I3c69923cb464fb1211f2e766c02e1b537e0b5de2
Reviewed-on: https://go-review.googlesource.com/56130
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When calling a Go function that returns multiple values from C, cgo
generates a structure to hold the values. According to the documentation
this structure is called `struct <function-name>_return`. When compiling
for gccgo the generated structure name is `struct <function-name>_result`.
This change updates the output for gccgo to match the documentation and
output for gc.
Fixes#20910
Change-Id: Iaea8030a695a7aaf9d9f317447fc05615d8e4adc
Reviewed-on: https://go-review.googlesource.com/49350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestSizes has been added in CL 50170. This test is
failing on Plan 9 because executables don't have
a DWARF symbol table.
Fixes#21480.
Change-Id: I51079abdc18ad944617bdbcfe2dad970a0cea0f2
Reviewed-on: https://go-review.googlesource.com/56210
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We use a call to strncpy to work around a TSAN bug (wherein TSAN only
delivers asynchronous signals when the thread receiving the signal
calls a libc function). Unfortunately, GCC 7 inlines the call,
avoiding the TSAN libc trap entirely.
Per Ian's suggestion, use global variables as strncpy arguments: that
way, the compiler can't make any assumptions about the concrete values
and can't inline the call away.
fixes#21196
Change-Id: Ie95f1feaf9af1a8056f924f49c29cfc8515385d7
Reviewed-on: https://go-review.googlesource.com/55872
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are a few cases where this can be useful. Apart from the obvious
(and silly)
100*n + 200*n
where we generate one IMUL instead of two, consider:
15*n + 31*n
Currently, the compiler strength-reduces both imuls, generating:
0x0000 00000 MOVQ "".n+8(SP), AX
0x0005 00005 MOVQ AX, CX
0x0008 00008 SHLQ $4, AX
0x000c 00012 SUBQ CX, AX
0x000f 00015 MOVQ CX, DX
0x0012 00018 SHLQ $5, CX
0x0016 00022 SUBQ DX, CX
0x0019 00025 ADDQ CX, AX
0x001c 00028 MOVQ AX, "".~r1+16(SP)
0x0021 00033 RET
But combining the imuls is both faster and shorter:
0x0000 00000 MOVQ "".n+8(SP), AX
0x0005 00005 IMULQ $46, AX
0x0009 00009 MOVQ AX, "".~r1+16(SP)
0x000e 00014 RET
even without strength-reduction.
Moreover, consider:
5*n + 7*(n+1) + 11*(n+2)
We already have a rule that rewrites 7(n+1) into 7n+7, so the
generated code (without imuls merging) looks like this:
0x0000 00000 MOVQ "".n+8(SP), AX
0x0005 00005 LEAQ (AX)(AX*4), CX
0x0009 00009 MOVQ AX, DX
0x000c 00012 NEGQ AX
0x000f 00015 LEAQ (AX)(DX*8), AX
0x0013 00019 ADDQ CX, AX
0x0016 00022 LEAQ (DX)(CX*2), CX
0x001a 00026 LEAQ 29(AX)(CX*1), AX
0x001f 00031 MOVQ AX, "".~r1+16(SP)
But with imuls merging, the 5n, 7n and 11n factors get merged, and the
generated code looks like this:
0x0000 00000 MOVQ "".n+8(SP), AX
0x0005 00005 IMULQ $23, AX
0x0009 00009 ADDQ $29, AX
0x000d 00013 MOVQ AX, "".~r1+16(SP)
0x0012 00018 RET
Which is both faster and shorter; that's also the exact same code that
clang and the intel c compiler generate for the above expression.
Change-Id: Ib4d5503f05d2f2efe31a1be14e2fe6cac33730a9
Reviewed-on: https://go-review.googlesource.com/55143
Reviewed-by: Keith Randall <khr@golang.org>
The DWARF entries for type-specific sudog entries used the
channel value type instead of a pointer-to-value type for the elem field.
Fixes#21094
R=go1.10
Change-Id: I3f63a5664f42b571f729931309f2c9f6f38ab031
Reviewed-on: https://go-review.googlesource.com/50170
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If the source importer only encounters "soft" type checking errors
it can safely return the type-checked package because it will be
completely set up. This makes the source importer slightly more
robust in the presence of errors.
Fixes#20855.
Change-Id: I5af9ccdb30eee6bca7a0fab872f6057bde521bf3
Reviewed-on: https://go-review.googlesource.com/55730
Reviewed-by: Alan Donovan <adonovan@google.com>
pkgPath always received the empty string. Worse yet, it panicked if it
received anything else. This has been the case ever since newName was
introduced in early 2016.
Change-Id: I5f164305bd30c34455ef35e776c7616f303b37e4
Reviewed-on: https://go-review.googlesource.com/54331
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
updates #13745
Multiprecision squaring can be done in a straightforward manner
with about half the multiplications of a basic multiplication
due to the symmetry of the operands. This change implements
basic squaring for nat types and uses it for Int multiplication
when the same variable is supplied to both arguments of
z.Mul(x, x). This has some overhead to allocate a temporary
variable to hold the cross products, shift them to double and
add them to the diagonal terms. There is a speed benefit in
the intermediate range when the overhead is neglible and the
asymptotic performance of karatsuba multiplication has not been
reached.
basicSqrThreshold = 20
karatsubaSqrThreshold = 400
Were set by running calibrate_test.go to measure timing differences
between the algorithms. Benchmarks for squaring:
name old time/op new time/op delta
IntSqr/1-4 51.5ns ±25% 25.1ns ± 7% -51.38% (p=0.008 n=5+5)
IntSqr/2-4 79.1ns ± 4% 72.4ns ± 2% -8.47% (p=0.008 n=5+5)
IntSqr/3-4 102ns ± 4% 97ns ± 5% ~ (p=0.056 n=5+5)
IntSqr/5-4 161ns ± 4% 163ns ± 7% ~ (p=0.952 n=5+5)
IntSqr/8-4 277ns ± 5% 267ns ± 6% ~ (p=0.087 n=5+5)
IntSqr/10-4 358ns ± 3% 360ns ± 4% ~ (p=0.730 n=5+5)
IntSqr/20-4 1.07µs ± 3% 1.01µs ± 6% ~ (p=0.056 n=5+5)
IntSqr/30-4 2.36µs ± 4% 1.72µs ± 2% -27.03% (p=0.008 n=5+5)
IntSqr/50-4 5.19µs ± 3% 3.88µs ± 4% -25.37% (p=0.008 n=5+5)
IntSqr/80-4 11.3µs ± 4% 8.6µs ± 3% -23.78% (p=0.008 n=5+5)
IntSqr/100-4 16.2µs ± 4% 12.8µs ± 3% -21.49% (p=0.008 n=5+5)
IntSqr/200-4 50.1µs ± 5% 44.7µs ± 3% -10.65% (p=0.008 n=5+5)
IntSqr/300-4 105µs ±11% 95µs ± 3% -9.50% (p=0.008 n=5+5)
IntSqr/500-4 231µs ± 5% 227µs ± 2% ~ (p=0.310 n=5+5)
IntSqr/800-4 496µs ± 9% 459µs ± 3% -7.40% (p=0.016 n=5+5)
IntSqr/1000-4 700µs ± 3% 710µs ± 5% ~ (p=0.841 n=5+5)
Show a speed up of 10-25% in the range where basicSqr is optimal,
improved single word squaring and no significant difference when
the fallback to standard multiplication is used.
Change-Id: Iae2c82ca91cf890823f91e5c83bbe9a2c534b72b
Reviewed-on: https://go-review.googlesource.com/53638
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
$ gotip tool -h says:
For more about each tool command, see 'go tool command -h'.
But it's better to suggest
go doc cmd/<command>
Fixes#18313
Change-Id: I0a36d585906a5e1879e5b7927d1b6173e97cb500
Reviewed-on: https://go-review.googlesource.com/55990
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current implementation of the extended Euclidean GCD algorithm
calculates both cosequences x and y inside the division loop. This
is unneccessary since the second Bezout coefficient can be obtained
at the end of calculation via a multiplication, subtraction and a
division. In case only one coefficient is needed, e.g. ModInverse
this calculation can be skipped entirely. This is a standard
optimization, see e.g.
"Handbook of Elliptic and Hyperelliptic Curve Cryptography"
Cohen et al pp 191
Available at:
http://cs.ucsb.edu/~koc/ccs130h/2013/EllipticHyperelliptic-CohenFrey.pdf
Updates #15833
Change-Id: I1e0d2e63567cfed97fd955048fe6373d36f22757
Reviewed-on: https://go-review.googlesource.com/50530
Reviewed-by: Robert Griesemer <gri@golang.org>
The current implementation uses a shift and add
loop to compute the product of x's exponent xe and
the integer part of y (yi) for yi up to 1<<63.
Since xe is an 11-bit exponent, this product can be
up to 74-bits and overflow both 32 and 64-bit int.
This change checks whether the accumulated exponent
will fit in the 11-bit float exponent of the output
and breaks out of the loop early if overflow is detected.
The current handling of yi >= 1<<63 uses Exp(y * Log(x))
which incorrectly returns Nan for x<0. In addition,
for y this large, Exp(y * Log(x)) can be enumerated
to only overflow except when x == -1 since the
boundary cases computed exactly:
Pow(NextAfter(1.0, Inf(1)), 1<<63) == 2.72332... * 10^889
Pow(NextAfter(1.0, Inf(-1)), 1<<63) == 1.91624... * 10^-445
exceed the range of float64. So, the call can be
replaced with a simple case statement analgous to
y == Inf that correctly handles x < 0 as well.
Fixes#7394
Change-Id: I6f50dc951f3693697f9669697599860604323102
Reviewed-on: https://go-review.googlesource.com/48290
Reviewed-by: Robert Griesemer <gri@golang.org>
The Writer logic was not consistent about when an IO error would
persist across multiple calls on Writer's methods.
Thus, to make the error handling more consistent we always check
the persistent state of the error prior to every exported method
call, and return an error if set. Otherwise, it is the responsibility
of every exported method to persist any fatal errors that may occur.
As a simplification, we can remove the close field since that
information can be represented by simply storing ErrWriteAfterClose
in the err field.
Change-Id: I8746ca36b3739803e0373253450db69b3bd12f38
Reviewed-on: https://go-review.googlesource.com/55590
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The GNU tar format defines the following type flags:
TypeGNULongName = 'L' // Next file has a long name
TypeGNULongLink = 'K' // Next file symlinks to a file w/ a long name
Anytime a string exceeds the field dedicated to store it, the GNU format
permits a fake "file" to be prepended where that file entry has a Typeflag
of 'L' or 'K' and the contents of the file is a NUL-terminated string.
Contrary to previous TODO comments,
the GNU format supports arbitrary strings (without NUL) rather UTF-8 strings.
The manual says the following:
<<<
The name, linkname, magic, uname, and gname are
null-terminated character strings
>>>
<<<
All characters in header blocks are represented
by using 8-bit characters in the local variant of ASCII.
>>>
From this description, we gather the following:
* We must forbid NULs in any GNU strings
* Any 8-bit value (other than NUL) is permitted
Since the modern world has moved to UTF-8, it is really difficult to
determine what a "local variant of ASCII" means. For this reason,
we treat strings as just an arbitrary binary string (without NUL)
and leave it to the user to determine the encoding of this string.
(Practically, it seems that UTF-8 is the typical encoding used
in GNU archives seen in the wild).
The implementation of GNU tar seems to confirm this interpretation
of the manual where it permits any arbitrary binary string to exist
within these fields so long as they do not contain the NUL character.
$ touch `echo -e "not\x80\x81\x82\x83utf8"`
$ gnutar -H gnu --tar -cvf gnu-not-utf8.tar $(echo -e "not\x80\x81\x82\x83utf8")
The fact that we permit arbitrary binary in GNU strings goes
hand-in-hand with the fact that GNU also permits a "base-256" encoding
of numeric fields, which is effectively two-complement binary.
Change-Id: Ic037ec6bed306d07d1312f0058594bd9b64d9880
Reviewed-on: https://go-review.googlesource.com/55573
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the existing implementation, if pattern is an empty string,
program calls a panic with the message which is a concatenation of
"http: invalid pattern " and pattern.
In this case, pattern is an empty, so the commit removes
this concatenation and the trailing space.
Fixes: #21102
Change-Id: I49f58b52d835311a6ac642de871eb15646e48a54
Reviewed-on: https://go-review.googlesource.com/50350
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Tom Bergan <tombergan@google.com>
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The code was adding race.Errors to t.raceErrors before checking
Failed, but Failed was using t.raceErrors+race.Errors. We don't want
to change Failed, since that would affect tests themselves, so modify
the harness to not unnecessarily change t.raceErrors.
Updates #19851Fixes#21338
Change-Id: I7bfdf281f90e045146c92444f1370d55c45221d4
Reviewed-on: https://go-review.googlesource.com/54050
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reduces the code footprint of code like:
println("foo=", foo, "bar=", bar)
which is fairly common in the runtime.
Prior to this change, this makes function calls to print each of:
"foo=", " ", foo, " ", "bar=", " ", bar, "\n"
After this change, this prints:
"foo= ", foo, " bar= ", bar, "\n"
This shrinks the hello world binary by 0.4%.
More importantly, this improves the instruction
density of important runtime routines.
Change-Id: I8971bdf5382fbaaf4a82bad4442f9da07c28d395
Reviewed-on: https://go-review.googlesource.com/55098
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Rather than emitting spaces and newlines for println
as we walk the expression, construct it all up front.
This enables further optimizations.
This requires using printstring instead of print in
the implementation of printsp and printnl,
on pain of infinite recursion.
That's ok; it's more efficient anyway, and just as simple.
While we're here, do it for other print routines as well.
Change-Id: I61d7df143810e00710c4d4d948d904007a7fd190
Reviewed-on: https://go-review.googlesource.com/55097
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Writing to selectdone on the stack of another goroutine meant a
pretty subtle dance between the select code and the stack copying
code. Instead move the selectdone variable into the g struct.
Change-Id: Id246aaf18077c625adef7ca2d62794afef1bdd1b
Reviewed-on: https://go-review.googlesource.com/53390
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I noticed that we don't set an itab's function pointers at compile
time. Instead, we currently do it at executable startup.
Set the function pointers at compile time instead. This shortens
startup time. It has no effect on normal binary size. Object files
will have more relocations, but that isn't a big deal.
For PIE there are additional pointers that will need to be adjusted at
load time. There are already other pointers in an itab that need to be
adjusted, so the cache line will already be paged in. There might be
some binary size overhead to mark these pointers. The "go test -c
-buildmode=pie net/http" binary is 0.18% bigger.
Update #20505
Change-Id: I267c82489915b509ff66e512fc7319b2dd79b8f7
Reviewed-on: https://go-review.googlesource.com/44341
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Currently, GC captures the start-the-world time stamp after
startTheWorldWithSema returns. This is problematic for two reasons:
1. It's possible to get preempted between startTheWorldWithSema
starting the world and calling nanotime.
2. startTheWorldWithSema does several clean-up tasks after the world
is up and running that on rare occasions can take upwards of 10ms.
Since the runtime uses the start-the-world time stamp to compute the
STW duration, both of these can significantly inflate the reported STW
duration.
Fix this by having startTheWorldWithSema itself call nanotime once the
world is started.
Change-Id: I114630234fb73c9dabae50a2ef1884661f2459db
Reviewed-on: https://go-review.googlesource.com/55410
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The processClientKeyExchange and processServerKeyExchange functions unmarshal an
encoded EC point and explicitly check whether the point is on the curve. The explicit
check can be omitted because elliptic.Unmarshal fails if the point is not on the curve
and the returned error would always be the same.
Fixes#20496
Change-Id: I5231a655eace79acee2737dd036a0c255ed42dbb
Reviewed-on: https://go-review.googlesource.com/44311
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Adam Langley <agl@golang.org>
golang.org/cl/55130 added utimensat for Solaris but didn't use it in
UtimesNano (despite indicating otherwise in the commit message). Fix
this by also using utimensat for UtimesNano on Solaris.
Because all versions of Solaris suppported by Go support utimensat,
there is no need for the fallback logic and utimensat can be called
unconditionally.
This issue was pointed out by Shawn Walker-Salas.
Updates #16480
Change-Id: I114338113a6da3cfcb8bca950674bdc8f5a7a9e5
Reviewed-on: https://go-review.googlesource.com/55141
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some IDEs (e.g. intellij IDE based ones) create the .idea folder
to store project specific settings. This is irrelevant to Go project
that does not assume any specific IDEs, but interferes with git.
Change-Id: I0c93d9a3f7edff095fbe0c7a53b06c92b391c970
Reviewed-on: https://go-review.googlesource.com/53770
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The destination slice does not need to be created at all. The source
slice itself can be used as the destination because the decode loop
increments by one and then the 'seen' byte is not used anymore. Therefore
the decoded byte can be stored in that index of the source slice itself.
This trick cannot be applied to EncodeString() because in that case,
the destination slice is large than the source. And for a single byte
in the source slice, two bytes in the destination slice is written.
func BenchmarkDecodeString(b *testing.B) {
for i := 0; i < b.N; i++ {
DecodeString("0123456789abcdef")
}
}
name old time/op new time/op delta
DecodeString 71.0ns ± 6% 58.0ns ± 0% -18.28% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
DecodeString 16.0B ± 0% 8.0B ± 0% -50.00% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
DecodeString 1.00 ± 0% 1.00 ± 0% ~ (all equal)
Change-Id: Id98db4e712444557a804155457a4dd8d1b8b416d
Reviewed-on: https://go-review.googlesource.com/55611
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL golang.org/cl/55130 messed up the definition of _AT_FDCWD on
dragonfly.
This fixes the following test failure on dragonfly/amd64:
--- FAIL: TestPackageMainTestImportsArchiveNotBinary (0.00s)
go_test.go:192: chtimes ./testdata/src/main_test/m.go: bad file descriptor
Change-Id: I4c96983769e6b02d714859dc838875c3c0f1be50
Reviewed-on: https://go-review.googlesource.com/55690
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The stxr/stxrw/stxrb/stxrh instructions belong to STLXR-like instructions
set and they require special handling. The current code has no special
handling for those instructions.
The fix adds the special handling for those instructions.
Uncomment stxr/stxrw/stxrb/stxrh test cases.
Fixes#21397
Change-Id: I31cee29dd6b30b1c25badd5c7574dda7a01bf016
Reviewed-on: https://go-review.googlesource.com/54951
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Improve static branch prediction in arm64 wrapper prologue
by making the unusual case branch forwards. (Most other
architectures implement this optimization.)
Additionally, replace a CMP+BNE pair with a CBNZ
to save one instruction.
Change-Id: Id970038b34b4aaec18c101d62e2ee00f3e32a761
Reviewed-on: https://go-review.googlesource.com/54070
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add support for generating TBZ/TBNZ instructions.
The bit-test-and-branch pattern shows up in a number of
important places, including the runtime (gc bitmaps).
Before this change, there were 3 TB[N]?Z instructions in the Go tool,
all of which were in hand-written assembly. After this change, there
are 285. Also, the go1 benchmark binary gets about 4.5kB smaller.
Fixes#21361
Change-Id: I170c138b852754b9b8df149966ca5e62e6dfa771
Reviewed-on: https://go-review.googlesource.com/54470
Run-TryBot: Philip Hofer <phofer@umich.edu>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
struct32 and struct40 structs are already declared, remove them to
make runtime tests build.
Change-Id: I3814f2b850dcb15c4002a3aa22e2a9326e5a5e53
Reviewed-on: https://go-review.googlesource.com/55614
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
The logic for USTAR was disabled because a previous implementation of
Writer had a wrong understanding of the differences between USTAR and GNU,
causing the prefix field is incorrectly be populated in GNU files.
Now that this issue has been fixed, we can re-enable the logic for USTAR
path splitting, which allows Writer to use the USTAR for a wider range
of possible inputs.
Updates #9683
Updates #12594
Updates #17630
Change-Id: I9fe34e5df63f99c6dd56fee3a7e7e4d6ec3995c9
Reviewed-on: https://go-review.googlesource.com/55574
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Move all sentinel errors to common.go since some of them are
returned by both the reader and writer and remove errInvalidHeader
since it not used.
Also, consistently use the "tar: " prefix for errors.
Change-Id: I0afb185bbf3db80dfd9595321603924454a4c2f9
Reviewed-on: https://go-review.googlesource.com/55650
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Instead of comparing if the number of elements will
not fit into memory check if the memory size of the
slices backing memory is higher then the memory limit.
This avoids a division or maxElems lookup.
With et.size > 0:
uintptr(newcap) > maxSliceCap(et.size)
-> uintptr(int(capmem / et.size)) > _MaxMem / et.size
-> capmem / et.size > _MaxMem / et.size
-> capmem > _MaxMem
Note that due to integer division from capmem > _MaxMem
it does not follow that uintptr(newcap) > maxSliceCap(et.size).
Consolidated runtime GrowSlice benchmarks by using sub-benchmarks and
added more struct sizes to show performance improvement when division
is avoided for element sizes larger than 32 bytes.
AMD64:
GrowSlice/Byte 38.9ns ± 2% 38.9ns ± 1% ~ (p=0.974 n=20+20)
GrowSlice/Int 58.3ns ± 3% 58.0ns ± 2% ~ (p=0.154 n=20+19)
GrowSlice/Ptr 95.7ns ± 2% 95.1ns ± 2% -0.60% (p=0.034 n=20+20)
GrowSlice/Struct/24 95.4ns ± 1% 93.9ns ± 1% -1.54% (p=0.000 n=19+19)
GrowSlice/Struct/32 110ns ± 1% 108ns ± 1% -1.76% (p=0.000 n=19+20)
GrowSlice/Struct/40 138ns ± 1% 128ns ± 1% -7.09% (p=0.000 n=20+20)
Change-Id: I1c37857c74ea809da373e668791caffb6a5cbbd3
Reviewed-on: https://go-review.googlesource.com/53471
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Both the GNU and PAX formats support atime and ctime fields.
The implementation is trivial now that we have:
* support for formatting PAX records for timestamps
* dedicated methods that only handle one format (e.g., GNU)
Fixes#17876
Change-Id: I0c604fce14a47d722098afc966399cca2037395d
Reviewed-on: https://go-review.googlesource.com/55570
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We forbid empty keys or keys with '=' because it leads to ambiguous parsing.
Relevent PAX specification:
<<<
A keyword shall not include an <equals-sign>.
>>>
Also, we forbid the writer from encoding records with an empty value.
While, this is a valid record syntactically, the semantics of an empty
value is that previous records with that key should be deleted.
Since we have no support (and probably never will) for global PAX records,
deletion is a non-sensible operation.
<<<
If the <value> field is zero length,
it shall delete any header block field,
previously entered extended header value,
or global extended header value of the same name.
>>>
Fixes#20698Fixes#15567
Change-Id: Ia29c5c6ef2e36cd9e6d7f6cff10e92b96a62f0d1
Reviewed-on: https://go-review.googlesource.com/55571
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add support for PAX subsecond resolution times. Since the parser
supports negative timestamps, the formatter also handles negative
timestamps.
The relevant PAX specification is:
<<<
Portable file timestamps cannot be negative. If pax encounters a
file with a negative timestamp in copy or write mode, it can reject
the file, substitute a non-negative timestamp, or generate a
non-portable timestamp with a leading '-'.
>>>
<<<
All of these time records shall be formatted as a decimal
representation of the time in seconds since the Epoch.
If a <period> ( '.' ) decimal point character is present,
the digits to the right of the point shall represent the units of
a subsecond timing granularity, where the first digit is tenths of
a second and each subsequent digit is a tenth of the previous digit.
>>>
Fixes#11171
Change-Id: Ied108f3d2654390bc1b0ddd66a4081c2b83e490b
Reviewed-on: https://go-review.googlesource.com/55552
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We weren't initializing this field for dynamically-generated itabs.
Turns out it doesn't matter, as any time we use this field we also
generate a static itab for the interface type / concrete type pair.
But we should initialize it anyway, just to be safe.
Performance on the benchmarks in CL 44339:
benchmark old ns/op new ns/op delta
BenchmarkItabFew-12 1040585 26466 -97.46%
BenchmarkItabAll-12 228873499 4287696 -98.13%
Change-Id: I58ed2b31e6c98b584122bdaf844fee7268b58295
Reviewed-on: https://go-review.googlesource.com/44475
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Keep itabs in a growable hash table.
Use a simple open-addressable hash table, quadratic probing, power
of two sized.
Synchronization gets a bit more tricky. The common read path now
has two atomic reads, one to get the table pointer and one to read
the entry out of the table.
I set the max load factor to 75%, kind of arbitrarily. There's a
space-speed tradeoff here, and I'm not sure where we should land.
Because we use open addressing the itab.link field is no longer needed.
I'll remove it in a separate CL.
Fixes#20505
Change-Id: Ifb3d9a337512d6cf968c1fceb1eeaf89559afebf
Reviewed-on: https://go-review.googlesource.com/44472
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Certain special type-flags, specifically 1, 2, 3, 4, 5, 6,
do not have a data section. Thus, regardless of what the size field
says, we should not attempt to write any data for these special types.
The relevant PAX and USTAR specification says:
<<<
If the typeflag field is set to specify a file to be of type 1 (a link)
or 2 (a symbolic link), the size field shall be specified as zero.
If the typeflag field is set to specify a file of type 5 (directory),
the size field shall be interpreted as described under the definition
of that record type. No data logical records are stored for types 1, 2, or 5.
If the typeflag field is set to 3 (character special file),
4 (block special file), or 6 (FIFO), the meaning of the size field is
unspecified by this volume of POSIX.1-2008, and no data logical records shall
be stored on the medium.
Additionally, for type 6, the size field shall be ignored when reading.
If the typeflag field is set to any other value, the number of logical
records written following the header shall be (size+511)/512, ignoring
any fraction in the result of the division.
>>>
Fixes#15565
Change-Id: Id11886b723b3b13deb15221dca51c25cd778a6b5
Reviewed-on: https://go-review.googlesource.com/55553
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Both GNU and BSD tar do not care if the devmajor and devminor values are
set on entries (like regular files) that aren't character or block devices.
While this is non-sensible, it is more consistent with the Writer to actually
read these fields always. In a vast majority of the cases these will still
be zero. In the rare situation where someone actually cares about these,
at least information was not silently lost.
Change-Id: I6e4ba01cd897a1b13c28b1837e102a4fdeb420ba
Reviewed-on: https://go-review.googlesource.com/55572
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ld.SymKind and objabi.RelocType have string representations,
which is human friendly. Prefer to use it.
Change-Id: I458ee0ca5866be0db8462c36cd053561a8206c95
Reviewed-on: https://go-review.googlesource.com/55253
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The preceding cleanup made it clear that two cases
(have golden data, unreachable key) are handled identically.
Simplify the control flow to reflect that.
Simplifies the code and generates shorter machine code.
Change-Id: Id612e0da6679813e855506f47222c58ea6497d70
Reviewed-on: https://go-review.googlesource.com/55093
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This fixes the -x output so that when it reports environment variables they
are correctly quoted for later execution by the shell.
Also fix -x output to use the right path to the pack tool, and note when
we are touching a file.
Fixes#21427
Change-Id: I323ef4edf9905b08bc26944b94183d8da2fa9675
Reviewed-on: https://go-review.googlesource.com/55350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Only set MH_NOUNDEFS if there are no undefined symbols.
Doesn't seem to matter, but may as well do it right.
Change-Id: I6c472e000578346c28cf0e10f24f870e3a0de628
Reviewed-on: https://go-review.googlesource.com/55310
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
They are currently not given a size, which makes the DWARF reader
very confused. Particularly things like [4]func() get a size of -4, not 32.
Fixes#21097
Change-Id: I01e754134d82fbbe6567e3c7847a4843792a3776
Reviewed-on: https://go-review.googlesource.com/55551
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change unifies the x and y cases.
It shrinks evacuate's machine code by ~25% and its stack size by ~15%.
It also eliminates a critical branch.
Whether an entry should go to x or y is designed to be unpredictable.
As a result, half of the branch predictions for useX were wrong.
Mispredicting that branch can easily incur an expensive cache miss.
Switching to an xy array allows elimination of that branch,
which in turn reduces cache misses.
Change-Id: Ie9cef53744b96c724c377ac0985b487fc50b49b1
Reviewed-on: https://go-review.googlesource.com/54653
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Make the calculation of k and v a bit lazier.
None of the following code cares about indirect-vs-direct k,
and it happens on all code paths, so check t.indirectkey earlier.
Simplifies the code and reduces both machine code and stack size.
Change-Id: I5ea4c0772848d7a4b15383baedb9a1f7feb47201
Reviewed-on: https://go-review.googlesource.com/55092
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Previous CLs (CL/54970, CL55231, and CL/55237) re-implemented tar.Writer
entirely using specialized methods (writeUSTARHeader, writePAXHeader,
and writeGNUHeader) allowing tar.Writer to entirely side-step the broken
and buggy logic in writeHeader.
Since writeHeader and writePAXHeaderLegacy is now dead-code,
we can delete them.
One minor change is that we call Writer.Flush at the start of WriteHeader.
This used to be performed by writeHeader, but doing so in WriteHeader
ensures each of the specialized methods can benefit from its effect.
Fixes#17665Fixes#12594
Change-Id: Iff2ef8e7310d40ac5484d2f8852fc5df25201426
Reviewed-on: https://go-review.googlesource.com/55550
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Rather than going through writeHeader, which attempts to handle all formats,
implement writeGNUHeader, which only has an understanding of the GNU format.
Currently, the implementation is nearly identical to writeUSTARHeader, except:
* formatNumeric is used instead of formatOctal
* the GNU magic value is used
This is kept as a separate method since it makes more logical sense
when we add support for sparse files, long filenames, and atime/ctime fields,
which do not affect USTAR.
Updates #12594
Change-Id: I76efc0b39dc649efc22646dfc9867a7c165f34a8
Reviewed-on: https://go-review.googlesource.com/55237
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Instead of printing Atoi as function name for test failures
print the actual function name and arguments tested.
Add a base field to the parseUint64BaseTests for consistency with
the parseInt64BaseTests tests.
Change-Id: Ib9891bdb87b62672b4216625212acfe6474c70fc
Reviewed-on: https://go-review.googlesource.com/55136
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This makes sure that its argument is marked live on entry.
We need its arg to be live so defers of KeepAlive get
scanned correctly by the GC.
Fixes#21402
Change-Id: I906813e433d0e9726ca46483723303338da5b4d7
Reviewed-on: https://go-review.googlesource.com/55150
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently go fmt formats all files sequentially.
That's a shame. Parallelize it over files.
Reduces time of go fmt ./... in std lib
from ~6.1s to ~0.9s.
Reduces time of go fmt github.com/google/syzkaller/...
from ~5.2s to ~1.8s.
Change-Id: I3d27fc25326106b2a4781e13506a25c12d5bcdc5
Reviewed-on: https://go-review.googlesource.com/45491
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also, unexport Machoadddynlib
n=`go test -c crypto/x509 && otool -l x509.test | grep libSystem | wc -l`
Before this CL, n = 3.
After this CL, n = 1.
on my environment.
Change-Id: Ic7b8157435cc85086404860dc6c84eb0aecc5d19
Reviewed-on: https://go-review.googlesource.com/44771
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change some configurations to enable the feature. Also add the test.
This CL doesn't include internal linking support which is tentatively
disabled due to #18968. We could do that another day.
Fixes#21220
Change-Id: I601d2d78446d36332acc70be0d5b9461ac635208
Reviewed-on: https://go-review.googlesource.com/54790
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The parser mistakenly assumed it could always fold \r\n into \n, which
is not true since a \r\n inside a quoted fields has no special meaning
and should be kept as is.
Fix this by not folding \r\n to \n inside quotes fields.
Fixes#21201
Change-Id: Ifebc302e49cf63e0a027ee90f088dbc050a2b7a6
Reviewed-on: https://go-review.googlesource.com/52810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
* Remove an unnecessary type conversion
* Make golint happier about consistent receiver names
* Make golint happier about a foo_bar var name
Change-Id: I5223808109f6f8b69ed4be76de82faf2478c6a2e
Reviewed-on: https://go-review.googlesource.com/54530
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
The old comment for the example
type PtrMutex *Mutex
talked about the method set of the base type of PtrMutex.
It's more direct and clearer to talk about the underlying
type of PtrMutex for this specific example.
Also removed link inside pre-formatted region of text.
Fixes#20900.
Change-Id: Ie37340e53670e34ebe13e780ba8ccb1bba67795c
Reviewed-on: https://go-review.googlesource.com/55070
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change replaces the current runtime capabilities check for ppc64x with the
new internal/cpu package. It also adds support for the new POWER9 ISA and
capabilities.
Updates #15403
Change-Id: I5b64a79e782f8da3603e5529600434f602986292
Reviewed-on: https://go-review.googlesource.com/53830
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Since test files don't exceed 10KiB, print the full context of the diff,
including bytes that are equal.
Also, fix the labels for got and want; they were backwards before.
Change-Id: Ibac022e5f988d26812c3f75b643cae8b95603fc9
Reviewed-on: https://go-review.googlesource.com/55151
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Rather than going through writeHeader, which attempts to handle all formats,
implement writePAXHeader, which only has an understanding of the PAX format.
In PAX, the USTAR header is filled out in a best-effort manner.
Thus, we change logic of formatString and formatOctal to try their best to
output something (possibly truncated) in the event of an error.
The new implementation of PAX headers causes several tests to fail.
An investigation into the new output reveals that the new behavior is correct,
while the tests had actually locked in incorrect behavior before.
A dump of the differences is listed below (-before, +after):
<< writer-big.tar >>
This change is due to fact that we changed the Header.Devminor to force the
tar.Writer to choose the GNU format over the PAX one.
The ability to control the output is an open issue (see #18710).
- 00000150 00 30 30 30 30 30 30 30 00 00 00 00 00 00 00 00 |.0000000........|
+ 00000150 00 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 |................|
<< writer-big-long.tar>>
The previous logic generated the GNU magic values for a PAX file.
The new logic correctly uses the USTAR magic values.
- 00000100 00 75 73 74 61 72 20 20 00 00 00 00 00 00 00 00 |.ustar ........|
- 00000500 00 75 73 74 61 72 20 20 00 67 75 69 6c 6c 61 75 |.ustar .guillau|
+ 00000100 00 75 73 74 61 72 00 30 30 00 00 00 00 00 00 00 |.ustar.00.......|
+ 00000500 00 75 73 74 61 72 00 30 30 67 75 69 6c 6c 61 75 |.ustar.00guillau|
The previous logic tried to use the specified timestmap in the PAX headers file,
but this is problematic as this timestamp can overflow, defeating the point
of using PAX, which is intended to extend tar.
The new logic uses the zero timestamp similar to what GNU and BSD tar do.
- 00000080 30 30 30 30 32 33 32 00 31 32 33 33 32 37 37 30 |0000232.12332770|
+ 00000080 30 30 30 30 32 35 36 00 30 30 30 30 30 30 30 30 |0000256.00000000|
The previous logic populated the devminor and devmajor fields.
The new logic leaves them zeroed just like what GNU and BSD tar do.
- 00000140 00 00 00 00 00 00 00 00 00 30 30 30 30 30 30 30 |.........0000000|
- 00000150 00 30 30 30 30 30 30 30 00 00 00 00 00 00 00 00 |.0000000........|
+ 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+ 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
The previous logic uses PAX headers, but fails to add a record for the size.
The new logic does properly add a record for the size.
- 00000290 31 36 67 69 67 2e 74 78 74 0a 00 00 00 00 00 00 |16gig.txt.......|
- 000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+ 00000290 31 36 67 69 67 2e 74 78 74 0a 32 30 20 73 69 7a |16gig.txt.20 siz|
+ 000002a0 65 3d 31 37 31 37 39 38 36 39 31 38 34 0a 00 00 |e=17179869184...|
The previous logic encoded the size as a base-256 field,
which is only valid in GNU, but the previous PAX headers implies this should
be a PAX file. This result in a strange hybrid that is neither GNU nor PAX.
The new logic uses PAX headers to store the size.
- 00000470 37 35 30 00 30 30 30 31 37 35 30 00 80 00 00 00 |750.0001750.....|
- 00000480 00 00 00 04 00 00 00 00 31 32 33 33 32 37 37 30 |........12332770|
+ 00000470 37 35 30 00 30 30 30 31 37 35 30 00 30 30 30 30 |750.0001750.0000|
+ 00000480 30 30 30 30 30 30 30 00 31 32 33 33 32 37 37 30 |0000000.12332770|
<< ustar.issue12594.tar >>
The previous logic used the specified timestamp for the PAX headers file.
The new logic just uses the zero timestmap.
- 00000080 30 30 30 30 32 33 31 00 31 32 31 30 34 34 30 32 |0000231.12104402|
+ 00000080 30 30 30 30 32 33 31 00 30 30 30 30 30 30 30 30 |0000231.00000000|
The previous logic populated the devminor and devmajor fields.
The new logic leaves them zeroed just like what GNU and BSD tar do.
- 00000140 00 00 00 00 00 00 00 00 00 30 30 30 30 30 30 30 |.........0000000|
- 00000150 00 30 30 30 30 30 30 30 00 00 00 00 00 00 00 00 |.0000000........|
+ 00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
+ 00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
Change-Id: I33419eb1124951968e9d5a10d50027e03133c811
Reviewed-on: https://go-review.googlesource.com/55231
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Just like https://golang.org/cl/34783
Given cgo.go:
1 package main
2
3 /*
4 long double x = 0;
5 */
6 import "C"
7
8 func main() {
9 _ = C.x
10 _ = C.x
11 }
Before:
./cgo.go:10:6: unexpected: 16-byte float type - long double
After:
./cgo.go:9:6: unexpected: 16-byte float type - long double
The above test case is not portable. So it is tested on only amd64.
Change-Id: If0b84cf73d381a22e2ada71c8e9a6e6ec77ffd2e
Reviewed-on: https://go-review.googlesource.com/54950
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We might want to replace some linker's feature by debug/macho in future.
This CL gathers information of required constants.
Change-Id: Iea14abdb32709a4f5404a17874f9c925d29ba999
Reviewed-on: https://go-review.googlesource.com/55252
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The tests for error scenarios were done by manually checking
error strings. Improved them by checking the actual error type
instead of just the string.
Printing the actual error in case of failure instead of a
generic string.
Also added a new scenario with both an invalid byte and an
invalid length string to verify that the length is checked first
before doing any computation.
Change-Id: Ic2a19a6d6058912632d597590186ee2d8348cb45
Reviewed-on: https://go-review.googlesource.com/55256
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Errors returned by Reader contain the line where the Reader originally
encountered the error. This can be suboptimal since that line does not
always correspond with the line the current record/field started at.
This can easily happen with LazyQuotes as seen in #19019, but also
happens for example when a quoted fields has no closing quote and
the parser hits EOF before it finds another quote.
When this happens finding the erroneous field can be somewhat
complicated and time consuming, and in most cases it would be better to
report the line where the record started.
This change updates Reader to keep track of the line on which a record
begins and uses it for errors instead of the current line, making it
easier to find errors.
Although a user-visible change, this should have no impact on existing
code, since most users don't explicitly work with the line in the error
and probably already expect the new behaviour.
Updates #19019
Change-Id: Ic9bc70fad2651c69435d614d537e7a9266819b05
Reviewed-on: https://go-review.googlesource.com/52830
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
No semantic change, just clarifying a bit by choosing better words
in a couple of places.
Change-Id: I4496062ee7909baf83d4d22d25e13ef93b358b4b
Reviewed-on: https://go-review.googlesource.com/55255
Reviewed-by: Ian Lance Taylor <iant@golang.org>
All the BSDs and Solaris support the utimensat syscall, but Darwin
doesn't. Account for that by adding the //sys lines not to
syscall_bsd.go but the individual OS's syscall_*.go files and implement
utimensat on Darwin as just returning ENOSYS, such that UtimesNano will
fall back to use utimes as it currently does unconditionally.
This also adds the previously missing utimensat syscall number for
FreeBSD and Dragonfly.
Fixes#16480
Change-Id: I367454c6168eb1f7150b988fa16cf02abff42f34
Reviewed-on: https://go-review.googlesource.com/55130
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
lookupName is only called in one location, and one of the return
values is unused, so let's remove it.
Change-Id: I35e22c7ec611e8eb349deb4f0561e212f7d9de0b
Reviewed-on: https://go-review.googlesource.com/55232
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
This reverts commit f612cd704a.
Reason for revert: We thought the original change had broken the
linux/amd64 and linux/386 builders, but it turned out to be a problem
with the build infrastructure, not the change.
Change-Id: Ic3318a63464fcba8d845ac04494115a7ba620364
Reviewed-on: https://go-review.googlesource.com/55050
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This generates better code.
Masking B in the return statement should be unnecessary,
but the compiler is understandably not yet clever enough to see that.
Someday, it'd also be nice for the compiler to generate
a CMOV for the saturation if statement.
Change-Id: Ie1c157b21f5212610da1f3c7823a93816b3b61b9
Reviewed-on: https://go-review.googlesource.com/54656
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Combine conditions into a single if statement.
This is more readable.
It should generate identical machine code, but it doesn't.
The new code is shorter.
Change-Id: I9bf52f8f288b0df97a2b9b4e4183f6ca74175e8a
Reviewed-on: https://go-review.googlesource.com/54651
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Currently we only support finding symbols in the VDSO using the old
DT_HASH. These days everything uses DT_GNU_HASH instead. To keep up
with the times and future-proof against DT_HASH disappearing from the
VDSO in the future, this commit adds support for DT_GNU_HASH and
prefers it over DT_HASH.
Tested by making sure it found a DT_GNU_HASH section and all of the
expected symbols in it, and then disabling the DT_GNU_HASH path and
making sure the old DT_HASH path still found all of the symbols.
Fixes#19649.
Change-Id: I508c8b35a019330d2c32f04f3833b69cb2686f13
Reviewed-on: https://go-review.googlesource.com/45511
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The ZIP format uses uint16 to contain the length of the file name and
the length of the Extra section. This change verifies that the length
of these fields fit in an uint16 prior to writing the ZIP file. If not,
an error is returned.
Fixes#17402
Change-Id: Ief9a864d2fe16b89ddb9917838283b801a2c58a4
Reviewed-on: https://go-review.googlesource.com/50250
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If needed cast the test table values to a higher bit size
integer type instead of casting the result values of the
tested function to a lower bit size integer type.
Change-Id: Iaa79742b2b1d90c7c7eac324f54032ebea0b1b41
Reviewed-on: https://go-review.googlesource.com/55137
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
If the value corresponding to the input string cannot be
represented by an unsigned integer of the given size,
err.Err = ErrRange and the returned value is the maximum
magnitude unsigned integer of the appropriate bitSize.
This is consistent with ParseInt's behavior and the documentation.
Expand tests to test 32 bit test value tables with bitsize 32 set.
These tests fail without the fix in this CL.
Fixes#21278
Change-Id: I8aab39279ec3e31905fcbf582a916cbf6d9b95da
Reviewed-on: https://go-review.googlesource.com/55134
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
By replacing fmt.Sprintf with a simple string concat, we see
pretty good improvements across the board on time and memory.
name old time/op new time/op delta
FormatPAXRecord 683ns ± 2% 210ns ± 5% -69.22% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
FormatPAXRecord 112B ± 0% 32B ± 0% -71.43% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
FormatPAXRecord 8.00 ± 0% 2.00 ± 0% -75.00% (p=0.000 n=10+10)
Ran with - -cpu=1 -count=10 on an AMD64 i5-5200U CPU @ 2.20GHz
Using the following benchmark:
func BenchmarkFormatPAXRecord(b *testing.B) {
for n := 0; n < b.N; n++ {
formatPAXRecord("foo", "bar")
}
}
Change-Id: I828ddbafad2e5d937f0cf5f777b512638344acfc
Reviewed-on: https://go-review.googlesource.com/55210
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Rather than going through the complicated logic of writeHeader,
implement a writeUSTARHeader that only knows about the USTAR format.
This makes the logic much easier to reason about since you only
need to be concerned about USTAR and not all the subtle
differences between USTAR, PAX, and GNU.
We seperate out the logic in writeUSTARHeader into templateV7Plus
and writeRawHeader since the planned implementations of
writePAXHeader and writeGNUHeader will use them.
Change-Id: Ie75a54ac998420ece82686159ae6fa39f8b128e9
Reviewed-on: https://go-review.googlesource.com/54970
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The dieFromSignal runtime function attempts to forward crashing
signals to a signal handler registered before the runtime was
initialized, if any. However, on Darwin, a special signal handler
trampoline is invoked, even for non-Go signal handlers.
Clear the crashing signal's handlingSig entry to ensure sigtramp
forwards the signal.
Fixes the darwin/386 builder.
Updates #20392
Updates #19389
Change-Id: I441a3d30c672cdb21ed6d8f1e1322d7c0e5b9669
Reviewed-on: https://go-review.googlesource.com/55032
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
$ go tool -h says:
For more about each tool command, see 'go tool command -h'.
but it was suggested to change the suggestion to say:
see 'go doc command'
In #18313.
That would work for every tool except dist, which has no doc.go.
This change adds a doc.go file to cmd/dist.
Updates #18313
Change-Id: If67a21934b87647a69359d9c14d8de3775c587b7
Reviewed-on: https://go-review.googlesource.com/54351
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently all trace slices get shifted to start at time 0. This makes
it very difficult to find specific points in time unless they fall in
the first slice.
For example, right now when you click "View trace
(6.005646218s-8.155419698s)" on the trace tool's main page, the trace
view puts the first event in that slice at time 0. If you're looking
for something that happened at time 7s, you have to look at time
0.9943537s in the trace view. And if you want to subtract times taken
from different slices, you have to figure out what those time really
correspond to.
Fix this by telling the trace viewer not to shift the times when it
imports the trace. In the above example, this makes the view of that
second trace slice start at time 6.005646218s, so you don't have to do
any gymnastics to find or calculate times in later slices.
Change-Id: I04e0afda60f5573fdd8ad96238c24013297ef263
Reviewed-on: https://go-review.googlesource.com/54633
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This updates the HTML served for the trace viewer to follow the latest
revision of the example from the upstream tracing project.
The main thing this adds is CSS for the trace viewer (which was
actually in the example at the originally referenced revision, so I'm
not sure why it got dropped). In particular, this expands the trace
viewer to use the entire browser client area, which fixes several
problems with the current page:
1. The details pane gets cut off at a strange place and can get a
scroll bar even if there's plenty of room below it on the page. This
fixes the bottom of the details pane to the bottom of the window.
2. If the track view is very tall (lots of procs), there's no way to
view the top tracks and the details pane at the same time. This fixes
this problem by limiting the height of the track view to something
less than the height of the window so it gets a scroll bar of its own
if necessary.
3. Dragging the divider between the track pane and the details pane
actually moves the bottom of the details pane without moving the
divider. Fixing the height of the trace viewer fixes this problem.
Change-Id: Ia811e72a7413417ca21c45e932c9db2724974633
Reviewed-on: https://go-review.googlesource.com/54632
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
_main has an early check to verify if a binary is statically or dynamically
linked that depends on R0 being zero. R0 is not guaranteed to be zero at that
point and this was breaking Go on Alpine for ppc64le.
Change-Id: I4a1059ff7fd3db6fc489e7dcfe631c1814dd965b
Reviewed-on: https://go-review.googlesource.com/54730
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The gofmt bug in question seems to be fixed (at least gofmt doesn't
complain), so reenable the commented-out ... test.
Change-Id: Icbfe0511160210557894ec8eb9b206aa6133d486
Reviewed-on: https://go-review.googlesource.com/55030
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This implements trunc, floor, and ceil in the math package
as intrinsics on ppc64x. Significant improvement mainly due
to avoiding call overhead of args and return value.
BenchmarkCeil-16 5.95 0.69 -88.40%
BenchmarkFloor-16 5.95 0.69 -88.40%
BenchmarkTrunc-16 5.82 0.69 -88.14%
Updates #21390
Change-Id: I951e182694f6e0c431da79c577272b81fb0ebad0
Reviewed-on: https://go-review.googlesource.com/54654
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
As noted in the TODO comment, the sticky bit is only used
when the rounding bit is zero or the rounding mode is
ToNearestEven. This change makes that check explicit and
will eliminate half the sticky bit calculations on average
when rounding mode is not ToNearestEven.
Change-Id: Ia4709f08f46e682bf97dabe5eb2a10e8e3d7af43
Reviewed-on: https://go-review.googlesource.com/54111
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Although mincore is declared in stubs.go, mincore isn't used by any
OSes except linux. Move it to os_linux.go and clean up unused code.
Change-Id: I6cfb0fed85c0317a4d091a2722ac55fa79fc7c9a
Reviewed-on: https://go-review.googlesource.com/54910
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This parameter is always false. The last occurrence of s.skipSpace(true)
was removed in mid-2015.
While at it, merge skipSpace into SkipSpace, since the latter was just a
wrapper without the parameter.
Found with github.com/mvdan/unparam.
Change-Id: I884ea4036f41234a898d6aeee515211c49b0b435
Reviewed-on: https://go-review.googlesource.com/52890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
The current logic in writeHeader attempts to encode the Header in one
format and if it discovered that it could not it would attempt to
switch to a different format mid-way through. This makes it very
hard to reason about what format will be used in the end and whether
it will even be a valid format.
Instead, we should verify from the start what formats are allowed
to encode the given input Header. If no formats are possible,
then we can return immediately, rejecting the Header.
For now, we continue on to the hairy logic in writeHeader, but
a future CL can split that logic up and specialize them for each
format now that we know what is possible.
Update #9683
Update #12594
Change-Id: I8406ea855dfcb8b478a03a7058ddf8b2b09d46dc
Reviewed-on: https://go-review.googlesource.com/54433
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I also wanted to test net sockets, but I do not know how to
access their file handles. So I did not implement socket tests.
Updates #21172
Change-Id: I5062c0e65a817571d755397d60762c175f9791ce
Reviewed-on: https://go-review.googlesource.com/53530
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The prior logic would over-write the NUL-terminator if the octal value
was long enough. In order to prevent this, we add a fitsInOctal function
that does the proper check.
The relevant USTAR specification about NUL-terminator is:
<<<
Each numeric field is terminated by one or more <space> or NUL characters.
>>>
Change-Id: I6fbc6e8fe71168727eea201925d0fe08d43116ac
Reviewed-on: https://go-review.googlesource.com/54432
Reviewed-by: Ian Lance Taylor <iant@golang.org>
USTAR and GNU strings are NUL-terminated. Thus, we should never
allow the NUL terminator, otherwise we will lose data round-trip.
Relevant specification text:
<<<
The fields magic, uname, and gname are character strings each terminated by a NUL character.
>>>
Technically, PAX keys and values should be UTF-8, but the observance
of invalid files in the wild causes us to be more liberal.
<<<
The <length> field, <blank>, <equals-sign>, and <newline> shown shall
be limited to the portable character set, as encoded in UTF-8.
>>>
Thus, we only reject NULs in PAX keys, and NULs for PAX values
representing the USTAR string fields (i.e., path, linkpath, uname, gname).
These are treated more strictly because they represent strings that
are typically represented as C-strings on POSIX systems.
Change-Id: I305b794d9d966faad852ff660bd0b3b0964e52bf
Reviewed-on: https://go-review.googlesource.com/14724
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Given that sparse file logic is not trivial, there should be a test
in TestPartialRead to ensure that partial reads work.
Change-Id: I913da3e331da06dca6758a8be3f5099abba233a6
Reviewed-on: https://go-review.googlesource.com/54430
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The encoding/hex package provides a nice Dump formatter that
prints both hex and ASCII. Use that instead for better visual
debugging of binary diffs.
Change-Id: Iad1084e8e52d7d523595e97ae20912657cea2ab5
Reviewed-on: https://go-review.googlesource.com/14729
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Prior to Go1.8, the Writer had a bug where it would output
an invalid tar file in certain rare situations because the logic
incorrectly believed that the old GNU format had a prefix field.
This is wrong and leads to an output file that mangles the
atime and ctime fields, which are often left unused.
In order to continue reading tar files created by former, buggy
versions of Go, we skeptically parse the atime and ctime fields.
If we are unable to parse them and the prefix field looks like
an ASCII string, then we fallback on the pre-Go1.8 behavior
of treating these fields as the USTAR prefix field.
Note that this will not use the fallback logic for all possible
files generated by a pre-Go1.8 toolchain. If the generated file
happened to have a prefix field that parses as valid
atime and ctime fields (e.g., when they are valid octal strings),
then it is impossible to distinguish between an valid GNU file
and an invalid pre-Go1.8 file.
Fixes#21005
Change-Id: Iebf5c67c08e0e46da6ee41a2e8b339f84030dd90
Reviewed-on: https://go-review.googlesource.com/53635
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In Go1.0, Writer.Flush used to finish off the current file with zeros
(if it was not already finished) and then write the padding.
Since Go1.1, a regression was made (https://golang.org/cl/5777064) where it was
an error to call Flush if the current file was incomplete. Thus, Flush now only
writes out the final padding bytes, which arguably isn't very useful to anyone.
Since this has been the behavior of Flush for 9 releases of Go (1.1 to 1.9),
we should keep this behavior and just simplify the logic.
We also mark the method as deprecated since it serves no purpose.
Change-Id: I94610d942cb75cad495efd8cf799c1a275a21751
Reviewed-on: https://go-review.googlesource.com/54434
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
https://golang.org/cl/37508 added an escape analysis test for #12397 to
escape2.go but missed to add it to escape2n.go. The comment at the top
of the former states that the latter should contain all the same tests
and the tests only differ in using -N to compile. Conform to this by
adding the function issue12397 to escape2n.go as well.
Also fix a whitespace difference in escape2.go, so the two files match
exactly (except for the comment at the top).
Change-Id: I3a09cf95169bf2150a25d6b4ec9e147265d36760
Reviewed-on: https://go-review.googlesource.com/54610
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
This computes the maximum possible waste in a size class due to both
internal and external fragmentation as a percent of the span size.
This parallels the reasoning about overhead in the comment at the top
of mksizeclasses.go and confirms that comment's assertion that (except
for the few smallest size classes), none of the size classes have
worst-case internal and external fragmentation simultaneously.
Change-Id: Idb66fe6c241d56f33d391831d4cd5a626955562b
Reviewed-on: https://go-review.googlesource.com/49370
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Ranging over a nil slice is a no-op, so guarding it with a nil check is
not useful.
Found with honnef.co/go/tools/cmd/staticcheck.
Change-Id: I6ce56bb6805809ca29349257f10fd69c30611643
Reviewed-on: https://go-review.googlesource.com/54131
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Before this CL, whenever the Go runtime wanted to kill its own
process with a signal dieFromSignal would reset the signal handler
to _SIG_DFL.
Unfortunately, if any signal handler were installed before the Go
runtime initialized, it wouldn't be invoked either.
Instead, use whatever signal handler was installed before
initialization.
The motivating use case is Crashlytics on Android. Before this CL,
Crashlytics would not consider a crash from a panic() since the
corresponding SIGABRT never reached its signal handler.
Updates #11382
Updates #20392 (perhaps even fixes it)
Fixes#19389
Change-Id: I0c8633329433b45cbb3b16571bea227e38e8be2e
Reviewed-on: https://go-review.googlesource.com/49590
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To avoid gigantic core dumps, the runtime avoids raising SIGABRT
on crashes on 64-bit Darwin systems. Mobile OS'es (probably) don't
generate huge core dumps, so to aid crash reporters, allow SIGABRT
on crashes on darwin/arm64.
Change-Id: I4a29608f400967d76f9bd0643fea22244c2da9df
Reviewed-on: https://go-review.googlesource.com/49770
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Probably went unnoticed because HTML normalizes multiple space
characters into one, unless you explicitly ask for them with .
Change-Id: I3f97b24a111da3f0f28894f1246388018beb084e
Reviewed-on: https://go-review.googlesource.com/54570
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
This reverts commit f0b3626904.
Reason for revert: this change caused the runtime tests on all linux/amd64 and linux/386 builders to timeout
Change-Id: Idf8cfdfc84540e21e8da403e74df5596a1d9327b
Reviewed-on: https://go-review.googlesource.com/54490
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Mostly node and position parameters that are no longer used.
Also remove an unnecessary node variable while at it.
Found with github.com/mvdan/unparam.
Change-Id: I88f9bd5d20bfc5b0f6f63ea81869daa246175061
Reviewed-on: https://go-review.googlesource.com/54130
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If we've already imported a named type, then there's no need to
process its associated methods except to validate that the signature
matches the existing known method.
However, the current import code still creates a new function node for
each method, saves its inline body (if any), and adds the node to the
global importlist. Because of this, the duplicate methods are never
garbage collected.
This CL changes the compiler to avoid amassing uncollectable garbage
or performing any unnecessary processing.
This is particularly noticeable for protobuf-heavy code. For the
motivating Go package, this CL reduced compile max-RSS from ~12GB to
~3GB and compile time from ~65s to ~50s.
Passes toolstash -cmp for std, cmd, and k8s.io/kubernetes/cmd/....
Change-Id: Ib53ba9f2ad3212995671cf6ba220ee8a56d8d009
Reviewed-on: https://go-review.googlesource.com/51331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Currently, the check for `ctx.Done() == context.Background().Done()`
comes before the check to see if we are ignoring any options. That
check should be done earlier, so that the options are not silently
ignored.
Fixes#21350
Change-Id: I3704e4209854c7d99f3f92498bae831cabc7e419
Reviewed-on: https://go-review.googlesource.com/53970
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The linux getrandom system call returns at most 33554431 = 2^25-1 bytes per
call. The existing behavior for larger reads is to report a failure, because
there appears to have been an unexpected short read. In this case the system
falls back to reading from "/dev/urandom".
This change performs reads of 2^25 bytes or more with multiple calls to
getrandom.
Fixes#20877
Change-Id: I618855bdedafd86cd11219fe453af1d6fa2c88a7
Reviewed-on: https://go-review.googlesource.com/49170
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current modInverse implementation allocates a big.Int
for the second parameter of GCD, while only the first is needed.
This is unnecessary and can lead to a speed up for optimizations
of GCD where the second parameter is not calculated at all.
Change-Id: I3f042e140ff643311bc3d0b8d192992d4d2c4c70
Reviewed-on: https://go-review.googlesource.com/50531
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filosottile.wiki@gmail.com>
Reviewed-by: Adam Langley <agl@golang.org>
Now that issue #12438 is resolved, this TODO can be completed.
Create a logf helper, which is similar to Server.logf method,
but takes a *Request to infer the *Server and its ErrorLog from.
Update documentation of Server.ErrorLog to mention a new type
of errors that may be logged to it.
Also update a statement in documentation of Server.ErrorLog from:
// If nil, logging goes to os.Stderr via the log package's
// standard logger.
To:
// If nil, logging is done via the log package's standard logger.
The motivation for doing so is to avoid making inaccurate claims.
Logging may not go to os.Stderr if anyone overrides the log package's
default output via https://godoc.org/log#SetOutput. Saying that
the standard logger is used should be sufficient to explain the
behavior, and users can infer that os.Stderr is used by default,
unless it's changed.
Updates #12438.
Change-Id: I3a4b0db51d652fd25fb2065fbc2157a3dec4dd38
Reviewed-on: https://go-review.googlesource.com/53950
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change enables buildmode c-shared on ppc64le.
A bug was fixed in runtime/rt0_linux_ppc64le.s that was necessary to
make this work. In _rt0_ppc64le_linux_lib, there is code to store
the value of r2 onto the caller's stack. However, if this file
is compiled using a build mode that maintains the TOC address in
r2, then instructions will be inserted at the beginning of this
function to generate the r2 value for the callee, not the caller.
That means the r2 value for the callee is stored onto the caller's
stack. If caller and callee don't have the same r2 values, then
the caller will restore the wrong r2 value after it returns. This
situation can happen when using dlopen since the caller of this
function will be in ld64.so and will definitely have a different
TOC.
Updates #20756
Change-Id: I6e165e0d0716e73721bbbcc520e8302e4856e3ba
Reviewed-on: https://go-review.googlesource.com/53890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We use lock-free reads from mheap.spans, but the safety of these is
somewhat subtle. Document this.
Change-Id: I928c893232176135308e38bed788d5f84ff11533
Reviewed-on: https://go-review.googlesource.com/54310
Reviewed-by: Rick Hudson <rlh@golang.org>
When If-Range does not match and the requested resource is
available, server should return a "200 OK" response to client.
Currently server returns "200 OK" when the request method is
GET, but "206 Partial Content" when method is HEAD.
This change fixed this inconsistency.
Change-Id: I5ad979919f4f089baba54a4445b70ca38471a906
Reviewed-on: https://go-review.googlesource.com/54110
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
Add test cases to verify behavior for Ldexp with exponents outside the
range of Minint32/Maxint32, for a gccgo bug.
Test for issue #21323.
Change-Id: Iea67bc6fcfafdfddf515cf7075bdac59360c277a
Reviewed-on: https://go-review.googlesource.com/54230
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
SkipNow and FailNow must be called from the goroutine running the
test. This is already documented, but it's easy to call them by
mistake when writing subtests. In the following:
func TestPanic(t *testing.T) {
t.Run("", func(t2 *testing.T) {
t.FailNow() // BAD: should be t2.FailNow()
})
}
the FailNow call on the outer t *testing.T correctly triggers a panic
panic: test executed panic(nil) or runtime.Goexit
The error message confuses users (see issues #17421, #21175) because
there is no way to trace back the relevant part of the message ("test
executed ... runtime.Goexit") to a bad FailNow call without checking
the testing package source code and finding out that FailNow calls
runtime.Goexit.
To help users debug the panic message, mention in the SkipNow and
FailNow documentation that they stop execution by calling
runtime.Goexit.
Fixes#21175
Change-Id: I0a3e5f768e72b464474380cfffbf2b67396ac1b5
Reviewed-on: https://go-review.googlesource.com/52770
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Functions XORKeyStream should panic if len(dst) < len(src), but it
write to dst before bounds checking. In asm routines and fastXORBytes,
this is an out of bounds write.
Fixes#21104
Change-Id: I354346cda8d63910f3bb619416ffd54cd0a04a0b
Reviewed-on: https://go-review.googlesource.com/52050
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Otherwise, vet might have false positives when "C" is a variable and
we're just using a method on it. Or when an import was renamed to "C".
Add test files for both of these cases.
Fixes#20655.
Change-Id: I55fb93119444a67fcf7891ad92653678cbd4670e
Reviewed-on: https://go-review.googlesource.com/45551
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
These rules trigger a few times during make.bash.
When we eliminate boundedness checks from walk.go
we'll rely on them more heavily.
Updates #19692
Change-Id: I268c36ae2f1401c68dd685b15f2d30f5d6971176
Reviewed-on: https://go-review.googlesource.com/43775
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
gc.Sysfunc must not be called concurrently.
We set up runtime routines used by the backend
prior to doing any backend compilation.
I missed the 387 ones; fix that.
Sysfunc should have been unexported during 1.9.
I will rectify that in a subsequent CL.
Fixes#21352
Change-Id: I8386eaa1e05879c25c672b9c9fc693c938e9aeb6
Reviewed-on: https://go-review.googlesource.com/54090
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The standard deviation of a uniform distribution is size / √12.
The size of the interval [0, 255] is 256, not 255.
While we're here, simplify the expression.
The tests previously passed only because the error margin was large enough.
Sample observed standard deviations while running tests:
73.7893634666819
73.9221651548294
73.8077961697150
73.9084236069471
73.8968446814785
73.8684209136244
73.9774618960282
73.9523483202549
255 / √12 == 73.6121593216772
256 / √12 == 73.9008344562721
Change-Id: I7bc6cdc11e5d098951f2f2133036f62489275979
Reviewed-on: https://go-review.googlesource.com/51310
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The compiler is now smart enough not to insert a bounds check.
Not only is this simpler, it eliminates a LEAQ from the
generated code.
Change-Id: Ie90cbd11584542edd99edd5456d9b02c406e8063
Reviewed-on: https://go-review.googlesource.com/53892
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Regular HTTP is insecure, oeis.org supports HTTPS and it is actually
used in some other places in the codebase. This changes these final urls
to use HTTPS.
Change-Id: Ia46410a9c7ce67238a10cb6bfffaceca46112f58
Reviewed-on: https://go-review.googlesource.com/52072
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Looking up a nonexistent CNAME record on an existing
domain on Plan 9 can return either a "dns failure"
error or a "resource does not exist" error.
Fixes#21335.
Change-Id: Iead8ed4fe3167db06adb4ab7797c52c7efc3ff89
Reviewed-on: https://go-review.googlesource.com/53670
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Avelino <t@avelino.xxx>
The only non test user of the assembler prefetch functions is the
heapBits.prefetch function which is itself unused.
The runtime prefetch functions have no functionality on most platforms
and are not inlineable since they are written in assembler. The function
call overhead eliminates the performance gains that could be achieved with
prefetching and would degrade performance for platforms where the functions
are no-ops.
If prefetch functions are needed back again later they can be improved
by avoiding the function call overhead and implementing them as intrinsics.
Change-Id: I52c553cf3607ffe09f0441c6e7a0a818cb21117d
Reviewed-on: https://go-review.googlesource.com/44370
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Setting the Content-Type header explicitly allows browsers to know what
the type of the content is. Otherwise, they have to guess the type from
the content itself, which could lead to unpredictable behavior, and
increases CPU usage.
Not setting the Content-Type despite writing a body may also trigger
unwanted warnings in user middleware, and make it more difficult to
resolve valid issues where the user forgets to set Content-Type in
some situations where it should be set.
There is some precedent for doing this in http.FileServer, which
sets "Content-Type" to "text/html; charset=utf-8" before writing
<pre><a href=...></a></pre> HTML.
Change-Id: I24286827bebf4da8adee9238b8c5a94d4069c8db
Reviewed-on: https://go-review.googlesource.com/50510
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change fixes the remaining examples where the raw strings had
suboptimal indentation (one level too many) when viewed in godoc.
Follows CL 48910.
Fixes#21026.
Change-Id: Ifc0dae3fa899a9fff8b1ff958414e2fe6852321d
Reviewed-on: https://go-review.googlesource.com/50990
Run-TryBot: Dmitri Shuralyov <shurcool@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CommandLine (exported in Go 1.2) has default output of os.Stderr.
Before it was exported, it made sense to have the global Usage func
(the implicit usage func if CommandLine.Usage is nil) hard-code
os.Stderr has its output. But once CommandLine was exported, Usage
should use it if provided.
Fixes#20998
Change-Id: I9e1c0415a563a982634b9808199c9ee175d72f4c
Reviewed-on: https://go-review.googlesource.com/48390
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Manual hyphenation doesn't work well when text gets reflown,
for example by godoc.
There are a few other manual hyphenations in the tree,
but they are in local comments or comments for unexported functions.
Change-Id: I17c9b1fee1def650da48903b3aae2fa1e1119a65
Reviewed-on: https://go-review.googlesource.com/53510
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The activeModules function is called by the cgo pointer checking code,
which is called by the write barrier (when GODEBUG=cgocheck=2), and as
such must be nosplit/nowritebarrier.
Fixes#21306
Change-Id: I57f2124f14de7f3872b2de9532abab15df95d45a
Reviewed-on: https://go-review.googlesource.com/53352
Reviewed-by: Austin Clements <austin@google.com>
Some editors can filter the autocompletion suggestions based on
whether the code will compile once autocompleted. Explain this
feature with better wording.
Change-Id: I29e4b0396878f18c79208915402c0a209a813b04
Reviewed-on: https://go-review.googlesource.com/53355
Reviewed-by: Florin Patan <florinpatan@gmail.com>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
/blog redirects to blog.golang.org (currently blocked in China)
unless there is a local checkout of golang.org/x/blog, which is
not possible on App Engine Classic.
Change-Id: Ia695e663c9bebcc6c3bedea324c630299eaad4dc
Reviewed-on: https://go-review.googlesource.com/53051
Reviewed-by: Chris Broadfoot <cbro@golang.org>
The vet tool only reports a type checking error when invoked with -v.
Don't let that by itself cause vet to exit with an error exit status.
Updates #21188
Change-Id: I172c13d46c35d49e229e96e833683d8c82a77de7
Reviewed-on: https://go-review.googlesource.com/52851
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
In the case where requests are coming from mainland China, hide
links to locations that are blocked and functionality that is
not permitted.
Additionally, some very small cleanup of the JS.
This change requires https://go-review.googlesource.com/c/52873
Change-Id: I7fc68748e629dbe5b966d6bf117e7f7b546966eb
Reviewed-on: https://go-review.googlesource.com/52872
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Check not only that a tsan program can be built, but also that it runs.
This fails with some installations of GCC 7.
Skip the tsan10 program when using GCC, as it reportedly hangs.
This is a patch to help people build 1.9; we may be able to do a
better fix for 1.10.
Updates #21196
Change-Id: Icd1ffbd018dc65a97ff45cab1264b9b0c7fa0ab2
Reviewed-on: https://go-review.googlesource.com/52790
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The testZoneAbbr assumes that
Parse(RFC1123, t1.Format(RFC1123))
will always succeed. This is not true because Format will fall back to
the numeric zone (ex. -07) for timezones with no abbreviation, but
Parse won't accept the numeric zone when the layout specifies 'MST'
(an abbreviation).
Skip the zone abbreviation test in timezones with no abbreviation.
Fixes#21183
Change-Id: If04691cc23ae1075d8a953733024e17f5a7646de
Reviewed-on: https://go-review.googlesource.com/52430
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For address of an auto or arg, on all non-x86 architectures
the assembler backend encodes the actual SP offset in the
instruction but leaves the offset in Prog unchanged. When the
assembly is printed in compile -S, it shows an offset
relative to pseudo FP/SP with an actual hardware SP base
register (e.g. R13 on ARM). This is confusing. Unset the
base register if it is indeed SP, so the assembly output is
consistent. If the base register isn't SP, it should be an
error and the error output contains the actual base register.
For address loading instructions, the base register isn't set
in the compiler on non-x86 architectures. Set it. Normally it
is SP and will be unset in the change mentioned above for
printing. If it is not, it will be an error and the error
output contains the actual base register.
No change in generated binary, only printed assembly. Passes
"go build -a -toolexec 'toolstash -cmp' std cmd" on all
architectures.
Fixes#21064.
Change-Id: Ifafe8d5f9b437efbe824b63b3cbc2f5f6cdc1fd5
Reviewed-on: https://go-review.googlesource.com/49432
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
We lazily map the bitmap and spans areas as the heap grows. However,
right now we're very slightly too lazy. Specifically, the following
can happen on 32-bit:
1. mallocinit fails to allocate any heap arena, so
arena_used == arena_alloc == arena_end == bitmap.
2. There's less than 256MB between the end of the bitmap mapping and
the next mapping.
3. On the first allocation, mheap.sysAlloc sees that there's not
enough room in [arena_alloc, arena_end) because there's no room at
all. It gets a 256MB mapping from somewhere *lower* in the address
space than arena_used and sets arena_alloc and arena_end to this
hole.
4. Since the new arena_alloc is lower than arena_used, mheap.sysAlloc
doesn't bother to call mheap.setArenaUsed, so we still don't have a
bitmap mapping or a spans array mapping.
5. mheap.grow, which called mheap.sysAlloc, attempts to fill in the
spans array and crashes.
Fix this by mapping the metadata regions for the initial arena_used
when the heap is initialized, rather than trying to wait for an
allocation. This maintains the intended invariant that the structures
are always mapped for [arena_start, arena_used).
Fixes#21044.
Change-Id: I4422375a6e234b9f979d22135fc63ae3395946b0
Reviewed-on: https://go-review.googlesource.com/51714
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Right now, if it's possible to grow the arena reservation but
mheap.sysAlloc fails to get 256MB more of memory, it simply fails.
However, on 32-bit we have a fallback path that uses much smaller
mmaps that could take in this situation, but fail to.
This commit fixes mheap.sysAlloc to use a common failure path in case
it can't grow the reservation. On 32-bit, this path includes the
fallback.
Ideally, mheap.sysAlloc would attempt smaller reservation growths
first, but taking the fallback path is a simple change for Go 1.9.
Updates #21044 (fixes one of two issues).
Change-Id: I1e0035ffba986c3551479d5742809e43da5e7c73
Reviewed-on: https://go-review.googlesource.com/51713
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Debuggers use DWARF information to find local variables on the
stack and in registers. Prior to this CL, the DWARF information for
functions claimed that all variables were on the stack at all times.
That's incorrect when optimizations are enabled, and results in
debuggers showing data that is out of date or complete gibberish.
After this CL, the compiler is capable of representing variable
locations more accurately, and attempts to do so. Due to limitations of
the SSA backend, it's not possible to be completely correct.
There are a number of problems in the current design. One of the easier
to understand is that variable names currently must be attached to an
SSA value, but not all assignments in the source code actually result
in machine code. For example:
type myint int
var a int
b := myint(int)
and
b := (*uint64)(unsafe.Pointer(a))
don't generate machine code because the underlying representation is the
same, so the correct value of b will not be set when the user would
expect.
Generating the more precise debug information is behind a flag,
dwarflocationlists. Because of the issues described above, setting the
flag may not make the debugging experience much better, and may actually
make it worse in cases where the variable actually is on the stack and
the more complicated analysis doesn't realize it.
A number of changes are included:
- Add a new pseudo-instruction, RegKill, which indicates that the value
in the register has been clobbered.
- Adjust regalloc to emit RegKills in the right places. Significantly,
this means that phis are mixed with StoreReg and RegKills after
regalloc.
- Track variable decomposition in ssa.LocalSlots.
- After the SSA backend is done, analyze the result and build location
lists for each LocalSlot.
- After assembly is done, update the location lists with the assembled
PC offsets, recompose variables, and build DWARF location lists. Emit the
list as a new linker symbol, one per function.
- In the linker, aggregate the location lists into a .debug_loc section.
TODO:
- currently disabled for non-X86/AMD64 because there are no data tables.
go build -toolexec 'toolstash -cmp' -a std succeeds.
With -dwarflocationlists false:
before: f02812195637909ff675782c0b46836a8ff01976
after: 06f61e8112a42ac34fb80e0c818b3cdb84a5e7ec
benchstat -geomean /tmp/220352263 /tmp/621364410
completed 15 of 15, estimated time remaining 0s (eta 3:52PM)
name old time/op new time/op delta
Template 199ms ± 3% 198ms ± 2% ~ (p=0.400 n=15+14)
Unicode 96.6ms ± 5% 96.4ms ± 5% ~ (p=0.838 n=15+15)
GoTypes 653ms ± 2% 647ms ± 2% ~ (p=0.102 n=15+14)
Flate 133ms ± 6% 129ms ± 3% -2.62% (p=0.041 n=15+15)
GoParser 164ms ± 5% 159ms ± 3% -3.05% (p=0.000 n=15+15)
Reflect 428ms ± 4% 422ms ± 3% ~ (p=0.156 n=15+13)
Tar 123ms ±10% 124ms ± 8% ~ (p=0.461 n=15+15)
XML 228ms ± 3% 224ms ± 3% -1.57% (p=0.045 n=15+15)
[Geo mean] 206ms 377ms +82.86%
name old user-time/op new user-time/op delta
Template 292ms ±10% 301ms ±12% ~ (p=0.189 n=15+15)
Unicode 166ms ±37% 158ms ±14% ~ (p=0.418 n=15+14)
GoTypes 962ms ± 6% 963ms ± 7% ~ (p=0.976 n=15+15)
Flate 207ms ±19% 200ms ±14% ~ (p=0.345 n=14+15)
GoParser 246ms ±22% 240ms ±15% ~ (p=0.587 n=15+15)
Reflect 611ms ±13% 587ms ±14% ~ (p=0.085 n=15+13)
Tar 211ms ±12% 217ms ±14% ~ (p=0.355 n=14+15)
XML 335ms ±15% 320ms ±18% ~ (p=0.169 n=15+15)
[Geo mean] 317ms 583ms +83.72%
name old alloc/op new alloc/op delta
Template 40.2MB ± 0% 40.2MB ± 0% -0.15% (p=0.000 n=14+15)
Unicode 29.2MB ± 0% 29.3MB ± 0% ~ (p=0.624 n=15+15)
GoTypes 114MB ± 0% 114MB ± 0% -0.15% (p=0.000 n=15+14)
Flate 25.7MB ± 0% 25.6MB ± 0% -0.18% (p=0.000 n=13+15)
GoParser 32.2MB ± 0% 32.2MB ± 0% -0.14% (p=0.003 n=15+15)
Reflect 77.8MB ± 0% 77.9MB ± 0% ~ (p=0.061 n=15+15)
Tar 27.1MB ± 0% 27.0MB ± 0% -0.11% (p=0.029 n=15+15)
XML 42.7MB ± 0% 42.5MB ± 0% -0.29% (p=0.000 n=15+15)
[Geo mean] 42.1MB 75.0MB +78.05%
name old allocs/op new allocs/op delta
Template 402k ± 1% 398k ± 0% -0.91% (p=0.000 n=15+15)
Unicode 344k ± 1% 344k ± 0% ~ (p=0.715 n=15+14)
GoTypes 1.18M ± 0% 1.17M ± 0% -0.91% (p=0.000 n=15+14)
Flate 243k ± 0% 240k ± 1% -1.05% (p=0.000 n=13+15)
GoParser 327k ± 1% 324k ± 1% -0.96% (p=0.000 n=15+15)
Reflect 984k ± 1% 982k ± 0% ~ (p=0.050 n=15+15)
Tar 261k ± 1% 259k ± 1% -0.77% (p=0.000 n=15+15)
XML 411k ± 0% 404k ± 1% -1.55% (p=0.000 n=15+15)
[Geo mean] 439k 755k +72.01%
name old text-bytes new text-bytes delta
HelloSize 694kB ± 0% 694kB ± 0% -0.00% (p=0.000 n=15+15)
name old data-bytes new data-bytes delta
HelloSize 5.55kB ± 0% 5.55kB ± 0% ~ (all equal)
name old bss-bytes new bss-bytes delta
HelloSize 133kB ± 0% 133kB ± 0% ~ (all equal)
name old exe-bytes new exe-bytes delta
HelloSize 1.04MB ± 0% 1.04MB ± 0% ~ (all equal)
Change-Id: I991fc553ef175db46bb23b2128317bbd48de70d8
Reviewed-on: https://go-review.googlesource.com/41770
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The linker is pretty good at combining a bunch of symbols into a
section, so let it do .debug_ranges the normal way. Along the way,
remove a bunch of globals that were only used by one function that would
only be called once per invocation.
Change-Id: I1a528a438b193c41e7c444e8830516b07f11affc
Reviewed-on: https://go-review.googlesource.com/43890
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When the compiler decomposes a user variable, track its origin so that
it can be recomposed during DWARF generation.
Change-Id: Ia71c7f8e7f4d65f0652f1c97b0dda5d9cad41936
Reviewed-on: https://go-review.googlesource.com/50878
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
64bit atomics on mips/mipsle are implemented using spinlocks. If SIGPROF
is received while the program is in the critical section, it will try to
write the sample using the same spinlock, creating a deadloop.
Prevent it by creating a counter of SIGPROFs during atomic64 and
postpone writing the sample(s) until called from elsewhere, with
pc set to _LostSIGPROFDuringAtomic64.
Added a test case, per Cherry's suggestion. Works around #20146.
Change-Id: Icff504180bae4ee83d78b19c0d9d6a80097087f9
Reviewed-on: https://go-review.googlesource.com/42652
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fix an oversight in decompose that caused floats to be missing from the
Names list.
Change-Id: I5db9c9498e9a4421742389eb929752fdac873b38
Reviewed-on: https://go-review.googlesource.com/50877
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When we start tracking the mapping from Value to Prog, valueProgs will
be confusing. Disambiguate.
Change-Id: Ib3b302fedb7eb0ff1bde789d70a11656d82f0897
Reviewed-on: https://go-review.googlesource.com/50876
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
After we track decomposition, offset could mean stack offset or offset
in recomposed variable. Disambiguate.
Change-Id: I4d810b8c0dcac7a4ec25ac1e52898f55477025df
Reviewed-on: https://go-review.googlesource.com/50875
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
It is possible to have an unexported name with a nil package,
for an embedded field whose type is a pointer to an unexported type.
We must encode that fact in the type..namedata symbol name,
to avoid incorrectly merging an unexported name with an exported name.
Fixes#21120
Change-Id: I2e3879d77fa15c05ad92e0bf8e55f74082db5111
Reviewed-on: https://go-review.googlesource.com/50710
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This avoids an error from clang when using -nopie during compilation,
and permits us to check that the entire build succeeds.
Updates #21042
Change-Id: I2e6c7d5c97a85c223ed3288622bbb58ce33b8774
Reviewed-on: https://go-review.googlesource.com/50874
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
https://golang.org/cl/33773 fixes the JSON marshaler to avoid serializing
embedded fields on unexported types of non-struct types. However, Go allows
embedding pointer to types, so the check for whether the field is a non-struct
type must first dereference the pointer to get at the underlying type.
Furthermore, due to a edge-case in the behavior of StructField.PkgPath not
being a reliable indicator of whether the field is unexported (see #21122),
we use our own logic to determine whether the field is exported or not.
The logic in this CL may be simplified depending on what happens in #21122.
Fixes#21121
Updates #21122
Change-Id: I8dfd1cdfac8a87950df294a566fb96dfd04fd749
Reviewed-on: https://go-review.googlesource.com/50711
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
From Josh's comments on https://golang.org/cl/50310
Once I removed the "from the Go standard library" bit, the beginning
wasn't worth keeping. It also wasn't clear whether what it meant by
"cache contention". Processor caches, or user-level caches built with
sync.Map? It didn't seem worth clarifying and didn't convey any useful
information, so deleted.
Change-Id: Id1d76105a3081d0855f6a64540700932bb83d98e
Reviewed-on: https://go-review.googlesource.com/50632
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
We can make it panic with a more explicit and readable error message
during Go 1.10, but document it for now. This has always been the
case; it's not a new rule.
Updates #20933
Change-Id: I53c1fefb47a8f4aae0bb32fa742afa3a2ed20e8a
Reviewed-on: https://go-review.googlesource.com/50634
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
In CL https://golang.org/cl/4893043 (6 years ago), a new package named
"url" was created (it is currently known as "net/url"). During that
change, some identifier name collisions were introduced, and two
parameters in net/http were renamed to "urlStr".
Since that time, Go has continued to put high emphasis on the quality
and readability of the documentation. Sometimes, that means making small
sacrifices in the implementation details of a package to ensure that
the godoc reads better, since that's what the majority of users interact
with. See https://golang.org/s/style#named-result-parameters:
> Clarity of docs is always more important than saving a line or two
> in your function.
I think the "urlStr" parameter name is suboptimal for godoc purposes,
and just "url" would be better.
During the review of https://golang.org/cl/4893043, it was also noted
by @rsc that having to rename parameters named "url" was suboptimal:
> It's unfortunate that naming the package url means
> you can't have a parameter or variable named url.
However, at the time, the name of the url package was still being
decided, and uri was an alternative name under consideration.
The reason urlStr was chosen is because it was a lesser evil
compared to naming the url package uri instead:
> Let's not get hung up on URI vs. URL, but I'd like s/uri/urlStr/ even for just
> that the "i" in "uri" looks very similar to the "l" in "url" in many fonts.
> Please let's go with urlStr instead of uri.
Now that we have the Go 1 compatibility guarantee, the name of the
net/url package is fixed. However, it's possible to improve the
signature of Redirect, NewRequest functions in net/http package
for godoc purposes by creating a package global alias to url.Parse,
and renaming urlStr parameter to url in the exported funcs. This CL
does so.
Updates #21077.
Change-Id: Ibcc10e3825863a663e6ad91b6eb47b1862a299a6
Reviewed-on: https://go-review.googlesource.com/49930
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The runtime tests may be invoked from a parent that has SIGQUIT
blocked. For example, Java invokes subprocesses this way. In this
situation, TestCrashDumpsAllThreads and TestPanicSystemstack will fail
because they depend on SIGQUIT to get tracebacks, and any subprocess
test that times out will fail to kill the subprocess.
Fix this by detecting if SIGQUIT is blocked and, if so, skipping tests
that depend on it and using SIGKILL to kill timed-out subprocesses.
Based on a fix by Carl Henrik Lunde in
https://golang.org/issue/19196#issuecomment-316145733Fixes#19196.
Change-Id: Ia20bf15b96086487d0ef6b75239dcc260c21714c
Reviewed-on: https://go-review.googlesource.com/50330
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we are using vfork, and if something (such as TSAN) is intercepting
the sigaction function, then we must call the system call, not the
libc function. Otherwise the intercepted sigaction call in the child
may trash the data structures in the parent.
Change-Id: Id9588bfeaa934f32c920bf829c5839be5cacf243
Reviewed-on: https://go-review.googlesource.com/50251
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
The Go ecosystem provides many tools to make Go
development more productive and seamless. Document
the availability of the editor plugins and IDEs,
add an overview of feature support and screencasts.
Updates #20398.
Updates #20402.
Updates #20399.
Updates #20401.
Updates #20569.
Change-Id: I0c6cb48eb4e3848807aaad78390493e14f097916
Reviewed-on: https://go-review.googlesource.com/45772
Reviewed-by: Steve Francia <spf@golang.org>
Currently we trace mark assists even if they're satisfied entirely by
stealing. This means even if background marking is keeping up with
allocation, we'll still emit a trace event every N bytes of
allocation. The event will be a few microseconds, if that, but they're
frequent enough that, when zoomed out in the trace view, it looks like
all of the time is spent in mark assists even if almost none is.
Change this so we only emit a trace event if the assist actually has
to do assisting. This makes the traces of these events far more
useful.
Change-Id: If4aed1c413b814341ef2fba61d2f10751d00451b
Reviewed-on: https://go-review.googlesource.com/50030
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Load/store-merging and move optimizations can result in unaligned
memory accesses. This is fine so long as the load/store instruction
used does not take a relative offset. In the SSA rules this means we
must not merge (MOVDaddr (SB)) ops into loads/stores unless we can
guarantee the alignment of the target.
Fixes#21048.
Change-Id: I70f13a62a148d5f0a56e704e8f76e36b4a4226d9
Reviewed-on: https://go-review.googlesource.com/49250
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
tSweepTerm and pauseStart are supposed to be when STW was triggered,
but right now they're captured a bit before STW. Move these down to
immediately before we trigger STW.
Fixes#19590.
Change-Id: Icd48a5c4d45c9b36187ff986e4f178b5064556c1
Reviewed-on: https://go-review.googlesource.com/49612
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, Windows stacks are either 128kB or 2MB depending on whether
the binary uses cgo. This is because we assume that Go system stacks
and the small amount of C code invoked by the standard library can
operate within smaller stacks, but general Windows C code assumes
larger stacks.
However, it's easy to call into arbitrary C code using the syscall
package on Windows without ever importing cgo into a binary. Such
binaries need larger system stacks even though they don't use cgo.
Fix this on 64-bit by increasing the system stack size to 2MB always.
This only costs address space, which is free enough on 64-bit to not
worry about. We keep (for now) the existing heuristic on 32-bit, where
address space comes at more of a premium.
Updates #20975.
Change-Id: Iaaaa9a2fcbadc825cddc797aaaea8d34ef8debf2
Reviewed-on: https://go-review.googlesource.com/49331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Framepointer is the default now. Only print an X: list
if the settings are _not_ the default.
Before:
$ go tool compile -V
compile version devel +a5f30d9508 Sun Jul 16 14:43:48 2017 -0400 X:framepointer
$ go1.8 tool compile -V
compile version go1.8 X:framepointer
$
After:
$ go tool compile -V
compile version devel +a5f30d9508 Sun Jul 16 14:43:48 2017 -0400
$ go1.9 tool compile -V # imagined
compile version go1.9
$
Perpetuates #18317.
Change-Id: I981ba5c62be32e650a166fc9740703122595639b
Reviewed-on: https://go-review.googlesource.com/49252
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Per note at top of doc, we don't use fixed-width spaces
in fixed-width phrases like "go doc".
Also ASN.1 NULL is not code so it's not <code> at all.
Change-Id: I791e4e6030b8b8d42f4621d2f4bf32fef93cf343
Reviewed-on: https://go-review.googlesource.com/47693
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing example for Decoder.Decode (Stream) had excessive
indentation in the godoc interface for the const jsonStream,
making it hard to read. This fixes the indentation in the
example_test.go to improve the readability in godoc.
Helps #21026.
Change-Id: I16f56b82182da1dcc73cca44e535a7f5695e975d
Reviewed-on: https://go-review.googlesource.com/48910
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a example for string.Compare that return the three possible results.
Change-Id: I103cf39327c1868fb249538d9e22b11865ba4b70
Reviewed-on: https://go-review.googlesource.com/49011
Reviewed-by: Heschi Kreinick <heschi@google.com>
While there's an example for SectionReader.Seek, if someone is
seeking documentation specifically about Seeker.Seek, they may
not immediately find the SectionReader example. Offset and whence
may not be entirely intuitive to new developers either, so include
examples of both positive/negative offsets and SeekStart/SeekEnd.
Change-Id: I5b7442ccf683d9706e9261c11bc0ea31a1ac21d4
Reviewed-on: https://go-review.googlesource.com/48873
Reviewed-by: Kevin Burke <kev@inburke.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing example for FileMode using Stat to get FileInfo.
But, Stat cannot get symlink info, it need to use Fstat instead.
Change-Id: I5cc38cd10caaa5912946abe2a2b90995a91ee10f
Reviewed-on: https://go-review.googlesource.com/47370
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Fails on iOS because CC_FOR_TARGET points to clangwrap.sh in the
original GOROOT. We could fix that but it doesn't seem worth it.
Fails on Android with "exec format error". I'm not sure why but I
doubt it is interesting.
Fails on Plan 9 because the original GOROOT is being preserved in some
unknown way. This is issue #21016.
Updates #21016
Change-Id: I4e7115d734fc7bf21e5a2ba18fb6ad0bfa31c735
Reviewed-on: https://go-review.googlesource.com/48650
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I just want to experience the whole Gerrit Flow, so I make this simple commit
as my first commit to golang src repo.
Change-Id: Ie744573beac7a8b9361f898fac269c9d88010493
Reviewed-on: https://go-review.googlesource.com/48630
Reviewed-by: Ma Peiqi <mapeiqi2017@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When StructOf is used with an anonymous field that has methods, and
that anonymous field is not the first field, the methods we generate
are incorrect because they do not offset to the field as required.
If we encounter that case, panic rather than doing the wrong thing.
Fixes#20824
Updates #15924
Change-Id: I3b0901ddbc6d58af5f7e84660b5e3085a431035d
Reviewed-on: https://go-review.googlesource.com/47035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current implementation ignores certificates that exist
in the login and System keychains.
This change adds the missing System and login keychain
files to the `/usr/bin/security` command in
`execSecurityRoots`. If the current user cannot be
obtained, the login keychain is ignored.
Refs #16532
Change-Id: I8594a6b8940c58df8a8015b274fa45c39e18862c
Reviewed-on: https://go-review.googlesource.com/36941
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The escaper contains information about which templates have already been
visited and escaped. This information is necessary to prevent templates
that have already been escaped from being over-escaped. However, since we
currently create a new escaper each time we execute a template, this
information does not persist across multiple template executions.
Fix this by saving an escaper in each template name space which is shared by
all templates in that name space.
While there, fix error message formatting for an escaping unit test.
Fixes#20842
Change-Id: Ie392c3e7ce0e0a9947bdf56c99e926e7c7db76e4
Reviewed-on: https://go-review.googlesource.com/47256
Reviewed-by: Mike Samuel <mikesamuel@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previous code failed to account for particular control flow
involving nested loops when updating phi function inputs.
Fix involves:
1) remove incorrect shortcut
2) generate a "better" order for children in dominator tree
3) note inner-loop updates and check before applying
outer-loop updates.
Fixes#20675.
Change-Id: I2fe21470604b5c259e777ad8b15de95f7706894d
Reviewed-on: https://go-review.googlesource.com/45791
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If we get an EAGAIN error on an unpollable file, don't try to wait for
it to be ready; just return EAGAIN.
It's possible that we should instead ensure that when Stdin is a pipe
in non-blocking mode, we wait for data to appear. For now take the
conservative approach of doing what we did in previous releases.
Based on https://golang.org/cl/47555 by Totoro W.
Fixes#20915
Change-Id: Icc9e97a5a877b0a3583ec056c35412d1afab62d1
Reviewed-on: https://go-review.googlesource.com/48490
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 44352 changed the behavior of SIGINT, which can break tests that
themselves use SIGINT. I think we can only implement this if the
testing package has a way to know whether the code under test is using
SIGINT, but os/signal does not provide an API for that. Roll back for
1.9 and think about this again for 1.10.
Updates #19397
Change-Id: I021c314db2b9d0a80d0088b120a6ade685459990
Reviewed-on: https://go-review.googlesource.com/48370
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It seems that when too much other code is running on the system,
the testprogcgo code can overrun its timeouts.
Updates #18598.
Not marking the issue as fixed until it doesn't recur for some time.
Change-Id: Ieaf106b41986fdda76b1d027bb9d5e3fb805cc3b
Reviewed-on: https://go-review.googlesource.com/48233
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
SysV semaphore undo lists should be shared by threads, just like
several other resources listed in cloneFlags. Currently we don't do
this, but it probably doesn't affect anything because 1) probably
nobody uses SysV semaphores from Go and 2) Go-created threads never
exit until the process does. Beyond being the right thing to do,
user-level QEMU requires this flag because it depends on glibc to
create new threads and glibc uses this flag.
Fixes#20763.
Change-Id: I1d1dafec53ed87e0f4d4d432b945e8e68bb72dcd
Reviewed-on: https://go-review.googlesource.com/48170
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To-be-released NetBSD 7.1.1 reportedly fixes the kernel panic that was
affecting our builders and is being released because of Go's warning.
So, soften our warning.
7.1.1 might work, but I can't get a builder up and running to verify
yet as it appears that Anita either doesn't support it yet, or the
NetBSD CDN doesn't have the files yet.
Change-Id: Ifaafc566879a6afdf1174e545ad10e240da427e8
Reviewed-on: https://go-review.googlesource.com/47970
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestStackGrowth is currently a parallel test. However, it depends on a
20 second timeout, which is already dubious in a parallel test, and
became really problematic on slow builders when runtime.GC switched to
triggering concurrent GC instead of STW GC. Before that change, the
test spent much of its time in STW GC, so it wasn't *really* parallel.
After that change, it was competing with all of the other parallel
tests and GC likely started taking ~4 times longer. On most builders
the whole test runs in well under a second, but on the slow builders
that was enough to push it over the 20 second timeout.
Fix this by making the test serial.
Updates #19381 (probably fixes it, but we'll have to wait and see).
Change-Id: I21af7cf543ab07f1ec1c930bfcb355b0df75672d
Reviewed-on: https://go-review.googlesource.com/48110
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Local variables can also be relied on the be 64-bit aligned, since
they will be escaped to the heap if used with any atomic operations.
Also, allocated arrays are also aligned, just like structs and slices.
Fixes#18955.
Change-Id: I8a1897f6ff78922c8bfcf20d6eb4bcb17a70ba2d
Reviewed-on: https://go-review.googlesource.com/48112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current description refers to the outermost "frame" which can be
misleading. A user reading it can think it means a stack frame.
Change-Id: Ie2c7cb4b4db8f41572df206478ce3b46a0245a5d
Reviewed-on: https://go-review.googlesource.com/47850
Reviewed-by: Austin Clements <austin@google.com>
ld.addpltsym adds an R_X86_64_JMP_SLOT dynamic relocation to .rela.plt
and uses Addaddrplus to reference the GOT in Elf64_Rela.r_offset.
Addaddrplus results in an R_ADDR relocation, which here we transform
into an R_X86_64_64 dynamic relocation. This is wrong for several
reasons:
1. .rela.plt is not a writable, relro section. It is mapped read-only,
causing the dynamic linker to segfault when it tried to handle the
relocation. This was the immediate cause of internal PIE cgo
crashes.
2. Relocations targetting other reloc sections are, as far as I can
tell, undefined behavior in the ELF spec and are unlikely to be a
good idea.
3. Even if the relocation did work, it isn't what we want. The
relocation, if successfully handled, would have put an absolute
address as the JMP_SLOT offset, but it should be the offset from the
beginning of the binary, just like any other relocation. What we want
is a statically resolved R_ADDR relocation, just as is used below for
the R_X86_64_64 relocation.
Skipping the .rela.plt allows reloc() to handle these R_ADDR
relocations.
With this CL, internal PIE cgo binaries work.
Updates #18968
Change-Id: Ie74e6fe249e88150baa0e340b1cb128cf7f28673
Reviewed-on: https://go-review.googlesource.com/47837
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On a slow or distracted machine, 0.1s is sometimes
not long enough for a non-blocking function call to complete.
This causes rare test flakes.
They can be easily reproduced by reducing the wait time to (say) 100ns.
For non-blocking functions, increase the window from 100ms to 10s.
Using different windows for block and non-blocking functions,
allows us to reduce the time for blocking functions.
The risk here is false negatives, but that risk is low;
this test is run repeatedly on many fast machines,
for which 10ms is ample time.
This reduces the time required to run the test by a factor of 10,
from ~1s to ~100ms.
Fixes#20299
Change-Id: Ice9a641a66c6c101d738a2ebe1bcb144ae3c9916
Reviewed-on: https://go-review.googlesource.com/47812
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, sysmon waits 60 ms during idle before relaxing. This is
primarily to avoid reducing the precision of short-duration timers. Of
course, if there are no short-duration timers, this wastes 60 ms
running the timer at high resolution.
Improve this by instead inspecting the time until the next timer fires
and relaxing the timer resolution immediately if the next timer won't
fire for a while.
Updates #20937.
Change-Id: If4ad0a565b65a9b3e8c4cdc2eff1486968c79f24
Reviewed-on: https://go-review.googlesource.com/47833
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, sysmon relaxes the Windows timer resolution as soon as the
Go process becomes idle. However, if it's going idle because of a
short sleep (< 15.6 ms), this can turn that short sleep into a long
sleep (15.6 ms).
To address this, wait for 60 ms of idleness before relaxing the timer
resolution. It would be better to check the time until the next wakeup
and relax immediately if it makes sense, but there's currently no
interaction between sysmon and the timer subsystem, so adding this
simple delay is a much simpler and safer change for late in the
release cycle.
Fixes#20937.
Change-Id: I817db24c3bdfa06dba04b7bc197cfd554363c379
Reviewed-on: https://go-review.googlesource.com/47832
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
R11 is callee-save in the C ABI, but the temporary register in the Go
ABI. Currently it's being clobbered by runtime.addmoduledata, which
has to follow the C ABI. The observed effect of this was that
dl_open_worker was returning to a bad PC because after it failed to
restore its SP because it was using R11 as a frame pointer.
Fix this by saving R11 around addmoduledata.
Fixes#19674.
Change-Id: Iaacbcc76809a3aa536e9897770831dcbcb6c8245
Reviewed-on: https://go-review.googlesource.com/47831
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A lot of code that uses runtime.Callers makes assumptions about the
result that are not true today under gccgo and will not be true in the
future in gc. This adds a section to the release notes discussing how
to correctly use runtime.Callers.
Change-Id: I96b7c7ef183cee2061442fc3501fceceefa54c09
Reviewed-on: https://go-review.googlesource.com/47691
Reviewed-by: Russ Cox <rsc@golang.org>
CL 47341 added support for decoding non-padded messages. But DecodedLen
still returned a multiple of 5 for messages without a padding, even
though it is possible to calculate the len exactly when using NoPadding.
This change makes DecodedLen return the exact number of bytes that
will be written. A change to the decoding logic is also made so that it
can handle this case.
DecodedLen now has the same behaviour as DecodedLen in encoding/base64.
Fixes#20854
Change-Id: I729e0b1c0946c866fb675c854f835f366dd4b5a4
Reviewed-on: https://go-review.googlesource.com/47710
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently only the rwmutex write lock prevents descheduling. The read
lock does not. This leads to the following situation:
1. A reader acquires the lock and gets descheduled.
2. GOMAXPROCS writers attempt to acquire the lock (or at least one
writer does, followed by readers). This blocks all of the Ps.
3. There is no 3. The descheduled reader never gets to run again
because there are no Ps, so it never releases the lock and the system
deadlocks.
Fix this by preventing descheduling while holding the read lock. This
requires also rewriting TestParallelRWMutexReaders to always create
enough GOMAXPROCS and to use non-blocking operations for
synchronization.
Fixes#20903.
Change-Id: Ibd460663a7e5a555be5490e13b2eaaa295fac39f
Reviewed-on: https://go-review.googlesource.com/47632
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
ResolveTCPAddr, ResolveUDPAddr, and ResolveIPAddr return at most one
address. When given a name like "golang.org" to resolve that might
have more than 1 address, the net package has historically preferred
IPv4 addresses, with the assumption that many users don't yet have
IPv6 connectivity and randomly selecting between an IPv4 address and
an IPv6 address at runtime wouldn't be a good experience for IPv4-only
users.
In CL 45088 (78cf0e56) I modified the resolution of the
unspecified/empty address to internally resolve to both IPv6 "::" and
0.0.0.0 to fix issue #18806.
That code has 3 other callers I hadn't considered, though: the
Resolve*Addr functions. Since they preferred IPv4, any Resolve*Addr of
"[::]:port" or "::" (for ResolveIPAddr) would internally resolve both
"::" and 0.0.0.0 and then prefer 0.0.0.0, even though the user was
looking up an IPv6 literal.
Add tests and fix it, not by undoing the fix to #18806 but by
selecting the preference function for Resolve*Addr more explicitly: we
still prefer IPv4, but if the address being looked up was an IPv6
literal, prefer IPv6.
The tests are skipped on machines without IPv6.
Fixes#20911
Change-Id: Ib7036cc43182ae4118cd1390c254e17c04a251a3
Reviewed-on: https://go-review.googlesource.com/47554
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The text before CL 45816 was:
-timeout t
If a test runs longer than t, panic.
The default is 10 minutes (10m).
CL 45816 was supposed to be about clarifying test vs test binary,
and it did add the clarification of referring to "duration d",
but it also introduced incorrect text about timeout 0.
The new text in this CL preserves the good change and
eliminates the incorrect one:
-timeout d
If a test binary runs longer than duration d, panic.
The default is 10 minutes (10m).
For #14780.
Change-Id: I4f79d6e48ed9295bc9f34a36aa90d3b03b40d7f5
Reviewed-on: https://go-review.googlesource.com/47571
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Following the spec clarification in CL 40393, copy that text
to reflect docs to state that the initial capacity of MakeMapWithSize
is a hint/approximate.
Fixes#19903
Change-Id: I6b3315b8183cafaa61fbb2839a4e42b76fd71544
Reviewed-on: https://go-review.googlesource.com/46270
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Go 1.9 beta 2 is already out.
It's too late to break code with a change like this.
This can be rolled forward for Go 1.10.
This reverts commit ae238688d2.
Change-Id: Ib67b8629e3deac5d50d76581aba6a91ca7a7853e
Reviewed-on: https://go-review.googlesource.com/47570
Reviewed-by: Russ Cox <rsc@golang.org>
mheap.allocLarge just calls bestFitTreap and is the only caller of
bestFitTreap. Flatten these into a single function. Also fix their
comments: allocLarge claims to return exactly npages but can in fact
return a larger span, and h.freelarge is not in fact indexed by span
start address.
Change-Id: Ia20112bdc46643a501ea82ea77c58596bc96f125
Reviewed-on: https://go-review.googlesource.com/47315
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The Server struct has exported fields, which allows users to manually
create a Server object without using using NewServer or NewTLSServer
and directly call Start or StartTLS on their object.
In order to ensure that manual creation of Server works, the
NewUnstartedServer function should not initialize Server in any way
that the user was not able to do themselves. For example, the setting
of a unexported filed, client, is not something a user can do.
Thus, rather than setting the client field in NewUnstartedServer,
we lazily initialize it when Start or StartTLS is called.
Otherwise, the Server logic can nil panic later when it assumes that this
field has been initialized.
Fixes#20871
Change-Id: I65c6a9f893ea963b0fbad0990b33af08007c1140
Reviewed-on: https://go-review.googlesource.com/47353
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Func type has allowed calling the Func.Name method on a nil pointer
since Go1.2, where it returned an empty string. A regression caused by
CL/37331 caused this behavior to change. This breaks code that lazily
does runtime.FuncForPC(myPtr).Name() without first checking that myPtr
is actually non-nil.
Fixes#20872
Change-Id: Iae9a2ebabca5e9d1f5a2cdaf2f30e9c6198fec4f
Reviewed-on: https://go-review.googlesource.com/47354
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Wrong instructions "MOVW 8(F0), R1" and "MOVW R0<<0(F1), R1"
are silently accepted, and all Fx are treated as Rx.
The patch checks all those illegal base registers.
fixes#20724
Change-Id: I05d41bb43fe774b023205163b7daf4a846e9dc88
Reviewed-on: https://go-review.googlesource.com/46132
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If a retryable error such as EAGAIN/EINTR is encountered during a call
to sendfile(), we should not assume that a partial write occurred.
Instead, just like any other platform, we should always try again even
if 0 bytes were written.
Fixes#20857
Change-Id: I9aa48d193c27c6794c550320da4d3f7544041f37
Reviewed-on: https://go-review.googlesource.com/47351
Run-TryBot: Shawn Walker-Salas <shawn.walker@oracle.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current code calculates register number incorrectly.
The fix corrects the register number calculation.
Add cases created by decoder to test assembler.
Fixes#20697Fixes#20723
Change-Id: I73ac153df9ea9f51c43a5104828d7a5389551c92
Reviewed-on: https://go-review.googlesource.com/45850
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Now that ReadMemStats is fast (CL 34937), CL 36791 is not so
necessary, and causes confusion. See #20863
This was already partially reverted in CL 46612 but missed two of the
spots.
Fixes#20863
Change-Id: I1307a0f7b1f9e86e8b6ceaa6a677f24f13431110
Reviewed-on: https://go-review.googlesource.com/47350
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Document that the byte value returned by ReadByte() is meaningless
if its error != nil. Because io.Reader and io.ByteReader are similar in
name, this CL aims to clear up any ambiguity surrounding the returned
values, particularly where io.Reader is allowed to return both a
non-zero number of valid bytes and err == EOF.
Fixes#20825
Change-Id: I3a23c18c80c471c0caae3b4d2f6f8e547da0bed9
Reviewed-on: https://go-review.googlesource.com/46950
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
FreeBSD 9.3.
Add Linux arm64. (required second line)
Clarify glibc requirement now that we have second line in notes.
OS X to macOS
Updates #20850
Change-Id: I684d464ed32a072081726b7c805a346c22c42f97
Reviewed-on: https://go-review.googlesource.com/47252
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apparently, "all such calls must happen" means that the t.Run call
must *return* before the outer test function returns, or the calls
will cause a data race on t.ran.
Clarify the docs.
Fixes#20339
Change-Id: I191a9af2a9095be1e0aaf10b79c30e00a9c495cb
Reviewed-on: https://go-review.googlesource.com/47150
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Apply code review suggestion from CL 46715.
The block is doing more than just checking len(r.certs) == len(tc.cns).
It also verifies that certificate common names match.
Change-Id: I28d6926a5da48bd8f6c80aa5e5a1ed6d4990f845
Reviewed-on: https://go-review.googlesource.com/47132
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
And some double space after period cleanup while I'm here.
I guess my previous regexps missed these. My next cleaner should
probably use go/ast instead of perl.
Updates #20221
Change-Id: Idb051e7ac3a7fb1fb86e015f709e32139d065d92
Reviewed-on: https://go-review.googlesource.com/47094
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Currently the execLock is a mutex, which has the unfortunate
side-effect of serializing all thread creation. This replaces it with
an rwmutex so threads can be created in parallel, but exec still
blocks thread creation.
Fixes#20738.
Change-Id: Ia8f30a92053c3d28af460b0da71176abe5fd074b
Reviewed-on: https://go-review.googlesource.com/47072
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently runtime.rwmutex is written to block the calling goroutine
rather than the calling thread. However, rwmutex was intended to be
used in the scheduler, which means it needs to be a thread-level
synchronization primitive.
Hence, this modifies rwmutex to synchronize threads instead of
goroutines. This has the consequence of making it write-barrier-free,
which is also important for using it in the scheduler.
The implementation makes three changes: it replaces the "w" semaphore
with a mutex, since this was all it was being used for anyway; it
replaces "writerSem" with a single pending M that parks on its note;
and it replaces "readerSem" with a list of Ms that park on their notes
plus a pass count that together emulate a counting semaphore. I
model-checked the safety and liveness of this implementation through
>1 billion schedules.
For #20738.
Change-Id: I3cf5a18c266a96a3f38165083812803510217787
Reviewed-on: https://go-review.googlesource.com/47071
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Prevent possible goroutine rescheduling to another P between
Put and Get calls by locking the goroutine to OS thread.
Inspired by the CL 42770.
Fixes#20198.
Change-Id: I18e24fcad1630658713e6b9d80d90d7941f604be
Reviewed-on: https://go-review.googlesource.com/44310
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
If the only way the user indicates they want alloc stats shown
is via ReportAllocs, we don't know that until benchFunc is run.
Therefore, StopTimer's ReadMemStats will return incorrect data
for single cycle runs since there's no counterpart ReadMemStats from
StartTimer that initializes alloc stats.
It appears that this bug was introduced by CL 46612,
"testing: only call ReadMemStats if necessary when benchmarking"
Fixes#20590
Change-Id: I3b5ef91677823f4b98011880a3be15423baf7e33
Reviewed-on: https://go-review.googlesource.com/46612
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test added for issue #18146 exposed a long-existing bug in the
Solaris port; notably, that syscall.Exec uses RawSyscall -- which is not
actually functional for the Solaris port (intentionally) and only exists
as a placebo to satisfy build requirements.
Call syscall.execve instead for Solaris.
Fixes#20832
Change-Id: I327d863f4bbbbbb6e5ecf66b82152c4030825d09
Reviewed-on: https://go-review.googlesource.com/47032
Run-TryBot: Shawn Walker-Salas <shawn.walker@oracle.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
os.Chmod returns an error when passed a long path (>=260) characters on
Windows. CL 32451 fixed most file functions in os. This change applies the
same fix to os.Chmod.
Fixes#20829
Change-Id: I3270db8317ce6e06e6d77070a32a5df6ab2491e0
Reviewed-on: https://go-review.googlesource.com/47010
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A common task is trying to get today's date in the local time zone
with zero values for the hour, minute, second, and nanosecond fields.
I tried this recently and incorrectly used Truncate(24*time.Hour),
which truncates based on a UTC clock, and gave me 5pm Pacific time
instead of midnight Pacific.
I thought it would be helpful to show a "correct" way to do this.
Change-Id: I479e6b0cc56367068530981ca69882b34febf945
Reviewed-on: https://go-review.googlesource.com/46833
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
t.Sub(u) would be -20 milliseconds.
The right computation is u.Sub(t), but rewrite to be even clearer.
Thanks to Karsten Weiss for catching this.
Change-Id: I6e274d69b0301840d57c5c65bf4114da0d33bf10
Reviewed-on: https://go-review.googlesource.com/46971
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this change, if the Writer needed to use the PAX format, it would
output a USTAR header with an empty name. This should be okay since the PAX
specification dictates that the PAX record for "path" should override the
semantic meaning of any of the old USTAR fields.
Unfortunately, the implementation of tar on OpenBSD 6.1 is too strict with
their handling of PAX files such that they check for the validity of this
bogus field even though the PAX header is present.
To allow Go's Writer output be parsible by OpenBSD's tar utility,
we write a best-effort (ASCII-only and truncated) version of the original
file name. Note that this still fails in some edge-cases (for example,
a Chinese filename containing all non-ASCII characters). OpenBSD should really
relax their checking, as you honestly can't always expect a sensible path
to be generated when USTAR cannot handle the original path.
Fixes#20707
Change-Id: Id7d77349023d2152d7291d582cd050b6681760e4
Reviewed-on: https://go-review.googlesource.com/46914
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
clang can emit some dwarf.VoidType which are wrapped by multiple
dwarf.TypedefType. We need to unwrap those before further processing.
Fixes#20129
Change-Id: I671ce6aef2dc7b55f1a02aec5f9789ac1b369643
Reviewed-on: https://go-review.googlesource.com/44772
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also reword the testing/quick.Config field docs to conform to the
normal subject-first style. Without that style, godoc links
/pkg/testing/quick/#Config.Rand to the wrong line, since it doesn't
recognize the preceding comment as necessarily being attached.
Fixes#20809
Change-Id: I9aebbf763eed9b1ab1a153fa11850d88a65571c6
Reviewed-on: https://go-review.googlesource.com/46910
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If the LHS is unassignable, there's no point in trying to make sure
the RHS can be assigned to it or making sure they're realizable
types. This is consistent with go/types.
In particular, this prevents "1 = 2" from causing a panic when "1"
still ends up with the type "untyped int", which is not realizable.
Fixes#20813.
Change-Id: I4710bdaac2e375ef12ec29b888b8ac84fb640e56
Reviewed-on: https://go-review.googlesource.com/46835
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Since Reader.Peek potentially reads from the underlying io.Reader,
discarding previous buffers, UnreadRune and UnreadByte cannot
necessarily work. Change Peek to invalidate the unread buffers in all
cases (as allowed according to the documentation) and thus prevent
hiding bugs in the caller.
Fixes#18556
Change-Id: I8d836db7ce31c4aaecb4f61c24573b0332bbf30d
Reviewed-on: https://go-review.googlesource.com/46850
Reviewed-by: Robert Griesemer <gri@golang.org>
Use 2 slashes, space, then tab. This is more consistent, and removes
inadvertent leading space.
Change-Id: I383770ed4eb8ac17c78c7ae5675b553d4fb70b1e
Reviewed-on: https://go-review.googlesource.com/46726
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This panic happens when the test fails due to the returned number of
certificates (r.certs) being less than expected by test case (tc.cns).
When i == len(r.certs) in the for loop, r.certs[i] will cause an index
out of range panic.
Also improve readability, consistency and style of the code. Use the
more common "got x, want y" pattern. See https://golang.org/s/style#useful-test-failures
for reference (and grep codebase for most common occurrences). Add a
comment, and remove blank line separating two blocks that are both
related to verifying that len(r.certs) == len(tc.cns). This should
help with readability.
Remove space after colon in call to t.Fatal, since it adds spaces
between its arguments.
Fixes#20801.
Change-Id: I40476103f1b5a0fa74b05637c250926b571c92fd
Reviewed-on: https://go-review.googlesource.com/46715
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
mutex profile requires explicit calls to
runtime.SetMutexProfileFraction to enable/disable
profiling (like block profile). It is worth
mentioning in the doc.
Change-Id: I2b8d654be9f5c6bc49fc802b7708c4c552fea9b2
Reviewed-on: https://go-review.googlesource.com/42070
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We used to do it sometimes as an optimization, but the optimization is
flawed: in all non-contrived cases we need to deep clone the map
anyway. So do it always, which both simplifies the code but also fixes
the X-Forward-For value leaking to the caller's Request, as well as
modifications from the optional Director func.
Fixes#18327
Change-Id: I0c86d10c557254bf99fdd988227dcb15f968770b
Reviewed-on: https://go-review.googlesource.com/46716
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When the dedicated mark worker runs, the scheduler won't run on that P
again until GC runs out of mark work. As a result, any goroutines in
that P's local run queue are stranded until another P steals them. In
a normally operating system this may take a long time, and in a 100%
busy system, the scheduler never attempts to steal from another P.
Fix this by draining the local run queue into the global run queue if
the dedicated mark worker has run for long enough. We don't do this
immediately upon scheduling the dedicated mark worker in order to
avoid destroying locality if the mark worker runs for a short time.
Instead, the scheduler delays draining the run queue until the mark
worker gets its first preemption request (and otherwise ignores the
preemption request).
Fixes#20011.
Change-Id: I13067194b2f062b8bdef25cb75e4143b7fb6bb73
Reviewed-on: https://go-review.googlesource.com/46610
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The existing implementation sequentially closes connection in the loop
and until the previous client connections is not closed the next one
would not be processed. Instead, the algorithm modified to spawn the
function that closes single connection in a standalone goroutine, thus
making at least a try to close it.
Change-Id: Ib96b5b477f841926450d122b67f14f1a2da36ee1
Reviewed-on: https://go-review.googlesource.com/33614
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When Stop is called on a channel, wait until all signals have been
delivered to the channel before returning.
Use atomic operations in sigqueue to communicate more reliably between
the os/signal goroutine and the signal handler.
Fixes#14571
Change-Id: I6c5a9eea1cff85e37a34dffe96f4bb2699e12c6e
Reviewed-on: https://go-review.googlesource.com/46003
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
If GOROOT_FINAL was set during the build, the default GOROOT
will not be testGOROOT. Determine the default GOROOT by reading
the right source file instead of guessing. (GOROOT_FINAL may no
longer be set when the test is actually run.)
Also refactor a bit.
Fixes#20284.
Change-Id: I2274595a235bee10c3f3a5ffecf4bb976f4d9982
Reviewed-on: https://go-review.googlesource.com/46428
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Maybe there are no Go files at all.
Maybe they are all excluded by build constraints.
Maybe there are only test Go files.
Be specific.
Fixes#17008.
Fixes parts of #20760.
Change-Id: If6ac82ba0ed437772e76e06763263747d3bc4f65
Reviewed-on: https://go-review.googlesource.com/46427
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We can't follow symlinks for fear of directory cycles and other problems,
but we can at least notice potentially-relevant symlinks that are being
ignored and report them.
Fixes#17662.
Change-Id: I1fce00bd5b80ea8df45dac8b61bfa08076ec5f4b
Reviewed-on: https://go-review.googlesource.com/46425
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We already detect this collision when both imports are used
anywhere in a single program. Also detect it when they are in
different targets being processed together.
Fixes#20264.
Change-Id: I5d3c822aae136053fbcb5ed167e1d67f9b847a0f
Reviewed-on: https://go-review.googlesource.com/46424
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
"MOVBS.U R0<<0(R1), R2" is assembled to 0xe19120d0 (ldrsb r2, [r1, r0]),
but it is expected to be 0xe11120d0 (ldrsb r2, [r1, -r0]).
This patch fixes it and adds more encoding tests.
fixes#20701
Change-Id: Ic1fb46438d71a978dbef06d97494a70c95fcbf3a
Reviewed-on: https://go-review.googlesource.com/45996
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
ascii85_test.go contains a variable called bigtest that is used as
test data for TestDecoderBuffering and TestEncoderBuffering. The
variable is initialised to a copy of the last element of the pairs
slice. When the variable was first added the last element of this
slice contained a sizable test case, 342 encoded characters. However,
https://golang.org/cl/5970078 added a new element to the end of the pairs
slice without updating bigtest. As the new element contained only 1 byte
of encoded data bigtest became very small test. This commit fixes the
problem by resetting bigtest to its original value and making its
initialisation independent of the layout of pairs. All the unit tests
still pass.
Change-Id: If7fb609ced9da93a2321dfd8372986b2fa772fd5
Reviewed-on: https://go-review.googlesource.com/46475
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current behavior is to filter out the non-main packages silently,
which is confusing if there are only non-main packages.
Instead, report an error unless it's used with a single main package.
To be clear, I don't really know what I'm doing.
It might be that multiple main packages are allowed, or even
that we do want the filtering, but all.bash passes with this change,
so I am taking that as a sign that we don't need that extra flexibility.
Fixes#15082.
Change-Id: I984d0f444a01c0ee0c3cd6646a75527ea99a9ebe
Reviewed-on: https://go-review.googlesource.com/46421
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change simplifies the documentation on methods of IPConn and adds
a reference to golang.org/x/net/ipv{4,6} packages to the documentation
on {Read,Write}MsgIP methods.
Change-Id: Ie07a853288940e0fef6a417ffc8d0c3d444c21cd
Reviewed-on: https://go-review.googlesource.com/44911
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change simplifies the documentation on methods of UDPConn and
adds a reference to golang.org/x/net/{ipv4,ipv6} packages to the
documentation on {Read,Write}MsgUDP methods.
Change-Id: I425a8d81bc46b6579aa9f89faa4982bb86b40f24
Reviewed-on: https://go-review.googlesource.com/44912
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes custom import path checks work even when the
custom import metadata directs checking out a subtree
of the subversion repository.
(Git and Mercurial allow no such thing, so they are unaffected.)
Fixes#20731.
Change-Id: I635f3a2037d69a87c6dac7b08b0a0d8266abd250
Reviewed-on: https://go-review.googlesource.com/46417
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds a reference to the Dial to clarify the parameters and
return values.
Change-Id: I611b9a79f4033ef035acd7098aea5965905d9a4c
Reviewed-on: https://go-review.googlesource.com/34880
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change clarifies the documentation on
Resolve{TCP,UDP,IP,Unix}Addr to avoid unnecessary confusion about how
the arguments are used to make end point addresses.
Also replaces "name" or "hostname" with "host name" when the term
implies the use of DNS.
Updates #17613.
Change-Id: Id6be87fe2e4666eecd5b92f18ad8b9a6c50a2bd6
Reviewed-on: https://go-review.googlesource.com/34879
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change clarifies the documentation on
Listen{TCP,UDP,MulticastUDP,IP,Unix,Unixgram} to avoid unnecessary
confusion about how the arguments for the connection setup functions
are used to make connections.
Change-Id: Ie269453ef49ec2db893391dc3ed2f7b641c14249
Reviewed-on: https://go-review.googlesource.com/34878
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change clarifies the documentation on Dial{TCP,UDP,IP,Unix} to
avoid unnecessary confusion about how the arguments for the connection
setup functions are used to make connections.
Change-Id: I2e378182948fbe221f6ae786ab55e77ae90c3f3b
Reviewed-on: https://go-review.googlesource.com/34877
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change clarifies the documentation on Listen and ListenPacket to
avoid unnecessary confusion about how the arguments for the connection
setup functions are used to make connections.
Also replaces "name" or "hostname" with "host name" when the term
implies the use of DNS.
Updates #17613.
Updates #17614.
Updates #17615.
Fixes#17616.
Updates #17738.
Updates #17956.
Change-Id: I0bad2e143207666f2358d397fc076548ee6c3ae9
Reviewed-on: https://go-review.googlesource.com/34876
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change clarifies the documentation on Dial and its variants to
avoid unnecessary confusion about how the arguments for the connection
setup functions are used to make connections.
Also replaces "name" or "hostname" with "host name" when the term
implies the use of DNS.
Updates #17613.
Fixes#17614.
Fixes#17738.
Fixes#17956.
Updates #18806.
Change-Id: I6adb3f2ae04a3bf83b96016ed73d8e59926f3e8a
Reviewed-on: https://go-review.googlesource.com/34875
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Loops of the form "for i,e := range" needed to have their
condition rotated to the "bottom" for the preemptible loops
GOEXPERIMENT, but this caused a performance regression
because it degraded bounds check removal. For now, make
the loop rotation/guarding conditional on the experiment.
Fixes#20711.
Updates #10958.
Change-Id: Icfba14cb3b13a910c349df8f84838cf4d9d20cf6
Reviewed-on: https://go-review.googlesource.com/46410
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Linux's execve has (at the time of writing, and since v2.6.30) a bug when it ran
concurrently with clone, in that it would fail to set up some datastructures if
the thread count before and after some steps differed. This is described better
and in more detail by Colin King in Launchpad¹ and kernel² bugs. When a program
written in Go runtime.Exec's a setuid binary, this issue may cause the resulting
process to not have the expected uid. This patch works around the issue by using
a mutex to serialize exec and clone.
1. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819
2. https://bugzilla.kernel.org/show_bug.cgi?id=195453Fixes#19546
Change-Id: I126e87d1d9ce3be5ea4ec9c7ffe13f92e087903d
Reviewed-on: https://go-review.googlesource.com/43713
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This certainly won't get inlined right now, but in the spirit of
making this more robust, we have to disable inlining because inlining
would defeat the purpose of separating forkAndExecInChild1 into a
separate function.
Updates #20732.
Change-Id: I736c3f909cc42c5f5783740c2e19ba4827c7c2ec
Reviewed-on: https://go-review.googlesource.com/46174
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, CLONE_VFORK is used without much regard to the stack. This
is dangerous, because anything the child does to the stack is visible
to the parent. For example, if the compiler were to reuse named stack
slots (which it currently doesn't do), it would be easy for the child
running in the same stack frame as the parent to corrupt local
variables that the parent then depended on. We're not sure of anything
specific going wrong in this code right now, but it is at best a
ticking time bomb.
CLONE_VFORK can only safely be used if we ensure the child does not
execute in any of the active stack frames of the parent. This commit
implements this by arranging for the parent to return immediately from
the frame the child will operate in, and for the child to never return
to the frame the parent will operate in.
Fixes#20732.
Change-Id: Iad5b4ddc2b994c082bd278bfd52ef53bd38c037f
Reviewed-on: https://go-review.googlesource.com/46173
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If you have BenchmarkX1 with sub-benchmark Y
and you have BenchmarkX2 with no sub-benchmarks,
then
go test -bench=X/Y
runs BenchmarkX1 once with b.N=1 (to find out about Y)
and then not again, because it has sub-benchmarks,
but arguably also because we're interested in Y.
In contrast, it runs BenchmarkX2 in full, even though clearly
that is not relevant to the match X/Y. We do have to run X2
once with b.N=1 to probe for having X2/Y, but we should not
run it with larger b.N.
Fixes#20589.
Change-Id: Ib86907e844f34dcaac6cd05757f57db1019201d0
Reviewed-on: https://go-review.googlesource.com/46031
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
This is a runtime version of sync.RWMutex that can be used by code in
the runtime package. The type is not quite the same, in that the zero
value is not valid.
For future use by CL 43713.
Updates #19546
Change-Id: I431eb3688add16ce1274dab97285f555b72735bf
Reviewed-on: https://go-review.googlesource.com/45991
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This doesn't change the existing restriction with disallows
spaces in import paths (as found in an import declaration).
It simply permits packages to be under a directory name that
may contain spaces.
Verified manually that it works. This could use a test, but the
change is trivial. We also can't use the existing test framework
(under test/) because the way those tests are run with test/run.go,
the mechanims for compiling a directory, even if it contains blanks
it its name, does't produce compiler paths with blanks
(the compilation is local).
Fixes#20306.
Change-Id: I6cbffb86c3394347897c3c94b110da0aadc5bfdf
Reviewed-on: https://go-review.googlesource.com/46001
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Make it clearer that -test=X/Y runs all the tests matching X,
even if they don't have sub-tests matching Y.
Fixes#20589.
Change-Id: Ic27e89e748d60f67b50c68445ec0480066bdf207
Reviewed-on: https://go-review.googlesource.com/46030
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The ascii85, base32 and base64 packages all contain a test called
TestDecoderBuffering. Each of these tests contain a loop that ignores
the error returned from the Read method of their decoders. The result
being that the tests loop for ever if the decoders actually return an
error. This commit fixes the issue by terminating the loops if an error
occurs and failing the tests with a suitable error message.
Change-Id: Idb385673cf9f3f6f8befe4288b4be366ab0985fd
Reviewed-on: https://go-review.googlesource.com/46010
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If an image has been cropped horizontally, writeImageBlock detects that
its width and Stride differ and acts accordingly.
However, if an image has been cropped vertically, trimming from the
bottom, the whole original image will be written in place. This results
in more data in the LZW stream than necessary, and many decoders
including image/gif's itself will fail to load.
Fixes#20692
Change-Id: Id332877e31bcf3729c89d8a50c1be0464028d82e
Reviewed-on: https://go-review.googlesource.com/45972
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
In some cases the netpoll code can cause a spurious wakeup. This is
normally harmless, as the woken up code simply retries the operation.
However, for connect, the test we were using to see whether the
connect had succeeded (setsockopt(SO_ERROR)) was not reliable in the
case of a spurious wakeup. Change to using a reliable test (getpeername).
On Darwin we used a different technique: a second call to connect;
change Darwin to use getpeername as well.
Return the result of getpeername to avoid having to call it twice.
Fixes#19289.
Change-Id: I119ec8e7a41f482f1e590d4c65a37f6103fa22d9
Reviewed-on: https://go-review.googlesource.com/45815
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Minimal reconstruction of reported failure case.
Manually verified that test fails with CL 45911 reverted.
Change-Id: Ia5d11500d91b46ba1eb5d841db3987edb9136c39
Reviewed-on: https://go-review.googlesource.com/45970
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The existing docs states that, get looks for a branch or tag
that matches the locally installed version of Go.
First, this is only working for "go1", so it could be confusing.
Second, "If no such version exists it retrieves the most recent
version of the package". It's more the default branch, by git defaults,
rather than most recent version.
This should address the potential unclear parts.
Fixes#20320
Change-Id: Id7d727d88dc350c9902974b64fa28c3766f7e245
Reviewed-on: https://go-review.googlesource.com/45890
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some of the _test.go files in the encoding packages contain a private
function called testEqual that calls testing.Errorf if the arguments
passed to it are unequal. The line numbers output by such calls to
Errorf identify the failure as being in testEqual itself which is not
very useful. This commit fixes the problem by adding a call to the
new t.Helper method in each of the testEqual functions. The line
numbers output when errors do occur now identify the real source of
the error.
Change-Id: I582d1934f40ef2b788116c3811074c67ea882021
Reviewed-on: https://go-review.googlesource.com/45871
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
They were failing when run on 32bit RFS, with 32bit gdb.
(mips64 builder now has 64bit RFS, with gdb 7.9.)
Leaving TestGdbPythonCgo disabled, it behaves as described in #18784.
Fixes#18173
Change-Id: I3c438cd5850b7bfd118ac6396f40c1208bac8c2d
Reviewed-on: https://go-review.googlesource.com/45874
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before CL 36170, we identified all function bodies that needed to be
exported before writing any export data.
With CL 36170, we started identifying additional functions while
exporting function bodies. As a consequence, we cannot use a
range-based for loop for iterating over function bodies anymore.
Fixes#18895.
Change-Id: I9cbefa8d311ca8c9898c8272b2ac365976b02396
Reviewed-on: https://go-review.googlesource.com/45817
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
These are used by DIV[U] and MOD[U] assembly instructions.
Add a test in the stdlib so we actually exercise linking
to these routines.
Update #19507
Change-Id: I0d8e19a53e3744abc0c661ea95486f94ec67585e
Reviewed-on: https://go-review.googlesource.com/45703
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I thought I was almost done, but had forgot the tools section, hidden
in comments.
Move the comments to a <pre> block, so it's visible in the HTML.
Updates #20587
Change-Id: I1dc22c63d9ee297e44bbb742f03b4a722247dbe8
Reviewed-on: https://go-review.googlesource.com/45811
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing code used Type.String() to obtain the name of a type;
specifically type reflect.Method in this case. However, Type.String()
formatting is intended for error messages and uses the format
pkgpath.name instead of pkgname.name if a package (in this case
package reflect) is imported multiple times. As a result, the
reflect.Method type detection failed under peculiar circumstances
(see the included test case).
Thanks to https://github.com/ericlagergren for tracking down
an easy way to make the bug disappear (which in turn directly
led to the underlying cause).
Fixes#19028.
Change-Id: I1b9c5dfd183260a9be74969fe916a94146fc36da
Reviewed-on: https://go-review.googlesource.com/45777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The check that the go tool version matched the go compiler version was
too aggressive and didn't cover the bootstrapping case with make.bash.
We never noticed because we never had a VERSION file in place.
Repro:
$ echo "go1.9beta1" > $GOROOT/VERSION
$ cd $GOROOT/src
$ ./make.bash
No test, because x/build/cmd/release catches it.
Updates #19064Fixes#20674
Change-Id: Ibdd7a92377f4cc77d71ed548f02d48bde6550f67
Reviewed-on: https://go-review.googlesource.com/45778
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Update x/net/http2 to git rev 6b17b9baf5 for:
http2: stop rejecting outgoing paths beginning with two slashes
https://golang.org/cl/45773
This also uses an updated version of x/tools/cmd/bundle (CL 45190)
that fixes an edge case where it used to drop some comments.
Updates #20627Fixes#19103
Change-Id: I450d61485e66098f4f8a79954f729f7bcd85856f
Reviewed-on: https://go-review.googlesource.com/45700
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Marshal must process unexported embedded fields of struct type,
looking for exported fields in those structs. However, it must
not process unexported embedded fields of non-struct type.
For example, consider:
type t1 struct {
X int
}
type t2 int
type T struct {
t1
t2
}
When considering T, Marshal must process t1 to find t1.X.
Marshal must not process t2, but it was. Fix that.
Fixes#18009
Change-Id: I62ba0b65ba30fd927990e101a26405a9998787a3
Reviewed-on: https://go-review.googlesource.com/33773
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
With current GCC a macro that refers to another macro can report an
error on the macro definition line, with a note on the use.
When cgo is trying to decide which line an error refers to,
it is looking at the uses. So if we see an error on a line that we
don't recognize followed by a note on a line that we do recognize,
treat the note as an error.
Fixes#20125.
Change-Id: I389cd0eb7d56ad2d54bef70e278d9f76c4d36448
Reviewed-on: https://go-review.googlesource.com/44290
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Hiroshi Ioka <hirochachacha@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Predefined escapers (i.e. "html" and "urlquery") should only occur in
Identifier nodes, and never in Field or Chain nodes, since these are
global functions that return string values (see inline comments for more
details). Therefore, skip Chain and Field nodes when searching for
predefined escapers in template pipelines.
Also, make a non-functional change two existing test cases to avoid
giving the impression that it is valid to reference a field of a
predefined escaper.
Fixes#20323
Change-Id: I34f722f443c778699fcdd575dc3e0fd1fd6f2eb3
Reviewed-on: https://go-review.googlesource.com/43296
Reviewed-by: Samuel Tan <samueltan@google.com>
Reviewed-by: Mike Samuel <mikesamuel@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, semrelease1 readies the next waiter before recording a
mutex event. However, if the next waiter is expecting to look at the
mutex profile, as is the case in TestMutexProfile, this may delay
recording the event too much.
Swap the order of these operations so semrelease1 records the mutex
event before readying the next waiter. This also means readying the
next waiter is the very last thing semrelease1 does, which seems
appropriate.
Fixes#19139.
Change-Id: I1a62063599fdb5d49bd86061a180c0a2d659474b
Reviewed-on: https://go-review.googlesource.com/45751
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Peter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When using golang on ppc64le there have been issues
when building executables that generate extremely large text
sections. This is due to the call instruction and the limitation
on the offset field, which is smaller than most platforms. If the
size of the call target offset is too big for the offset field in
the call instruction, then link errors can occur.
The original solution to this problem in golang was to split the
text section when it became too large, allowing the external (GNU)
linker to insert the necessary stub to handle the long call. That
worked fine until the another size limit for the program size was hit,
where a plt_branch was created instead of a long branch. In that case
the plt_branch code sequence expects r2 to contain the address of the
TOC, but when golang creates dynamic executables by default
(-buildmode=exe) r2 does not always contain the address of the TOC
and as a result when building programs that reach this extremely
large size, a runtime SEGV or SIGILL can occur due to branching to a bad
address.
When using internal linking, trampolines are generated to handle the
long calls but the text sections are not split. With this change,
text sections will still be split approrpriately with external linking
but if the buildmode being used does not maintain r2 as the TOC
addresses, then trampolines will be created for those calls.
Fixes#20497
Change-Id: If5400b0f86c2c08e106b332be6db0b259b07d93d
Reviewed-on: https://go-review.googlesource.com/45130
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Block all signals during a fork. In the parent process, after the
fork, restore the signal mask. In the child process, reset all
currently handled signals to the default handler, and then restore the
signal mask.
The effect of this is that the child will be operating using the same
signal regime as the program it is about to exec, as exec resets all
non-ignored signals to the default, and preserves the signal mask.
We do this so that in the case of a signal sent to the process group,
the child process will not try to run a signal handler while in the
precarious state after a fork.
Fixes#18600.
Change-Id: I9f39aaa3884035908d687ee323c975f349d5faaa
Reviewed-on: https://go-review.googlesource.com/45471
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Before, all accesses to the lines and infos tables of each File were
serialized by the lock of the owning FileSet, causing parsers running
in parallel to contend. Now, each File has its own mutex.
This fixes a data race in (*File).PositionFor, which used to call
f.position then f.unpack without holding the mutex's lock.
Fixesgolang/go#18348
Change-Id: Iaa5989b2eba88a7fb2e91c1a0a8bc1e7f6497f2b
Reviewed-on: https://go-review.googlesource.com/34591
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I was surprised to see readvarint show up in a cpu profile.
Use a few simple optimizations to speed up stack copying:
* Avoid making a copy of the cache.entries array or any of its elements.
* Use a shift instead of a signed division in stackmapdata.
* Change readvarint to return the number of bytes consumed
rather than an updated slice.
* Make some minor optimizations to readvarint to help the compiler.
* Avoid called readvarint when the value fits in a single byte.
The first and last optimizations are the most significant,
although they all contribute a little.
Add a benchmark for stack copying that includes lots of different
functions in a recursive loop, to bust the cache.
This might speed up other runtime operations as well;
I only benchmarked stack copying.
name old time/op new time/op delta
StackCopy-8 96.4ms ± 2% 82.7ms ± 1% -14.24% (p=0.000 n=20+19)
StackCopyNoCache-8 167ms ± 1% 131ms ± 1% -21.58% (p=0.000 n=20+20)
Change-Id: I13d5c455c65073c73b656acad86cf8e8e3c9807b
Reviewed-on: https://go-review.googlesource.com/43150
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The path package has a reference to the path/filepath package, so add
a reverse reference.
And clarify the path package doesn't do Windows paths.
Fixes#20117
Change-Id: I65c5ce24e600b32ea20c5821b744bd89f6aff98c
Reviewed-on: https://go-review.googlesource.com/45653
Reviewed-by: Jaana Burcu Dogan <jbd@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are currently two arrays indexed by P ID: allp and pdesc.
Consolidate these by moving the pdesc fields into type p so they can
be indexed off allp along with all other per-P state.
For #15131.
Change-Id: Ib6c4e6e7612281a1171ba4a0d62e52fd59e960b4
Reviewed-on: https://go-review.googlesource.com/45572
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently MaxGomaxprocs is 256. The previous CL saved enough per-P
static space that we can quadruple MaxGomaxprocs (and hence the static
size of allp) and still come out ahead.
This is safe for Go 1.9. In Go 1.10 we'll eliminate the hard-coded
limit entirely.
Updates #15131.
Change-Id: I919ea821c1ce64c27812541dccd7cd7db4122d16
Reviewed-on: https://go-review.googlesource.com/45673
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
According to the language spec, a struct field name should
be an identifier.
identifier = letter { letter | unicode_digit } .
letter = unicode_letter | "_" .
Implements a function 'isValidFieldName(fieldName string) bool'.
To check if the field name is a valid identifier or not.
It will panic if the field name is invalid.
It uses the non-exported function implementation 'isLetter'
from the package 'scanner', used to parse an identifier.
Fixes#20600.
Change-Id: I1db7db1ad88cab5dbea6565be15cc7461cc56c44
Reviewed-on: https://go-review.googlesource.com/45590
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The compiler now also prints column information - make sure we use
the correct regexp for compiler error cleanups. Accept both, error
positions with columns and without, since column printing may be
disabled with -gcflags=-C.
Fixes#20628.
Change-Id: I46dc921dd5c29d7b8172cd19a3df57951f60d889
Reviewed-on: https://go-review.googlesource.com/45612
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Ensure a Stmt prepared on a Conn executes on the same driver.Conn.
This also removes another instance of duplicated prepare logic
as a side effect.
Fixes#20647
Change-Id: Ia00a19e4dd15e19e4d754105babdff5dc127728f
Reviewed-on: https://go-review.googlesource.com/45391
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Back in the day, allp was just a pointer to an array. As a result, the
runtime has a few loops of the form:
for i := 0; ; i++ {
p := allp[i]
if p == nil {
break
}
...
}
This is silly now because it requires that allp be one longer than the
maximum possible number of Ps, but now that allp is in Go it has a
length.
Replace these with range loops.
Change-Id: I91ef4bc7bd3c9d4fda2264f4aa1b1d0271d7f578
Reviewed-on: https://go-review.googlesource.com/45571
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
"MOVW FPSR, g" should be assembled to 0xeef1aa10, but actually
0xee30a110 (RFS). "MOVW g, FPSR" should be 0xeee1aa10, but actually
0xee20a110 (WFS). They should be updated to VFP forms, since the ARM
back end doesn't support non-VFP floating points.
The patch fixes them and adds more assembly encoding tests.
fixes#20643
Change-Id: I3b29490337c6e8d891b400fcedc8b0a87b82b527
Reviewed-on: https://go-review.googlesource.com/45276
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Last time zoneinfo_abbrs_windows.go was updated in CL 27832.
Time for another update.
Change-Id: I8dc3a1de6f22e90e634b2176188f257a260b6463
Reviewed-on: https://go-review.googlesource.com/45450
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Rather then write to the same variable per fakeConn, write to either
fakeConn or rowsCursor.
Fixes#20646
Change-Id: Ifc79f989bd1606b8e3ebecb1e7844cce3ad06e17
Reviewed-on: https://go-review.googlesource.com/45393
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In addition to adding a guard to the Rows close, add a var
in the fakeConn that gets read and written to on each
operation, simulating writing or reading from the server.
TestConcurrency/TxStmt* tests have been commented out
as they now fail after checking for races on the fakeConn.
See issue #20646 for more information.
Fixes#20622
Change-Id: I80b36ea33d776e5b4968be1683ff8c61728ee1ea
Reviewed-on: https://go-review.googlesource.com/45275
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ARM currently does not use a hardware yield instruction in the spin
loop in procyield because the YIELD instruction was only added in
ARMv6K. However, it appears earlier ARM chips will interpret the YIELD
encoding as an effective NOP (specifically an MSR instruction that
ultimately has no effect on the CPSR register).
Hence, use YIELD in procyield on ARM since it should be, at worst,
harmless.
Fixes#16663.
Change-Id: Id1787ac48862b785b92c28f1ac84cb4908d2173d
Reviewed-on: https://go-review.googlesource.com/45250
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If we're in a situation where printing the fp and sp in the traceback
is useful, it's almost certainly also useful to print the PC.
Change-Id: Ie48a0d5de8a54b5b90ab1d18638a897958e48f70
Reviewed-on: https://go-review.googlesource.com/45210
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Several of the CLs that were against the runtime are noted in other
places in the release notes, depending on where they are most
user-visible.
Change-Id: I167dc7ff17a4c5f9a5d22d5bd123aa0e99f5639e
Reviewed-on: https://go-review.googlesource.com/45137
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
"MOVW R1, CPSR" is assembled to 0xe129f001, which should be 0xe12cf001.
"MOVW $255, CPSR" is assembled to 0xe329f0ff, which should be 0xe32cf0ff.
This patch fixes them and adds more assembly encoding tests.
fix#20626
Change-Id: Iefc945879ea774edf40438ce39f52c144e1501a1
Reviewed-on: https://go-review.googlesource.com/45170
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Because of parallel tests, which have stalled executions, the RUN
output of a test can be much earlier than its completion output resulting
in hard-to-read verbose output.
The tests are displayed in the order in which the output shows
that they began, to make it easy to line up with the "RUN" output.
Similarly, the definitions of when tests begin and complete is
determined by when RUN and FAIL/SKIP/PASS are output since the
focus of this code is on enhancing readability.
Fixes#19397
Change-Id: I4d0ca3fd268b620484e7a190117f79a33b3dc461
Reviewed-on: https://go-review.googlesource.com/44352
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The net/http package has long documented that Request.ProtoMajor and
Request.ProtoMinor are ignored for outgoing requests (HTTP/1.1 or
HTTP/2 is always used, never HTTP/1.0). There was one part in the code
that was actually checking 1.0 vs 1.1, but it appears to have been
harmless. Remove it.
Fixes#18407
Change-Id: I362ed6c47ca2de7a2fbca917ed3e866273cfe41f
Reviewed-on: https://go-review.googlesource.com/45155
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Both runtime.exit and syscall.Exit call Windows ExitProcess.
But recently (CL 34616) runtime.exit was changed to ignore
Windows CreateThread errors if ExitProcess is called.
This CL adjusts syscall.Exit to do the same.
Fixes#18253 (maybe)
Change-Id: I6496c31b01e7c7d73b69c0b2ae33ed7fbe06736b
Reviewed-on: https://go-review.googlesource.com/45115
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Some machines can be configured (or came/come configured) in such a
state that IPv6 only half works: you can bind on [::]:n but not
connect back to it.
This implements a fallback such that it's guaranteed that this pattern
works:
ln, err := Listen("tcp", ":0")
...
addr := ln.Addr().String() // "[::]:n"
c, err := Dial("tcp", addr)
... which is also now tested. It will first try to dial "[::]:n", as
before, but if that dial fails, it will also try "0.0.0.0:n".
Fixes#18806 (contains more details)
Fixes#20611 (I was going to fix nacl later, but it was easy enough)
Change-Id: I1107eb197e902ae8185c781ad1bc4e2bc61d1f4c
Reviewed-on: https://go-review.googlesource.com/45088
Reviewed-by: Paul Marks <pmarks@google.com>
Allow the Resolver.Dial func to return instances of Conn other than
*TCPConn and *UDPConn. If the Conn is also a PacketConn, assume DNS
messages transmitted over the Conn adhere to section 4.2.1. "UDP usage".
Otherwise, follow section 4.2.2. "TCP usage".
Provides a hook mechanism so that DNS queries generated by the net
package may be answered or modified before being sent to over the
network.
Updates #19910
Change-Id: Ib089a28ad4a1848bbeaf624ae889f1e82d56655b
Reviewed-on: https://go-review.googlesource.com/45153
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds diagnostics so we can tell if the finalizer has started, in
addition to whether or not it has finished.
Updates #19381.
Change-Id: Icb7b1b0380c9ad1128b17074828945511a6cca5d
Reviewed-on: https://go-review.googlesource.com/45138
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
runtime.GC no longer triggers a STW GC. This fixes the description of
GODEBUG=gctrace=1 so it doesn't claim otherwise.
Change-Id: Ibd34a55c5ae7b5eda5c2393b9a6674bdf1d51eb3
Reviewed-on: https://go-review.googlesource.com/45131
Reviewed-by: Rick Hudson <rlh@golang.org>
Server.ServeTLS wraps Server.Serve with added TLS support. This is
particularly useful for serving on manually initialized listeners.
Example use-case includes ability to serve with TLS on listener
provided by systemd's socket activation.
A matching test heavily based on TestAutomaticHTTP2_ListenAndServe
is also included.
Original code by Gurpartap Singh as
https://go-review.googlesource.com/c/38114/Fixes#13228
Change-Id: I73bb703f501574a84d261c2d7b9243a89fa52d62
Reviewed-on: https://go-review.googlesource.com/44074
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For non-constant shifts with an untyped constant shift count, the
spec only said that it must "be converted to unsigned integer type".
go/types accepts any (arbitrarily large) integer value. Both cmd/compile
and gccgo require that the shift count be representable as a uint value
in that case (if the shift count is typed, it may be any unsigned integer
type).
This change adjusts the spec to state what the compilers have been doing
all along. The new wording matches similar rules elsewhere (e.g., for
untyped array and slice indices). Also, while technically this is a
restriction (we could permit arbitrarily large shift counts), in practice
this is irrelevant.
Fixes#14822.
Change-Id: Ia75834c67483cf761c10025c8df758f225ef67c2
Reviewed-on: https://go-review.googlesource.com/45072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The current implementation of "goroutine N cmd" assumes it can get
goroutine N's state from the goroutine's sched buffer. But this only
works if the goroutine is blocked. Extend find_goroutine so that, if
there is no saved scheduler state for a goorutine, it tries to find
the thread the goroutine is running on and use the thread's current
register state. We also extend find_goroutine to understand saved
syscall register state.
Fixes#13887.
Change-Id: I739008a8987471deaa4a9da918655e4042cf969b
Reviewed-on: https://go-review.googlesource.com/45031
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestBuildIDContainsArchModeEnv fails on arm64 because defaultGO386 has
different value from x86 (amd64/386). On arm64 defaultGO386 = '387' but
on x86 defaultGO386 = 'sse2'. The difference will make the test succeed
on x86 while fail on arm64 since it generates the same build ID.
Fix it by explicitly setting GO386 instead of using default value
Fixes#20608
Change-Id: I864b0e47325942d9513516bdf47f60391d18c0d0
Reviewed-on: https://go-review.googlesource.com/45112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Remove note that sync.Cond, sync.Mutex, sync.RWMutex and atomic.Value
can be created as part of other data structures. Structs can be embedded
by default, and default should not be repeated.
Fixes#20471.
Change-Id: If3f5703d3f60abd96482b58ca43450d02a9e645a
Reviewed-on: https://go-review.googlesource.com/44071
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change updates the vendored tzdata database to version 2017b
(released 2017-03-20).
The TestFirstZone test (which always uses the vendored database) is
updated to make it work with the new timezones database. (The Tokelau
abbreviation was changed from 'TKT' to the numeric abbreviation in
tzdata-2017a)
Fixes#19376
Change-Id: I0dea93e8703992de5c92c7840b8bacad9d02c50d
Reviewed-on: https://go-review.googlesource.com/44832
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The Tx methods Query and Exec uses context.Background()
even Tx was created by context.
This patch enables using Tx.ctx in all Tx methods
which do not has context arg.
Backward compatibility:
- If Tx has created without context, nothing changes.
- If Tx has created with context and non-context method is called:
- If context is expired, the execution fails,
but it can fail on Commit or Rollback as well,
so in terms of whole transaction - nothing changes.
- If context is not expired, nothing changes too.
Fixes#20098
Change-Id: I9570a2deaace5875bb4c5dcf7b3a084a6bcd0d00
Reviewed-on: https://go-review.googlesource.com/44956
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We insert guard instructions after each "dangerous" instruction
to make NaCl's validator happy. This happens before asmout. If
in asmout an instruction is split to two dangerous instructions,
but only one guard instruction is inserted, the validation fails.
Therefore don't split instructions on NaCl.
Fixes#20595.
Change-Id: Ie34f209bc7d907d6d16ecef6721f88420981ac01
Reviewed-on: https://go-review.googlesource.com/45021
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The new math/bits package has a section for itself, and should not be
mentioned in the 'Minor changes to the library' section of the release
notes.
Updates #20587
Change-Id: I13ecd35f5cee4324e50b2d31800e399c00159126
Reviewed-on: https://go-review.googlesource.com/45051
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently the extra Ms created for cgo callbacks have a corresponding
G that's kept in syscall state with only a call to goexit on its
stack. This leads to confusing output from runtime.NumGoroutines and
in tracebacks:
goroutine 17 [syscall, locked to thread]:
runtime.goexit()
.../src/runtime/asm_amd64.s:2197 +0x1
Fix this by putting this goroutine into state _Gdead when it's not in
use instead of _Gsyscall. To keep the goroutine counts correct, we
also add one to sched.ngsys while the goroutine is in _Gdead. The
effect of this is as if the goroutine simply doesn't exist when it's
not in use.
Fixes#16631.
Fixes#16714.
Change-Id: Ieae08a2febd4b3d00bef5c23fd6ca88fb2bb0087
Reviewed-on: https://go-review.googlesource.com/45030
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test is inherently racy, and for me fails about 0.05% of the time.
So only fail the test if it fails ten times in a row.
Fixes#20594
Change-Id: I3b3f7598f2196f7406f1a3937f38f21ff0c0e4b5
Reviewed-on: https://go-review.googlesource.com/45020
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For cgo programs on linux-amd64 we call the C function mmap.
This supports programs such as the C memory sanitizer that need to
intercept all calls to mmap. It turns out that there are programs that
intercept both mmap and munmap, or that at least expect that if they
intercept mmap, they also intercept munmap. So, if we permit mmap
to be intercepted, also permit munmap to be intercepted.
No test, as it requires two odd things: a C program that intercepts
mmap and munmap, and a Go program that calls munmap.
Change-Id: Iec33f47d59f70dbb7463fd12d30728c24cd4face
Reviewed-on: https://go-review.googlesource.com/45016
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Go doesn't guarantee that the result of floating point operations will
be the same on different architectures. It was not stated in the
documentation, that can lead to confusion.
Fixes#18354
Change-Id: Idb1b4c256fb9a7158a74256136eca3b8ce44476f
Reviewed-on: https://go-review.googlesource.com/34938
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows reading from package storage systems that may not
preserve the .a suffix (used with -importcfg).
Fixes#20579 (combined with CLs earlier in stack).
Change-Id: If2fc6a3d01bd0170a757e1f2ba9a22a4d9be7dbf
Reviewed-on: https://go-review.googlesource.com/44853
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Adds the ability to specify the file location of each imported package,
like in the -importcfg added to cmd/compile in a related CL.
In effect, -importcfg is a generalization of and supersedes -installsuffix
and -L. Of course, those flags will continue to be supported, for
compatibility with other tools.
Having this flag in Go 1.9 will let us try some experiments involving
package management without needing guinea pigs to build a custom
Go toolchain.
This flag also helps with #14271 at some later point.
For #20579.
Change-Id: Ie4c171bcd3aa2faa446ac340e36516f2f9853882
Reviewed-on: https://go-review.googlesource.com/44851
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Allows reading -importmap options from a file instead of putting
them all on the command line, and adds the ability to specify the
file location of specific packages. In effect, -importcfg is a generalization
of and supersedes -importmap, -importsuffix, and -I.
Of course, those flags will continue to be supported,
for compatibility with other tools.
Having this flag in Go 1.9 will let us try some experiments involving
package management without needing guinea pigs to build a
custom Go toolchain.
This flag also helps with #14271 at some later point.
For #20579.
Change-Id: If005dbc2b01d8fd16cbfd3687dfbe82499f4bc56
Reviewed-on: https://go-review.googlesource.com/44850
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apparently people get confused by the fact that
Split("", ",")
returns []{""} instead of []{}.
This is actually just a consequence of the fact that if the separator
sep (2nd argument) is not found the string s (1st argument), then the
Split* functions return a length 1 slice with the string s in it.
Document the general case: if sep is not in s, what you get is a len 1
slice with s in it; unless both s and sep are "", in that case you get
an empty slice of length 0.
Fixes#19726
Change-Id: I64c8220b91acd1e5aa1cc1829199e0cd8c47c404
Reviewed-on: https://go-review.googlesource.com/44950
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Try to avoid a race between the main goroutine exiting and a panic
occurring. Don't try too hard, to avoid hanging.
Updates #3934Fixes#20018
Change-Id: I57a02b6d795d2a61f1cadd137ce097145280ece7
Reviewed-on: https://go-review.googlesource.com/41052
Reviewed-by: Austin Clements <austin@google.com>
Make sure that in complex division we reject divisors that would
underflow to zero when using the textbook complex-division method we
currently use.
This change does for go/types what golang.org/cl/42650 did for gc.
Fixes#20227
Change-Id: Iaa784ac5e60141f51c501eb0e3ce0e9c1c2993d0
Reviewed-on: https://go-review.googlesource.com/44590
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
C code expects CR2, CR3, and CR4 to be preserved across function calls.
Preserve the entire CR register across function calls in
_rt0_ppc64le_linux_lib and crosscall2. The standard ppc64le call frame
uses 8(R1) as the place to save CR; emulate that.
It's hard to write a reliable test for this as it requires writing C
code that sets CR2, CR3, or CR4 across a call to a Go function.
Change-Id: If39e771a5b574602b848227312e83598fe74eab7
Reviewed-on: https://go-review.googlesource.com/44733
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The MOVFL instruction (which external PPC64 docs call mtcrf) can take
either a CR register or a constant. It doesn't make sense to specify
both, as the CR register implies the constant value. Specifying either
a register or a constant is enforced by the implementation in the
asmout method (case 69).
However, the optab was providing a form that specified both a constant
and a CR register, and was not providing a form that specified only a
constant. This CL fixes the optab table to provide a form that takes
only a constant.
No test because I don't know where to write it. The next CL in this
series will use the new instruction format.
Change-Id: I8bb5d3ed60f483b54c341ce613931e126f7d7be6
Reviewed-on: https://go-review.googlesource.com/44732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Programs built from N libraries required O(N²) time to do the
deduplication checks, even if there were never any duplicates.
In most programs N is small enough not to worry, but this may
affect large programs.
Noticed by inspection, not any specific bug report.
Fixes#20578.
Change-Id: Ic4108f1058be39da990a79b1e0b8ce95fde44cef
Reviewed-on: https://go-review.googlesource.com/44852
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Otherwise removing a .f file won't trigger a rebuild.
Noticed by inspection while working on the code.
I don't have a good way to write a test for this,
and I expect the code to change significantly in the next
release, but might as well get it right for Go 1.9.
Change-Id: I3f6f9f71b3a7d4f0be49a47419dac59899959e7c
Reviewed-on: https://go-review.googlesource.com/44855
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Close any Rows queried within a Tx when the Tx is closed. This prevents
the Tx from blocking on rollback if a Rows query has not been closed yet.
Fixes#20575
Change-Id: I4efe9c4150e951d8a0f1c40d9d5e325964fdd608
Reviewed-on: https://go-review.googlesource.com/44812
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is another attempt at the change attempted in
https://golang.org/cl/27117 and rolled back in https://golang.org/cl/34134
The difference between this and the previous attempt is that this version only
retries if the new field GetBody is set on the Request.
Additionally, this allows retries of requests with idempotent methods even if
they have bodies, as long as GetBody is defined.
This also fixes an existing bug where readLoop could make a redundant call to
setReqCanceler for DELETE/POST/PUT/etc requests with no body with zero bytes
written.
This clarifies the existing TestRetryIdempotentRequestsOnError test (and changes
it into a test with 4 subtests). When that test was written, it was in fact
testing "retry idempotent requests" logic, but the logic had changed since then,
and it was actually testing "retry requests with no body when no bytes have been
written". (You can confirm this by changing the existing test from a GET to a
DELETE; it passes without the changes in this CL.) We now test for the no-Body
and GetBody cases for both idempotent and nothing-written-non-idempotent
requests.
Fixes#18241Fixes#17844
Change-Id: I69a48691796f6dc08c31f7aa7887b7dfd67e278a
Reviewed-on: https://go-review.googlesource.com/42142
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There are two issues in constant decomposition.
1. A typo in "func immrot2s" blocks "case 107" of []optab be triggered.
2. Though "ADD $0xffff, R0, R0" is decomposed to "ADD $0xff00, R0, R0" and
"ADD $0x00ff, R0, R0" as expected, "ADD $0xffff, R0" still uses the
constant pool, which should be the same as "ADD $0xffff, R0, R0".
This patch fixes them and adds more instruction encoding tests.
fix#20516
Change-Id: Icd7bdfa1946b29db15580dcb429111266f1384c6
Reviewed-on: https://go-review.googlesource.com/44335
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Since TestPingPongHog tests the scheduler, it's ultimately
probabilistic. Currently, it requires the result be at most of factor
of 2 off of the ideal. It turns out this isn't quite enough in
practice, with factors on 1000 iterations on linux/amd64 ranging from
0.48 to 2.5. If the test were failing, we would expect a factor closer
to 1000X, so it's pretty safe to expand the accepted factor from 2 to
5.
Fixes#20494.
Change-Id: If8f2e96194fe66f1fb981a965d1167fe74ff38d7
Reviewed-on: https://go-review.googlesource.com/44859
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I learned from CL 41770 that valState’s size
matters to compiler performance.
Encode that knowledge in a test.
Change-Id: I7c0fde6a4cf460017619dbcce1c1ddaa7af10239
Reviewed-on: https://go-review.googlesource.com/44737
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For test.go:
package main
import (
"C"
"fmt"
)
func main() {
fmt.Println("Hello, world!")
C.no_such_f()
}
Before:
could not determine kind of name for C.no_such_f
After:
./test.go:10:2: could not determine kind of name for C.no_such_f
Fixes#18452
Change-Id: I49c136b7fa60fab25d2d5b905d440fe4d106e565
Reviewed-on: https://go-review.googlesource.com/34783
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
1) Split atLineBegin into its two components: writing of // line directives
and writing of indentation (no functionality changes).
2) Don't call writeLineDirective at the beginning of a line if we're
writing white space - it's not necessary. This is the bug fix.
3) Move testing of the SourcePos mode out of writeLineDirective and
into the (single) caller. Clearer and more efficient.
(Instead of these 3 changes one could also have simply called the
original atLineBegin with position p.out rather than p.pos. This
would have caused atLineBegin to not write a line directive.
Factoring the code seemed like a cleaner and more direct approach.)
Fixes#5945.
Change-Id: Ia8710806b6d3d4e5044116b142c036a4ab5a1764
Reviewed-on: https://go-review.googlesource.com/44651
Reviewed-by: Alan Donovan <adonovan@google.com>
Arguments to inlined calls are hidden from setPos as follows:
args := as.Rlist
as.Rlist.Set(nil)
// setPos...
as.Rlist.Set(args.Slice())
Previously, this code had no effect since the value of as was
overwritten by the assignment in the retvars loop.
Fixes#19799.
Change-Id: Iaf97259f82fdba8b236136337cc42b2774c7fef5
Reviewed-on: https://go-review.googlesource.com/44351
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Apply the fix in CL 44355 to MIPS.
ARM64 has these rules but commented out for performance reason.
Fix the commented rules, in case they are enabled in the future.
Enhance the test so it triggers the failure on ARM and MIPS without
the fix.
Updates #20530.
Change-Id: I82d77448e3939a545fe519d0a29a164f8fa5417c
Reviewed-on: https://go-review.googlesource.com/44430
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The current implementation of forkAndExecInChild for Linux does not allow
spawned processes steal the controlling terminal from a different session
group. This patch passes 1 as the argument to TIOCSCTTY in order to allow
spawned processes steal controlling terminals.
Fixes#20454
Change-Id: I171b8981509d648b07f89bddc1e9d45cb70e00e6
Reviewed-on: https://go-review.googlesource.com/44343
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Replacing byteload-of-bytestore-of-x with x is incorrect
when x contains a larger-than-byte value (and so on for
16 and 32-bit load/store pairs). Replace "x" with the
appropriate zero/sign extension of x, which if unnecessary
will be repaired by other rules.
Made logic for arm match x86 and amd64; yields minor extra
optimization, plus I am (much) more confident it's correct,
despite inability to reproduce bug on arm.
Ppc64 lacks this optimization, hence lacks this problem.
See related https://golang.org/cl/37154/Fixes#20530.
Change-Id: I6af9cac2ad43bee99cafdcb04725ce7e55a43323
Reviewed-on: https://go-review.googlesource.com/44355
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
key32 is called between entersyscallblock and exitsyscall
stack split may occur if disable inlining and the G is preempted
Fix the problem by describing key32 as nosplit function
Fixes#20510
Change-Id: I1f0787995936f34ef0052cf79fde036f1b338865
Reviewed-on: https://go-review.googlesource.com/44390
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
cmd/compile/internal/ld/decodesym.go is now
cmd/link/internal/ld/decodesym.go
Change-Id: I16ec5c89aa3507e70676c2b50d70f1fde533a085
Reviewed-on: https://go-review.googlesource.com/44373
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Vet returns with a nonzero exit for all possible messages in the
buildtag check. However for this file:
//+buildlinux
package main
vet returns a zero exit status:
$ go vet main.go
demo.go:1: possible malformed +build comment
$ echo $?
0
This CL sets the exit status to non zero for the remaining messages in
the buildtag check.
Change-Id: Ia2c35ebc3ec5ac311d2a0295b5b9fdd997a85726
Reviewed-on: https://go-review.googlesource.com/44371
Reviewed-by: Rob Pike <r@golang.org>
In preparation for CL 41770, upgrade .debug_info to DWARF4, and emit
DW_AT_frame_base on subprograms. This should make no semantic
difference.
Also fix a long-standing bug/inconsistency in puttattr: it didn't
add the addend to ref_addrs. Previously this didn't matter because it
was only used for types, but now it's used for section offsets into
symbols that have multiple entries.
RELNOTE=yes
Change-Id: Ib10654ac92edfa29c5167c44133648151d70cf76
Reviewed-on: https://go-review.googlesource.com/44210
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
This avoids false-positive TSAN reports when using the C sigaction
function to read handlers registered by the Go runtime.
(Unfortunately, I can't seem to coax the runtime into reproducing the
failure in a small unit-test.)
Change-Id: I744279a163708e24b1fbe296ca691935c394b5f3
Reviewed-on: https://go-review.googlesource.com/44270
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Currently debug/dwarf assumes all paths in line tables will be
UNIX-style paths, which obviously isn't the case for binaries built on
Windows. However, we can't simply switch from the path package to the
filepath package because we don't know that we're running on the same
host type that built the binary and we want this to work even if we're
not. This is essentially the approach taken by GDB, which treats paths
in accordance with the system GDB itself is compiled for. In fact, we
can't even guess the compilation system from the type of the binary
because it may have been cross-compiled.
We fix this by heuristically determining whether paths are UNIX-style
or DOS-style by looking for a drive letter or UNC path. If we see a
DOS-style path, we use appropriate logic for determining whether the
path is absolute and for joining two paths. This is helped by the fact
that we should basically always be starting with an absolute path.
However, it could mistake a relative UNIX-style path that begins with
a directory like "C:" for an absolute DOS-style path. There doesn't
seem to be any way around this.
Fixes#19784.
Change-Id: Ie13b546d2f1dcd8b02e668583a627b571b281588
Reviewed-on: https://go-review.googlesource.com/44017
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
It is expected to test assembly code for ARMv5, ARMv6 and ARMv7
in cmd/asm/internal/asm/endtoend_test.go. But actually the loop
in "func TestARMEndToEnd(t *testing.T)" runs three times all
for ARMv5.
This patch fixes that bug and adds a new armv6.s which is only tested
with GOARM=6.
fixes#20465
Change-Id: I5dbf00809a47ace2c195335e2c9bdd768479aada
Reviewed-on: https://go-review.googlesource.com/43930
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
"ADDF F0, R1, F2" is silently accepted by the arm assembler and
assembled to the same binary code of "ADDF F0, F1, F2". So does
"CMPF F0, R1".
"ABSF F0, F1, F2" is also silently accepted and assembled to a
different instruction.
This patch reports those illegal forms and adds test cases.
fix#20464
Change-Id: I88b80dc29de24c6266ac7bf7bce1578c5adbc68c
Reviewed-on: https://go-review.googlesource.com/43931
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, the heap arena allocator allocates monotonically increasing
addresses. This is fine on 64-bit where we stake out a giant block of
the address space for ourselves and start at the beginning of it, but
on 32-bit the arena starts at address 0 but we start allocating from
wherever the OS feels like giving us memory. We can generally hint the
OS to start us at a low address, but this doesn't always work.
As a result, on 32-bit, if the OS gives us an arena block that's lower
than the current block we're allocating from, we simply say "thanks
but no thanks", return the whole (256MB!) block of memory, and then
take a fallback path that mmaps just the amount of memory we need
(which may be as little as 8K).
We have to do this because mheap_.arena_used is *both* the highest
used address in the arena and the next address we allocate from.
Fix all of this by separating the second role of arena_used out into a
new field called arena_alloc. This lets us accept any arena block the
OS gives us. This also slightly changes the invariants around
arena_end. Previously, we ensured arena_used <= arena_end, but this
was related to arena_used's second role, so the new invariant is
arena_alloc <= arena_end. As a result, we no longer necessarily update
arena_end when we're updating arena_used.
Fixes#20259 properly. (Unlike the original fix, this one should not
be cherry-picked to Go 1.8.)
This is reasonably low risk. I verified several key properties of the
32-bit code path with both 4K and 64K physical pages using a symbolic
model and the change does not materially affect 64-bit (arena_used ==
arena_alloc on 64-bit). The only oddity is that we no longer call
setArenaUsed with racemap == false to indicate that we're creating a
hole in the address space, but this only happened in a 32-bit-only
code path, and the race detector require 64-bit, so this never
mattered anyway.
Change-Id: Ib1334007933e615166bac4159bf357ae06ec6a25
Reviewed-on: https://go-review.googlesource.com/44010
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
CL 43779/commit 6a6c792eef
broke the builds at tip, and that CL doesn't account for
cases where Redirect is directly invoked with a full URL
that itself has a query string.
Updates #17841
Change-Id: Idb0486bae8625e1f9e033ca4cfcd87de95bc835c
Reviewed-on: https://go-review.googlesource.com/44100
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We weren't setting r0 to 0, as required by our generated code.
Before this patch, the misc/cgo/testcarchive tests failed on ppc64le.
After this patch, they work, so enable them.
Change-Id: I53b16746961da9f7c34f59030a1e40953c9c1e05
Reviewed-on: https://go-review.googlesource.com/44093
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The logic performs a series of shifts, which are useless given
that they are followed by an assignment that overrides the
value of the previous computation.
I suspect (but cannot prove) that this is leftover logic from an
original approach that attempted to store both the Huffman code
and the length within the same variable instead of using two
different variables as it currently does now.
Fixes#17949
Change-Id: Ibf6c807c6cef3b28bfdaf2b68d9bc13503ac21b2
Reviewed-on: https://go-review.googlesource.com/44091
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Test that we really do move spills down to the dominator of
all the uses.
Also add a test where go1.8 would have moved the spill out of
the loop into two exit points, but go1.9 doesn't move the spill.
This is a case where the 1.9 spill moving code does not subsume
the 1.8 spill moving code.
Maybe we resurrect moving-spills-out-of-loops CL to fix this one.
(I suspect it wouldn't be worth the effort, but would be happy
to hear evidence otherwise.)
Update #20472
Change-Id: I7dbf8d65e7f4d675d14e5ecf502887cebda35d2a
Reviewed-on: https://go-review.googlesource.com/44038
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When writing the 'Connection: close' header based on response Close
attribute we also check if it is already in the headers scheduled
to be written and skip if necessary.
Fixes#19499
Change-Id: I92357344a37ae385454ec8006114fa4cfa585810
Reviewed-on: https://go-review.googlesource.com/38076
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Despite the previously known behavior of Request.WithContext
shallow copying a request, usage of the request inside server.ServeHTTP
mutates the request's URL. This CL implements deep copying of the URL.
Fixes#20068
Change-Id: I86857d7259e23ac624d196401bf12dde401c42af
Reviewed-on: https://go-review.googlesource.com/41308
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is one hurdle to building Go on Android; the runtime does
not build properly because *_linux.go files are excluded from
the "Building go_bootstrap" step when GOOS=android.
There are other hurdles; this is the first one.
Change-Id: I766e4bbf6ffc0d273888913f2516cf3e995a1786
Reviewed-on: https://go-review.googlesource.com/38308
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing Transport implementation does not detect gzip encoding
when the Content-Encoding header is not lower-case. This is not
compliant with RFC2616 section 3.5 "All content-coding values are
case-insensitive." and caused issues in the wild.
Fixes#19248
Change-Id: I1b49992832dc3c8ef700058596a27dd9909640a3
Reviewed-on: https://go-review.googlesource.com/37431
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This will be used to allow http2 servers to register a shutdown function
so that net/http.Server.Shutdown will work when the http2 server is
configured via a manual call to http2.ConfigureServer. Currently, Shutdown
only works when the http2 server is configured automatically by the
net/http package.
Updates #20302
Updates #18471
Change-Id: Ifc2b5f3126126a106b49ea4a7e999279852b9cc9
Reviewed-on: https://go-review.googlesource.com/44003
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Commit 4dcba023c6 replaced select with pselect6 on linux/amd64 and
linux/arm, but it turns out the Android emulator uses linux/386. This
makes the equivalent change there, too.
Fixes#20409 more.
Change-Id: If542d6ade06309aab8758d5f5f6edec201ca7670
Reviewed-on: https://go-review.googlesource.com/44011
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Current code cannot handle string #define macros if those macros are
defined via other macros. This CL solve the issue.
Updates #18720
Change-Id: Ibed0773d10db3d545bb246b97e81c0d19e3af3d5
Reviewed-on: https://go-review.googlesource.com/41312
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now:
$ GOARCH=arm GOARM=5 go install -x cmd/go
... followed by:
$ GOARCH=arm GOARM= go install -x cmd/go
... actually does work. Previously the second "go install" would reuse
the cached binaries from the GOARM=5 command and not rebuild.
(Or vice versa from GOARM= to GOARM=5)
And do the same for GO386.
Fixes#9737
Change-Id: I9630aab34d06465d5033e6743dfe6592c8247aa0
Reviewed-on: https://go-review.googlesource.com/43855
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We only need to read the number of bytes required to store the value
"max - 1" to generate a random number in the range [0, max).
Before, there was an off-by-one error where an extra byte was read from
the io.Reader for inputs like "256" (right at the boundary for a byte).
There was a similar off-by-one error in the logic for clearing bits and
thus for any input that was a power of 2, there was a 50% chance the
read would continue to be retried as the mask failed to remove a bit.
Fixes#18165.
Change-Id: I548c1368990e23e365591e77980e9086fafb6518
Reviewed-on: https://go-review.googlesource.com/43891
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There are two copies each of the stackPreempt/_StackPreempt and
stackFork/_StackFork constants. Remove the ones left over from C that
are no longer used.
Change-Id: I849604c72c11e4a0cb08e45e9817eb3f5a6ce8ba
Reviewed-on: https://go-review.googlesource.com/43638
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Setting stackCache to 0 to disable stack caches for debugging hasn't
worked for a long time. It causes stackalloc to fall back to full span
allocation, round sub-page stacks down to 0 pages, and blow up.
Fix this debug mode so it disables the per-P caches, but continues to
use the global stack pools for small stacks, which correctly handle
sub-page stacks. While we're here, rename stackCache to stackNoCache
so it acts like the rest of the stack allocator debug modes where "0"
is the right default value.
Fixes#17291.
Change-Id: If401c41cee3448513cbd7bb2e9334a8efab257a7
Reviewed-on: https://go-review.googlesource.com/43637
Reviewed-by: Keith Randall <khr@golang.org>
The stackFromSystem debug mode has two problems:
1) It rounds the stack allocation to _PageSize. If the physical page
size is >8K, this can cause unmapping the memory later to either
under-unmap or over-unmap.
2) It doesn't return the rounded-up allocation size to its caller, so
when we later unmap the memory, we may pass the wrong length.
Fix these problems by rounding the size up to the physical page size
and putting that rounded-up size in the returned stack bounds.
Fixes#17289.
Change-Id: I6b854af3b06bb16e3750798397bb5e2a722ec1cb
Reviewed-on: https://go-review.googlesource.com/43636
Reviewed-by: Keith Randall <khr@golang.org>
If mheap.sysAlloc doesn't have room in the heap arena for an
allocation, it will attempt to map more address space with sysReserve.
sysReserve is given a hint, but can return any unused address range.
Currently, mheap.sysAlloc incorrectly assumes the returned region will
never fall between arena_start and arena_used. If it does,
mheap.sysAlloc will blindly accept the new region as the new
arena_used and arena_end, causing these to decrease and make it so any
Go heap above the new arena_used is no longer considered part of the
Go heap. This assumption *used to be* safe because we had all memory
between arena_start and arena_used mapped, but when we switched to an
arena_start of 0 on 32-bit, it became no longer safe.
Most likely, we've only recently seen this bug occur because we
usually start arena_used just above the binary, which is low in the
address space. Hence, the kernel is very unlikely to give us a region
before arena_used.
Since mheap.sysAlloc is a linear allocator, there's not much we can do
to handle this well. Hence, we fix this problem by simply rejecting
the new region if it isn't after arena_end. In this case, we'll take
the fall-back path and mmap a small region at any address just for the
requested memory.
Fixes#20259.
Change-Id: Ib72e8cd621545002d595c7cade1e817cfe3e5b1e
Reviewed-on: https://go-review.googlesource.com/43870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
By changing getRandomLinux to immediately use the getrandom() syscall
without GRND_NONBLOCK, we now only fall back to reading from
/dev/urandom on Linux if the kernel does not support the getrandom()
syscall. This means reads for crypto/rand will now block if the kernel
has insufficient entropy on Linux kernels after v3.16.
Before, if the kernel had insufficient entropy, it would fall back to
reading from /dev/urandom. This would potentially return predictable
data.
Fixes#19274
Change-Id: I1cb081ce2f3096f18ad2820e52ecdbd993dc2afc
Reviewed-on: https://go-review.googlesource.com/43852
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Due to the fact that -cover injects additional code to the original
source, tests run with -cover will often have incorrect line numbers.
Also includes docs for -list regexp missed by ba8ff87
Updates #6329
Change-Id: I87f0618ac31e96071bca61055cc17c0cbdee208a
Reviewed-on: https://go-review.googlesource.com/38640
Reviewed-by: Rob Pike <r@golang.org>
According to RFC 6255 a cookie value may contain neither spaces " "
nor commas ",". But browsers seem to handle these pretty well and such
values are not uncommon in the wild so we do allow spaces and commas
in cookie values too. Up to now we use the double-quoted wire format
only for cookie values with leading and/or trailing spaces and commas.
Values with internal spaces/commas are sent without the optional double
quotes. This seems to be a problem for some agents.
This CL changes the behaviour for cookie values with spaces or commas:
Such values are always sent in double quotes. This should not have
any impact on existing agents and the increases of data transmitted
is negligible.
Fixes#18627
Change-Id: I575a98d589e048aa39d976a3c984550daaca730a
Reviewed-on: https://go-review.googlesource.com/37328
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trailers that are not announced in the Trailer must be passed on to
the downstream client.
Rather than iterate over each and find missing trailer values,
this re-adds all trailers to the headers if there is a disparity
between the number of announced trailers and the final number.
This fixes#20437
Change-Id: I867e85f45feff68616a9a9bd6f65f12d73825eb7
Reviewed-on: https://go-review.googlesource.com/43712
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Query and Exec functions on DB first attempt to get a cached
connection before requesting the connection pool to ignore
the cache and get a new connection. This change aligns Stmt to
that behavior as well.
Fixes#20433
Change-Id: Idda5f61927289d7ad0882effa3a50ffc9efd88e6
Reviewed-on: https://go-review.googlesource.com/43790
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Allow the memory limit passed into ReadForm to be used as the
memory limit for processing non-file form data as well as file
form data, rather than the existing behaviour of the memory limit
only applying to the file parts and the non-file parts being
arbitrarily limited to 10MB.
This ensures backwards compatibility while still providing the
user with control over the amount of non-file data that can be
processed instead of enforcing an arbitrary 10MB limit.
Change-Id: I53c09eae00147d3ff2d6bdfd4e50949267932c3d
Reviewed-on: https://go-review.googlesource.com/38195
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ensure that the implicitly created redirect
for
"/route"
after
"/route/"
has been registered doesn't lose the query string information.
Fixes#17841.
Change-Id: Ib7df9242fab8c9368a18fc0da678003d6bec63b8
Reviewed-on: https://go-review.googlesource.com/43779
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Many instructions can not have a .S suffix, such as MULS, SWI, CLZ,
CMP, STREX and others. And so do .P and .W suffixes. Even wrong
assembly code is generated for some instructions with invalid
suffixes.
This patch tries to simplify .S/.W/.P checks. And a wrong assembly
test for arm is added.
fixes#20377
Change-Id: Iba1c99d9e6b7b16a749b4d93ca2102e17c5822fe
Reviewed-on: https://go-review.googlesource.com/43561
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Instead of just printing the value, print the original node to make the
error more human-friendly. Also print the value if its string form is
different than the original node, to make sure it's obvious what value
was duplicated.
This means that "case '@', '@':", which used to print:
duplicate case 64 in switch
Will now print:
duplicate case '@' (value 64) in switch
Factor this logic out into its own function to reuse it in range cases
and any other place where we might want to print a node and its value in
the future.
Also needed to split the errorcheck files because expression switch case
duplicates are now detected earlier, so they stop the compiler before it
gets to generating the AST and detecting the type switch case
duplicates.
Fixes#20112.
Change-Id: I9009b50dec0d0e705e5de9c9ccb08f1dce8a5a99
Reviewed-on: https://go-review.googlesource.com/41852
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Android O black-lists the select system call because its libc, Bionic,
does not use this system call. Replace our use of select with pselect6
(which is allowed) on the platforms that support targeting Android.
linux/arm64 already uses pselect6 because there is no select on arm64,
so only linux/amd64 and linux/arm need changing. pselect6 has been
available since Linux 2.6.16, which is before Go's minimum
requirement.
Fixes#20409.
Change-Id: Ic526b5b259a9e01d2f145a1f4d2e76e8c49ce809
Reviewed-on: https://go-review.googlesource.com/43641
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change makes {TCP,UDP,IP,Unix}Conn types compliant of
syscall.Conn interface and adds type rawConn as an implementation of
syscall.RawConn interface.
By this change, the long-standing issues regarding unsupported socket
options and system calls can be solved partly and the broken x/net
packages due to https://go-review.googlesource.com/36799 can be
repaired.
Fixes#3661.
Updates #9661.
Updates #19051.
Updates #19435.
Change-Id: Ic996b040418b54f6d043bc70591789d5a5b23270
Reviewed-on: https://go-review.googlesource.com/37039
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds RawControl, RawRead and RawWrite methods to type FD
to make the runtime-integrated network poller work together with a
user-defined function. The methods are used via the net package from
external packages and type FD is considered as an implementation of
syscall.Conn and syscall.RawConn interfaces.
Updates #19435.
Change-Id: I4ad04b10ffddb2b54fa8d70587440960d73c0a2d
Reviewed-on: https://go-review.googlesource.com/37038
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds Conn and RawConn interfaces which can be used to
manipulate raw network connection end points typically represented as
socket descriptors.
Fixes#19435.
Change-Id: Ide2d28eeab91bfd27473ab47a87bec69950b64c9
Reviewed-on: https://go-review.googlesource.com/37913
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Recent CL 41834 made windows Stat work for all symlinks.
But CL 41834 also made Stat slow.
John Starks sugested
(see https://github.com/golang/go/issues/19922#issuecomment-300031421)
to use GetFileAttributesEx for files and directories instead.
This makes Stat as fast as at go1.9.
I see these improvements on my Windows 7
name old time/op new time/op delta
StatDot 26.5µs ± 1% 20.6µs ± 2% -22.37% (p=0.000 n=9+10)
StatFile 22.8µs ± 2% 6.2µs ± 1% -72.69% (p=0.000 n=10+10)
StatDir 21.0µs ± 2% 6.1µs ± 3% -71.12% (p=0.000 n=10+9)
LstatDot 20.1µs ± 1% 20.7µs ± 6% +3.37% (p=0.000 n=9+10)
LstatFile 6.23µs ± 1% 6.36µs ± 8% ~ (p=0.587 n=9+10)
LstatDir 6.10µs ± 0% 6.14µs ± 4% ~ (p=0.590 n=9+10)
and on my Windows XP
name old time/op new time/op delta
StatDot-2 20.6µs ± 0% 10.8µs ± 0% -47.44% (p=0.000 n=10+10)
StatFile-2 20.2µs ± 0% 7.9µs ± 0% -60.91% (p=0.000 n=8+10)
StatDir-2 19.3µs ± 0% 7.6µs ± 0% -60.51% (p=0.000 n=10+9)
LstatDot-2 10.8µs ± 0% 10.8µs ± 0% -0.48% (p=0.000 n=10+8)
LstatFile-2 7.83µs ± 0% 7.83µs ± 0% ~ (p=0.844 n=10+8)
LstatDir-2 7.59µs ± 0% 7.56µs ± 0% -0.46% (p=0.000 n=10+10)
Updates #19922
Change-Id: Ice1fb5825defb05c79bab4dec0692e0fd1bcfcd5
Reviewed-on: https://go-review.googlesource.com/43071
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestScopeRanges has been added in CL 40095. This
test is failing on Plan 9 because executables don't
have a DWARF symbol table.
Fixes#20418.
Change-Id: I6dd3baa636998134ccd042203c8b5c3199a4d6e1
Reviewed-on: https://go-review.googlesource.com/43670
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change compiler and linker to emit DWARF lexical blocks in .debug_info
section when compiling with -N -l.
Version of debug_info is updated from DWARF v2 to DWARF v3 since
version 2 does not allow lexical blocks with discontinuous PC ranges.
Remaining open problems:
- scope information is removed from inlined functions
- variables records do not have DW_AT_start_scope attributes so a
variable will shadow other variables with the same name as soon as its
containing scope begins, even before its declaration.
Updates #6913.
Updates #12899.
Change-Id: Idc6808788512ea20e7e45bcf782453acb416fb49
Reviewed-on: https://go-review.googlesource.com/40095
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
A number of issues in decoder.Read and newlineFilteringReader.Read were
preventing errors from the reader supplying the encoded data from being
propagated to the caller. Fixing these issues revealed some additional
problems in which valid decoded data was not always returned to the user
when errors were actually propagated.
This commit fixes both the error propagation and the lost decoded data
problems. It also adds some new unit tests to ensure errors are handled
correctly by decoder.Read. The new unit tests increase the test coverage
of this package from 96.2% to 97.9%.
Fixes#20044
Change-Id: I1a8632da20135906e2d191c2a8825b10e7ecc4c5
Reviewed-on: https://go-review.googlesource.com/42094
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously all arguments were passed through driver.IsValid.
This checked arguments against a few fundamental go types and
prevented others from being passed in as arguments.
The new interface driver.NamedValueChecker may be implemented
by both driver.Stmt and driver.Conn. This allows
this new interface to completely supersede the
driver.ColumnConverter interface as it can be used for
checking arguments known to a prepared statement and
arbitrary query arguments. The NamedValueChecker may be
skipped with driver.ErrSkip after all special cases are
exhausted to use the default argument converter.
In addition if driver.ErrRemoveArgument is returned
the argument will not be passed to the query at all,
useful for passing in driver specific per-query options.
Add a canonical Out argument wrapper to be passed
to OUTPUT parameters. This will unify checks that need to
be written in the NameValueChecker.
The statement number check is also moved to the argument
converter so the NamedValueChecker may remove arguments
passed to the query.
Fixes#13567Fixes#18079
Updates #18417
Updates #17834
Updates #16235
Updates #13067
Updates #19797
Change-Id: I89088bd9cca4596a48bba37bfd20d987453ef237
Reviewed-on: https://go-review.googlesource.com/38533
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Cannot reproduce original problem. Compiler internals
have changed enough such that this appears to work now.
Restore original test (exported interfaces), but also
keep version of the test using non-exported interfaces.
Fixes#15596.
Change-Id: Idb32da80239963242bd5d1609343c80f19773b0c
Reviewed-on: https://go-review.googlesource.com/43622
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The writebarrier pass processes WB ops from beginning to end,
replacing them by other values.
But it also checks whether there are more ops to process
by walking from beginning to end.
This is quadratic, so walk from end to beginning instead.
This speeds up compiling the code in issue 13554:
name old time/op new time/op delta
Pkg 11.9s ± 2% 8.3s ± 3% -29.88% (p=0.000 n=18+17)
Updates #13554
Passes toolstash-check.
Change-Id: I5f8a872ddc4b783540220d89ea2ee188a6d2b2ff
Reviewed-on: https://go-review.googlesource.com/43571
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
SWI only support "SWI $imm", but currently "SWI (Reg)" is also
accepted. This patch fixes it.
And more instruction tests are added to cmd/asm/internal/asm/testdata/arm.s
fixes#20375
Change-Id: Id437d853924a403e41da9b6cbddd20d994b624ff
Reviewed-on: https://go-review.googlesource.com/43552
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Second attempt to fix#14710.
CL 35272 already tried to fix this issue. But CL 35272 assumed
that runtime.epclntab type is STEXT, while it is actually SRODATA.
This CL uses Symbol.Sect.Seg to determine if symbol is part
of Segtext or Segdata.
Fixes#14710
Change-Id: Ic6b6f657555c87a64d2bc36cc4c07ab0591d00c4
Reviewed-on: https://go-review.googlesource.com/42390
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
profileBuilder.locForPC returns 0 to mean "no location" because 0 is
an invalid location index. However, the code to build count profiles
doesn't check the result of locForPC, so this 0 location index ends up
in the profile's location list. This, in turn, causes problems later
when we decode the profile because it puts a nil *Location in the
sample's location slice, which can later lead to a nil pointer panic.
Fix this by making printCountProfile correctly discard the result of
locForPC if it returns 0. This makes this call match the other two
calls of locForPC.
Updates #15156.
Change-Id: I4492b3652b513448bc56f4cfece4e37da5e42f94
Reviewed-on: https://go-review.googlesource.com/43630
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestGoroutineCounts was flaky when running on a system under load.
This happened on three builds the last couple of days.
Fix this by running this test with a single operating system thread, so
we do not depend on the operating system scheduler. 50 000 tests ran
without failure with the new version, the old version failed 0.5% of the
time.
Fixes#15156.
Change-Id: I1e5a18d0fef4f72cc9a56e376822b2849cdb0f8b
Reviewed-on: https://go-review.googlesource.com/43590
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
fuseBlockPlain was accidentally quadratic.
If you had plain blocks b1 -> b2 -> b3 -> b4,
each containing single values v1, v2, v3, and v4 respectively,
fuseBlockPlain would move v1 from b1 to b2 to b3 to b4,
then v2 from b2 to b3 to b4, etc.
There are two obvious fixes.
* Look for runs of blocks in fuseBlockPlain
and handle them in a single go.
* Fuse from end to beginning; any given value in a run
of blocks to fuse then moves only once.
The latter is much simpler, so that's what this CL does.
Somewhat surprisingly, this change does not pass toolstash-check.
The resulting set of blocks is the same,
and the values in them are the same,
but the order of values in them differ,
and that order of values (while arbitrary)
is enough to change the compiler's output.
This may be due to #20178; deadstore is the next pass after fuse.
Adding basic sorting to the beginning of deadstore
is enough to make this CL pass toolstash-check:
for _, b := range f.Blocks {
obj.SortSlice(b.Values, func(i, j int) bool { return b.Values[i].ID < b.Values[j].ID })
}
Happily, this CL appears to result in better code on average,
if only by accident. It cuts 4k off of cmd/go; go1 benchmarks
are noisy as always but don't regress (numbers below).
No impact on the standard compilebench benchmarks.
For the code in #13554, this speeds up compilation dramatically:
name old time/op new time/op delta
Pkg 53.1s ± 2% 12.8s ± 3% -75.92% (p=0.008 n=5+5)
name old user-time/op new user-time/op delta
Pkg 55.0s ± 2% 14.9s ± 3% -73.00% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
Pkg 2.04GB ± 0% 2.04GB ± 0% +0.18% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Pkg 6.21M ± 0% 6.21M ± 0% ~ (p=0.222 n=5+5)
name old object-bytes new object-bytes delta
Pkg 28.4M ± 0% 28.4M ± 0% +0.00% (p=0.008 n=5+5)
name old export-bytes new export-bytes delta
Pkg 208 ± 0% 208 ± 0% ~ (all equal)
Updates #13554
go1 benchmarks:
name old time/op new time/op delta
BinaryTree17-8 2.29s ± 2% 2.26s ± 2% -1.43% (p=0.000 n=48+50)
Fannkuch11-8 2.74s ± 2% 2.79s ± 2% +1.63% (p=0.000 n=50+49)
FmtFprintfEmpty-8 36.6ns ± 3% 34.6ns ± 4% -5.29% (p=0.000 n=49+50)
FmtFprintfString-8 58.3ns ± 3% 59.1ns ± 3% +1.35% (p=0.000 n=50+49)
FmtFprintfInt-8 62.4ns ± 2% 63.2ns ± 3% +1.19% (p=0.000 n=49+49)
FmtFprintfIntInt-8 95.1ns ± 2% 96.7ns ± 3% +1.61% (p=0.000 n=49+50)
FmtFprintfPrefixedInt-8 118ns ± 3% 113ns ± 2% -4.00% (p=0.000 n=50+49)
FmtFprintfFloat-8 191ns ± 2% 192ns ± 2% +0.40% (p=0.034 n=50+50)
FmtManyArgs-8 419ns ± 2% 420ns ± 2% ~ (p=0.228 n=49+49)
GobDecode-8 5.26ms ± 3% 5.19ms ± 2% -1.33% (p=0.000 n=50+49)
GobEncode-8 4.12ms ± 2% 4.15ms ± 3% +0.68% (p=0.007 n=49+50)
Gzip-8 198ms ± 2% 197ms ± 2% -0.50% (p=0.018 n=48+48)
Gunzip-8 31.9ms ± 3% 31.8ms ± 3% -0.47% (p=0.024 n=50+50)
HTTPClientServer-8 64.4µs ± 0% 64.0µs ± 0% -0.55% (p=0.000 n=43+46)
JSONEncode-8 10.6ms ± 2% 10.6ms ± 3% ~ (p=0.543 n=49+49)
JSONDecode-8 43.3ms ± 3% 43.1ms ± 2% ~ (p=0.079 n=50+50)
Mandelbrot200-8 3.70ms ± 2% 3.70ms ± 2% ~ (p=0.553 n=47+50)
GoParse-8 2.70ms ± 2% 2.71ms ± 3% ~ (p=0.843 n=49+50)
RegexpMatchEasy0_32-8 70.5ns ± 4% 70.4ns ± 4% ~ (p=0.867 n=48+50)
RegexpMatchEasy0_1K-8 162ns ± 3% 162ns ± 2% ~ (p=0.739 n=48+48)
RegexpMatchEasy1_32-8 66.1ns ± 5% 66.2ns ± 4% ~ (p=0.970 n=50+50)
RegexpMatchEasy1_1K-8 297ns ± 7% 296ns ± 7% ~ (p=0.406 n=50+50)
RegexpMatchMedium_32-8 105ns ± 5% 105ns ± 5% ~ (p=0.702 n=50+50)
RegexpMatchMedium_1K-8 32.3µs ± 4% 32.2µs ± 3% ~ (p=0.614 n=49+49)
RegexpMatchHard_32-8 1.75µs ±18% 1.74µs ±12% ~ (p=0.738 n=50+48)
RegexpMatchHard_1K-8 52.2µs ±14% 51.3µs ±13% ~ (p=0.230 n=50+50)
Revcomp-8 366ms ± 3% 367ms ± 3% ~ (p=0.745 n=49+49)
Template-8 48.5ms ± 4% 48.5ms ± 4% ~ (p=0.824 n=50+48)
TimeParse-8 263ns ± 2% 256ns ± 2% -2.98% (p=0.000 n=48+49)
TimeFormat-8 265ns ± 3% 262ns ± 3% -1.35% (p=0.000 n=48+49)
[Geo mean] 41.1µs 40.9µs -0.48%
Change-Id: Ib35fa15b54282abb39c077d150beee27f610891a
Reviewed-on: https://go-review.googlesource.com/43570
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When the race detector is enabled,
the compiler randomizes the order in which functions are compiled,
in an attempt to shake out bugs.
But we never re-seed the rand source, so every execution is identical.
Fix that to get more coverage.
Change-Id: If5cdde03ef4f1bab5f45e07f03fb6614945481d7
Reviewed-on: https://go-review.googlesource.com/43572
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, cgo converts integer macros into int64 if it's possible.
As a result, some macros which satisfy
math.MaxInt64 < x <= math.MaxUint64
will lose their original values.
This CL introduces the new probe to check signs,
so we can handle signed ints and unsigned ints separately.
Fixes#20369
Change-Id: I002ba452a82514b3a87440960473676f842cc9ee
Reviewed-on: https://go-review.googlesource.com/43476
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The generated file runtime/internal/sys/zversion.go is deleted by
`go tool cmd dist clean` as part of running clean.bash. Don't treat
a missing file as a reason to stop running the go tool; just treat
is as meaning that runtime/internal/sys is stale.
No test because I don't particularly want to clobber $GOROOT.
Fixes#20385.
Change-Id: I5251a99542cc93c33f627f133d7118df56e18af1
Reviewed-on: https://go-review.googlesource.com/43559
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Restore the handling of io.ErrShortWrite in (*File).Write:
if we write less than the requested amount, and there is no error from
the syscall, then return io.ErrShortWrite.
I can't figure out how to write a test for this. It would require a
non-pollable file (not a pipe) on a device that is almost but not
quite entirely full. The original code (https://golang.org/cl/36800043,
committed as part of https://golang.org/cl/36930044) does not have a test.
Fixes#20386.
Change-Id: Ied7b411e621e1eaf49f864f8db90069f276256f5
Reviewed-on: https://go-review.googlesource.com/43558
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In low memory situations mmap(2) on Illumos[2] can return EAGAIN when it
is unable to reserve the necessary space for the requested mapping. Go
was not previously handling this correctly for Illumos and would fail to
recognize it was in a low-memory situation, the result being the program
would terminate with a panic instead of running the GC.
Fixes: #14930
[1]: https://www.illumos.org/man/2/mmap
Change-Id: I889cc0547e23f9d6c56e4fdd7bcbd0e15403873a
Reviewed-on: https://go-review.googlesource.com/43461
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On other systems we use "SWI $n". Change Plan 9 files to be
consistent. Generated binary is unchanged.
Fixes#20378.
Change-Id: Ia2a722061da2450c7b30cb707ed4f172fafecf74
Reviewed-on: https://go-review.googlesource.com/43533
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
LLV and SCV are 64-bit load-linked and store-conditional. They
were used in runtime as #define WORD. Change them to normal
instruction form.
NOOP is hardware no-op. It was written as WORD $0. Make a name
for it for better disassembly output.
Fixes#12561.
Fixes#18238.
Change-Id: I82c667ce756fa83ef37b034b641e8c4366335e83
Reviewed-on: https://go-review.googlesource.com/40297
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds several examples, with emphasis on special or edge
cases such as a directory parameter consisting of an empty string.
Change-Id: Ib4ac3d0f6d503493eeed0c4fda7c12acf782e9e2
Reviewed-on: https://go-review.googlesource.com/43010
Reviewed-by: Steve Francia <spf@golang.org>
Run-TryBot: Jaana Burcu Dogan <jbd@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previous CL (cmd/internal/objabi: shrink SymType down to a uint8) shrinks
SymType down to a uint8 but forgot making according change in goobj.
Fixes#20296
Also add a test to catch such Goobj format inconsistency bug
Change-Id: Ib43dd7122cfcacf611a643814e95f8c5a924941f
Reviewed-on: https://go-review.googlesource.com/42971
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Mark variables as used even when they appear within an expression
context which we can't type-check; e.g., because the expression is
erroneous, or comes from an import "C" declaration.
Fixes#20358.
Change-Id: Ib28cc78d3867c597c7a1ace54de09ada02f5b33a
Reviewed-on: https://go-review.googlesource.com/43500
Reviewed-by: Alan Donovan <adonovan@google.com>
Attaching positions to SB, SP, initial mem can result in
less-good line-numbering when compiled for debugging.
This "fix" also removes source position from a zero-valued
struct (but not from its fields) and from a zero-length
array constant.
This may be a general problem for constants in entry blocks.
Fixes#20367.
Change-Id: I7e9df3341be2e2f60f127d35bb31e43cdcfce9a1
Reviewed-on: https://go-review.googlesource.com/43531
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Enhance the one-live-memory-at-a-time check to run during many
more phases of the SSA backend. Also make it work in an interblock
fashion.
Change types.IsMemory to return true for tuples containing a memory type.
Fix trim pass to build the merged phi correctly. Doesn't affect
code but allows the check to pass after trim runs.
Switch the AddTuple* ops to take the memory-containing tuple argument second.
Update #20335
Change-Id: I5b03ef3606b75a9e4f765276bb8b183cdc172b43
Reviewed-on: https://go-review.googlesource.com/43495
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Documentation of build.Import says:
// If the path is a local import path naming a package that can be imported
// using a standard import path, the returned package will set p.ImportPath
// to that path.
// ...
// If an error occurs, Import returns a non-nil error and a non-nil
// *Package containing partial information.
That behavior was previously untested, and broken by change in CL 33158.
Fix that by avoiding returning early on error for local import paths.
First, gather partial information, and only then check that the p.Dir
directory exists.
Add tests for this behavior.
Fixes#19769.
Fixes#20175 (duplicate of #19769).
Updates #17863.
Change-Id: I169cb35291099d05e02aaa3cb23a7403d1cc3657
Reviewed-on: https://go-review.googlesource.com/42350
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently proto symbolization uses runtime.FuncForPC and assumes each
PC maps to a single frame. This isn't true in the presence of inlining
(even with leaf-only inlining this can get incorrect results).
Change PC symbolization to use runtime.CallersFrames to expand each PC
to all of the frames at that PC.
Change-Id: I8d20dff7495a5de495ae07f569122c225d433ced
Reviewed-on: https://go-review.googlesource.com/41256
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Proto profile conversion is inconsistent about call vs return PCs in
profile locations. The proto defines locations to be call PCs. This is
what we do when proto-izing CPU profiles, but we fail to convert the
return PCs in memory and count profile stacks to call PCs when
converting them to proto locations.
Fix this in the heap and count profile conversion functions.
TestConvertMemProfile also hard-codes this failure to convert from
return PCs to call PCs, so fix up the addresses in the synthesized
profile to be return PCs while checking that we get call PCs out of
the conversion.
Change-Id: If1fc028b86fceac6d71a2d9fa6c41ff442c89296
Reviewed-on: https://go-review.googlesource.com/42951
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Adjust finddebugruntimepath to look for runtime/debug.go file
instead of runtime/runtime.go. This actually finds runtime.GOMAXPROCS
in every Go executable (including windows).
I also included "-Wl,-T,fix_debug_gdb_scripts.ld" parameter to gcc
invocation on windows to work around gcc bug (see #20183 for details).
This CL only fixes windows -buildmode=exe, buildmode=c-archive
is still broken.
Thanks to Egon Elbre and Nick Clifton for investigation.
Fixes#20183Fixes#20218
Change-Id: I5369a4db3913226aef3d9bd6317446856b0a1c34
Reviewed-on: https://go-review.googlesource.com/43331
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Make yellow the last highlight color rather than the first.
Yellow is also the color that Chrome uses to highlight
search results, which can be confusing.
Also, when Night Shift is on on macOS,
yellow highlighting is completely invisible.
I suppose should be sleeping instead.
Also, remove a completed TODO.
Change-Id: I0eb4439272fad9ccb5fe8e2cf409fdd5dc15b26e
Reviewed-on: https://go-review.googlesource.com/43463
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When compiling concurrently, we walk all functions before compiling
any of them. Walking functions can cause variables to switch from
being non-addrtaken to addrtaken, e.g. to prepare for a runtime call.
Typechecking propagates addrtaken-ness of closure variables to
their outer variables, so that capturevars can decide whether to
pass the variable's value or a pointer to it.
When all functions are compiled immediately, as long as the containing
function is compiled prior to the closure, this propagation has no effect.
When compilation is deferred, though, in rare cases, this results in
a change in the addrtaken-ness of a variable in the outer function,
which in turn changes the compiler's output.
(This is rare because in a great many cases, a temporary has been
introduced, insulating the outer variable from modification.)
But concurrent compilation must generate identical results.
To fix this, track whether capturevars has run.
If it has, there is no need to update outer variables
when closure variables change.
Capturevars always runs before any functions are walked or compiled.
The remainder of the changes in this CL are to support the test.
In particular, -d=compilelater forces the compiler to walk all
functions before compiling any of them, despite being non-concurrent.
This is useful because -live is fundamentally incompatible with
concurrent compilation, but we want -c=1 to have no behavior changes.
Fixes#20250
Change-Id: I89bcb54268a41e8588af1ac8cc37fbef856a90c2
Reviewed-on: https://go-review.googlesource.com/42853
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
While at it, unindent source text so column values are easier
to read, remove unnecessary text in output, and simplify the
loop.
Fixes#20346.
Change-Id: I0fde02b9e4242383da427f4cf4c6c13dd0ab3b47
Reviewed-on: https://go-review.googlesource.com/43450
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In some cases it is desirable to customize the way the DNS server is
contacted, for instance to use a specific LocalAddr. While most
operating-system level resolvers do not allow this, we have the
opportunity to do so with the Go resolver. Most of the code was
already in place to allow tests to override the dialer. This exposes
that functionality, and as a side effect eliminates the need for a
testing hook.
Fixes#17404
Change-Id: I1c5e570f8edbcf630090f8ec6feb52e379e3e5c0
Reviewed-on: https://go-review.googlesource.com/37260
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
runtime.gchelper depends on the non-atomic load of work.ndone
happening strictly before the atomic add of work.nwait. Until very
recently (commit 978af9c2db, fixing #20334), the compiler reordered
these operations. This created a race since work.ndone can change as
soon as work.nwait is equal to work.ndone. If that happened, more than
one gchelper could attempt to wake up the work.alldone note, causing a
"double wakeup" panic.
This was fixed in the compiler, but to make this code less subtle,
make the load of work.ndone atomic. This clearly forces the order of
these operations, ensuring the race doesn't happen.
Fixes#19305 (though really 978af9c2db fixed it).
Change-Id: Ieb1a84e1e5044c33ac612c8a5ab6297e7db4c57d
Reviewed-on: https://go-review.googlesource.com/43311
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TestCgoContainsSpace builds a small program which mimics $CC.
Usually, $CC attempts to compile a trivial code to detect its own
supported flags (i.e. "-no-pie", which must be passed on some systems),
however the mimic didn't consider these cases.
This CL solve the issue.
Also, use the same name as $CC, it may solve other potential problems.
Fixes#20324
Change-Id: I7a00ac016a5fd0667540f2a715371f8152edc395
Reviewed-on: https://go-review.googlesource.com/43330
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Tuple ops are weird. They are essentially a pair of ops,
one which consumes a mem and one which generates a mem (the Select1).
The schedule pass didn't handle these quite right.
Fix the scheduler to include both parts of the paired op in
the store chain. That makes sure that loads are correctly ordered
with respect to the first of the pair.
Add a check for the ssacheck builder, that there is only one
live store at a time. I thought we already had such a check, but
apparently not...
Fixes#20335
Change-Id: I59eb3446a329100af38d22820b1ca2190ca46a78
Reviewed-on: https://go-review.googlesource.com/43294
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The writebarrier test has to change.
Now that T23 composite literals are passed to the backend,
they get SSA'd, so writes to their fields are treated separately,
so the relevant part of the first write to t23 is now a dead store.
Preserve the intent of the test by splitting it up into two functions.
Reduces code size a bit:
name old object-bytes new object-bytes delta
Template 386k ± 0% 386k ± 0% ~ (all equal)
Unicode 202k ± 0% 202k ± 0% ~ (all equal)
GoTypes 1.16M ± 0% 1.16M ± 0% ~ (all equal)
Compiler 3.92M ± 0% 3.91M ± 0% -0.19% (p=0.008 n=5+5)
SSA 7.91M ± 0% 7.91M ± 0% ~ (all equal)
Flate 228k ± 0% 228k ± 0% -0.05% (p=0.008 n=5+5)
GoParser 283k ± 0% 283k ± 0% ~ (all equal)
Reflect 952k ± 0% 952k ± 0% -0.06% (p=0.008 n=5+5)
Tar 188k ± 0% 188k ± 0% -0.09% (p=0.008 n=5+5)
XML 406k ± 0% 406k ± 0% -0.02% (p=0.008 n=5+5)
[Geo mean] 649k 648k -0.04%
Fixes#18872
Change-Id: Ifeed0f71f13849732999aa731cc2bf40c0f0e32a
Reviewed-on: https://go-review.googlesource.com/43154
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
v is not a pointer receiver, and v.typ isn't used in the lines below.
The assignment is dead. Remove it.
Keep the comment, as it refers to the whole case block and not just the
removed line.
Change-Id: Icb2d20c287d9a41bf620ebe5cdec764cd84178a7
Reviewed-on: https://go-review.googlesource.com/43134
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reuse block head or preceding instruction's line number for
register allocator's spill, fill, copy, rematerialization
instructionsl; and also for phi, and for no-src-pos
instructions. Assembler creates same line number tables
for copy-predecessor-line and for no-src-pos,
but copy-predecessor produces better-looking assembly
language output with -S and with GOSSAFUNC, and does not
require changes to tests of existing assembly language.
Split "copyInto" into two cases, one for register allocation,
one for otherwise. This caused the test score line change
count to increase by one, which may reflect legitimately
useful information preserved. Without any special treatment
for copyInto, the change count increases by 21 more, from
51 to 72 (i.e., quite a lot).
There is a test; using two naive "scores" for line number
churn, the old numbering is 2x or 4x worse.
Fixes#18902.
Change-Id: I0a0a69659d30ee4e5d10116a0dd2b8c5df8457b1
Reviewed-on: https://go-review.googlesource.com/36207
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Implements detection of x86 cpu features that
are used in the go standard library.
Changes all standard library packages to use the new cpu package
instead of using runtime internal variables to check x86 cpu features.
Updates: #15403
Change-Id: I2999a10cb4d9ec4863ffbed72f4e021a1dbc4bb9
Reviewed-on: https://go-review.googlesource.com/41476
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Eliminates stores of values that have just been loaded from the same
location. Handles the common case where there are up to 3 intermediate
stores to non-overlapping struct fields.
For example the loads and stores of x.a, x.b and x.d in the following
function are now removed:
type T struct {
a, b, c, d int
}
func f(x *T) {
y := *x
y.c += 8
*x = y
}
Before this CL (s390x):
TEXT "".f(SB)
MOVD "".x(R15), R5
MOVD (R5), R1
MOVD 8(R5), R2
MOVD 16(R5), R0
MOVD 24(R5), R4
ADD $8, R0, R3
STMG R1, R4, (R5)
RET
After this CL (s390x):
TEXT "".f(SB)
MOVD "".x(R15), R1
MOVD 16(R1), R0
ADD $8, R0, R0
MOVD R0, 16(R1)
RET
In total these rules are triggered ~5091 times during all.bash,
which is broken down as:
Intermediate stores | Triggered
--------------------+----------
0 | 1434
1 | 2508
2 | 888
3 | 261
--------------------+----------
Change-Id: Ia4721ae40146aceec1fdd3e65b0e9283770bfba5
Reviewed-on: https://go-review.googlesource.com/38793
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The files PPC64.rules and rewritePPC64.go were out of sync due to
conflicts between CL 41630 and CL 42145 (i.e. running 'go run *.go'
in the gen directory resulted in unexpected changes).
Change-Id: I1d409656b66afeab6cb9c6df9b3dcab7859caa75
Reviewed-on: https://go-review.googlesource.com/43091
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This can make life easier for Delve (and other debuggers),
and can help them with bug reports.
Sample producer field (from objdump):
<48> DW_AT_producer : Go cmd/compile devel +8a59dbf41a Mon May 8 16:02:44 2017 -0400
Change-Id: I0605843c959b53a60a25a3b870aa8755bf5d5b13
Reviewed-on: https://go-review.googlesource.com/33588
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We do a division by the elem type size to check if the array size would
be too large for the virtual address space. This is a silly check if the
size is 0, but the problem is that it means a division by zero and a
panic.
Since arrays of empty structs are valid in a regular program, make them
also work in reflect.
Use a separate, explicit test with struct{}{} to make sure the test for
a zero-sized type is not confused with the rest.
Fixes#20313.
Change-Id: I47b8b87e6541631280b79227bdea6a0f6035c9e0
Reviewed-on: https://go-review.googlesource.com/43131
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This adds math/bits intrinsics for OnesCount, Len, TrailingZeros on
ppc64x.
benchmark old ns/op new ns/op delta
BenchmarkLeadingZeros-16 4.26 1.71 -59.86%
BenchmarkLeadingZeros16-16 3.04 1.83 -39.80%
BenchmarkLeadingZeros32-16 3.31 1.82 -45.02%
BenchmarkLeadingZeros64-16 3.69 1.71 -53.66%
BenchmarkTrailingZeros-16 2.55 1.62 -36.47%
BenchmarkTrailingZeros32-16 2.55 1.77 -30.59%
BenchmarkTrailingZeros64-16 2.78 1.62 -41.73%
BenchmarkOnesCount-16 3.19 0.93 -70.85%
BenchmarkOnesCount32-16 2.55 1.18 -53.73%
BenchmarkOnesCount64-16 3.22 0.93 -71.12%
Update #18616
I also made a change to bits_test.go because when debugging some failures
the output was not quite providing the right argument information.
Change-Id: Ia58d31d1777cf4582a4505f85b11a1202ca07d3e
Reviewed-on: https://go-review.googlesource.com/41630
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
When constructing a new type for an array type in ArrayOf, we don't
reset tflag to 0. All the other methods in the package, such as SliceOf,
do this already. This results in the new array type having weird issues
when being printed, such as having tflagExtraStar set when it shouldn't.
That flag removes the first char to get rid of '*', but when used
incorrectly in this case it eats the '[' character leading to broken
strings like "3]int".
This was fixed in 56752eb2 for issue #16722, but ArrayOf was missed.
Also make the XM test struct have a non-zero size as that leads to a
division by zero panic in ArrayOf.
Fixes#20311.
Change-Id: I18f1027fdbe9f71767201e7424269c3ceeb23eb5
Reviewed-on: https://go-review.googlesource.com/43130
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
OpVarXXX Values don't generate instructions,
so there's no reason not to duplicate them,
and duplicating them generates better code
(fewer branches).
This requires changing the start/end accounting
to correctly handle the case in which we have run
of Values beginning with an OpVarXXX, e.g.
OpVarDef, OpZeroWB, OpMoveWB.
In that case, the sequence of values should begin
at the OpZeroWB, not the OpVarDef.
This also lays the groundwork for experimenting
with allowing duplication of some scalar stores.
Shrinks function text sizes a tiny amount:
name old object-bytes new object-bytes delta
Template 381k ± 0% 381k ± 0% -0.01% (p=0.008 n=5+5)
Unicode 203k ± 0% 203k ± 0% -0.04% (p=0.008 n=5+5)
GoTypes 1.17M ± 0% 1.17M ± 0% -0.01% (p=0.008 n=5+5)
SSA 8.24M ± 0% 8.24M ± 0% -0.00% (p=0.008 n=5+5)
Flate 230k ± 0% 230k ± 0% ~ (all equal)
GoParser 286k ± 0% 286k ± 0% ~ (all equal)
Reflect 1.00M ± 0% 1.00M ± 0% ~ (all equal)
Tar 189k ± 0% 189k ± 0% ~ (all equal)
XML 415k ± 0% 415k ± 0% -0.01% (p=0.008 n=5+5)
Updates #19838
Change-Id: Ic5ef30855919f1468066eba08ae5c4bd9a01db27
Reviewed-on: https://go-review.googlesource.com/42011
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In PPC64 ELF files, the st_other field indicates the number of
prologue instructions between the global and local entry points.
We add the instructions in the compiler and assembler if -shared is used.
We were assuming that the instructions were present when building a
c-archive or PIE or doing dynamic linking, on the assumption that those
are the cases where the go tool would be building with -shared.
That assumption fails when using some other tool, such as Bazel,
that does not necessarily use -shared in exactly the same way.
This CL records in the object file whether a symbol was compiled
with -shared (this will be the same for all symbols in a given compilation)
and uses that information when setting the st_other field.
Fixes#20290.
Change-Id: Ib2b77e16aef38824871102e3c244fcf04a86c6ea
Reviewed-on: https://go-review.googlesource.com/43051
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When package ssa was created, Type was in package gc.
To avoid circular dependencies, we used an interface (ssa.Type)
to represent type information in SSA.
In the Go 1.9 cycle, gri extricated the Type type from package gc.
As a result, we can now use it in package ssa.
Now, instead of package types depending on package ssa,
it is the other way.
This is a more sensible dependency tree,
and helps compiler performance a bit.
Though this is a big CL, most of the changes are
mechanical and uninteresting.
Interesting bits:
* Add new singleton globals to package types for the special
SSA types Memory, Void, Invalid, Flags, and Int128.
* Add two new Types, TSSA for the special types,
and TTUPLE, for SSA tuple types.
ssa.MakeTuple is now types.NewTuple.
* Move type comparison result constants CMPlt, CMPeq, and CMPgt
to package types.
* We had picked the name "types" in our rules for the handy
list of types provided by ssa.Config. That conflicted with
the types package name, so change it to "typ".
* Update the type comparison routine to handle tuples and special
types inline.
* Teach gc/fmt.go how to print special types.
* We can now eliminate ElemTypes in favor of just Elem,
and probably also some other duplicated Type methods
designed to return ssa.Type instead of *types.Type.
* The ssa tests were using their own dummy types,
and they were not particularly careful about types in general.
Of necessity, this CL switches them to use *types.Type;
it does not make them more type-accurate.
Unfortunately, using types.Type means initializing a bit
of the types universe.
This is prime for refactoring and improvement.
This shrinks ssa.Value; it now fits in a smaller size class
on 64 bit systems. This doesn't have a giant impact,
though, since most Values are preallocated in a chunk.
name old alloc/op new alloc/op delta
Template 37.9MB ± 0% 37.7MB ± 0% -0.57% (p=0.000 n=10+8)
Unicode 28.9MB ± 0% 28.7MB ± 0% -0.52% (p=0.000 n=10+10)
GoTypes 110MB ± 0% 109MB ± 0% -0.88% (p=0.000 n=10+10)
Flate 24.7MB ± 0% 24.6MB ± 0% -0.66% (p=0.000 n=10+10)
GoParser 31.1MB ± 0% 30.9MB ± 0% -0.61% (p=0.000 n=10+9)
Reflect 73.9MB ± 0% 73.4MB ± 0% -0.62% (p=0.000 n=10+8)
Tar 25.8MB ± 0% 25.6MB ± 0% -0.77% (p=0.000 n=9+10)
XML 41.2MB ± 0% 40.9MB ± 0% -0.80% (p=0.000 n=10+10)
[Geo mean] 40.5MB 40.3MB -0.68%
name old allocs/op new allocs/op delta
Template 385k ± 0% 386k ± 0% ~ (p=0.356 n=10+9)
Unicode 343k ± 1% 344k ± 0% ~ (p=0.481 n=10+10)
GoTypes 1.16M ± 0% 1.16M ± 0% -0.16% (p=0.004 n=10+10)
Flate 238k ± 1% 238k ± 1% ~ (p=0.853 n=10+10)
GoParser 320k ± 0% 320k ± 0% ~ (p=0.720 n=10+9)
Reflect 957k ± 0% 957k ± 0% ~ (p=0.460 n=10+8)
Tar 252k ± 0% 252k ± 0% ~ (p=0.133 n=9+10)
XML 400k ± 0% 400k ± 0% ~ (p=0.796 n=10+10)
[Geo mean] 428k 428k -0.01%
Removing all the interface calls helps non-trivially with CPU, though.
name old time/op new time/op delta
Template 178ms ± 4% 173ms ± 3% -2.90% (p=0.000 n=94+96)
Unicode 85.0ms ± 4% 83.9ms ± 4% -1.23% (p=0.000 n=96+96)
GoTypes 543ms ± 3% 528ms ± 3% -2.73% (p=0.000 n=98+96)
Flate 116ms ± 3% 113ms ± 4% -2.34% (p=0.000 n=96+99)
GoParser 144ms ± 3% 140ms ± 4% -2.80% (p=0.000 n=99+97)
Reflect 344ms ± 3% 334ms ± 4% -3.02% (p=0.000 n=100+99)
Tar 106ms ± 5% 103ms ± 4% -3.30% (p=0.000 n=98+94)
XML 198ms ± 5% 192ms ± 4% -2.88% (p=0.000 n=92+95)
[Geo mean] 178ms 173ms -2.65%
name old user-time/op new user-time/op delta
Template 229ms ± 5% 224ms ± 5% -2.36% (p=0.000 n=95+99)
Unicode 107ms ± 6% 106ms ± 5% -1.13% (p=0.001 n=93+95)
GoTypes 696ms ± 4% 679ms ± 4% -2.45% (p=0.000 n=97+99)
Flate 137ms ± 4% 134ms ± 5% -2.66% (p=0.000 n=99+96)
GoParser 176ms ± 5% 172ms ± 8% -2.27% (p=0.000 n=98+100)
Reflect 430ms ± 6% 411ms ± 5% -4.46% (p=0.000 n=100+92)
Tar 128ms ±13% 123ms ±13% -4.21% (p=0.000 n=100+100)
XML 239ms ± 6% 233ms ± 6% -2.50% (p=0.000 n=95+97)
[Geo mean] 220ms 213ms -2.76%
Change-Id: I15c7d6268347f8358e75066dfdbd77db24e8d0c1
Reviewed-on: https://go-review.googlesource.com/42145
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 39915 introduced sorting of signats by ShortString
for reproducible builds. But ShortString treats types
byte and uint8 identically; same for rune and uint32.
CL 39915 attempted to compensate for this by only
adding the underlying type (uint8) to signats in addsignat.
This only works for byte and uint8. For e.g. *byte and *uint,
both get added, and their sort order is random,
leading to non-reproducible builds.
One fix would be to add yet another type printing mode
that doesn't eliminate byte and rune, and use it
for sorting signats. But the formatting routines
are complicated enough as it is.
Instead, just sort first by ShortString and then by String.
We can't just use String, because ShortString makes distinctions
that String doesn't. ShortString is really preferred here;
String is serving only as a backstop for handling of bytes and runes.
The long series of types in the test helps increase the odds of
failure, allowing a smaller number of iterations in the test.
On my machine, a full test takes 700ms.
Passes toolstash-check.
Updates #19961Fixes#20272
name old alloc/op new alloc/op delta
Template 37.9MB ± 0% 37.9MB ± 0% +0.12% (p=0.032 n=5+5)
Unicode 28.9MB ± 0% 28.9MB ± 0% ~ (p=0.841 n=5+5)
GoTypes 110MB ± 0% 110MB ± 0% ~ (p=0.841 n=5+5)
Compiler 463MB ± 0% 463MB ± 0% ~ (p=0.056 n=5+5)
SSA 1.11GB ± 0% 1.11GB ± 0% +0.02% (p=0.016 n=5+5)
Flate 24.7MB ± 0% 24.8MB ± 0% +0.14% (p=0.032 n=5+5)
GoParser 31.1MB ± 0% 31.1MB ± 0% ~ (p=0.421 n=5+5)
Reflect 73.9MB ± 0% 73.9MB ± 0% ~ (p=1.000 n=5+5)
Tar 25.8MB ± 0% 25.8MB ± 0% +0.15% (p=0.016 n=5+5)
XML 41.2MB ± 0% 41.2MB ± 0% ~ (p=0.310 n=5+5)
[Geo mean] 72.0MB 72.0MB +0.07%
name old allocs/op new allocs/op delta
Template 384k ± 0% 385k ± 1% ~ (p=0.056 n=5+5)
Unicode 343k ± 0% 344k ± 0% ~ (p=0.548 n=5+5)
GoTypes 1.16M ± 0% 1.16M ± 0% ~ (p=0.421 n=5+5)
Compiler 4.43M ± 0% 4.44M ± 0% +0.26% (p=0.032 n=5+5)
SSA 9.86M ± 0% 9.87M ± 0% +0.10% (p=0.032 n=5+5)
Flate 237k ± 1% 238k ± 0% +0.49% (p=0.032 n=5+5)
GoParser 319k ± 1% 320k ± 1% ~ (p=0.151 n=5+5)
Reflect 957k ± 0% 957k ± 0% ~ (p=1.000 n=5+5)
Tar 251k ± 0% 252k ± 1% +0.49% (p=0.016 n=5+5)
XML 399k ± 0% 401k ± 1% ~ (p=0.310 n=5+5)
[Geo mean] 739k 741k +0.26%
Change-Id: Ic27995a8d374d012b8aca14546b1df9d28d30df7
Reviewed-on: https://go-review.googlesource.com/42955
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
If there were more unused imports than
the maximum default number of errors to report,
the set of reported imports was non-deterministic.
Fix by accumulating and sorting them prior to output.
Fixes#20298
Change-Id: Ib3d5a15fd7dc40009523fcdc1b93ddc62a1b05f2
Reviewed-on: https://go-review.googlesource.com/42954
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
ARM64 assembler backend only accepts loads and stores with small
or aligned offset. The compiler therefore can only fold small or
aligned offsets into loads and stores. For locals and args, their
offsets to SP are not known until very late, and the compiler
makes conservative decision not folding some of them. However,
in most cases, the offset is indeed small or aligned, and can
be folded into load and store (but actually not).
This CL adds support of loads and stores with large and unaligned
offsets. When the offset doesn't fit into the instruction, it
uses two instructions and (for very large offset) the constant
pool. This way, the compiler doesn't need to be conservative,
and can simply fold the offset.
To make it work, the assembler's optab matching rules need to be
changed. Before, MOVD accepts C_UAUTO32K which matches multiple
of 8 between 0 and 32K, and also C_UAUTO16K, which may not be
multiple of 8 and does not fit into MOVD instruction. The
assembler errors in the latter case. This change makes it only
matches multiple of 8 (or offsets within ±256, which also fits
in instruction), and uses the large-or-unaligned-offset rule
for things doesn't fit (without error). Other sized move rules
are changed similarly.
Class C_UAUTO64K and C_UOREG64K are removed, as they are never
used.
In shared library, load/store of global is rewritten to using
GOT and temp register, which conflicts with the use of temp
register for assembling large offset. So the folding is disabled
for globals in shared library mode.
Reduce cmd/go binary size by 2%.
name old time/op new time/op delta
BinaryTree17-8 8.67s ± 0% 8.61s ± 0% -0.60% (p=0.000 n=9+10)
Fannkuch11-8 6.24s ± 0% 6.19s ± 0% -0.83% (p=0.000 n=10+9)
FmtFprintfEmpty-8 116ns ± 0% 116ns ± 0% ~ (all equal)
FmtFprintfString-8 196ns ± 0% 192ns ± 0% -1.89% (p=0.000 n=10+10)
FmtFprintfInt-8 199ns ± 0% 198ns ± 0% -0.35% (p=0.001 n=9+10)
FmtFprintfIntInt-8 294ns ± 0% 293ns ± 0% -0.34% (p=0.000 n=8+8)
FmtFprintfPrefixedInt-8 318ns ± 1% 318ns ± 1% ~ (p=1.000 n=10+10)
FmtFprintfFloat-8 537ns ± 0% 531ns ± 0% -1.17% (p=0.000 n=9+10)
FmtManyArgs-8 1.19µs ± 1% 1.18µs ± 1% -1.41% (p=0.001 n=10+10)
GobDecode-8 17.2ms ± 1% 17.3ms ± 2% ~ (p=0.165 n=10+10)
GobEncode-8 14.7ms ± 1% 14.7ms ± 2% ~ (p=0.631 n=10+10)
Gzip-8 837ms ± 0% 836ms ± 0% -0.14% (p=0.006 n=9+10)
Gunzip-8 141ms ± 0% 139ms ± 0% -1.24% (p=0.000 n=9+10)
HTTPClientServer-8 256µs ± 1% 253µs ± 1% -1.35% (p=0.000 n=10+10)
JSONEncode-8 40.1ms ± 1% 41.3ms ± 1% +3.06% (p=0.000 n=10+9)
JSONDecode-8 157ms ± 1% 156ms ± 1% -0.83% (p=0.001 n=9+8)
Mandelbrot200-8 8.94ms ± 0% 8.94ms ± 0% +0.02% (p=0.000 n=9+9)
GoParse-8 8.69ms ± 0% 8.54ms ± 1% -1.69% (p=0.000 n=8+10)
RegexpMatchEasy0_32-8 227ns ± 1% 228ns ± 1% +0.48% (p=0.016 n=10+9)
RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.08% (p=0.000 n=10+9)
RegexpMatchEasy1_32-8 256ns ± 0% 251ns ± 0% -2.19% (p=0.000 n=10+9)
RegexpMatchEasy1_1K-8 2.38µs ± 0% 2.09µs ± 0% -12.49% (p=0.000 n=10+9)
RegexpMatchMedium_32-8 352ns ± 0% 354ns ± 0% +0.39% (p=0.002 n=10+9)
RegexpMatchMedium_1K-8 106µs ± 0% 106µs ± 0% -0.05% (p=0.005 n=10+9)
RegexpMatchHard_32-8 5.92µs ± 0% 5.89µs ± 0% -0.40% (p=0.000 n=9+8)
RegexpMatchHard_1K-8 180µs ± 0% 179µs ± 0% -0.14% (p=0.000 n=10+9)
Revcomp-8 1.20s ± 0% 1.13s ± 0% -6.29% (p=0.000 n=9+8)
Template-8 159ms ± 1% 154ms ± 1% -3.14% (p=0.000 n=9+10)
TimeParse-8 800ns ± 3% 769ns ± 1% -3.91% (p=0.000 n=10+10)
TimeFormat-8 826ns ± 2% 817ns ± 2% -1.04% (p=0.050 n=10+10)
[Geo mean] 145µs 143µs -1.79%
Change-Id: I5fc42087cee9b54ea414f8ef6d6d020b80eb5985
Reviewed-on: https://go-review.googlesource.com/42172
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TestGoroutineCounts currently depends on timing to get 100 goroutines
to a known blocking point before taking a profile. This fails
frequently, with different goroutines captured at different stacks.
The test is disabled on openbsd because it was too flaky, but in fact
it flakes on all platforms.
Fix this by using Gosched instead of timing. This is both much more
reliable and makes the test run faster.
Fixes#15156.
Change-Id: Ia6e894196d717655b8fb4ee96df53f6cc8bc5f1f
Reviewed-on: https://go-review.googlesource.com/42953
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This permits the user to override the code generation flag when they
know better. This is always a good policy for all flags automatically
inserted by the build system.
Doing this now so that I can write a test for #20290.
Update #20290
Change-Id: I5c6708a277238d571b8d037993a5a59e2a442e98
Reviewed-on: https://go-review.googlesource.com/42952
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Issue #15228 describes that reserved address blocks should be used for
documentation purposes. This change updates the prefix length so the
IPv4 address adheres to this.
Change-Id: I237d9cce1a71f4fd95f927ec894ce53fa806047f
Reviewed-on: https://go-review.googlesource.com/42991
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As necessary, math functions were structured to use stubs, so that they can
be accelerated with assembly on any platform.
Technique used was minimax polynomial approximation using tables of
polynomial coefficients, with argument range reduction.
Benchmark New Old Speedup
BenchmarkAcos 12.2 47.5 3.89
BenchmarkAcosh 18.5 56.2 3.04
BenchmarkAsin 13.1 40.6 3.10
BenchmarkAsinh 19.4 62.8 3.24
BenchmarkAtan 10.1 23 2.28
BenchmarkAtanh 19.1 53.2 2.79
BenchmarkAtan2 16.5 33.9 2.05
BenchmarkCbrt 14.8 58 3.92
BenchmarkErf 10.8 20.1 1.86
BenchmarkErfc 11.2 23.5 2.10
BenchmarkExp 8.77 53.8 6.13
BenchmarkExpm1 10.1 38.3 3.79
BenchmarkLog 13.1 40.1 3.06
BenchmarkLog1p 12.7 38.3 3.02
BenchmarkPowInt 31.7 40.5 1.28
BenchmarkPowFrac 33.1 141 4.26
BenchmarkTan 11.5 30 2.61
Accuracy was tested against a high precision
reference function to determine maximum error.
Note: ulperr is error in "units in the last place"
max
ulperr
Acos 1.15
Acosh 1.07
Asin 2.22
Asinh 1.72
Atan 1.41
Atanh 3.00
Atan2 1.45
Cbrt 1.18
Erf 1.29
Erfc 4.82
Exp 1.00
Expm1 2.26
Log 0.94
Log1p 2.39
Tan 3.14
Pow will have 99.99% correctly rounded results with reasonable inputs
producing numeric (non Inf or NaN) results
Change-Id: I850e8cf7b70426e8b54ec49d74acd4cddc8c6cb2
Reviewed-on: https://go-review.googlesource.com/38585
Reviewed-by: Michael Munday <munday@ca.ibm.com>
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test "TestTryGrowByResliceInlined" introduced in c08ac36 broke the
noopt builder as it fails when inlining is disabled.
Since there are currently no other options at hand for checking
inlined-ness other than looking at emited symbols of the compilation,
we for now skip the problem causing test by default and only run
it on one specific builder ("linux-amd64").
Also see CL 42813, which introduced the test and contains comments
suggesting this temporary solution.
Change-Id: I3978ab0831da04876cf873d78959f821c459282b
Reviewed-on: https://go-review.googlesource.com/42820
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also switch "stating" to "statting" to describe applying os.Stat to
a resource; the former is more confusable than the latter.
Change-Id: I9d8e3506bd383f8f1479c05948c03b8c633dc4af
Reviewed-on: https://go-review.googlesource.com/42855
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the common case, the grow method only needs to reslice the internal
buffer. Making another function call to grow can be expensive when Write
is called very often with small pieces of data (like a byte or rune).
Thus, we add a tryGrowByReslice method that is inlineable so that we can
avoid an extra call in most cases.
name old time/op new time/op delta
WriteByte-4 35.5µs ± 0% 17.4µs ± 1% -51.03% (p=0.000 n=19+20)
WriteRune-4 55.7µs ± 1% 38.7µs ± 1% -30.56% (p=0.000 n=18+19)
BufferNotEmptyWriteRead-4 304µs ± 5% 283µs ± 3% -6.86% (p=0.000 n=19+17)
BufferFullSmallReads-4 87.0µs ± 5% 66.8µs ± 2% -23.26% (p=0.000 n=17+17)
name old speed new speed delta
WriteByte-4 115MB/s ± 0% 235MB/s ± 1% +104.19% (p=0.000 n=19+20)
WriteRune-4 221MB/s ± 1% 318MB/s ± 1% +44.01% (p=0.000 n=18+19)
Fixes#17857
Change-Id: I08dfb10a1c7e001817729dbfcc951bda12fe8814
Reviewed-on: https://go-review.googlesource.com/42813
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
MOVSD is properly handled but its encoding test wasn't enabled. Enable
it.
For reference this was found with a little tool I wrote [1] to explore
which instructions are missing or not tested in the go obj package and
assembler:
"which SSE2 instructions aren't tested? And don't list instructions
which can take MMX operands"
$ x86db-gogen list --extension SSE2 --not-tested --not-mmx
CLFLUSH mem [m: np 0f ae /7] WILLAMETTE,SSE2
MOVSD xmmreg,xmmreg [rm: f2 0f 10 /r] WILLAMETTE,SSE2
MOVSD xmmreg,xmmreg [mr: f2 0f 11 /r] WILLAMETTE,SSE2
MOVSD mem64,xmmreg [mr: f2 0f 11 /r] WILLAMETTE,SSE2
MOVSD xmmreg,mem64 [rm: f2 0f 10 /r] WILLAMETTE,SSE2
(CLFLUSH was introduced with SSE2, but has its own CPUID bit)
[1] https://github.com/dlespiau/x86db
Change-Id: Ic3af3028cb8d4f02e53fdebb9b30fb311f4ee454
Reviewed-on: https://go-review.googlesource.com/42814
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently windows Stat uses combination of Lstat and Readlink to
walk symlinks until it reaches file or directory. Windows Readlink
is implemented via Windows DeviceIoControl(FSCTL_GET_REPARSE_POINT, ...)
call, but that call does not work on network shares or inside of
Docker container (see issues #18555 ad #19922 for details).
But Raymond Chen suggests different approach:
https://blogs.msdn.microsoft.com/oldnewthing/20100212-00/?p=14963/
- he suggests to use Windows I/O manager to dereferences the
symbolic link.
This appears to work for all normal symlinks, but also for network
shares and inside of Docker container.
This CL implements described procedure.
I also had to adjust TestStatSymlinkLoop, because the test is
expecting Stat to return syscall.ELOOP for symlink with a loop.
But new Stat returns Windows error of ERROR_CANT_RESOLVE_FILENAME
= 1921 instead. I could map ERROR_CANT_RESOLVE_FILENAME into
syscall.ELOOP, but I suspect the former is broader than later.
And ERROR_CANT_RESOLVE_FILENAME message text of "The name of
the file cannot be resolved by the system." sounds fine to me.
Fixes#10935Fixes#18555Fixes#19922
Change-Id: I979636064cdbdb9c7c840cf8ae73fe2c24499879
Reviewed-on: https://go-review.googlesource.com/41834
Reviewed-by: Harshavardhana <hrshvardhana@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As discussion in issue #19141, the addend should be the third
argument of MULA. This patch fixes it in both the front end
and the back end of the assembler. And also tests are added to
the encoding test.
Fixes#19141
Change-Id: Idbc6f338b8fdfcad97a135f27a98c5b375b27d43
Reviewed-on: https://go-review.googlesource.com/42028
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
NewPackage required through documentation that the package name not
be blank (which wasn't true since each time we check a new package
we create one with a blank name (api.go:350). NewPackage also asserted
that a package name not be "_". While it is invalid for a package name
to be "_", one could conceivably create a package named "_" through
export data manipulation. Furthermore, it is ok to import a package
with package path "_" as long as the package itself is not named "_".
- removed misleading documentation
- removed unnecessary assertion
- added safety checks when we actually do the import
Fixes#20231.
Change-Id: I1eb1ab7b5e3130283db715374770cf05d749d159
Reviewed-on: https://go-review.googlesource.com/42852
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Generated hash and eq routines don't need nil checks.
Prior to this CL, this was accomplished by
temporarily incrementing the global variable disable_checknil.
However, that increment lasted only the lifetime of the
call to funccompile. After CL 41503, funccompile may
do nothing but enqueue the function for compilation,
resulting in nil checks being generated.
Fix this by adding an explicit flag to a function
indicating whether nil checks should be disabled
for that function.
While we're here, allow concurrent compilation
with the -w and -W flags, since that was needed
to investigate this issue.
Fixes#20242
Change-Id: Ib9140c22c49e9a09e62fa3cf350f5d3eff18e2bd
Reviewed-on: https://go-review.googlesource.com/42591
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The Power processor manual states that "Branches not from the last instruction
of an aligned quadword and not to the first instruction of an aligned quadword
cause inefficiencies in the IBuffer". This changes the function alignment from 8
to 16 bytes to comply with that.
Fixes#18963
Change-Id: Ibce9bf8302110a86c6ab05948569af9ffdfcf4bb
Reviewed-on: https://go-review.googlesource.com/36390
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Allow the predefined escapers "html", "urlquery", and "js" to be used
in pipelines when they have no potential to affect the correctness or
safety of the escaped pipeline output. Specifically:
- "urlquery" may be used if it is the last command in the pipeline.
- "html" may be used if it is the last command in the pipeline, and
the pipeline does not occur in an unquoted HTML attribute value
context.
- "js" may be used in any pipeline, since it does not affect the
merging of contextual escapers.
This change will loosens the restrictions on predefined escapers
introduced in golang.org/cl/37880, which will hopefully ease the
upgrade path for existing template users.
This change brings back the escaper-merging logic, and associated
unit tests, that were removed in golang.org/cl/37880. However, a
few notable changes have been made:
- "_html_template_nospaceescaper" is no longer considered
equivalent to "html", since the former escapes spaces, while
the latter does not (see #19345). This change should not silently
break any templates, since pipelines where this substituion will
happen will already trigger an explicit error.
- An "_eval_args_" internal directive has been added to
handle pipelines containing a single explicit call to a
predefined escaper, e.g. {{html .X}} (see #19353).
Also, the HTMLEscape function called by the predefined
text/template "html" function now escapes the NULL character as
well. This effectively makes it as secure as the internal
html/template HTML escapers (see #19345). While this change is
backward-incompatible, it will only affect illegitimate uses
of this escaper, since the NULL character is always illegal in
valid HTML.
Fixes#19952
Change-Id: I9b5570a80a3ea284b53901e6a1f842fc59b33d3a
Reviewed-on: https://go-review.googlesource.com/40936
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Execute incurs separate writes for each "step", e.g. each
variable that needs to be printed, and the final newline.
While it is correct to state that templates can be executed
concurrently, there is a more subtle nuance that is easily missed:
when writing to the same writer, the writes from concurrent execute
calls can be interleaved, leading to unexpected output.
Change-Id: I0abbd7960d8a8d15e109a8a3eeff3b43b852bbbf
Reviewed-on: https://go-review.googlesource.com/37444
Reviewed-by: Rob Pike <r@golang.org>
The external darwin linker has been printing:
ld: warning: -read_only_relocs cannot be used with x86_64
for a long time. Now that it is printed by CL 33301, we may as
well get rid of it.
Fixes#20246
Change-Id: I1147cf1ff197fdfda228a1349f13627bcf9fc72f
Reviewed-on: https://go-review.googlesource.com/42730
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If we've already complained about a type T,
don't complain again about further expressions
involving it.
Fixes#20245 and hopefully all of its ilk.
Change-Id: Ic0abe8235d52e8a7ac40e3615aea8f3a54fd7cec
Reviewed-on: https://go-review.googlesource.com/42690
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We already set it for mips32 objects. The native ELF linker warns when
linking PIC objects with non-PIC objects. Our objects are PIC, but we
were not marking them as such.
Fixes#20243.
Change-Id: Ifab131200b263e4c72cf81f7b131a65ac02a13a9
Reviewed-on: https://go-review.googlesource.com/42710
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change passes runtime.Version from the go tool to the compiler.
If the versions do not match, the compilation fails.
The result is a go tool from one GOROOT will complain loudly if it
is invoked with a different GOROOT value.
Only release versions are checked, so that when developing Go
you can still use "go install cmd/go" and "go install cmd/compile"
separately.
Fixes#19064
Change-Id: I17e184d07d3c1092b1d9af53ba55ed3ecf67791d
Reviewed-on: https://go-review.googlesource.com/42595
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Before this change, building a GOROOT using make.bash, and then
moving the entire to a new path confused the go tool. Correct
operation of the go tool under these conditions required either
running make.bash again (not always possible if the new location
was owned by a different system user) or setting the GOROOT
environment variable. Setting GOROOT is unfortunate and
discouraged, as it makes it too easy to use the go tool from
one GOROOT and the compiler from another GOROOT.
With this change, the go tool finds its GOROOT relative to its
own location, using os.Executable. It checks it is in a GOROOT
by searching for the GOROOT/pkg/tool directory, to avoid two
plausible situations:
ln -s $GOROOT/bin/go /usr/local/bin/go
and
PATH=$HOME/bin:$PATH
GOPATH=$HOME
ln -s $GOROOT/bin/go $HOME/bin/go
Additionally, if the current executable path is not in a GOROOT,
the tool will follow any symlinks for the executable and check
to see if its original path is a GOROOT.
Fixes#18678
Change-Id: I151d7d449d213164f98193cc176b616849e6332c
Reviewed-on: https://go-review.googlesource.com/42533
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Compile:
package p
var f = func(...A)
Before this CL:
x.go:3:13: type %!v(PANIC=runtime error: invalid memory address or nil pointer dereference) is not an expression
x.go:3:17: undefined: A
After this CL:
x.go:3:13: type func(...<T>) is not an expression
x.go:3:17: undefined: A
Found with go-fuzz.
Fixes#20233
Change-Id: Ibb232b3954c4091071440eba48b44c4022a8083f
Reviewed-on: https://go-review.googlesource.com/42610
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change explicitly documents that DES, MD5, RC4 and SHA-1 are
insecure / broken - at all or at least within a commonly used scenario.
Fixes#14395
Change-Id: Id1d543c85d67968ba64ed7495313501953c3ef3a
Reviewed-on: https://go-review.googlesource.com/42511
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add the ability to override the default file and directory from
which certificates are loaded by setting the OpenSSL compatible
environment variables: SSL_CERT_FILE, SSL_CERT_DIR.
If the variables are set the default locations are not checked.
Added new default file "/usr/local/etc/ssl/cert.pem" for FreeBSD.
Certificates in the first valid location found for both file and
directory are added, instead of only the first file location if
a valid one was found, which is consistent with OpenSSL.
Fixes#3905Fixes#14022Fixes#14311Fixes#16920Fixes#18813 - If user sets SSL_CERT_FILE.
Change-Id: Ia24fb7c1c2ffff4338b4cf214bd040326ce27bb0
Reviewed-on: https://go-review.googlesource.com/36093
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When compiling the program:
package p
func _(){
*;:=
}
Before:
x.go:4:3: syntax error: unexpected semicolon, expecting expression
x.go:4:4: non-name *%!v(PANIC=runtime error: invalid memory address or nil pointer dereference) on left side of :=
x.go:5:1: syntax error: unexpected }, expecting expression
After:
x.go:4:3: syntax error: unexpected semicolon, expecting expression
x.go:4:4: non-name *<N> on left side of :=
x.go:5:1: syntax error: unexpected }, expecting expression
No test because:
(1) we don't have a good mechanism to check for the
absence of the string "PANIC" in an error message
(2) the string "*<N>", while better, is itself ugly enough
that I don't want to actively check for it
(3) the bug isn't very important, the kind of thing only fuzzers encounter
(4) the fix is obvious and trivial
Fixes#20220
Change-Id: I35faa986b60b671414ee999d6264b06937f250e3
Reviewed-on: https://go-review.googlesource.com/42498
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Because the hint parameter is supposed to be treated
purely as a hint, if it doesn't meet the requirements
we disregard it and continue as if there was no hint
at all.
Fixes#19926
Change-Id: I86e7f99472fad6b99ba4e2fd33e4a9e55d55115e
Reviewed-on: https://go-review.googlesource.com/40854
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
There's no Settings->Agreement path for PolyGerrit users, but if we
link directly to the page in the instructions, Gerrit will inform them
that they can access the page by switching to the old UI.
Fixes#20207
Change-Id: I0887ee854e4ac5975b5f305adb6259b81b41618f
Reviewed-on: https://go-review.googlesource.com/42412
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL modifies how MOV[DWHB] instructions that store a constant to
memory are assembled to avoid them clobbering the condition code
(flags). It also modifies zeroAuto to use MOVD instructions instead of
CLEAR (which is assembled as XC).
MOV[DWHB]storeconst ops also no longer clobbers flags.
Note: this CL modifies the assembler so that it can no longer handle
immediates outside the range of an int16 or offsets from SB, which
reflects what the machine instructions support. The compiler doesn't
need this capability any more and I don't think this affects any existing
assembly, but it is easy to workaround if it does.
Fixes#20187.
Change-Id: Ie54947ff38367bd6a19962bf1a6d0296a4accffb
Reviewed-on: https://go-review.googlesource.com/42179
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
5 shards, each of which spins up NumCPU processes,
each of which is running at GOMAXPROCS=NumCPU,
is too much for one machine. It makes my laptop unusable.
It might also be in part responsible for test flakes
that require a moderately responsive system,
like #18589 (backedge scheduling) and #19276 (locklinear).
It's possible that Go should be a better neighbor in general;
that's #17969. In the meantime, fix this corner of the world.
Builders snapshot the world and run shards on different
machines, so keeping sharding high for them is good.
This is a partial reversion of CL 18199.
Fixes#20141.
Change-Id: I123cf9436f4f4da3550372896265c38117b78071
Reviewed-on: https://go-review.googlesource.com/42431
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this CL, the compiler and assembler
were sloppy about the LSym.Type for LSyms
containing static data.
The linker then fixed this up, converting
Sxxx and SBSS to SDATA, and SNOPTRBSS to SNOPTRDATA
if it noticed that the symbol had associated data.
It is preferable to just get this right in cmd/compile
and cmd/asm, because it removes an unnecessary traversal
of the symbol table from the linker (see #14624).
Do this by touching up the LSym.Type fixes in
LSym.prepwrite and Link.Globl.
I have confirmed by instrumenting the linker
that the now-eliminated code paths were unreached.
And an additional check in the object file writing code
will help preserve that invariant.
There was a case in the Windows linker,
with internal linking and cgo,
where we were generating SNOPTRBSS symbols with data.
For now, convert those at the site at which they occur
into SNOPTRDATA, just like they were.
Does not pass toolstash-check,
but does generate identical linked binaries.
No compiler performance changes.
Change-Id: I77b071ab103685ff8e042cee9abb864385488872
Reviewed-on: https://go-review.googlesource.com/40864
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
On Android, the exec wrapper passes on output from adb to its parent
process by passing on os.Stderr and os.Stdout to adb. If the adb
process somehow hangs, it will keep stderr and stdout will open, in turn
blocking go test from ever returning from its cmd.Wait() even though
it has killed the exec wrapper process.
Break the short circuit by introducing a wrapper between adb and the
exec wrapper, preventing os/exec.Run from passing along the raw
file descriptors for os.Stdout and os.Stderr.
(Hopefully) fixes occasional indefinite hangs on the Android builder.
Change-Id: I1188211fbde79b4a66bf93ff8e9d0091abf34560
Reviewed-on: https://go-review.googlesource.com/42271
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
DUFFZERO on 386 is not marked as clobbering flags, but rewriteToUseGot rewrote
"ADUFFZERO $offset" to "MOVL runtime.duffxxx@GOT, CX; ADDL $offset, CX; CALL CX"
which does. Luckily the fix is easier than figuring out what the problem was:
replace the ADDL $offset, CX with LEAL $offset(CX), CX.
On amd64 DUFFZERO clobbers flags, on arm, arm64 and ppc64 ADD does not clobber
flags and s390x does not use the duff functions, so I'm fairly confident this
is the only fix required.
I don't know how to write a test though.
Change-Id: I69b0958f5f45771d61db5f5ecb4ded94e8960d4d
Reviewed-on: https://go-review.googlesource.com/41821
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
ANDPS, like all others PS (Packed Single precision floats) instructions,
need Ym: they don't use the 0x66 prefix.
From the manual:
NP 0F 54 /r ANDPS xmm1, xmm2/m128
NP meaning, quoting the manual:
NP - Indicates the use of 66/F2/F3 prefixes (beyond those already part
of the instructions opcode) are not allowed with the instruction.
And indeed, the same instruction prefixed by 0x66 is ANDPD.
Updates #14069
Change-Id: If312a6f1e77113ab8c0febe66bdb1b4171e41e0a
Reviewed-on: https://go-review.googlesource.com/42090
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We generate code that calls each user init function one at a time.
When there are lots of user init functions,
usually due to generated code, like test/rotate* or
github.com/juju/govmomi/vim25/types,
we can end up with a giant function,
which can be slow to compile.
This CL puts in an escape valve.
When there are more than 500 functions, instead of doing:
init.0()
init.1()
// ...
we construct a static array of functions:
var fns = [...]func(){init.0, init.1, ... }
and call them in a loop.
This generates marginally bigger, marginally worse code,
so we restrict it to cases in which it might start to matter.
500 was selected as a mostly arbitrary threshold for "lots".
Each call uses two Progs, one for PCDATA and one for the call,
so at 500 calls we use ~1000 Progs.
At concurrency==8, we get a Prog cache of about
1000 Progs per worker.
So a threshold of 500 should more or less avoid
exhausting the Prog cache in most cases.
Change-Id: I276b887173ddbf65b2164ec9f9b5eb04d8c753c2
Reviewed-on: https://go-review.googlesource.com/41500
Reviewed-by: Keith Randall <khr@golang.org>
overLoadFactor used a uintptr for its calculations.
When the number of potential buckets was large,
perhaps due to a coding error or corrupt/malicious user input
leading to a very large map size hint,
this led to overflow on 32 bit systems.
This overflow resulted in an infinite loop.
Prevent it by always using a 64 bit calculation.
Updates #20195
Change-Id: Iaabc710773cd5da6754f43b913478cc5562d89a2
Reviewed-on: https://go-review.googlesource.com/42185
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Noticed while adding to the bitset implementation
in cmd/compile/internal/gc.
The (Com (Const)) optimizations were already present
in the AMD64 lowered optimizations.
They trigger 118, 44, 262, and 108 times
respectively for int sizes 8, 16, 32, and 64
in a run of make.bash.
The (Or (And)) optimization is new.
It triggers 3 times for int size 8
and once for int size 64 during make.bash,
in packages internal/poll, reflect,
encoding/asn1, and go/types,
so there is a bit of natural test coverage.
Change-Id: I44072864ff88831d5ec7dce37c516d29df056e98
Reviewed-on: https://go-review.googlesource.com/41758
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Per gri's suggestion on CL 41623,
add a comment to trackAllTypes
about the trade-offs of enabling it.
Change-Id: Iec42b0da7933543200729003d1b2c6e0d9dcc5f0
Reviewed-on: https://go-review.googlesource.com/42186
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The generated test cases had their arguments reversed, putting them back
in order makes those tests pass.
CMPPS SRC, DEST, CC
Change-Id: Ie15021edc533d5681a6a78d10d88b665e3de9017
Reviewed-on: https://go-review.googlesource.com/42097
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I want to move the SHIDDEN type bit into Attribute, but AttrHidden is already
there and means something completely different, so rename it. (I'll give the
SHIDDEN bit a better name when it moves too).
Change-Id: I075403d9542b7626d4c1f6db9094329c4181aad3
Reviewed-on: https://go-review.googlesource.com/42024
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently Go sets the system-wide timer resolution to 1ms the whole
time it's running. This has negative affects on system performance and
power consumption. Unfortunately, simply reducing the timer resolution
to the default 15ms interferes with several sleeps in the runtime
itself, including sysmon's ability to interrupt goroutines.
This commit takes a hybrid approach: it only reduces the timer
resolution when the Go process is entirely idle. When the process is
idle, nothing needs a high resolution timer. When the process is
non-idle, it's already consuming CPU so it doesn't really matter if
the OS also takes timer interrupts more frequently.
Updates #8687.
Change-Id: I0652564b4a36d61a80e045040094a39c19da3b06
Reviewed-on: https://go-review.googlesource.com/38403
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(ADDconst [c] x) && !isARMImmRot(uint32(c)) && isARMImmRot(uint32(-c)) -> (SUBconst [int64(int32(-c))] x)
(SUBconst [c] x) && !isARMImmRot(uint32(c)) && isARMImmRot(uint32(-c)) -> (ADDconst [int64(int32(-c))] x)
Currently
a = a + 0xfffffff1 is compiled to （variable a is in R0)
MVN $14, R11
ADD R11, R0, R0
After applying the above 2 rules, it becomes
SUB $15, R0, R0
(BICconst [c] (BICconst [d] x)) -> (BICconst [int64(int32(c|d))] x)
This rule also optimizes the generated ARM code.
The other rules are added to avoid to generate less optimized ARM code
when substitutions ADD->SUB happen.
Change-Id: I3ead9aae2b446b674e2ab42d37259d38ceb93a4d
Reviewed-on: https://go-review.googlesource.com/41679
Reviewed-by: Keith Randall <khr@golang.org>
Instead of playing whack-a-mole finding all
the non-dowidth'd expressions that can sneak
out of the frontend and then deciding on
just the right place to handle them,
use a big hammer.
Fixes#20152
Change-Id: Id452d9e8c4e9585216bd8bf0e0004c85aba4f9f7
Reviewed-on: https://go-review.googlesource.com/42021
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently the pprof tests re-symbolize PCs in profiles, and do so in a
way that can't handle inlining. Proto profiles already contain full
symbol information, so this modifies the tests to use the symbol
information already present in the profile.
Change-Id: I63cd491de7197080fd158b1e4f782630f1bbbb56
Reviewed-on: https://go-review.googlesource.com/41255
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
When running a Query on Stmt a dependency is added to the stmt and
rows. To do that it needs a reference to Rows, so the releaseConn
function is defined after the definition. However the
rows.initContextClose was set to run before the releaseConn was
set on rows, setting up a situation where the connection could
be canceled before the releaseConn was set and resulting in
a segfault.
Fixes#20160
Change-Id: I5592e7db2cf653dfc48d42cbc2b03ca20501b1a0
Reviewed-on: https://go-review.googlesource.com/42139
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently _TinySizeClass is untyped, which means it can accidentally
be used as a spanClass (not that I would know this from experience or
anything). Make it an int8 to avoid this mix up.
This is a cherry-pick of dev.garbage commit 81b74bf9c5.
Change-Id: I1e69eccee436ea5aa45e9a9828a013e369e03f1a
Reviewed-on: https://go-review.googlesource.com/41254
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This is no longer necessary now that we can more efficiently consult
the span's noscan bit.
This is a cherry-pick of dev.garbage commit 312aa09996.
Change-Id: Id0b00b278533660973f45eb6efa5b00f373d58af
Reviewed-on: https://go-review.googlesource.com/41252
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, we mix objects with pointers and objects without pointers
("noscan" objects) together in memory. As a result, for every object
we grey, we have to check that object's heap bits to find out if it's
noscan, which adds to the per-object cost of GC. This also hurts the
TLB footprint of the garbage collector because it decreases the
density of scannable objects at the page level.
This commit improves the situation by using separate spans for noscan
objects. This will allow a much simpler noscan check (in a follow up
CL), eliminate the need to clear the bitmap of noscan objects (in a
follow up CL), and improves TLB footprint by increasing the density of
scannable objects.
This is also a step toward eliminating dead bits, since the current
noscan check depends on checking the dead bit of the first word.
This has no effect on the heap size of the garbage benchmark.
We'll measure the performance change of this after the follow-up
optimizations.
This is a cherry-pick from dev.garbage commit d491e550c3. The only
non-trivial merge conflict was in updatememstats in mstats.go, where
we now have to separate the per-spanclass stats from the per-sizeclass
stats.
Change-Id: I13bdc4869538ece5649a8d2a41c6605371618e40
Reviewed-on: https://go-review.googlesource.com/41251
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
In particular, this says that Frames.Function uniquely identifies a
function within a program. We depend on this in various places that
use runtime.Frames in std, but it wasn't actually written down.
Change-Id: Ie7ede348c17673e11ae513a094862b60c506abc5
Reviewed-on: https://go-review.googlesource.com/41610
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code in #20162 contains an embedded interface.
It didn't get dowidth'd by the frontend,
and during DWARF generation, ngotype asked
for a string description of it,
which triggered a request for the number of fields
in the interface, which triggered a dowidth,
which is disallowed in the backend.
The other changes in this CL are to support the test.
Fixes#20162
Change-Id: I4d0be5bd949c361d4cdc89a8ed28b10977e40cf9
Reviewed-on: https://go-review.googlesource.com/42131
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It used to be simple, and then it got complicated for speed (to reduce
allocations, mostly), but that involved a mutex and hurt multi-core
performance, contending on the mutex.
A change was sent to try to improve that mutex contention in
https://go-review.googlesource.com/c/42110/2/src/net/http/server.go
but that introduced its own allocations (the string->interface{}
boxing for the sync.Map key), which runs counter to the whole point of
that statusLine function: to remove allocations.
Instead, make the code simple again and not have a mutex. It's a bit
slower for the single-core case, but nobody with a single-user HTTP
server cares about 50 nanoseconds:
name old time/op new time/op delta
ResponseStatusLine 37.5ns ± 2% 87.1ns ± 2% +132.42% (p=0.029 n=4+4)
ResponseStatusLine-2 63.1ns ± 1% 43.1ns ±12% -31.67% (p=0.029 n=4+4)
ResponseStatusLine-4 53.8ns ± 8% 40.2ns ± 2% -25.29% (p=0.029 n=4+4)
name old alloc/op new alloc/op delta
ResponseStatusLine 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
ResponseStatusLine-2 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
ResponseStatusLine-4 0.00B ±NaN% 0.00B ±NaN% ~ (all samples are equal)
name old allocs/op new allocs/op delta
ResponseStatusLine 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
ResponseStatusLine-2 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
ResponseStatusLine-4 0.00 ±NaN% 0.00 ±NaN% ~ (all samples are equal)
(Note the code could be even simpler with fmt.Fprintf, but that is
relatively slow and involves a bunch of allocations getting arguments
into interface{} for the call)
Change-Id: I1fa119132dbbf97a8e7204ce3e0707d433060da2
Reviewed-on: https://go-review.googlesource.com/42133
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Using 'go build -tags "foo,bar"' might seem to work when you wanted
-tags "foo bar", since they make up a single tag that doesn't exist and
the build is unaffected.
Instead, error on any tag that contains a comma.
Fixes#18800.
Change-Id: I6641e03e2ae121c8878d6301c4311aef97026b73
Reviewed-on: https://go-review.googlesource.com/41951
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The comment for Cmd.Stdout and Cmd.Stderr says that it's safe to
set both to the same writer, but it doesn't say that this only
works when both writers are comparable.
This change updates the comment to explain that using a
non-comparable writer may still lead to a race.
Fixes#19804
Change-Id: I63b420034666209a2b6fab48b9047c9d07b825e2
Reviewed-on: https://go-review.googlesource.com/42052
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Profile labels added by the user using pprof.Do, if present will
be in a *labelMap stored in the unsafe.Pointer 'tag' field of
the profile map entry. This change extracts the labels from the tag
field and writes them to the profile proto.
Change-Id: Ic40fdc58b66e993ca91d5d5effe0e04ffbb5bc46
Reviewed-on: https://go-review.googlesource.com/39613
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If g1 sets its labels and then they are copied into a profile buffer
and then g2 reads the profile buffer and inspects the labels,
the race detector must understand that g1's recording of the labels
happens before g2's use of the labels. Make that so.
Fixes race test failure in CL 39613.
Change-Id: Id7cda1c2aac6f8eef49213b5ca414f7154b4acfa
Reviewed-on: https://go-review.googlesource.com/42111
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
More specifically, allow Unicode letters in the directories of GitHub
repositories, which can occur and don't have a valid reason to be
disallowed by go get.
Do so by using a predefined character class, the Unicode character
property class \p{L} that describes the Unicode characters that are
letters:
http://www.regular-expressions.info/unicode.html#category
Since it's not possible to create GitHub usernames or repositories
containing Unicode letters at this time, those parts of the import path
are still restricted to ASCII letters only.
Fix name of tested func in t.Errorf messages.
Fixes#18660.
Change-Id: Ia0ef4742bfd8317d989ef1eb1d7065e382852fe2
Reviewed-on: https://go-review.googlesource.com/41822
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is the same technique used in CL 24466. By adding a little bit of
size to the binary, we can remove a function call and gain a lot of
performance.
A raw array ([128]bool) would be faster, but is also be 128 bytes
instead of 16.
Running tip on a Mac:
name old time/op new time/op delta
QuoteMetaAll-4 192ns ±12% 120ns ±11% -37.27% (p=0.000 n=10+10)
QuoteMetaNone-4 186ns ± 6% 64ns ± 6% -65.52% (p=0.000 n=10+10)
name old speed new speed delta
QuoteMetaAll-4 73.2MB/s ±11% 116.6MB/s ±10% +59.21% (p=0.000 n=10+10)
QuoteMetaNone-4 139MB/s ± 6% 405MB/s ± 6% +190.74% (p=0.000 n=10+10)
Change-Id: I68ce9fe2ef1c28e2274157789b35b0dd6ae3efb5
Reviewed-on: https://go-review.googlesource.com/41495
Run-TryBot: Kevin Burke <kev@inburke.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use it to ensure that dowidth is not called
from the backend on a type whose size
has not yet been calculated.
This is an alternative to CL 42016.
Change-Id: I8c7b4410ee4c2a68573102f6b9b635f4fdcf392e
Reviewed-on: https://go-review.googlesource.com/42018
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Node.Used was written to from the backend
concurrently with reads of Node.Class
for the same ONAME Nodes.
I do not know why it was not failing consistently
under the race detector, but it is a race.
This is likely also a problem with Node.HasVal and Node.HasOpt.
They will be handled in a separate CL.
Fix Used by moving it to gc.Name and making it a separate bool.
There was one non-Name use of Used, marking OLABELs as used.
That is no longer needed, now that goto and label checking
happens early in the front end.
Leave the getters and setters in place,
to ease changing the representation in the future
(or changing to an interface!).
Updates #20144
Change-Id: I9bec7c6d33dcb129a4cfa9d338462ea33087f9f7
Reviewed-on: https://go-review.googlesource.com/42015
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Type.Size and Type.Alignment are for the front end:
They calculate size and alignment if needed.
Type.MustSize and Type.MustAlignment are for the back end:
They call Fatal if size and alignment are not already calculated.
Most uses are of MustSize and MustAlignment,
but that's because the back end is newer,
and this API was added to support it.
This CL was mostly generated with sed and selective reversion.
The only mildly interesting bit is the change of the ssa.Type interface
and the supporting ssa dummy types.
Follow-up to review feedback on CL 41970.
Passes toolstash-check.
Change-Id: I0d9b9505e57453dae8fb6a236a07a7a02abd459e
Reviewed-on: https://go-review.googlesource.com/42016
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
dowidth is fundamentally unsafe to call from the back end;
it will cause data races.
Replace all calls to dowidth in the backend with
assertions that the width has been calculated.
Then fix all the cases in which that was not so,
including the cases from #20145.
Fixes#20145.
Change-Id: Idba3d19d75638851a30ec2ebcdb703c19da3e92b
Reviewed-on: https://go-review.googlesource.com/41970
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Many (most!) of the values of objapi.SymKind are used only in the linker, so
this creates a separate cmd/link/internal/ld.SymKind type, removes most values
from SymKind and maps one to the other when reading object files in the linker.
Two of the remaining objapi.SymKind values are only checked for, never set and
so will never be actually found but I wanted to keep this to the most
mechanical change possible.
Change-Id: I4bbc5aed6713cab3e8de732e6e288eb77be0474c
Reviewed-on: https://go-review.googlesource.com/40985
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, the following two codes generate the identical dwarf info
for type Foo.
prog 1)
type Foo struct {
Bar
}
prog 2)
type Foo struct {
Bar Bar
}
This change adds a go-specific attribute DW_AT_go_embedded_field
to annotate each member entry. Its absence or false value indicates
the corresponding member is not an embedded field.
Update #20037
Change-Id: Ibcbd2714f3e4d97c7b523d7398f29ab2301cc897
Reviewed-on: https://go-review.googlesource.com/41873
Reviewed-by: David Chase <drchase@google.com>
There's been one failure on the race builder so far,
before we started sorting functions by length.
The race detector can only detect actual races,
and ordering functions by length might reduce the odds
of catching some kinds of races. Give it more to chew on.
Updates #20144
Change-Id: I0206ac182cb98b70a729dea9703ecb0fef54d2d0
Reviewed-on: https://go-review.googlesource.com/41973
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Its sole use is in walk.go. 100% code movement.
gsubr.go increasingly contains backend-y things.
With a few more relocations, it could probably be
fruitfully renamed progs.go.
Change-Id: I61ec5c2bc1f8cfdda64c6d6f580952c154ff60e0
Reviewed-on: https://go-review.googlesource.com/41972
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
They were used only in esc.go. 100% code movement.
Also, remove the rather outdated comment at the top of gen.go.
It's not really clear what gen.go is for any more.
Change-Id: Iaedfe7015ef6f5c11c49f3e6721b15d779a00faa
Reviewed-on: https://go-review.googlesource.com/41971
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When a constant doesn't fit in a single instruction, use two
paired instructions instead of the constant pool. For example
ADD $0xaa00bb, R0, R1
Used to rewrite to:
MOV ?(IP), R11
ADD R11, R0, R1
Instead, do:
ADD $0xaa0000, R0, R1
ADD $0xbb, R1, R1
Same number of instructions.
Good:
4 less bytes (no constant pool entry)
One less load.
Bad:
Critical path is one instruction longer.
It's probably worth it to avoid the loads, they are expensive.
Dave Cheney got us some performance numbers: https://perf.golang.org/search?q=upload:20170426.1
TL;DR mean 1.37% improvement.
Change-Id: Ib206836161fdc94a3962db6f9caa635c87d57cf1
Reviewed-on: https://go-review.googlesource.com/41612
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The current code treats condition as special register and write
its raw data directly into instruction.
The fix converts the raw data into correct condition encoding.
Also fix the operand catogery of FCCMP.
Add tests to cover all cases.
Change-Id: Ib194041bd9017dd0edbc241564fe983082ac616b
Reviewed-on: https://go-review.googlesource.com/41511
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Previously, the package did not distinguish between baseline and
extended sequential images. Both are non-progressive images, but the Th
range differs between the two, as per Annex B of
https://www.w3.org/Graphics/JPEG/itu-t81.pdf
Extended sequential images are often emitted by the Guetzli encoder.
Fixes#19913
Change-Id: I3d0f9e16d5d374ee1c65e3a8fb87519de61cff94
Reviewed-on: https://go-review.googlesource.com/41831
Reviewed-by: David Symonds <dsymonds@golang.org>
When using a concurrent backend,
the overall compilation time is bounded
in part by the slowest function to compile.
The number of top-level statements in a function
is an easily calculated and fairly reliable
proxy for compilation time.
Here's a standard compilecmp output for -c=8 with this CL:
name old time/op new time/op delta
Template 127ms ± 4% 125ms ± 6% -1.33% (p=0.000 n=47+50)
Unicode 84.8ms ± 4% 84.5ms ± 4% ~ (p=0.217 n=49+49)
GoTypes 289ms ± 3% 287ms ± 3% -0.78% (p=0.002 n=48+50)
Compiler 1.36s ± 3% 1.34s ± 2% -1.29% (p=0.000 n=49+47)
SSA 2.95s ± 3% 2.77s ± 4% -6.23% (p=0.000 n=50+49)
Flate 70.7ms ± 3% 70.9ms ± 2% ~ (p=0.112 n=50+49)
GoParser 85.0ms ± 3% 83.0ms ± 4% -2.31% (p=0.000 n=48+49)
Reflect 229ms ± 3% 225ms ± 4% -1.83% (p=0.000 n=49+49)
Tar 70.2ms ± 3% 69.4ms ± 3% -1.17% (p=0.000 n=49+49)
XML 115ms ± 7% 114ms ± 6% ~ (p=0.158 n=49+47)
name old user-time/op new user-time/op delta
Template 352ms ± 5% 342ms ± 8% -2.74% (p=0.000 n=49+50)
Unicode 117ms ± 5% 118ms ± 4% +0.88% (p=0.005 n=46+48)
GoTypes 986ms ± 3% 980ms ± 4% ~ (p=0.110 n=46+48)
Compiler 4.39s ± 2% 4.43s ± 4% +0.97% (p=0.002 n=50+50)
SSA 12.0s ± 2% 13.3s ± 3% +11.33% (p=0.000 n=49+49)
Flate 222ms ± 5% 219ms ± 6% -1.56% (p=0.002 n=50+50)
GoParser 271ms ± 5% 268ms ± 4% -0.83% (p=0.036 n=49+48)
Reflect 560ms ± 4% 571ms ± 3% +1.90% (p=0.000 n=50+49)
Tar 183ms ± 3% 183ms ± 3% ~ (p=0.903 n=45+50)
XML 364ms ±13% 391ms ± 4% +7.16% (p=0.000 n=50+40)
A more interesting way of viewing the data is by
looking at the ratio of the time taken to compile
the slowest-to-compile function to the overall
time spent compiling functions.
If this ratio is small (near 0), then increased concurrency might help.
If this ratio is big (near 1), then we're bounded by that single function.
I instrumented the compiler to emit this ratio per-package,
ran 'go build -a -gcflags=-c=C -p=P std cmd' three times,
for varying values of C and P,
and collected the ratios encountered into an ASCII histogram.
Here's c=1 p=1, which is a non-concurrent backend, single process at a time:
90%|
80%|
70%|
60%|
50%|
40%|
30%|
20%|**
10%|***
0%|*********
----+----------
|0123456789
The x-axis is floor(10*ratio), so the first column indicates the percent of
ratios that fell in the 0% to 9.9999% range.
We can see in this histogram that more concurrency will help;
in most cases, the ratio is small.
Here's c=8 p=1, before this CL:
90%|
80%|
70%|
60%|
50%|
40%|
30%| *
20%| *
10%|* * *
0%|**********
----+----------
|0123456789
In 30-40% of cases, we're mostly bound by the compilation time
of a single function.
Here's c=8 p=1, after this CL:
90%|
80%|
70%|
60%|
50%| *
40%| *
30%| *
20%| *
10%| *
0%|**********
----+----------
|0123456789
The sorting pays off; we are bound by the
compilation time of a single function in over half of packages.
The single * in the histogram indicates 0-10%.
The actual values for this chart are:
0: 5%, 1: 1%, 2: 1%, 3: 4%, 4: 5%, 5: 7%, 6: 7%, 7: 7%, 8: 9%, 9: 55%
This indicates that efforts to increase or enable more concurrency,
e.g. by optimizing mutexes or increasing the value of c,
will probably not yield fruit.
That matches what compilecmp tells us.
Further optimization efforts should thus focus instead on one of:
(1) making more functions compile concurrently
(2) improving the compilation time of the slowest functions
(3) speeding up the remaining serial parts of the compiler
(4) automatically splitting up some large autogenerated functions
into small ones, as discussed in #19751
I hope to spend more time on (1) before the freeze.
Adding process parallelism doesn't change the story much.
For example, here's c=8 p=8, after this CL:
90%|
80%|
70%|
60%|
50%|
40%| *
30%| *
20%| *
10%| ***
0%|**********
----+----------
|0123456789
Since we don't need to worry much about p,
these histograms can help us select a good
general value of c to use as a default,
assuming we're not bounded by GOMAXPROCS.
Here are some charts after this CL, for c from 1 to 8:
c=1 p=1
90%|
80%|
70%|
60%|
50%|
40%|
30%|
20%|**
10%|***
0%|*********
----+----------
|0123456789
c=2 p=1
90%|
80%|
70%|
60%|
50%|
40%|
30%|
20%|
10%| **** *
0%|**********
----+----------
|0123456789
c=3 p=1
90%|
80%|
70%|
60%|
50%|
40%|
30%|
20%| *
10%| ** * *
0%|**********
----+----------
|0123456789
c=4 p=1
90%|
80%|
70%|
60%|
50%|
40%|
30%| *
20%| *
10%| * *
0%|**********
----+----------
|0123456789
c=5 p=1
90%|
80%|
70%|
60%|
50%|
40%|
30%| *
20%| *
10%| * *
0%|**********
----+----------
|0123456789
c=6 p=1
90%|
80%|
70%|
60%|
50%|
40%| *
30%| *
20%| *
10%| *
0%|**********
----+----------
|0123456789
c=7 p=1
90%|
80%|
70%|
60%|
50%| *
40%| *
30%| *
20%| *
10%| **
0%|**********
----+----------
|0123456789
c=8 p=1
90%|
80%|
70%|
60%|
50%| *
40%| *
30%| *
20%| *
10%| *
0%|**********
----+----------
|0123456789
Given the increased user-CPU costs as
c increases, it looks like c=4 is probably
the sweet spot, at least for now.
Pleasingly, this matches (and explains)
the results of the standard benchmarking
that I have done.
Updates #15756
Change-Id: I82b606c06efd34a5dbd1afdbcf66a605905b2aeb
Reviewed-on: https://go-review.googlesource.com/41192
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL adds initial support for concurrent backend compilation.
BACKGROUND
The compiler currently consists (very roughly) of the following phases:
1. Initialization.
2. Lexing and parsing into the cmd/compile/internal/syntax AST.
3. Translation into the cmd/compile/internal/gc AST.
4. Some gc AST passes: typechecking, escape analysis, inlining,
closure handling, expression evaluation ordering (order.go),
and some lowering and optimization (walk.go).
5. Translation into the cmd/compile/internal/ssa SSA form.
6. Optimization and lowering of SSA form.
7. Translation from SSA form to assembler instructions.
8. Translation from assembler instructions to machine code.
9. Writing lots of output: machine code, DWARF symbols,
type and reflection info, export data.
Phase 2 was already concurrent as of Go 1.8.
Phase 3 is planned for eventual removal;
we hope to go straight from syntax AST to SSA.
Phases 5–8 are per-function; this CL adds support for
processing multiple functions concurrently.
The slowest phases in the compiler are 5 and 6,
so this offers the opportunity for some good speed-ups.
Unfortunately, it's not quite that straightforward.
In the current compiler, the latter parts of phase 4
(order, walk) are done function-at-a-time as needed.
Making order and walk concurrency-safe proved hard,
and they're not particularly slow, so there wasn't much reward.
To enable phases 5–8 to be done concurrently,
when concurrent backend compilation is requested,
we complete phase 4 for all functions
before starting later phases for any functions.
Also, in reality, we automatically generate new
functions in phase 9, such as method wrappers
and equality and has routines.
Those new functions then go through phases 4–8.
This CL disables concurrent backend compilation
after the first, big, user-provided batch of
functions has been compiled.
This is done to keep things simple,
and because the autogenerated functions
tend to be small, few, simple, and fast to compile.
USAGE
Concurrent backend compilation still defaults to off.
To set the number of functions that may be backend-compiled
concurrently, use the compiler flag -c.
In future work, cmd/go will automatically set -c.
Furthermore, this CL has been intentionally written
so that the c=1 path has no backend concurrency whatsoever,
not even spawning any goroutines.
This helps ensure that, should problems arise
late in the development cycle,
we can simply have cmd/go set c=1 always,
and revert to the original compiler behavior.
MUTEXES
Most of the work required to make concurrent backend
compilation safe has occurred over the past month.
This CL adds a handful of mutexes to get the rest of the way there;
they are the mutexes that I didn't see a clean way to avoid.
Some of them may still be eliminable in future work.
In no particular order:
* gc.funcsymsmu. The global funcsyms slice is populated
lazily when we need function symbols for closures.
This occurs during gc AST to SSA translation.
The function funcsym also does a package lookup,
which is a source of races on types.Pkg.Syms;
funcsymsmu also covers that package lookup.
This mutex is low priority: it adds a single global,
it is in an infrequently used code path, and it is low contention.
Since funcsyms may now be added in any order,
we must sort them to preserve reproducible builds.
* gc.largeStackFramesMu. We don't discover until after SSA compilation
that a function's stack frame is gigantic.
Recording that error happens basically never,
but it does happen concurrently.
Fix with a low priority mutex and sorting.
* obj.Link.hashmu. ctxt.hash stores the mapping from
types.Syms (compiler symbols) to obj.LSyms (linker symbols).
It is accessed fairly heavily through all the phases.
This is the only heavily contended mutex.
* gc.signatlistmu. The global signatlist map is
populated with types through several of the concurrent phases,
including notably via ngotype during DWARF generation.
It is low priority for removal.
* gc.typepkgmu. Looking up symbols in the types package
happens a fair amount during backend compilation
and DWARF generation, particularly via ngotype.
This mutex helps us to avoid a broader mutex on types.Pkg.Syms.
It has low-to-moderate contention.
* types.internedStringsmu. gc AST to SSA conversion and
some SSA work introduce new autotmps.
Those autotmps have their names interned to reduce allocations.
That interning requires protecting types.internedStrings.
The autotmp names are heavily re-used, and the mutex
overhead and contention here are low, so it is probably
a worthwhile performance optimization to keep this mutex.
TESTING
I have been testing this code locally by running
'go install -race cmd/compile'
and then doing
'go build -a -gcflags=-c=128 std cmd'
for all architectures and a variety of compiler flags.
This obviously needs to be made part of the builders,
but it is too expensive to make part of all.bash.
I have filed #19962 for this.
REPRODUCIBLE BUILDS
This version of the compiler generates reproducible builds.
Testing reproducible builds also needs automation, however,
and is also too expensive for all.bash.
This is #19961.
Also of note is that some of the compiler flags used by 'toolstash -cmp'
are currently incompatible with concurrent backend compilation.
They still work fine with c=1.
Time will tell whether this is a problem.
NEXT STEPS
* Continue to find and fix races and bugs,
using a combination of code inspection, fuzzing,
and hopefully some community experimentation.
I do not know of any outstanding races,
but there probably are some.
* Improve testing.
* Improve performance, for many values of c.
* Integrate with cmd/go and fine tune.
* Support concurrent compilation with the -race flag.
It is a sad irony that it does not yet work.
* Minor code cleanup that has been deferred during
the last month due to uncertainty about the
ultimate shape of this CL.
PERFORMANCE
Here's the buried lede, at last. :)
All benchmarks are from my 8 core 2.9 GHz Intel Core i7 darwin/amd64 laptop.
First, going from tip to this CL with c=1 has almost no impact.
name old time/op new time/op delta
Template 195ms ± 3% 194ms ± 5% ~ (p=0.370 n=30+29)
Unicode 86.6ms ± 3% 87.0ms ± 7% ~ (p=0.958 n=29+30)
GoTypes 548ms ± 3% 555ms ± 4% +1.35% (p=0.001 n=30+28)
Compiler 2.51s ± 2% 2.54s ± 2% +1.17% (p=0.000 n=28+30)
SSA 5.16s ± 3% 5.16s ± 2% ~ (p=0.910 n=30+29)
Flate 124ms ± 5% 124ms ± 4% ~ (p=0.947 n=30+30)
GoParser 146ms ± 3% 146ms ± 3% ~ (p=0.150 n=29+28)
Reflect 354ms ± 3% 352ms ± 4% ~ (p=0.096 n=29+29)
Tar 107ms ± 5% 106ms ± 3% ~ (p=0.370 n=30+29)
XML 200ms ± 4% 201ms ± 4% ~ (p=0.313 n=29+28)
[Geo mean] 332ms 333ms +0.10%
name old user-time/op new user-time/op delta
Template 227ms ± 5% 225ms ± 5% ~ (p=0.457 n=28+27)
Unicode 109ms ± 4% 109ms ± 5% ~ (p=0.758 n=29+29)
GoTypes 713ms ± 4% 721ms ± 5% ~ (p=0.051 n=30+29)
Compiler 3.36s ± 2% 3.38s ± 3% ~ (p=0.146 n=30+30)
SSA 7.46s ± 3% 7.47s ± 3% ~ (p=0.804 n=30+29)
Flate 146ms ± 7% 147ms ± 3% ~ (p=0.833 n=29+27)
GoParser 179ms ± 5% 179ms ± 5% ~ (p=0.866 n=30+30)
Reflect 431ms ± 4% 429ms ± 4% ~ (p=0.593 n=29+30)
Tar 124ms ± 5% 123ms ± 5% ~ (p=0.140 n=29+29)
XML 243ms ± 4% 242ms ± 7% ~ (p=0.404 n=29+29)
[Geo mean] 415ms 415ms +0.02%
name old obj-bytes new obj-bytes delta
Template 382k ± 0% 382k ± 0% ~ (all equal)
Unicode 203k ± 0% 203k ± 0% ~ (all equal)
GoTypes 1.18M ± 0% 1.18M ± 0% ~ (all equal)
Compiler 3.98M ± 0% 3.98M ± 0% ~ (all equal)
SSA 8.28M ± 0% 8.28M ± 0% ~ (all equal)
Flate 230k ± 0% 230k ± 0% ~ (all equal)
GoParser 287k ± 0% 287k ± 0% ~ (all equal)
Reflect 1.00M ± 0% 1.00M ± 0% ~ (all equal)
Tar 190k ± 0% 190k ± 0% ~ (all equal)
XML 416k ± 0% 416k ± 0% ~ (all equal)
[Geo mean] 660k 660k +0.00%
Comparing this CL to itself, from c=1 to c=2
improves real times 20-30%, costs 5-10% more CPU time,
and adds about 2% alloc.
The allocation increase comes from allocating more ssa.Caches.
name old time/op new time/op delta
Template 202ms ± 3% 149ms ± 3% -26.15% (p=0.000 n=49+49)
Unicode 87.4ms ± 4% 84.2ms ± 3% -3.68% (p=0.000 n=48+48)
GoTypes 560ms ± 2% 398ms ± 2% -28.96% (p=0.000 n=49+49)
Compiler 2.46s ± 3% 1.76s ± 2% -28.61% (p=0.000 n=48+46)
SSA 6.17s ± 2% 4.04s ± 1% -34.52% (p=0.000 n=49+49)
Flate 126ms ± 3% 92ms ± 2% -26.81% (p=0.000 n=49+48)
GoParser 148ms ± 4% 107ms ± 2% -27.78% (p=0.000 n=49+48)
Reflect 361ms ± 3% 281ms ± 3% -22.10% (p=0.000 n=49+49)
Tar 109ms ± 4% 86ms ± 3% -20.81% (p=0.000 n=49+47)
XML 204ms ± 3% 144ms ± 2% -29.53% (p=0.000 n=48+45)
name old user-time/op new user-time/op delta
Template 246ms ± 9% 246ms ± 4% ~ (p=0.401 n=50+48)
Unicode 109ms ± 4% 111ms ± 4% +1.47% (p=0.000 n=44+50)
GoTypes 728ms ± 3% 765ms ± 3% +5.04% (p=0.000 n=46+50)
Compiler 3.33s ± 3% 3.41s ± 2% +2.31% (p=0.000 n=49+48)
SSA 8.52s ± 2% 9.11s ± 2% +6.93% (p=0.000 n=49+47)
Flate 149ms ± 4% 161ms ± 3% +8.13% (p=0.000 n=50+47)
GoParser 181ms ± 5% 192ms ± 2% +6.40% (p=0.000 n=49+46)
Reflect 452ms ± 9% 474ms ± 2% +4.99% (p=0.000 n=50+48)
Tar 126ms ± 6% 136ms ± 4% +7.95% (p=0.000 n=50+49)
XML 247ms ± 5% 264ms ± 3% +6.94% (p=0.000 n=48+50)
name old alloc/op new alloc/op delta
Template 38.8MB ± 0% 39.3MB ± 0% +1.48% (p=0.008 n=5+5)
Unicode 29.8MB ± 0% 30.2MB ± 0% +1.19% (p=0.008 n=5+5)
GoTypes 113MB ± 0% 114MB ± 0% +0.69% (p=0.008 n=5+5)
Compiler 443MB ± 0% 447MB ± 0% +0.95% (p=0.008 n=5+5)
SSA 1.25GB ± 0% 1.26GB ± 0% +0.89% (p=0.008 n=5+5)
Flate 25.3MB ± 0% 25.9MB ± 1% +2.35% (p=0.008 n=5+5)
GoParser 31.7MB ± 0% 32.2MB ± 0% +1.59% (p=0.008 n=5+5)
Reflect 78.2MB ± 0% 78.9MB ± 0% +0.91% (p=0.008 n=5+5)
Tar 26.6MB ± 0% 27.0MB ± 0% +1.80% (p=0.008 n=5+5)
XML 42.4MB ± 0% 43.4MB ± 0% +2.35% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Template 379k ± 0% 378k ± 0% ~ (p=0.421 n=5+5)
Unicode 322k ± 0% 321k ± 0% ~ (p=0.222 n=5+5)
GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.548 n=5+5)
Compiler 4.12M ± 0% 4.11M ± 0% -0.14% (p=0.032 n=5+5)
SSA 9.72M ± 0% 9.72M ± 0% ~ (p=0.421 n=5+5)
Flate 234k ± 1% 234k ± 0% ~ (p=0.421 n=5+5)
GoParser 316k ± 1% 315k ± 0% ~ (p=0.222 n=5+5)
Reflect 980k ± 0% 979k ± 0% ~ (p=0.095 n=5+5)
Tar 249k ± 1% 249k ± 1% ~ (p=0.841 n=5+5)
XML 392k ± 0% 391k ± 0% ~ (p=0.095 n=5+5)
From c=1 to c=4, real time is down ~40%, CPU usage up 10-20%, alloc up ~5%:
name old time/op new time/op delta
Template 203ms ± 3% 131ms ± 5% -35.45% (p=0.000 n=50+50)
Unicode 87.2ms ± 4% 84.1ms ± 2% -3.61% (p=0.000 n=48+47)
GoTypes 560ms ± 4% 310ms ± 2% -44.65% (p=0.000 n=50+49)
Compiler 2.47s ± 3% 1.41s ± 2% -43.10% (p=0.000 n=50+46)
SSA 6.17s ± 2% 3.20s ± 2% -48.06% (p=0.000 n=49+49)
Flate 126ms ± 4% 74ms ± 2% -41.06% (p=0.000 n=49+48)
GoParser 148ms ± 4% 89ms ± 3% -39.97% (p=0.000 n=49+50)
Reflect 360ms ± 3% 242ms ± 3% -32.81% (p=0.000 n=49+49)
Tar 108ms ± 4% 73ms ± 4% -32.48% (p=0.000 n=50+49)
XML 203ms ± 3% 119ms ± 3% -41.56% (p=0.000 n=49+48)
name old user-time/op new user-time/op delta
Template 246ms ± 9% 287ms ± 9% +16.98% (p=0.000 n=50+50)
Unicode 109ms ± 4% 118ms ± 5% +7.56% (p=0.000 n=46+50)
GoTypes 735ms ± 4% 806ms ± 2% +9.62% (p=0.000 n=50+50)
Compiler 3.34s ± 4% 3.56s ± 2% +6.78% (p=0.000 n=49+49)
SSA 8.54s ± 3% 10.04s ± 3% +17.55% (p=0.000 n=50+50)
Flate 149ms ± 6% 176ms ± 3% +17.82% (p=0.000 n=50+48)
GoParser 181ms ± 5% 213ms ± 3% +17.47% (p=0.000 n=50+50)
Reflect 453ms ± 6% 499ms ± 2% +10.11% (p=0.000 n=50+48)
Tar 126ms ± 5% 149ms ±11% +18.76% (p=0.000 n=50+50)
XML 246ms ± 5% 287ms ± 4% +16.53% (p=0.000 n=49+50)
name old alloc/op new alloc/op delta
Template 38.8MB ± 0% 40.4MB ± 0% +4.21% (p=0.008 n=5+5)
Unicode 29.8MB ± 0% 30.9MB ± 0% +3.68% (p=0.008 n=5+5)
GoTypes 113MB ± 0% 116MB ± 0% +2.71% (p=0.008 n=5+5)
Compiler 443MB ± 0% 455MB ± 0% +2.75% (p=0.008 n=5+5)
SSA 1.25GB ± 0% 1.27GB ± 0% +1.84% (p=0.008 n=5+5)
Flate 25.3MB ± 0% 26.9MB ± 1% +6.31% (p=0.008 n=5+5)
GoParser 31.7MB ± 0% 33.2MB ± 0% +4.61% (p=0.008 n=5+5)
Reflect 78.2MB ± 0% 80.2MB ± 0% +2.53% (p=0.008 n=5+5)
Tar 26.6MB ± 0% 27.9MB ± 0% +5.19% (p=0.008 n=5+5)
XML 42.4MB ± 0% 44.6MB ± 0% +5.20% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Template 380k ± 0% 379k ± 0% -0.39% (p=0.032 n=5+5)
Unicode 321k ± 0% 321k ± 0% ~ (p=0.841 n=5+5)
GoTypes 1.14M ± 0% 1.14M ± 0% ~ (p=0.421 n=5+5)
Compiler 4.12M ± 0% 4.14M ± 0% +0.52% (p=0.008 n=5+5)
SSA 9.72M ± 0% 9.76M ± 0% +0.37% (p=0.008 n=5+5)
Flate 234k ± 1% 234k ± 1% ~ (p=0.690 n=5+5)
GoParser 316k ± 0% 317k ± 1% ~ (p=0.841 n=5+5)
Reflect 981k ± 0% 981k ± 0% ~ (p=1.000 n=5+5)
Tar 250k ± 0% 249k ± 1% ~ (p=0.151 n=5+5)
XML 393k ± 0% 392k ± 0% ~ (p=0.056 n=5+5)
Going beyond c=4 on my machine tends to increase CPU time and allocs
without impacting real time.
The CPU time numbers matter, because when there are many concurrent
compilation processes, that will impact the overall throughput.
The numbers above are in many ways the best case scenario;
we can take full advantage of all cores.
Fortunately, the most common compilation scenario is incremental
re-compilation of a single package during a build/test cycle.
Updates #15756
Change-Id: I6725558ca2069edec0ac5b0d1683105a9fff6bea
Reviewed-on: https://go-review.googlesource.com/40693
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When using Lstat against symlinks that point to a directory,
the function returns FileInfo with both ModeDir and ModeSymlink set.
Change that to never set ModeDir if ModeSymlink is set.
Fixes#10424Fixes#17540Fixes#17541
Change-Id: Iba280888aad108360b8c1f18180a24493fe7ad2b
Reviewed-on: https://go-review.googlesource.com/41830
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Taken from the Intel Software Development Manual (of course, in the line
below it's ADC DST, SRC; The opposite of the commit subject).
12 /r ADC r8, r/m8
We need 0x12 for the corresponding ytab line, not 0x10.
{Ymb, Ynone, Yrb, Zm_r, 1},
Updates #14069
Change-Id: Id37cbd0c581c9988c2de355efa908956278e2189
Reviewed-on: https://go-review.googlesource.com/41857
Reviewed-by: Keith Randall <khr@golang.org>
Follow-up to review comments on CL 41797.
Mask the input to set2 and set3, so that at the very least,
we won't corrupt the rest of the flags in case of a bad input.
It also seems more semantically appropriate.
Do minor cleanup in addrescapes. I started on larger cleanup,
but it wasn't clear that it was an improvement.
Add warning comments and sanity checks to Initorder and Class constants,
to attempt to prevent them from overflowing their allotted flag bits.
Passes toolstash-check.
Change-Id: I57b9661ba36f56406aa7a1d8da9b7c70338f9119
Reviewed-on: https://go-review.googlesource.com/41817
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When the stack register is decremented to acquire stack space at
the beginning of a function, a MOVDU should be used so it is done
atomically, unless the size of the stack frame is too large for
that instruction. The code to determine whether to use MOVDU
or MOVD was checking if the function was a leaf and always generating MOVD
when it was. The choice of MOVD vs. MOVDU should only depend on the stack
frame size. This fixes that problem.
Change-Id: I0e49c79036f1e8f7584179e1442b938fc6da085f
Reviewed-on: https://go-review.googlesource.com/41813
Reviewed-by: Michael Munday <munday@ca.ibm.com>
In many cases the records returned by Reader.Read will only be used between calls
to Read and become garbage once a new record is read. In this case, instead of
allocating a new slice on each call to Read, we can reuse the last allocated slice
for successive calls to avoid unnecessary allocations.
This change adds a new field ReuseRecord to the Reader struct to enable this reuse.
ReuseRecord is false by default to avoid breaking existing code which dependss on
the current behaviour.
I also added 4 new benchmarks, corresponding to the existing Read benchmarks, which
set ReuseRecord to true.
Benchstat on my local machine (old is ReuseRecord = false, new is ReuseRecord = true)
name old time/op new time/op delta
Read-8 2.75µs ± 2% 1.88µs ± 1% -31.52% (p=0.000 n=14+15)
ReadWithFieldsPerRecord-8 2.75µs ± 0% 1.89µs ± 1% -31.43% (p=0.000 n=13+13)
ReadWithoutFieldsPerRecord-8 2.77µs ± 1% 1.88µs ± 1% -32.06% (p=0.000 n=15+15)
ReadLargeFields-8 55.4µs ± 1% 54.2µs ± 0% -2.07% (p=0.000 n=15+14)
name old alloc/op new alloc/op delta
Read-8 664B ± 0% 24B ± 0% -96.39% (p=0.000 n=15+15)
ReadWithFieldsPerRecord-8 664B ± 0% 24B ± 0% -96.39% (p=0.000 n=15+15)
ReadWithoutFieldsPerRecord-8 664B ± 0% 24B ± 0% -96.39% (p=0.000 n=15+15)
ReadLargeFields-8 3.94kB ± 0% 2.98kB ± 0% -24.39% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
Read-8 18.0 ± 0% 8.0 ± 0% -55.56% (p=0.000 n=15+15)
ReadWithFieldsPerRecord-8 18.0 ± 0% 8.0 ± 0% -55.56% (p=0.000 n=15+15)
ReadWithoutFieldsPerRecord-8 18.0 ± 0% 8.0 ± 0% -55.56% (p=0.000 n=15+15)
ReadLargeFields-8 24.0 ± 0% 12.0 ± 0% -50.00% (p=0.000 n=15+15)
Fixes#19721
Change-Id: I79b14128bb9bb3465f53f40f93b1b528a9da6f58
Reviewed-on: https://go-review.googlesource.com/41730
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some large testing/build systems require some form of test discovery before
running tests. This usually allows for analytics, history, and stats on a per
tests basis. Typically these systems are meant used in multi-language
environments and the original source code is not known or available.
This adds a -test.list option which takes a regular expression as an
argument. Any tests, benchmarks, or examples that match that regular
expression will be printed, one per line, to stdout and then the program
will exit.
Since subtests are named/discovered at run time this will only show
top-level tests names and is a known limitation.
Fixes#17209
Change-Id: I7e607f5f4f084d623a1cae88a1f70e7d92b7f13e
Reviewed-on: https://go-review.googlesource.com/41195
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The Context definition to date has not defined what Err returns
before the Done channel is closed. Define that it returns nil,
as most implementations do.
All the standard context implementations (those in package
context and in golang.org/x/net/context) return Err() == nil
when Done is not yet closed. However, some non-standard
implementations may exist that return Err() != nil in this case,
as permitted by the Context definition before this date.
Call these "errorful implementations".
Because all the standard context implementations ensure that
Err() == nil when Done is not yet closed, clients now exist that
assume Err() != nil implies Done is closed and use calling Err
as a quick short-circuit check instead of first doing a non-blocking
receive from Done and then, if that succeeds, needing to call Err.
This assumption holds for all the standard Context implementations,
so these clients work fine in practice, even though they are making
unwarranted assumptions about the Context implementations.
Call these "technically incorrect clients".
If a technically incorrect client encounters an errorful
implementation, the client misbehaves. Because there are few
errorful implementations, over time we expect that many clients
will end up being technically incorrect without realizing it,
leading to latent, subtle bugs. If we want to eliminate these
latent, subtle bugs, there are two ways to do this:
either make errorful implementations more common
(exposing the client bugs more often) or redefine the Context
interface so that the clients are not buggy after all.
If we make errorful implementations more common, such
as by changing the standard context implementations to
return ErrNotDone instead of nil when Err is called before
Done is closed, this will shake out essentially all of the
technically incorrect clients, forcing people to find and fix
those clients during the transition to Go 1.9.
Technically this is allowed by the compatibility policy,
but we expect there are many pieces of code assuming
that Err() != nil means done, so updating will cause real pain.
If instead we disallow errorful implementations, then they
will need to be fixed as they are discovered, but the fault
will officially lie in the errorful Context implementation,
not in the clients. Technically this is disallowed by the compatibility
policy, because these errorful implementations were "correct"
in earlier versions of Go, except that they didn't work with
common client code. We expect there are hardly any errorful
implementations, so that disallowing them will be less disruptive
and more in the spirit of the compatibility policy.
This CL takes the path of expected least disruption,
narrowing the Context interface semantics and potentially
invalidating existing implementations. A survey of the
go-corpus v0.01 turned up only five Context implementations,
all trivial and none errorful (details in #19856).
We are aware of one early Context implementation inside Google,
from before even golang.org/x/net/context existed,
that is errorful. The misbehavior of an open-source library
when passed such a context is what prompted #19856.
That context implementation would be disallowed after this CL
and would need to be corrected. We are aware of no other
affected context implementations. On the other hand, a survey
of the go-corpus v0.01 turned up many instances of client
code assuming that Err() == nil implies not done yet
(details also in #19856). On balance, narrowing Context and
thereby allowing Err() == nil checks should invalidate significantly
less code than a push to flush out all the currently technically
incorrect Err() == nil checks.
If release feedback shows that we're wrong about this balance,
we can roll back this CL and try again in Go 1.10.
Fixes#19856.
Change-Id: Id45d126fac70e1fcc42d73e5a87ca1b66935b831
Reviewed-on: https://go-review.googlesource.com/40291
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Since close errors have been cleaned up in CL 39997,
TestCloseError is failing on Plan 9, because
TCPListener.Close didn't check that the listener
has already been closed before writing the "hangup"
string to the listener control file.
This change fixes TCPListener.Close on Plan 9,
by closing poll.FD before writing the "hangup"
string.
Fixes#20128.
Change-Id: I13862b23a9055dd1be658acef7066707d98c591f
Reviewed-on: https://go-review.googlesource.com/41850
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This updates sha256.block and sha512.block to use vector instructions. While
each round must still be performed independently, this allows for the use of
the vshasigma{w,d} crypto acceleration instructions.
For crypto/sha256:
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 570 300 -47.37%
BenchmarkHash1K 7529 3018 -59.91%
BenchmarkHash8K 55308 21938 -60.33%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 14.01 26.58 1.90x
BenchmarkHash1K 136.00 339.23 2.49x
BenchmarkHash8K 148.11 373.40 2.52x
For crypto/sha512:
benchmark old ns/op new ns/op delta
BenchmarkHash8Bytes 725 394 -45.66%
BenchmarkHash1K 5062 2107 -58.38%
BenchmarkHash8K 34711 13918 -59.90%
benchmark old MB/s new MB/s speedup
BenchmarkHash8Bytes 11.03 20.29 1.84x
BenchmarkHash1K 202.28 485.84 2.40x
BenchmarkHash8K 236.00 588.56 2.49x
Fixes#20069
Change-Id: I28bffe6e9eb484a83a004116fce84acb4942abca
Reviewed-on: https://go-review.googlesource.com/41391
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Moved the relevant file.close() usages close to after the
file opens and put them in defer statements, so that readers
don't have to think too much as to where the file is
being closed.
Change-Id: Ic4190b02ea2f5ac281b9ba104e0023e9f87ca8c7
Reviewed-on: https://go-review.googlesource.com/41796
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Catch all the cases where a file operation might return ErrFileClosing,
and convert to ErrClosed. Use a new method for the conversion, which
permits us to remove some KeepAlive calls.
Change-Id: I584178f297efe6cb86f3090b2341091b412f1041
Reviewed-on: https://go-review.googlesource.com/41793
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Node.Walkdef is 0, 1, or 2, so it only requires two bits.
Add support for 2-bit values to bitset,
and use it for Node.Walkdef.
Class, Embedded, Typecheck, and Initorder will follow suit
in subsequent CLs.
The multi-bit flags will go at the beginning,
since that generates (marginally) more efficient code.
Change-Id: Id6e2e66e437f10aaa05b8a6e1652efb327d06128
Reviewed-on: https://go-review.googlesource.com/41791
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In the past we returned "use of closed network connection" when using
a closed network descriptor in some way. In CL 36799 that was changed
to return "use of closed file or network connection". Because programs
have no access to a value of this error type (see issue #4373) they
resort to doing direct string comparisons (see issue #19252). This CL
restores the old error string so that we don't break programs
unnecessarily with the 1.9 release.
This adds a test to the net package for the expected string.
For symmetry check that the os package returns the expected error,
which for os already exists as os.ErrClosed.
Updates #4373.
Fixed#19252.
Change-Id: I5b83fd12cfa03501a077cad9336499b819f4a38b
Reviewed-on: https://go-review.googlesource.com/39997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
node.Likely may once have held -1/0/+1,
but it is now only 0/1.
With improved SSA heuristics,
it may someday go away entirely.
Change-Id: I6451d17fd7fb47e67fea4d39df302b6db00ea57b
Reviewed-on: https://go-review.googlesource.com/41760
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In an effort to at least understand the complete set of things not
working on Alpine Linux, I've been trying to get the build passing
again, even with tests disabled.
The race detector is broken on Alpine. That is #14481 (and #9918).
So disable those tests for now.
Also, internal linking with PIE doesn't work on Alpine yet.
That is #18243. So disable that test for now.
With this CL, all.bash almost passes. There's some cgo test failing
still, but there's no bug yet, so that can be a separate CL.
Change-Id: I3ffbb0e787ed54cb82f298b6bd5bf3ccfbc82622
Reviewed-on: https://go-review.googlesource.com/41678
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
isifacemethod accessed thisT without checking if it was initialized,
opening the possibility for a bug during type checking. Give better
name, move it to package types, and provide accessor instead.
Change-Id: I29ffc408252a4ba4ef1de218fa154397786c9be6
Reviewed-on: https://go-review.googlesource.com/41673
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This comment is very useful but still refers to the C implementation.
Adapting it for Go is fairly straightforward though.
Change-Id: Ib6dde25f3a18acbce76bb3cffdc29f5ccf43c1f7
Reviewed-on: https://go-review.googlesource.com/41696
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The assembler reordered the operands of some instructions to put the
first operand into From3. Unfortunately this meant that when the
instructions were printed the operands were in a different order than
the assembler would expect as input. For example, 'MVC $8, (R1), (R2)'
would be printed as 'MVC (R1), $8, (R2)'.
Originally this was done to ensure that From contained the source
memory operand. The current compiler no longer requires this and so
this CL simply makes all instructions use the standard order for
operands: From, Reg, From3 and finally To.
Fixes#18295
Change-Id: Ib2b5ec29c647ca7a995eb03dc78f82d99618b092
Reviewed-on: https://go-review.googlesource.com/40299
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Breaks are implicit, and since there is no outer loop this one could not
mean a loop break that was missing a label.
Change-Id: Ie91018db1825aa8285c1aa55c9d28fc7ec7148af
Reviewed-on: https://go-review.googlesource.com/39691
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now that the os package uses internal/poll on Unix and Windows systems,
it can rely on internal/poll reference counting to ensure that the
file descriptor is not closed until all I/O is complete.
That was already working. This CL completes the job by not trying to
modify the Sysfd field when it might still be used by the I/O routines.
Fixes#7970
Change-Id: I7a3daa1a6b07b7345bdce6f0cd7164bd4eaee952
Reviewed-on: https://go-review.googlesource.com/41674
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reduces cmd/go by 4464 bytes on amd64.
Removes the duplicate detection of AVX support and
presence of Intel processors.
Change-Id: I4670189951a63760fae217708f68d65e94a30dc5
Reviewed-on: https://go-review.googlesource.com/41570
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Implemented low-level time system for windows on hardware (software),
which does not support memory mapped _KSYSTEM_TIME page update.
In particular this problem exists on Wine where _KSYSTEM_TIME
only contains time at the start, and is never modified.
On start we try to detect Wine and if it's so we fallback to
GetSystemTimeAsFileTime() for current time and a monotonic
timer based on QueryPerformanceCounter family of syscalls:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspxFixes#18537
Change-Id: I269d22467ed9b0afb62056974d23e731b80c83ed
Reviewed-on: https://go-review.googlesource.com/35710
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since Pread/Pwrite specify a file offset, using incref is sufficient.
This permits multiple Pread/Pwrite calls in parallel.
Since Pread/Pwrite specify a file offset, it doesn't seem to make
sense to use the poller for them, so don't.
Updates #19586
Change-Id: I676be16bf519b9a45f8e6b1d991c44f10848bc11
Reviewed-on: https://go-review.googlesource.com/41670
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
As Ian said at:
https://github.com/golang/go/issues/19964#issuecomment-296347750
> the -fdebug-prefix-map option is being applied to the debug info but
> not to the initial .file pseudo-op.
>
> My only current thought for how to fix this is that instead of
> compiling $WORK/a/b/foo.c, we should change the command to (cd
> $WORK/a/b && clang -g -c foo.c). We'll still want
> -fdebug-prefix-map, I think, but that should fix the .file
> pseudo-op.
This CL does that.
Fixes#19964
Change-Id: I442b1201cab9e0448fc520ab243ad364d59cd7c3
Reviewed-on: https://go-review.googlesource.com/41629
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When unshare specifies a new namespace, the syscall
package changes / to make namespace changes private.
If a chroot is specified, the unshare must be done first.
If the chroot is done first then the unshare will
not specify the correct /.
A new test is included which test combining chroot
and CLONE_NEWNS; it fails without the patch and works with
it.
Fixes#20103
Change-Id: I86022803c784bd418a30383321f3d64103d95c62
Reviewed-on: https://go-review.googlesource.com/41626
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reduces the size of the ssa export data
by 10%, from 76154 to 67886.
It doesn't appear that #20084, which would do this automatically,
is going to be fixed soon. Do it manually for now.
This speeds up compiling cmd/compile/internal/amd64
and presumably its comrades as well:
name old time/op new time/op delta
CompileAMD64 89.6ms ± 6% 86.7ms ± 5% -3.29% (p=0.000 n=49+47)
name old user-time/op new user-time/op delta
CompileAMD64 116ms ± 5% 112ms ± 5% -3.51% (p=0.000 n=45+42)
name old alloc/op new alloc/op delta
CompileAMD64 26.7MB ± 0% 25.8MB ± 0% -3.26% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
CompileAMD64 223k ± 0% 213k ± 0% -4.46% (p=0.008 n=5+5)
Updates #20084
Change-Id: I49e8951c5bfce63ad2b7f4fc3bfa0868c53114f9
Reviewed-on: https://go-review.googlesource.com/41493
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There were a number of places in crypto/x509 that used hardcoded
representations of the ASN.1 NULL type, in both byte slice and
RawValue struct forms. This change adds two new exported vars to
the asn1 package for working with ASN.1 NULL in both its forms, and
converts all usages from the x509 package.
In addition, tests were added to exercise Marshal and Unmarshal on
both vars.
See #19446 for discussion.
Change-Id: I63dbd0835841ccbc810bd6ec794360a84e933f1e
Reviewed-on: https://go-review.googlesource.com/38660
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
We can also remove the internal/load import as a result.
Found with honnef.co/go/tools/cmd/unused.
Change-Id: Ie70c5713e7a6f238158804acec07807c14f8e092
Reviewed-on: https://go-review.googlesource.com/41473
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This will be used in the future to control backend concurrency.
See CL 40693.
In the meantime, make it a no-op.
This should fix the linux-amd64-racecompile builders.
Change-Id: Ibf3b2a7fff6f8f8c94f5fafb26e0500a51c8a4a6
Reviewed-on: https://go-review.googlesource.com/41614
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Databases have the following concepts: Statement, Batch, and Session.
A statement is often a single line like:
SELECT Amount from Account where ID = 50;
A batch is one or more statements submitted together for the query
to process. It may be a DELETE, INSERT, two UPDATES and a SELECT in
a single query text.
A session is usually represented by a single database connection.
This often is an issue when dealing with scopes in databases.
Temporary tables and variables can have batch, session, or global
scope depending on the syntax, database, and use.
Furthermore, some databases (sybase and derivatives in perticular)
that prevent certain statements from being in the same batch
and may necessitate being in the same session.
By allowing users to extract a Conn from the database they can manage
session on their own without hacking around it by making connection
pools of single connections (a real workaround presented in issue).
It is tempting to just use a transaction, but this isn't always
desirable or an option if running an interactive session or
alter script set that itself starts transactions.
Fixes#18081
Change-Id: I9bdf0796632c48d4bcaef3624c629641984ffaf2
Reviewed-on: https://go-review.googlesource.com/40694
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We have dedicated asm implementation of sincos only on 386 and amd64,
on everything else we are just jumping to generic version.
However amd64 version is actually slower than generic one:
Sincos-6 34.4ns ± 0% 24.8ns ± 0% -27.79% (p=0.000 n=8+10)
So remove all sincos*.s and keep only generic and 386.
Updates #19819
Change-Id: I7eefab35743729578264f52f6d23ee2c227c92a5
Reviewed-on: https://go-review.googlesource.com/41200
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This change adds line position tests for several yyerror calls in the
typechecker that are currently not tested in any way.
Untested yyerror calls were found by replacing them with
yerrorl(src.NoXPos, ...)
(thus destroying position information in the error), and then running
the test suite. No failures means no test coverage for the relevant
yyerror call.
For #19683
Change-Id: Iedb3d2f02141b332e9bfa76dbf5ae930ad2fddc3
Reviewed-on: https://go-review.googlesource.com/41477
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
doubleselect.go defines a flag to control the number of iterations,
but never called flag.Parse so it was unusable.
Change-Id: Ib5d0c7119e7f7c9a808dcc02d0d9cc6ba5bbc16e
Reviewed-on: https://go-review.googlesource.com/41299
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
While we're here, do minor style cleanup.
Also, since we know exactly how many init
functions there are, use that knowledge.
This is cleanup prior to a more substantive CL.
Change-Id: I2bba60b3c051c852590f798f45e8268f8bc54ca8
Reviewed-on: https://go-review.googlesource.com/41499
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is mildly wasteful to always create values
that must sometimes then be dead code eliminated.
Given that it is very easy to avoid, do so.
Noticed when examining a package with thousands
of generated wrappers, each of which uses
only a handful of Values to compile.
Change-Id: If02eb4aa786dfa20f7aa43e8d729dad8b3db2786
Reviewed-on: https://go-review.googlesource.com/41502
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
dumptypestructs did several different jobs.
Split them into separate functions
and call them in turn.
Hand dumptypestructs a list of dcls,
rather than reading the global.
Rename dumpptabs for (marginal) clarity.
This is groundwork for compiling autogenerated
functions concurrently.
Passes toolstash-check.
Change-Id: I627a1dffc70a7e4b7b4436ab19af1406267f01dc
Reviewed-on: https://go-review.googlesource.com/41501
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was just a cache, and the CL series yesterday
removed 40% of the calls to types.Linksym in make.bash.
Testing atop CL 40693 (backend concurrency)
indicates that removing it is actually a very minor
performance improvement.
Passes toolstash-check.
Change-Id: I97c2973036964acdd11b3cb842bc31f33ae60389
Reviewed-on: https://go-review.googlesource.com/41492
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The last mention of those types in this package are in:
commit 6bd0d0542e
Author: Russ Cox <rsc@golang.org>
Date: Thu Nov 6 19:56:55 2014 -0500
cmd/objdump, cmd/pprof: factor disassembly into cmd/internal/objfile
Found with honnef.co/go/tools/cmd/unused.
Change-Id: Iacc2902f7d0784ac0efdd92da239f3e97491469a
Reviewed-on: https://go-review.googlesource.com/41472
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestSeekError has been added in CL 41311. This
test doesn't build on Plan 9 because syscall.ESPIPE
is not defined on Plan 9.
This change defines syscall.ESPIPE on Plan 9.
Fixes#20078.
Change-Id: I3d9e95b00e0c4e43312eada6441d80961ae6bd67
Reviewed-on: https://go-review.googlesource.com/41471
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Hopefully the last refactoring of TestRespectGroupSticky:
* Properly tested (+simplified) FreeBSD fix
* Tested on Darwin (10.12.4)
* Rename to TestRespectSetgidDir (I believe this is the accepted
terminology)
Fixesgolang/go#19596.
Change-Id: I8d689ac3e245846cb3f1338ea13e35be512ccb9c
Reviewed-on: https://go-review.googlesource.com/41430
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Change a few functions so that instead of
accepting a *types.Sym and calling Linksym
themselves, they accept an *obj.LSym.
Adapt the callsites.
Passes toolstash-check.
Change-Id: Ic5d3f306f2fdd3913281215a1f54d893a966bb1f
Reviewed-on: https://go-review.googlesource.com/41404
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This batch from reflect.go.
Changes made manually, since they are simple,
few, and typechecked by the compiler.
Passes toolstash-check.
Change-Id: I0030daab2dac8e7c95158678c0f7141fd90441f9
Reviewed-on: https://go-review.googlesource.com/41399
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The only remaining uses of duintxx
are in the implementation of duintNN.
I hope to inline those once I figure out why
CL 40864 is broken.
Note that some uses of duintxx with width Widthint
were converted into duintptr.
I did that, since #19954 is officially going to move forward.
Passes toolstash-check.
Change-Id: Id25253b711ea589d0199b51be9a3c18ca1af59ce
Reviewed-on: https://go-review.googlesource.com/41398
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is an automated refactoring to eliminate
all dxxx calls in gc/obj.go that accept types.Sym
instead of obj.LSym parameters.
The refactoring was of the form:
gorename -from '"cmd/compile/internal/gc".duintxx' -to Duintxx
gorename -from '"cmd/compile/internal/gc".duintxxLSym' -to DuintxxLSym
eg -t t.go -w cmd/compile/internal/gc
gofmt -r 'DuintxxLSym -> duintxxLSym' -w cmd/compile/internal/gc
where t.go looked like:
func before(s *types.Sym, off int, v uint64, wid int) int {
return gc.Duintxx(s, off, v, wid)
}
func after(s *types.Sym, off int, v uint64, wid int) int {
return gc.DuintxxLSym(s.Linksym(), off, v, wid)
}
The rename/gofmt shenanigans were to work around
limitations and bugs in eg and gorename.
The resulting code in reflect.go looks temporarily ugly,
but it makes refactoring and cleanup opportunities
much clearer.
Next step is to rename all the dxxx methods to rename the -LSym suffix
and clean up reflect.go.
The renaming is left for a separate CL to make the changes in
this CL more obvious, and thus hopefully easier to review.
Passes toolstash-check.
Change-Id: Ib31a2b6fd146ed03a855d20ecb0433f0f74e2f10
Reviewed-on: https://go-review.googlesource.com/41396
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- Add new BranchStmt.Target field: It's the destination for break,
continue, or goto statements.
- When parsing with CheckBranches enabled, set the BranchStmt.Target
field. We get the information practically for free from the branch
checker, so keep it for further use.
- Fix a couple of comments.
- This could use a test, but the new Target field is currently not
used, and writing a test is tedious w/o a general tree visitor.
Do it later. For now, visually verified output from syntax dump.
Change-Id: Id691d89efab514ad885e19ac9759506106579520
Reviewed-on: https://go-review.googlesource.com/40988
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ARM's udiv function is nosplit and it shouldn't be preemptied
(passing args in registers). It is in some sense like DUFFCOPY,
which we don't mark as safepoint.
Change-Id: I49f7c4e69e787ac364d0b0def0661e79a0ea9e69
Reviewed-on: https://go-review.googlesource.com/41370
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently one needs to refer to the sources to have a list of accepted
debug keys. We can copy what 'ssa/help' does and introspect the list of
debug keys to print a more detailed help:
$ go tool compile -d help
usage: -d arg[,arg]* and arg is <key>[=<value>]
<key> is one of:
append print information about append compilation
closure print information about closure compilation
disablenil disable nil checks
dclstack run internal dclstack check
gcprog print dump of GC programs
nil print information about nil checks
panic do not hide any compiler panic
slice print information about slice compilation
typeassert print information about type assertion inlining
wb print information about write barriers
export print export data
pctab print named pc-value table
ssa/help print help about SSA debugging
<value> is key-specific.
Key "pctab" supports values:
"pctospadj", "pctofile", "pctoline", "pctoinline", "pctopcdata"
For '-d help' to be discoverable, a hint is given in the -d flag
description.
A last thing, today at least one go file needs to be provided to get to
the code printing ssa/help.
$ go tool compile -d ssa/help foo.go
Add a check so one can just do '-d help' or '-d ssa/help'
Caught by trybot: I needed to update fmt_test.go as I'm introducing the
usage of %-*s in a format string.
Fixes#20041
Change-Id: Ib2858b038c1bcbe644aa3b1a371009710c6d957d
Reviewed-on: https://go-review.googlesource.com/41091
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The experiment "clobberdead" clobbers all pointer fields that the
compiler thinks are dead, just before and after every safepoint.
Useful for debugging the generation of live pointer bitmaps.
Helped find the following issues:
Update #15936
Update #16026
Update #16095
Update #18860
Change-Id: Id1d12f86845e3d93bae903d968b1eac61fc461f9
Reviewed-on: https://go-review.googlesource.com/23924
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently TestSetGCPercent checks that NextGC is within 10 MB of the
expected value. For some reason it's much noisier on some of the
builders. To get these passing again, raise the threshold to 20 MB.
Change-Id: I14e64025660d782d81ff0421c1eb898f416e11fe
Reviewed-on: https://go-review.googlesource.com/41374
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
More steps towards simpler symbol handling:
- Pushdcl's incoming pos argument, saved in a newly pushed *Sym, was always
immediately overwritten by the Lastlineno value of the saved *Sym.
- Markdcl's incoming pos argument, saved in the stack mark *Sym, was not
restored when the stack mark was popped.
- Popdcl always maintained the most recent Lastlineno for a *Sym given
by package and name, making it unnecessary to save Lastlineno in the
first place. Removed Lastlineno from the set of fields that need saving,
and simplified Popdcl.
Change-Id: Ie93da1fbd780dcafc2703044e781c0c6298df569
Reviewed-on: https://go-review.googlesource.com/41390
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently SetGCPercent forces a GC in order to recompute GC pacing.
Since we can now recompute pacing on the fly using gcSetTriggerRatio,
change SetGCPercent (really runtime.setGCPercent) to go through
gcSetTriggerRatio and not trigger a GC.
Fixes#19076.
Change-Id: Ib30d7ab1bb3b55219535b9f238108f3d45a1b522
Reviewed-on: https://go-review.googlesource.com/39835
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
The current SetGCPercent test is, shall we say, minimal.
Expand it to check that the GC target is actually computed and updated
correctly.
For #19076.
Change-Id: I6e9b2ee0ef369f22f72e43b58d89e9f1e1b73b1b
Reviewed-on: https://go-review.googlesource.com/39834
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This changes gcSetTriggerRatio so it can be called even during
concurrent mark or sweep. In this case, it will adjust the pacing of
the current phase, accounting for progress that has already been made.
To make this work for concurrent sweep, this introduces a "basis" for
the pagesSwept count, much like the basis we just introduced for
heap_live. This lets gcSetTriggerRatio shift the basis to the current
heap_live and pagesSwept and compute a slope from there to completion.
This avoids creating a discontinuity where, if the ratio has
increased, there has to be a flurry of sweep activity to catch up.
Instead, this creates a continuous, piece-wise linear function as
adjustments are made.
For #19076.
Change-Id: Ibcd76aeeb81ff4814b00be7cbd3530b73bbdbba9
Reviewed-on: https://go-review.googlesource.com/39833
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, proportional sweep maintains its own count of how many
bytes have been allocated since the beginning of the sweep cycle so it
can compute how many pages need to be swept for a given allocation.
However, this requires a somewhat complex reimbursement scheme since
proportional sweep must be done before a span is allocated, but we
don't know how many bytes to charge until we've allocated a span. This
means that the allocated byte count used by proportional sweep can go
up and down, which has led to underflow bugs in the past (#18043) and
is going to interfere with adjusting sweep pacing on-the-fly (for #19076).
This approach also means we're maintaining a statistic that is very
closely related to heap_live, but has a different 0 value. This is
particularly confusing because the sweep ratio is computed based on
heap_live, so you have to understand that these two statistics are
very closely related.
Replace all of this and compute the sweep debt directly from the
current value of heap_live. To make this work, we simply save the
value of heap_live when the sweep ratio is computed to use as a
"basis" for later computing the sweep debt.
This eliminates the need for reimbursement as well as the code for
maintaining the sweeper's version of the live heap size.
For #19076.
Coincidentally fixes#18043, since this eliminates sweep reimbursement
entirely.
Change-Id: I1f931ddd6e90c901a3972c7506874c899251dc2a
Reviewed-on: https://go-review.googlesource.com/39832
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, the computations that derive controls from the GC trigger
are spread across several parts of the mark termination code.
Consolidate computing the absolute trigger, the heap goal, and sweep
pacing into a single function called at the end of mark termination.
Unlike the code being consolidated, this has to be more careful about
negative gcpercent. Many of the consolidated code paths simply didn't
execute if GC was off.
This is a step toward being able to change the GC trigger ratio in the
middle of concurrent sweeping and marking. For this commit, we try to
stick close to the original structure of the code that's being
consolidated, so it doesn't yet support mid-cycle adjustments.
For #19076.
Change-Id: Ic5335be04b96ad20e70d53d67913a86bd6b31456
Reviewed-on: https://go-review.googlesource.com/39831
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
gcController.triggerRatio is the only field in gcController that
persists across cycles. As global mutable state, the places where it
written and read are spread out, making it difficult to see that
updates and downstream calculations are done correctly.
Improve this situation by doing two things:
1) Move triggerRatio to memstats so it lives with the other
trigger-related fields and makes gcController entirely transient
state.
2) Commit the new trigger ratio during mark termination when we
compute other next-cycle controls, including the absolute trigger.
This forces us to explicitly thread the new trigger ratio from
gcController.endCycle to mark termination, so we're not just pulling
it out of global state.
Change-Id: I6669932f8039a8c0ef46a3f2a8c537db72e578aa
Reviewed-on: https://go-review.googlesource.com/39830
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
heap_live is updated atomically without locking, so we should also use
atomic loads to read it. Fix the reads of heap_live that happen
outside of STW to be atomic.
Change-Id: Idca9451c348168c2a792a9499af349833a3c333f
Reviewed-on: https://go-review.googlesource.com/41371
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The inliner's ishairy passes a budget and a reason down through the
walk. Lift these into a visitor object and turn ishairy and its
helpers into methods.
This will make it easy to add more state.
Change-Id: Ic6ae246e1affd67ed283c3205f9595ae33e22215
Reviewed-on: https://go-review.googlesource.com/41151
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Response to code review feedback on CL 40693.
It is now only accessible by types.TypePkgLookup.
Passes toolstash-check.
Change-Id: I0c422c1a271f97467ae38de53af9dc33f4b31bdb
Reviewed-on: https://go-review.googlesource.com/41304
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Response to code review feedback on CL 40693.
Remove the final reference to it from package gc,
and manually unexport.
Passes toolstash-check.
Change-Id: I7fc48edd43263d8f7c56b47aeb7573408463dc22
Reviewed-on: https://go-review.googlesource.com/41303
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Previously, helpers were identified by entry PC, but this breaks if the
helper is inlined (as in notHelperCallingHelper). Instead, identify
helpers by function name (with package path). Now TestTBHelper and
TestTBHelperParallel pass with -l=4.
To keep the code unified, this change makes it so that the runner
is also identified by function name instead of entry PC.
Change-Id: I1b1987fc49d114e69d075fab56aeeacd5294982b
Reviewed-on: https://go-review.googlesource.com/41257
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
runtime.getcaller{pc,sp} expect their argument to be a pointer to the
caller's first function argument. This assumption breaks when the caller
is inlined. For example, with -l=4, calls to runtime.entersyscall (which
calls getcallerpc) are inlined and that breaks multiple cgo tests.
This change modifies the compiler to refuse to inline functions that
call runtime.getcaller{pc,sp}. Alternatively, we could mark these
functions //go:noinline but that limits optimization opportunities if
the calls to getcaller{pc,sp} are eliminated as dead code.
Previously TestCgoPprofPIE, TestCgoPprof, and TestCgoCallbackGC failed
with -l=4. Now all of the runtime tests pass with -l=4.
Change-Id: I258bca9025e20fc451e673a18f862b5da1e07ae7
Reviewed-on: https://go-review.googlesource.com/40998
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>
On 32-bit architectures (or if we fail to map a 64-bit-style arena),
we try to map the heap arena just above the end of the process image.
While we can accept any address, using lower addresses is preferable
because lower addresses cause us to map less of the heap bitmap.
However, if a program is linked against C code that has global
constructors, those constructors may call brk/sbrk to allocate memory
(e.g., many C malloc implementations do this for small allocations).
The brk also starts just above the process image, so this may adjust
the brk past the beginning of where we want to put the heap arena. In
this case, the kernel will pick a different address for the arena and
it will usually be very high (at least, as these things go in a 32-bit
address space).
Fix this by consulting the current value of the brk and using this in
addition to the end of the process image to compute the initial arena
placement.
This is implemented only on Linux currently, since we have no evidence
that it's an issue on any other OSes.
Fixes#19831.
Change-Id: Id64b45d08d8c91e4f50d92d0339146250b04f2f8
Reviewed-on: https://go-review.googlesource.com/39810
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This makes the cmd/compile/internal/ssa package
compile much faster, and has no impact
on the speed of the compiler.
The chunk size was selected empirically,
in that at chunk size 10, the object
file was smaller than at chunk size 5 or 20.
name old time/op new time/op delta
SSA 7.33s ± 5% 5.64s ± 1% -23.10% (p=0.000 n=10+10)
name old user-time/op new user-time/op delta
SSA 9.70s ± 1% 8.04s ± 2% -17.17% (p=0.000 n=9+10)
name old obj-bytes new obj-bytes delta
SSA 9.82M ± 0% 8.28M ± 0% -15.67% (p=0.000 n=10+10)
Change-Id: Iab472905da3f0e82f3db2c93d06e2759abc9dd44
Reviewed-on: https://go-review.googlesource.com/41296
Reviewed-by: Keith Randall <khr@golang.org>
FreeBSD doesn't allow non-root users to enable the SetGID bit on
files or directories in /tmp, however it does allow this in
subdirectories, so create the test directory one level deeper.
Followup to golang/go#19596.
Change-Id: I30e71c6d6a156badc863e8068df10ef6ed817e26
Reviewed-on: https://go-review.googlesource.com/41216
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Brad noticed a bullet list was rendered as preformatted text because of
the indentation. One can use a unicode bullet as an ersatz for bullet
lists.
Fixes#20043
Change-Id: Iaed3582d14bd05920455669039a900d7155960d9
Reviewed-on: https://go-review.googlesource.com/41212
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adding the Go Time podcast under the `Stay informed` section of the help
page on the website.
Change-Id: Ifb1c6bb20cbf640a91572d47f14a432f58439261
Reviewed-on: https://go-review.googlesource.com/41146
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
At VARKILLs, zero a variable if it is ambiguously live.
After the VARKILL anything this variable references
might be collected. If it were to become live again later,
the GC will see references to already-collected objects.
We don't know a variable is ambiguously live until very
late in compilation (after lowering, register allocation, ...),
so it is hard to generate the code in an arch-independent way.
We also have to be careful not to clobber any registers.
Fortunately, this almost never happens so performance is ~irrelevant.
There are only 2 instances where this triggers in the stdlib.
Fixes#20029
Change-Id: Ia9585a91d7b823fad4a9d141d954464cc7af31f4
Reviewed-on: https://go-review.googlesource.com/41076
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
There were only two versions, 0 and 1,
and the only user of version 1 was the assembler,
to indicate that a symbol was static.
Rename LSym.Version to Static,
and add it to LSym.Attributes.
Simplify call-sites.
Passes toolstash-check.
Change-Id: Iabd39918f5019cce78f381d13f0481ae09f3871f
Reviewed-on: https://go-review.googlesource.com/41201
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Imported interfaces must be completed, whether they are named or not.
The original code was collecting all types (including anonymous ones)
in the importer's typList. That list was used in the end to complete
interface types. When we introduced tracking of named types only, we
lost anonymous interfaces. Use an independent list of interface types
so the completion code is independent of which types are tracked.
Added test and factored some of the existing tests.
Fixes#20046.
Change-Id: Icd1329032aec33f96890380dd5042de3bef8cdc7
Reviewed-on: https://go-review.googlesource.com/41198
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TestBreakpoint expects to see "runtime.Breakpoint()" in the stack trace.
If runtime.Breakpoint() is inlined, then the stack trace prints
"runtime.Breakpoint(...)" since the runtime does not have information
about arguments (or lack thereof) to inlined functions. This change
makes the test independent of inlining by looking for the string
"runtime.Breakpoint(". Now TestBreakpoint passes with -l=4.
Change-Id: Ia044a8e8a4de2337cb2b393d6fa78c73a2f25926
Reviewed-on: https://go-review.googlesource.com/40997
Run-TryBot: David Lazar <lazard@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TestBlockProfile matches samples against a regexp that accepts "," in
profile PCs. I suspect this was just a syntax mistake. Remove "," from
the character class.
Change-Id: Idcfc20ed6900075abae08597ba71db559e89b37b
Reviewed-on: https://go-review.googlesource.com/41111
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
TestBlockProfile currently requires exactly five PCs in each sample.
With more aggressive inlining there may be fewer, so change this test
to use the same pattern as TestMutexProfile, which accepts one or more
PCs. With this change, this test passes when compiled with -l=4.
Change-Id: I1421a6d56c96b77111bdc671d88723a222672fd6
Reviewed-on: https://go-review.googlesource.com/41110
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Lazar <lazard@golang.org>
CL 40876 changed ExampleFrames so that the output
was stable with and without mid-stack inlining.
However, that change lost some of the
pedagogical and copy/paste value of the example.
It was unclear why both more and i were being tracked,
and whether the 5 in i < 5 is related to len(pc),
and if so, why and how.
This CL rewrites the example with lots more comments,
and such that the core structure more closely matches
normal usage, and such that it is obvious
which lines of code should be deleted when copying.
As a bonus, it also now illustrates Frame.File.
Change-Id: Iab73541dd096657ddf79c5795337e8b596d89740
Reviewed-on: https://go-review.googlesource.com/41136
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The period recorded in CPU profiles is in nanoseconds, but was being
computed incorrectly as hz * 1000. As a result, many absolute times
displayed by pprof were incorrect.
Fix this by computing the period correctly.
Change-Id: I6fadd6d8ad3e57f31e8cc7a25a24fcaec510d8d4
Reviewed-on: https://go-review.googlesource.com/40995
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Convert the parsed attribute name to lowercase before checking its value in
the HTML parser state machine. This ensures that the type attribute in
the script element is handled in a case-sensitive manner, just like all
other attribute names.
Fixes#19965
Change-Id: I806d8c62aada2c3b5b4328aff75f217ea60cb339
Reviewed-on: https://go-review.googlesource.com/40650
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Handle MIME types found in the type attribute of the script element
in a case insensitive way, as per Section 5.1 of RFC 2045.
Fixes#19968
Change-Id: Ie1416178c937dcf2c96bcec4191cebe7c3477af8
Reviewed-on: https://go-review.googlesource.com/40702
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This updates PPC64.rules to include rules to generate rotates
for ADD, OR, XOR operators that combine two opposite shifts
that sum to 32 or 64.
To support this change opcodes for ROTL and ROTLW were added to
be used like the rotldi and rotlwi extended mnemonics.
This provides the following improvement in sha3:
BenchmarkPermutationFunction-8 302.83 376.40 1.24x
BenchmarkSha3_512_MTU-8 98.64 121.92 1.24x
BenchmarkSha3_384_MTU-8 136.80 168.30 1.23x
BenchmarkSha3_256_MTU-8 169.21 211.29 1.25x
BenchmarkSha3_224_MTU-8 179.76 221.19 1.23x
BenchmarkShake128_MTU-8 212.87 263.23 1.24x
BenchmarkShake256_MTU-8 196.62 245.60 1.25x
BenchmarkShake256_16x-8 163.57 194.37 1.19x
BenchmarkShake256_1MiB-8 199.02 248.74 1.25x
BenchmarkSha3_512_1MiB-8 106.55 133.13 1.25x
Fixes#20030
Change-Id: I484c56f48395d32f53ff3ecb3ac6cb8191cfee44
Reviewed-on: https://go-review.googlesource.com/40992
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Instead of populating the aux symbol
of CALLudiv during rewrite rules,
populate it during genssa.
This simplifies the rewrite rules.
It also removes all remaining calls
to ctxt.Lookup from any rewrite rules.
This is a first step towards removing
ctxt from ssa.Cache entirely,
and also a first step towards converting
the obj.LSym.Version field into a boolean.
It should also speed up compilation.
Also, move func udiv into package runtime.
That's where it is anyway,
and it lets udiv look and act like the rest of
the runtime support functions.
Change-Id: I41462a632c14fdc41f61b08049ec13cd80a87bfe
Reviewed-on: https://go-review.googlesource.com/41191
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ld.ldelf contained a mixture of normal and C style, goto bad, error
handling. The use of goto requires many variables to be declared well
before their use which inhibited further refactoring to this method.
This CL removes the gotos in this function. Future CLs will address
remainder of the C style function scoped declarations in this function.
Change-Id: Ib9def495209a2f8deb11dcf30ee954bca95390c6
Reviewed-on: https://go-review.googlesource.com/41172
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The dclstack is now a proper stack and thus we can implement it
using a slice rather than a linked list.
Change-Id: I200e85621ff76c111bdeb7eb382fd82da438f3ba
Reviewed-on: https://go-review.googlesource.com/41135
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- PkgMap was only needed to test import/export in a "cleanroom"
environment, with debugFormat set. Provided helper function
instead.
- PkgList was only used to identify directly imported packages.
Instead, compute that list explicitly from the package map.
It happens only once, the list is small, and it's more robust
than keeping two data structures in sync.
Change-Id: I82dce3c0b5cb816faae58708e877799359c20fcb
Reviewed-on: https://go-review.googlesource.com/41078
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Such dead code is legitimate when dealing with arch-specific
types (int, uint, uintptr).
The CL removes the majority of 'too small for shift' false positives
from such a code.
Change-Id: I62c5635a1d3774ab2d71d3d7056f0589f214cbe5
Reviewed-on: https://go-review.googlesource.com/38065
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This extends the GCSweepDone event with counts of swept and reclaimed
bytes. These are useful for understanding the duration and
effectiveness of sweep events.
Change-Id: I3c97a4f0f3aad3adbd188adb264859775f54e2df
Reviewed-on: https://go-review.googlesource.com/40811
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Currently, each individual span sweep emits a span to the trace. But
sweeps are generally done in loops until some condition is satisfied,
so this tracing is lower-level than anyone really wants any hides the
fact that no other work is being accomplished between adjacent sweep
events. This is also high overhead: enabling tracing significantly
impacts sweep latency.
Replace this with instead tracing around the sweep loops used for
allocation. This is slightly tricky because sweep loops don't
generally know if any sweeping will happen in them. Hence, we make the
tracing lazy by recording in the P that we would like to start tracing
the sweep *if* one happens, and then only closing the sweep event if
we started it.
This does mean we don't get tracing on every sweep path, which are
legion. However, we get much more informative tracing on the paths
that block allocation, which are the paths that matter.
Change-Id: I73e14fbb250acb0c9d92e3648bddaa5e7d7e271c
Reviewed-on: https://go-review.googlesource.com/40810
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Changes the text to match GOOS which appends 'and so on' at the
end to avoid restricting the set of possible values.
Change-Id: I54bcde71334202cf701662cdc2582c974ba8bf53
Reviewed-on: https://go-review.googlesource.com/41074
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When allocating a non-small array of buckets for a map,
also preallocate some overflow buckets.
The estimate of the number of overflow buckets
is based on a simulation of putting mid=(low+high)/2 elements
into a map, where low is the minimum number of elements
needed to reach this value of b (according to overLoadFactor),
and high is the maximum number of elements possible
to put in this value of b (according to overLoadFactor).
This estimate is surprisingly reliable and accurate.
The number of overflow buckets needed is quadratic,
for a fixed value of b.
Using this mid estimate means that we will overallocate a few
too many overflow buckets when the actual number of elements is near low,
and underallocate significantly too few overflow buckets
when the actual number of elements is near high.
The mechanism introduced in this CL can be re-used for
other overflow bucket optimizations.
For example, given an initial size hint,
we could estimate quite precisely the number of overflow buckets.
This is #19931.
We could also change from "non-nil means end-of-list"
to "pointer-to-hmap.buckets means end-of-list",
and then create a linked list of reusable overflow buckets
when they are freed by map growth.
That is #19992.
We could also use a similar mechanism to do bulk allocation
of overflow buckets.
All these uses can co-exist with only the one additional pointer
in mapextra, given a little care.
name old time/op new time/op delta
MapPopulate/1-8 60.1ns ± 2% 60.3ns ± 2% ~ (p=0.278 n=19+20)
MapPopulate/10-8 577ns ± 1% 578ns ± 1% ~ (p=0.140 n=20+20)
MapPopulate/100-8 8.06µs ± 1% 8.19µs ± 1% +1.67% (p=0.000 n=20+20)
MapPopulate/1000-8 104µs ± 1% 104µs ± 1% ~ (p=0.317 n=20+20)
MapPopulate/10000-8 891µs ± 1% 888µs ± 1% ~ (p=0.101 n=19+20)
MapPopulate/100000-8 8.61ms ± 1% 8.58ms ± 0% -0.34% (p=0.009 n=20+17)
name old alloc/op new alloc/op delta
MapPopulate/1-8 0.00B 0.00B ~ (all equal)
MapPopulate/10-8 179B ± 0% 179B ± 0% ~ (all equal)
MapPopulate/100-8 3.33kB ± 0% 3.38kB ± 0% +1.48% (p=0.000 n=20+16)
MapPopulate/1000-8 55.5kB ± 0% 53.4kB ± 0% -3.84% (p=0.000 n=19+20)
MapPopulate/10000-8 432kB ± 0% 428kB ± 0% -1.06% (p=0.000 n=19+20)
MapPopulate/100000-8 3.65MB ± 0% 3.62MB ± 0% -0.70% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
MapPopulate/1-8 0.00 0.00 ~ (all equal)
MapPopulate/10-8 1.00 ± 0% 1.00 ± 0% ~ (all equal)
MapPopulate/100-8 18.0 ± 0% 17.0 ± 0% -5.56% (p=0.000 n=20+20)
MapPopulate/1000-8 96.0 ± 0% 72.6 ± 1% -24.38% (p=0.000 n=20+20)
MapPopulate/10000-8 625 ± 0% 319 ± 0% -48.86% (p=0.000 n=20+20)
MapPopulate/100000-8 6.23k ± 0% 4.00k ± 0% -35.79% (p=0.000 n=20+20)
Change-Id: I01f41cb1374bdb99ccedbc00d04fb9ae43daa204
Reviewed-on: https://go-review.googlesource.com/40979
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Any change to how we allocate overflow buckets
will require some extra hmap storage,
but we don't want hmap to grow,
particular as small maps usually don't need overflow buckets.
This CL converts the existing hmap overflow field,
which is usually used for pointer-free maps,
into a generic extra field.
This extra field can be used to hold data that is optional.
If it is valuable enough to do have special
handling of overflow buckets, which are medium-sized,
it is valuable enough to pay an extra alloc and two extra words for.
Adding fields to extra would entail adding overhead to pointer-free maps;
any mapextra fields added would need to be weighed against that.
This CL is just rearrangement, though.
Updates #19931
Updates #19992
Change-Id: If8537a206905b9d4dc6cd9d886184ece671b3f80
Reviewed-on: https://go-review.googlesource.com/40976
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
goobj.importPathToPrefix is 3x faster than gc.pathToPrefix so rename and
move it to cmd/internal/objabi which is already imported by both goobj and
gc.
Change-Id: I10eda5bce95ef6d5d888818c5c47258c2833ea45
Reviewed-on: https://go-review.googlesource.com/40875
Run-TryBot: Todd Neal <todd@tneal.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Replace derecursed postorder computation with one that
mimics DFS traversal.
Corrected outerinner function in loopfinder
Leave enhanced checks in place.
Change-Id: I657ba5e89c88941028d6d4c72e9f9056e30f1ce8
Reviewed-on: https://go-review.googlesource.com/40872
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Follow-up on https://go-review.googlesource.com/#/c/39998/
which dropped this information.
The reported blocks are the innermost blocks containing a
label jumped to from outside, not the outermost block as
reported originally by cmd/compile.
We could report the outermost block with a slighly more
involved algorithm (need to track containing blocks for
all unresolved forward gotos), but since gccgo also reports
the innermost blocks, the current approach seems good enough.
Change-Id: Ic0235b8fafe8d5f99dc9872b58e90e8d9e72c5db
Reviewed-on: https://go-review.googlesource.com/40980
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Instead of a separate check control flow pass (checkcfg.go)
operating on nodes, perform this check at parse time on the
new syntax tree. Permits this check to be done concurrently,
and doesn't depend on the specifics of the symbol's dclstack
implementation anymore. The remaining dclstack uses will be
removed in a follow-up change.
- added CheckBranches Mode flag (so we can turn off the check
if we only care about syntactic correctness, e.g. for tests)
- adjusted test/goto.go error messages: the new branches
checker only reports if a goto jumps into a block, but not
which block (we may want to improve this again, eventually)
- also, the new branches checker reports one variable that
is being jumped over by a goto, but it may not be the first
one declared (this is fine either way)
- the new branches checker reports additional errors for
fixedbugs/issue14006.go (not crucial to avoid those errors)
- the new branches checker now correctly reports only
variable declarations being jumped over, rather than
all declarations (issue 8042). Added respective tests.
Fixes#8042.
Change-Id: I53b6e1bda189748e1e1fb5b765a8a64337c27d40
Reviewed-on: https://go-review.googlesource.com/39998
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now only cmd/asm and cmd/compile depend on cmd/internal/obj. Changing
the assembler backends no longer requires reinstalling cmd/link or
cmd/addr2line.
There's also now one canonical definition of the object file format in
cmd/internal/objabi/doc.go, with a warning to update all three
implementations.
objabi is still something of a grab bag of unrelated code (e.g., flag
and environment variable handling probably belong in a separate "tool"
package), but this is still progress.
Fixes#15165.
Fixes#20026.
Change-Id: Ic4b92fac7d0d35438e0d20c9579aad4085c5534c
Reviewed-on: https://go-review.googlesource.com/40972
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Now cgo reads source files twice: for c prefix generation and parsing
go code to an ast node. It can be narrowed down to single loop.
Change-Id: Ie05452a3a12106aaab863244727390037e69e8e6
Reviewed-on: https://go-review.googlesource.com/40939
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Here we restrict using cgo builtin references because internally they're go functions
as opposed to C usafe.Pointer values.
Fixes#18889
Change-Id: I1e4332e4884063ccbaf9772c172d4462ec8f3d13
Reviewed-on: https://go-review.googlesource.com/40934
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestMultiReaderFlatten determines the call depth by counting PCs
returned by runtime.Callers. With inlining, this is incorrect because
a PC can represent multiple calls. Furthermore, runtime.Callers might
return an additional "skip" PC, which does not represent a real call.
This modifies the test to use CallersFrames to determine the call depth.
Now the test passes with -l=4.
Change-Id: I284f3b1e0b2d194bd08c230c616914503e5a370d
Reviewed-on: https://go-review.googlesource.com/40990
Run-TryBot: David Lazar <lazard@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Only the noinline pragma on testCallerFoo is needed to pass the test,
but the second pragma makes the test robust to future changes to the
inliner.
Change-Id: I80b384380c598f52e0382f53b59bb47ff196363d
Reviewed-on: https://go-review.googlesource.com/40877
Run-TryBot: David Lazar <lazard@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This rewrites runtime.Caller in terms of stackExpander, which already
handles inlined frames and partially skipped frames. This also has the
effect of making runtime.Caller understand cgo frames if there is a cgo
symbolizer.
Updates #19348.
Change-Id: Icdf4df921aab5aa394d4d92e3becc4dd169c9a6e
Reviewed-on: https://go-review.googlesource.com/40270
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
CL 27254 changed hextable to a byte array for performance.
CL 28219 fixed the compiler so that that is no longer necessary.
As Kirill notes in #15808, a string is preferable
as the linker can easily de-dup it.
So go back. No performance changes.
Change-Id: Ibef7d21d0f2507968a0606602c5dd57ed4a85b1b
Reviewed-on: https://go-review.googlesource.com/40970
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Automated refactoring using github.com/mdempsky/unbed (to rewrite
s.Foo to s.FuncInfo.Foo) and then gorename (to rename the FuncInfo
field to just Func).
Passes toolstash-check -all.
Change-Id: I802c07a1239e0efea058a91a87c5efe12170083a
Reviewed-on: https://go-review.googlesource.com/40670
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This CL adds a simple explanation about what means the ptrdata field of
the reflect.rtype type.
Also document that rtype needs to be kept in sync with the runtime._type
type that rtype mirrors.
Change-Id: Icd9663a2e4bb94d922a2417cfe4537861d2ccc97
Reviewed-on: https://go-review.googlesource.com/40917
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the bool value isn't used, there is no need to assign to underscore -
there is a shorter form that only returns the value and behaves in the
exact same way.
Change-Id: Iaf801b8e966da6c2f565bc39e3bb028175c92d60
Reviewed-on: https://go-review.googlesource.com/40920
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change just picks a few constants from DragonfFly BSD 4.6 kernel
and doesn't synchronize all the existing constants with the latest
DragonFly BSD kernels.
Updates #14222.
Change-Id: Ie107a8bee1a09393b3b42b6f82489532f5d13290
Reviewed-on: https://go-review.googlesource.com/40894
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The compiler handled gcargs and gclocals LSyms unusually.
It generated placeholder symbols (makefuncdatasym),
filled them in, and then renamed them for content-addressability.
This is an important binary size optimization;
the same locals information occurs over and over.
This CL continues to treat these LSyms unusually,
but in a slightly more explicit way,
and importantly for concurrent compilation,
in a way that does not require concurrent
modification of Ctxt.Hash.
Instead of creating gcargs and gclocals in the usual way,
by creating a types.Sym and then an obj.LSym,
we add them directly to obj.FuncInfo,
initialize them in obj.InitTextSym,
and deduplicate and add them to ctxt.Data at the end.
Then the backend's job is simply to fill them in
and rename them appropriately.
Updates #15756
name old alloc/op new alloc/op delta
Template 38.8MB ± 0% 38.7MB ± 0% -0.22% (p=0.016 n=5+5)
Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.690 n=5+5)
GoTypes 113MB ± 0% 113MB ± 0% -0.24% (p=0.008 n=5+5)
SSA 1.25GB ± 0% 1.24GB ± 0% -0.39% (p=0.008 n=5+5)
Flate 25.3MB ± 0% 25.2MB ± 0% -0.43% (p=0.008 n=5+5)
GoParser 31.7MB ± 0% 31.7MB ± 0% -0.22% (p=0.008 n=5+5)
Reflect 78.2MB ± 0% 77.6MB ± 0% -0.80% (p=0.008 n=5+5)
Tar 26.6MB ± 0% 26.3MB ± 0% -0.85% (p=0.008 n=5+5)
XML 42.4MB ± 0% 41.9MB ± 0% -1.04% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
Template 378k ± 0% 377k ± 1% ~ (p=0.151 n=5+5)
Unicode 321k ± 1% 321k ± 0% ~ (p=0.841 n=5+5)
GoTypes 1.14M ± 0% 1.14M ± 0% -0.47% (p=0.016 n=5+5)
SSA 9.71M ± 0% 9.67M ± 0% -0.33% (p=0.008 n=5+5)
Flate 233k ± 1% 232k ± 1% ~ (p=0.151 n=5+5)
GoParser 316k ± 0% 315k ± 0% -0.49% (p=0.016 n=5+5)
Reflect 979k ± 0% 972k ± 0% -0.75% (p=0.008 n=5+5)
Tar 250k ± 0% 247k ± 1% -0.92% (p=0.008 n=5+5)
XML 392k ± 1% 389k ± 0% -0.67% (p=0.008 n=5+5)
Change-Id: Idc36186ca9d2f8214b5f7720bbc27b6bb22fdc48
Reviewed-on: https://go-review.googlesource.com/40697
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The Frames API forces the PC slice to escape to the heap because it
stores it in the Frames object. However, we'd like to use this API for
call stack expansion internally in the runtime in places where it
would be very good to avoid heap allocation.
This commit makes this possible by pulling the bulk of the Frames
implementation into an internal frameExpander API. The key difference
between these APIs is that the frameExpander does not hold the PC
slice; instead, the caller is responsible for threading the PC slice
through the frameExpander API calls. This makes it possible to keep
the PC slice on the stack. The Frames API then becomes a thin shim
around the frameExpander that keeps the PC slice in the Frames object.
Change-Id: If6b2d0b9132a2a905a0cf5deced9feddce76fc0e
Reviewed-on: https://go-review.googlesource.com/40610
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Lazar <lazard@golang.org>
Reading a response with a status line like "HTTP/1.0 401 Unauthorized"
(with two spaces after the version) has been returning an error. Now the
extra space will be ignored.
Fixes#19989
Change-Id: I0c88a6ef7562ba80e2e2635be2070dd1b5b671a7
Reviewed-on: https://go-review.googlesource.com/40933
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously the "ABI hash" for a package (used to determine if a loaded shared
library has the ABI expected by its loader) was the hash of the entire
__.PKGDEF file. But that means it depends on the build ID generated by the go
tool for the package, which means that if a file is added (even a .c or .h
file!) to the package, the ABI changes, perhaps uncessarily.
Fixes#19920
Change-Id: If919481e1a03afb350c8a9c7a0666bb90ee90270
Reviewed-on: https://go-review.googlesource.com/40401
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Added a paragraph and examples explaining when an implementation
may use fused floating-point operations (such as FMA) and how to
prevent operation fusion.
For #17895.
Change-Id: I64c9559fc1097e597525caca420cfa7032d67014
Reviewed-on: https://go-review.googlesource.com/40391
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
While debugging a recent regression it was discovered that
the assembler for ppc64x was not always generating the correct
instruction for DS form loads and stores. When an instruction
is DS form then the offset must be a multiple of 4, and if it
isn't then bits outside the offset field were being incorrectly
set resulting in unexpected and incorrect instructions.
This change adds a check to determine when the opcode is DS form
and then verifies that the offset is a multiple of 4 before
generating the instruction, otherwise logs an error.
This also changes a few asm files that were using unaligned offsets
for DS form loads and stores. In the runtime package these were
instructions intended to cause a crash so using aligned or unaligned
offsets doesn't change that behavior.
Change-Id: Ie3a7e1e65dcc9933b54de7a46a054da8459cb56f
Reviewed-on: https://go-review.googlesource.com/40476
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Avoid the use of constant absolute temp files in tests. This could
produce flaky results, for example on multiuser development machines.
Change-Id: Ia76157a0660fbe294bb31a46ded886cea5deec97
Reviewed-on: https://go-review.googlesource.com/40916
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The first part of this test tries to confirm that we can't create
a TempFile in a non-existent directory, but does not ensure that
the non-existent directory really does not exist. Instead, let's
create an empty temp directory, and use a non-existent subdir of
that.
Change-Id: I176f14ed5f5a2d7a8c29d8f6949755db69d7dbb6
Reviewed-on: https://go-review.googlesource.com/40914
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use our own tempdir, to avoid having to Init (and somehow teardown)
Builder. This way we don't leave behind any temp files.
Also, don't create a hardcoded path inside a testcase.
Followup to golang/go#18878.
Fixesgolang/go#19449.
Change-Id: Ieb1ebeab24ae8a74a6fa058d9c23f72b3fc1c444
Reviewed-on: https://go-review.googlesource.com/40912
Reviewed-by: Ian Lance Taylor <iant@golang.org>
They do basically the same work.
Setuintxx was only used in a single place,
so eliminate it in favor of WriteInt.
duintxxLSym's alignment rounding was not used in practice;
change it into alignment assertion.
Passes toolstash-check. No compiler performance changes.
Change-Id: I0f7410cf2ccffbdc02ad796eaf973ee6a83074f8
Reviewed-on: https://go-review.googlesource.com/40863
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Update the route package to git rev 6b27048a.
Introduce the following changes:
- 6b27048 route: drop support for go1.5
- b7fd658 route: fix typo
- 41bba8d route: add support for the manipulation of routing informaion
Updates #19967
Change-Id: Id2bb93df97a45254a2df2b048db0143e3e52bbdf
Reviewed-on: https://go-review.googlesource.com/40830
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was added in 2013 in CL 7064048.
All uses of it in the compiler disappeared with
(or possibly before) the SSA backend.
Several releases have gone by without it,
from which I conclude that it is now not needed.
Change-Id: I2095f4ac05d4d7ab998168993a7fd5d954aeee88
Reviewed-on: https://go-review.googlesource.com/40856
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update the lif package to rev 7bf7a75.
Introduce the following changes:
- 7bf7a75 lif: use of nativeEndian to make API endian agnostic
- adc6ba9 lif: drop support for go1.5
Updates #19967
Change-Id: Iaba893b5ee9af4c54bf5ba4244ce5752ce9f6ad3
Reviewed-on: https://go-review.googlesource.com/40831
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This comment was out of date since the bump to 80 done as the same time
as inlining transitive functions in:
commit 77ccb16eb1
Author: Russ Cox <rsc@golang.org>
Date: Tue Feb 24 12:19:01 2015 -0500
cmd/internal/gc: transitive inlining
Adjust the comment at the top of the file accordingly.
Change-Id: Ia6d7397c874e3b85396e82dc9678e56aab9ad728
Reviewed-on: https://go-review.googlesource.com/40910
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change delays IP protocol stack-snooping system calls until the
start of connection setup for the better experience with some system
call auditing, such as seccomp on Linux. See #16789 for examples.
Also updates the documentation on favoriteAddrFamily, which is the
owner of stack-snooping system calls.
Fixes#16789.
Change-Id: I4af27bc1ed06ffb1f657b6f6381c328c1f41c66c
Reviewed-on: https://go-review.googlesource.com/40750
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL implements the proposal at
https://github.com/golang/proposal/blob/master/design/4899-testing-helper.md.
It's based on Josh's CL 79890043 from a few years ago:
https://codereview.appspot.com/79890043 but makes several changes,
most notably by using the new CallersFrames API so that it works with
mid-stack inlining.
Another detail came up while I was working on this: I didn't want the
user to be able to call t.Helper from inside their TestXxx function
directly (which would mean we'd print a file:line from inside the
testing package itself), so I explicitly prevented this from working.
Fixes#4899.
Change-Id: I37493edcfb63307f950442bbaf993d1589515310
Reviewed-on: https://go-review.googlesource.com/38796
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The fixedbugs/issue12536.go file was erroneously deleted just before
committing the patch that fixed the issue (CL 14400).
That's an easy test and there's a small reproducer in the issue, add
it back.
Updates #12536
Change-Id: Ib7b0cd245588299e9a5469e1d75805fd0261ce1a
Reviewed-on: https://go-review.googlesource.com/40712
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Now the runtime/trace tests pass with -l=4.
This also gets rid of the frames cache for multiple reasons:
1) The frames cache was used to avoid repeated calls to funcname and
funcline. Now these calls happen inside the CallersFrames iterator.
2) Maintaining a frames cache is harder: map[uintptr]traceFrame
doesn't work since each PC can map to multiple traceFrames.
3) It's not clear that the cache is important.
Change-Id: I2914ac0b3ba08e39b60149d99a98f9f532b35bbb
Reviewed-on: https://go-review.googlesource.com/40591
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The argument of the first parameter for connection setup functions on
IP networks must contain a protocol name or number. This change adds
validation for arguments of IP networks to connection setup functions.
Fixes#18185.
Change-Id: I6aaedd7806e3ed1043d4b1c834024f350b99361d
Reviewed-on: https://go-review.googlesource.com/40512
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The net package uses various textual representations for network
identifiers and locators on the Internet protocol suite as API.
In fact, the representations are the composition of subset of multple
RFCs: RFC 3986, RFC 4007, RFC 4632, RFC 4291 and RFC 5952.
RFC 4007 describes guidelines for the use of textual representation of
IPv6 addressing/routing scope zone and doesn't prohibit the format for
implementation dependent purposes, as in, specifying a literal IPv6
address and its connected region of routing topology as application
user interface. However, a non-literal IPv6 address, for example, a
host name, with a zone enclosed in square brackets confuses us because
a zone is basically for non-global IPv6 addresses and a pair of square
brackets is used as a set of delimiters between a literal IPv6 address
and a service name or transport port number.
To mitigate such confusion, this change makes JoinHostPort not enclose
non-literal IPv6 addresses in square brackets and SplitHostPort accept
the form "host%zone:port" to recommend that anything enclosed in
square brackets should be a literal IPv6 address.
Before this change:
JoinHostPort("name%zone", "80") = "[name%zone]:80"
JoinHostPort("[::1%zone]", "80") = "[::1%zone]:80"
SplitHostPort("name%zone:80") = "", "", "address name%zone:80: missing brackets in address"
SplitHostPort("[name%zone]:80") = "name%zone", "80", nil
SplitHostPort("[::1%zone]:80") = "::1%zone", "80", nil
After this change:
JoinHostPort("name%zone", "80") = "name%zone:80"
JoinHostPort("[::1%zone]", "80") = "[::1%zone]:80"
SplitHostPort("name%zone:80") = "name%zone", "80", nil
SplitHostPort("[name%zone]:80") = "name%zone", "80", nil // for backwards compatibility
SplitHostPort("[::1%zone]:80") = "::1%zone", "80", nil
Also updates docs and test cases on SplitHostPort and JoinHostPort for
clarification.
Fixes#18059.
Fixes#18060.
Change-Id: I5c3ccce4fa0fbdd58f698fc280635ea4a14d2a37
Reviewed-on: https://go-review.googlesource.com/40510
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On s390x unsigned integer comparisons with immediates require the immediate
to be an unsigned 32-bit integer. The rule was checking that the immediate
was a signed 32-bit integer.
This CL also adds a test for comparisons that could be turned into compare
with immediate or equivalent instructions (depending on architecture and
optimizations applied).
Fixes#19940.
Change-Id: Ifd6aa989fd3d50e282f7d30fec9db462c28422b1
Reviewed-on: https://go-review.googlesource.com/40433
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This extends the sweeper to free workbufs back to the heap between GC
cycles, allowing this memory to be reused for GC'd allocations or
eventually returned to the OS.
This helps for applications that have high peak heap usage relative to
their regular heap usage (for example, a high-memory initialization
phase). Workbuf memory is roughly proportional to heap size and since
we currently never free workbufs, it's proportional to *peak* heap
size. By freeing workbufs, we can release and reuse this memory for
other purposes when the heap shrinks.
This is somewhat complicated because this costs ~1–2 µs per workbuf
span, so for large heaps it's too expensive to just do synchronously
after mark termination between starting the world and dropping the
worldsema. Hence, we do it asynchronously in the sweeper. This adds a
list of "free" workbuf spans that can be returned to the heap. GC
moves all workbuf spans to this list after mark termination and the
background sweeper drains this list back to the heap. If the sweeper
doesn't finish, that's fine, since getempty can directly reuse any
remaining spans to allocate more workbufs.
Performance impact is negligible. On the x/benchmarks, this reduces
GC-bytes-from-system by 6–11%.
Fixes#19325.
Change-Id: Icb92da2196f0c39ee984faf92d52f29fd9ded7a8
Reviewed-on: https://go-review.googlesource.com/38582
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently the runtime allocates workbufs from persistent memory, which
means they can never be freed.
Switch to allocating them from manually-managed heap spans. This
doesn't free them yet, but it puts us in a position to do so.
For #19325.
Change-Id: I94b2512a2f2bbbb456cd9347761b9412e80d2da9
Reviewed-on: https://go-review.googlesource.com/38581
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This introduces a new type, *gcBits, to use for alloc/mark bitmap
allocations instead of *uint8. This type is marked go:notinheap, so
uses of it correctly eliminate write barriers. Since we now have a
type, this also extracts some common operations to methods both for
convenience and to avoid (*uint8) casts at most use sites.
For #19325.
Change-Id: Id51f734fb2e96b8b7715caa348c8dcd4aef0696a
Reviewed-on: https://go-review.googlesource.com/38580
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This clarifies that the gcBits type is actually an arena of gcBits and
will let us introduce a new gcBits type representing a single
mark/alloc bitmap allocated from the arena.
For #19325.
Change-Id: Idedf76d202d9174a17c61bcca9d5539e042e2445
Reviewed-on: https://go-review.googlesource.com/38579
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, manually-managed spans are included in memstats.heap_inuse
and memstats.heap_sys, but when we export these stats to the user, we
subtract out how much has been allocated for stack spans from both.
This works for now because stacks are the only manually-managed spans
we have.
However, we're about to use manually-managed spans for more things
that don't necessarily have obvious stats we can use to adjust the
user-presented numbers. Prepare for this by changing the accounting so
manually-managed spans don't count toward heap_inuse or heap_sys. This
makes these fields align with the fields presented to the user and
means we don't have to track more statistics just so we can adjust
these statistics.
For #19325.
Change-Id: I5cb35527fd65587ff23339276ba2c3969e2ad98f
Reviewed-on: https://go-review.googlesource.com/38577
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
We're going to start using manually-managed spans for GC workbufs, so
rename the allocate/free methods and pass in a pointer to the stats to
use instead of using the stack stats directly.
For #19325.
Change-Id: I37df0147ae5a8e1f3cb37d59c8e57a1fcc6f2980
Reviewed-on: https://go-review.googlesource.com/38576
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
We're about to generalize _MSpanStack to be used for other forms of
in-heap manual memory management in the runtime. This is an automated
rename of _MSpanStack to _MSpanManual plus some comment fix-ups.
For #19325.
Change-Id: I1e20a57bb3b87a0d324382f92a3e294ffc767395
Reviewed-on: https://go-review.googlesource.com/38574
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This avoids needing a mutex to protect stringsym,
and preserves a consistent ctxt.Data ordering
in the face of a concurrent backend.
Updates #15756
Change-Id: I775daae11db5db1269533a00f5249e3a03086ffc
Reviewed-on: https://go-review.googlesource.com/40509
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In my experience, this usually happens when vet panics.
Dumping all unparseable lines should help diagnosis.
Inspired by the trybot failures in CL 40511.
Change-Id: Ib73e8c8b2942832589c3cc5d33ef35fdafe9965a
Reviewed-on: https://go-review.googlesource.com/40508
Reviewed-by: Rob Pike <r@golang.org>
The current interface can't access all environment
variables directly or via cgi.RequestFromMap, which
only reads variables on its "white list" to be set on
the http.Request it returns. If an fcgi variable is
not on the "white list" - e.g. REMOTE_USER - the old
code has no access to its value.
This passes variables in the Request context that aren't
used to add data to the Request itself and adds a method
that parses those env vars from the Request's context.
Fixes#16546
Change-Id: Ibf933a768b677ece1bb93d7bf99a14cef36ec671
Reviewed-on: https://go-review.googlesource.com/40012
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To preserve reproducible builds, the text entries
during compilation will be sorted before being printed.
TestAssembly currently assumes that function init
comes after all user-defined functions.
Remove that assumption.
Instead of looking for "TEXT" to tell you where
a function ends--which may now yield lots of
non-function-code junk--look for a line beginning
with non-whitespace.
Updates #15756
Change-Id: Ibc82dba6143d769ef4c391afc360e523b1a51348
Reviewed-on: https://go-review.googlesource.com/39853
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Instead of constructing ctxt.Text in Flushplist,
which will be called concurrently,
do it in InitTextSym, which must be called serially.
This allows us to avoid a mutex for ctxt.Text,
and preserves the existing ordering of functions
for debug output.
Passes toolstash-check.
Updates #15756
Change-Id: I6322b4da24f9f0db7ba25e5b1b50e8d3be2deb37
Reviewed-on: https://go-review.googlesource.com/40502
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The current implementation uses a max of 28 bits when decoding an
ObjectIdentifier. This change makes it so that an int64 is used to
accumulate up to 35 bits. If the resulting data would not overflow
an int32, it is used as an int. Thus up to 31 bits may be used to
represent each subidentifier of an ObjectIdentifier.
Fixes#19933
Change-Id: I95d74b64b24cdb1339ff13421055bce61c80243c
Reviewed-on: https://go-review.googlesource.com/40436
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
It's flaky and distracting.
I'm not sure what it's testing, either. It hasn't saved us before.
Somebody can resurrect it if they have time.
Updates #15157
Change-Id: I27bbfe51e09b6259bba0f73d60d03a4d38711951
Reviewed-on: https://go-review.googlesource.com/40498
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Prior to this CL, flags such as NOSPLIT
on ATEXT Progs were stored in From3.Offset.
Some but not all of those flags were also
duplicated into From.Sym.Attribute.
This CL migrates all of those flags into
From.Sym.Attribute and stops creating a From3.
A side-effect of this is that printing an
ATEXT Prog can no longer simply dump From3.Offset.
That's kind of good, since the raw flag value
wasn't very informative anyway, but it did
necessitate a bunch of updates to the cmd/asm tests.
The reason I'm doing this work now is that
avoiding storing flags in both From.Sym and From3.Offset
simplifies some other changes to fix the data
race first described in CL 40254.
This CL almost passes toolstash-check -all.
The only changes are in cases where the assembler
has decided that a function's flags may be altered,
e.g. to make a function with no calls in it NOSPLIT.
Prior to this CL, that information was not printed.
Sample before:
"".Ctz64 t=1 size=63 args=0x10 locals=0x0
0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) TEXT "".Ctz64(SB), $0-16
0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)
Sample after:
"".Ctz64 t=1 nosplit size=63 args=0x10 locals=0x0
0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) TEXT "".Ctz64(SB), NOSPLIT, $0-16
0x0000 00000 (/Users/josh/go/tip/src/runtime/internal/sys/intrinsics.go:35) FUNCDATA $0, gclocals·f207267fbf96a0178e8758c6e3e0ce28(SB)
Observe the additional "nosplit" in the first line
and the additional "NOSPLIT" in the second line.
Updates #15756
Change-Id: I5c59bd8f3bdc7c780361f801d94a261f0aef3d13
Reviewed-on: https://go-review.googlesource.com/40495
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
These patterns are the only uses of isArg and isAuto, and they all
follow a common pattern too. Extract out so that we can more easily
tweak the interface for isArg/isAuto.
Passes toolstash -cmp for linux/arm64.
Change-Id: I9c509dabdc123c93cb1ad2f34fe8c12a9f313f6d
Reviewed-on: https://go-review.googlesource.com/40490
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also adjust truncfltlit to make it more similar to trunccmplxlit, and
make it report an error for bad Etypes.
Fixes#19947
Change-Id: I6684523e989c2293b8a8e85bd2bfb9c399c5ea36
Reviewed-on: https://go-review.googlesource.com/40453
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, dist allows GOOS and GOARCH to appear as *any* substring in
a file name when selecting source files to go into go_bootstrap. This
was necessary prior to Go 1.4, where it needed to match names like
"windows.c", but now it's gratuitously different from go/build. This
led to a bug chase to figure out why "stubs_nonlinux.go" was not being
built on non-Linux OSes.
Change shouldbuild to require an "_" before the GOOS and GOARCH in a
file name. This is still less strict than go/build, but the behavior
is much closer.
Change-Id: I580e9344a3c40d57c0721d345e911e8b4f141f5d
Reviewed-on: https://go-review.googlesource.com/40435
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Currently CallersFrames expands each PC to a slice of Frames and then
iteratively returns those Frames. However, this makes it very
difficult to avoid heap allocation: either the Frames slice will be
heap allocated, or, if it uses internal scratch space for small slices
(as it currently does), the Frames object itself has to be heap
allocated.
Fix this, at least in the common case, by expanding each PC
iteratively. We introduce a new pcExpander type that's responsible for
expanding a single PC. This maintains state from one Frame to the next
in the same PC. Frames then becomes a wrapper around this responsible
for feeding it the next PC when the pcExpander runs out of frames for
the current PC.
This makes it possible to stack-allocate a Frames object, which will
make it possible to use this API for PC expansion from within the
runtime itself.
Change-Id: I993463945ab574557cf1d6bedbe79ce7e9cbbdcd
Reviewed-on: https://go-review.googlesource.com/40434
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Lazar <lazard@golang.org>
TestRuntimeTypeDIEs has been added in CL 38350. This
test is failing on Plan 9 because executables don't
have a DWARF symbol table.
Fixes#19944.
Change-Id: I121875bfd5f9f02ed668f8fb0686a0edffa2a99d
Reviewed-on: https://go-review.googlesource.com/40452
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When casting an ideal to complex{64,128}, for example during the
evaluation of
var a = complex64(0) / 1e-50
we want the compiler to report a division-by-zero error if a divisor
would be zero after the cast.
We already do this for floats; for example
var b = float32(0) / 1e-50
generates a 'division by zero' error at compile time (because
float32(1e-50) is zero, and the cast is done before performing the
division).
There's no such check in the path for complex{64,128} expressions, and
no cast is performed before the division in the evaluation of
var a = complex64(0) / 1e-50
which compiles just fine.
This patch changes the convlit1 function so that complex ideals
components (real and imag) are correctly truncated to float{32,64}
when doing an ideal -> complex{64, 128} cast.
Fixes#11674
Change-Id: Ic5f8ee3c8cfe4c3bb0621481792c96511723d151
Reviewed-on: https://go-review.googlesource.com/37891
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Move it to the x86 package, matching our handling
of deferreturn in x86 and arm.
While we're here, improve the concurrency safety
of both Plan9privates and deferreturn
by eagerly initializing them in instinit.
Updates #15756
Change-Id: If3b1995c1e4ec816a5443a18f8d715631967a8b1
Reviewed-on: https://go-review.googlesource.com/40408
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A recent performance improvement for PPC64.rules introduced a
regression for the case where the size of a move is <= 8 bytes
and the value used in the offset field of the instruction is not
aligned correctly for the instruction. In the cases where this happened,
the assembler was not detecting the incorrect offset and still generated
the instruction even though it was invalid.
This fix changes the PPC64.rules for the moves that are now failing
to include the correct alignment checks, along some additional testcases
for gc/ssa for the failing alignments.
I will add a fix to the assembler to detect incorrect offsets in
another CL.
This fixes#19907
Change-Id: I3d327ce0ea6afed884725b1824f9217cef2fe6bf
Reviewed-on: https://go-review.googlesource.com/40290
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Curently the vendor paths are not always searched for imports if
the compiler is gccgo. This change generates the vendor paths
and adds them with -I as arguments to the gccgo compile.
Fixes#15628
Change-Id: I318accbbbd8e6af45475eda399377455a3565880
Reviewed-on: https://go-review.googlesource.com/40432
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Continues outside of a loop are not allowed. Most of these possibilities
were tested in label1.go, but one was missing - a plain continue in a
switch/select but no enclosing loop.
This used to error with a "continue not in loop" in 1.8, but recently
was broken by c03e75e5. In particular, innerloop does not only account
for loops, but also for switches and selects. Swap it by bools that
track whether breaks and continues should be allowed.
While at it, improve the wording of errors for breaks that are not where
they should be. Change "loop" by "loop, switch, or select" since they
can be used in any of those.
And add tests to make sure this isn't broken again. Use a separate func
since I couldn't get the compiler to crash on f() itself, possibly due
to the recursive call on itself.
Fixes#19934.
Change-Id: I8f09c6c2107fd95cac50efc2a8cb03cbc128c35e
Reviewed-on: https://go-review.googlesource.com/40357
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Previously, int values of #define macro are retrieved from DWARF via enums.
Currently, those values are retrieved from symbol tables.
It seems that previous code is unused.
Change-Id: Id76c54baa46d6196738ea35aebd5de99b05b9bf8
Reviewed-on: https://go-review.googlesource.com/40072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The reflect package can be used to create new types at runtime, these
types will have runtime._type entries describing them but no entry in
debug_info (obviously).
A debugger that wanted to print the value of variables with such types
will have to read the runtime._type directly, however the
"specializations" of runtime._type (runtime.slicetype, runtime.maptype,
etc) are not exported to debug_info, besides runtime.interfacetype.
All those types (i.e. runtime.slicetype, runtime.maptype, etc) should
be exported to debug_info so that debuggers don't have to hard-code
their description.
Fixes#19602
Change-Id: I086d523a4421a4ed964e16bc3c2274319a98b45b
Reviewed-on: https://go-review.googlesource.com/38350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Prevent a crash if the same type in two plugins had a recursive
definition, either by referring to a pointer to itself or a map existing
with the type as a value type (which creates a recursive definition
through the overflow bucket type).
Fixes#19258
Change-Id: Iac1cbda4c5b6e8edd5e6859a4d5da3bad539a9c6
Reviewed-on: https://go-review.googlesource.com/40292
Run-TryBot: Todd Neal <todd@tneal.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
open modified the plugin symbols map while ranging over it. This is
normally harmless, except that the operations performed were not
idempotent leading to function pointers being corrupted.
Fixes#19269
Change-Id: I4b6eb1d45567161412e4a34b41f1ebf647bcc942
Reviewed-on: https://go-review.googlesource.com/40431
Run-TryBot: Todd Neal <todd@tneal.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Form a new method pattern where *driverConn and
release functions are passed into the method.
They are named DB.execDC, DB.queryDC, DB.beginDC. This
allows more code to be de-duplicated when starting
queries.
The Stmt creation and management code are untouched.
Change-Id: I24c853531e511d8a4bc1f53dd4dbdf968763b4e7
Reviewed-on: https://go-review.googlesource.com/39630
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
sort.Slice was added in Go 1.8.
It's nice to use, and faster than sort.Sort,
so it'd be nice to be able to use it in the toolchain.
This CL adds obj.SortSlice, which is sort.Slice,
but with a slower fallback version for bootstrapping.
This CL also includes a single demo+test use.
Change-Id: I2accc60b61f8e48c8ab4f1a63473e3b87af9b691
Reviewed-on: https://go-review.googlesource.com/40114
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the newest AES implementation in asm for ppc64le, this part
MOVW $·rcon(SB), PTR
should be
MOVD $·rcon(SB), PTR
since it is loading a doubleword value into PTR.
Change-Id: I7e3d6ad87a2237015aeeb30c68fb409a18f2801c
Reviewed-on: https://go-review.googlesource.com/40298
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
OpenBSD 6.0 and later have support for PT_TLS in ld.so(1). Now that OpenBSD
6.1 has been released, OpenBSD 5.9 is no longer officially supported and Go
can start generating PT_TLS for OpenBSD cgo binaries. This also allows us
to remove the workarounds in the OpenBSD cgo runtime.
This change also removes the environ and progname exports - these are now
provided directly by ld.so(1) itself.
Fixes#19932
Change-Id: I42e75ef9feb5dcd4696add5233497e3cbc48ad52
Reviewed-on: https://go-review.googlesource.com/40331
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Noticed by Cherry while reviewing CL 40252.
The alternative to this is to place t on the stack, like
t := obj.Prog{Ctxt: ctxt}
However, there are only a couple of places where we
manually construct Progs, which is useful.
This isn't hot enough code to warrant
breaking abstraction layers to avoid an allocation.
Passes toolstash-check.
Change-Id: I46c79090b60641c90ee977b750ba5c708aca8ecf
Reviewed-on: https://go-review.googlesource.com/40373
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 39922 made the arm assembler concurrency-safe.
This CL does the same, but for s390x.
The approach is similar: introduce ctxtz to hold
function-local state and thread it through
the assembler as necessary.
One race remains after this CL, similar to CL 40252.
That race is conceptually unrelated to this refactoring,
and will be addressed in a separate CL.
Passes toolstash-check -all.
Updates #15756
Change-Id: Iabf17aa242b70c0b078c2e85dae3d93a5e512372
Reviewed-on: https://go-review.googlesource.com/40371
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
CL 39922 made the arm assembler concurrency-safe.
This CL does the same, but for ppc64.
The approach is similar: introduce ctxt9 to hold
function-local state and thread it through
the assembler as necessary.
One race remains after this CL, similar to CL 40252.
That race is conceptually unrelated to this refactoring,
and will be addressed in a separate CL.
Passes toolstash-check -all.
Updates #15756
Change-Id: Icc37d9a971bed2184c8e66b1a64f4f2e556dc207
Reviewed-on: https://go-review.googlesource.com/40372
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 39922 made the arm assembler concurrency-safe.
This CL does the same, but for arm64.
The approach is similar: introduce ctxt7 to hold
function-local state and thread it through
the assembler as necessary.
One race remains after this CL, deep in aclass,
in the check that a Prog does not take the address
of a TLS variable.
That race is conceptually unrelated to this refactoring,
and will be addressed in a separate CL.
Passes toolstash-check -all.
Updates #15756
Change-Id: Icab1ef70008468f9a5b8bf728a77c4520bbcb67d
Reviewed-on: https://go-review.googlesource.com/40252
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 39922 made the arm assembler concurrency-safe.
This CL does the same, but for mips.
The approach is similar: introduce ctxt0 to hold
function-local state and thread it through
the assembler as necessary.
One race remains after this CL, similar to CL 40252.
That race is conceptually unrelated to this refactoring,
and will be addressed in a separate CL.
Passes toolstash-check -all.
Updates #15756
Change-Id: I2c54a889aa448a4476c9a75da4dd94ef69657b16
Reviewed-on: https://go-review.googlesource.com/40370
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The hardware divider is an optional component of ARMv7. This patch
detects whether it is available in runtime and use it or not.
1. The hardware divider is detected at startup and a flag is set/clear
according to a perticular bit of runtime.hwcap.
2. Each call of runtime.udiv will check this flag and decide if
use the hardware division instruction.
A rough test shows the performance improves 40-50% for ARMv7. And
the compatibility of ARMv5/v6 is not broken.
fixes#19118
Change-Id: Ic586bc9659ebc169553ca2004d2bdb721df823ac
Reviewed-on: https://go-review.googlesource.com/37496
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Current code could return a non-nil os.FileInfo even if there is an error.
This is a bit incompatible with Stat on other OSes.
Change-Id: I37b608da234f957bb89b82509649de78ccc70bbb
Reviewed-on: https://go-review.googlesource.com/40330
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes the core Flushplist loop clearer.
We may also want to move the Sym initialization
much earlier in the compiler (see discussion on
CL 40254), for which this paves the way.
While we're here, eliminate package log in favor of ctxt.Diag.
Passes toolstash-check -all.
Updates #15756
Change-Id: Ieaf848d196764a5aa82578b689af7bc6638c385a
Reviewed-on: https://go-review.googlesource.com/40313
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Changing mheap_.arena_used requires several steps that are currently
repeated multiple times in mheap_.sysAlloc. Consolidate these into a
single function.
In the future, this will also make it easier to add other auxiliary VM
structures.
Change-Id: Ie68837d2612e1f4ba4904acb1b6b832b15431d56
Reviewed-on: https://go-review.googlesource.com/40151
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The existing implementation does not provide a useful error message
if a negative offset is passed in File.ReadAt or File.WriteAt. This
change is to return descriptive errors. An error of type *PathError
is returned to keep it consistent with rest of the code.
There is no need to add an exported error variable since it's used only
in one file.
Fixes#19031
Change-Id: Ib94cab0afae8c5fe4dd97ed2887018a09b9f4538
Reviewed-on: https://go-review.googlesource.com/39136
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Users (like myself) may be tempted to think the higher-numbered curve
is somehow better or more secure, but P256 is currently the best
ECDSA implementation, due to its better support in TLS clients, and a
constant time implementation.
For example, sites that present a certificate signed with P521
currently fail to load in Chrome stable, and the error on the Go side
says simply "remote error: tls: illegal parameter".
Fixes#19901.
Change-Id: Ia5e689e7027ec423624627420e33029c56f0bd82
Reviewed-on: https://go-review.googlesource.com/40211
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I plan to use c as a consistent local variable
in this packages. Rename most variables named c,
excepting only some simple functions in asm9.go.
Changes prepared with gorename.
Passes toolstash-check -all.
Updates #15756
Change-Id: If79baac43fca68fad1076e1ff23ae87c2ba638e4
Reviewed-on: https://go-review.googlesource.com/40172
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Move global state from obj.Link
to a new function-local state struct arm.ctxt5.
This ends up being cleaner than threading
all the state through as parameters; there's a lot of it.
While we're here, move newprog from a parameter to ctxt5.
We reserve the variable name c for ctxt5,
so a few local variables named c have been renamed.
Instead of lazily initializing deferreturn
and Sym_div and friends, initialize them up front.
Passes toolstash-check -all.
Updates #15756
Change-Id: Ifb4e4b9879e4e1f25e6168d8b7b2a25a3390dc11
Reviewed-on: https://go-review.googlesource.com/39922
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This allows the go tool to run "go vet" with both the build flags
that make sense, such as -x and -tags, and vet with all its flags.
To do this, create a new package cmd/go/internal/cmdflag to
hold functionality common to flag handling for test and vet.
Fixes#19350
RELNOTES=yes
Change-Id: Ia1ae213bd3f6cab1c5e492501c8d43ce61a7ee89
Reviewed-on: https://go-review.googlesource.com/40112
Reviewed-by: Russ Cox <rsc@golang.org>
Report an error if a predefined escaper (i.e. "html", "urlquery", or "js")
is found in a pipeline that will be rewritten by the contextual auto-escaper,
instead of trying to merge the escaper-inserted escaping directives
with these predefined escapers. This merging behavior is a source
of several security and correctness bugs (eee #19336, #19345, #19352,
and #19353.)
This merging logic was originally intended to ease migration of text/template
templates with user-defined escapers to html/template. Now that
migration is no longer an issue, this logic can be safely removed.
NOTE: this is a backward-incompatible change that fixes known security
bugs (see linked issues for more details). It will explicitly break users
that attempt to execute templates with pipelines containing predefined
escapers.
Fixes#19336, #19345, #19352, #19353
Change-Id: I46b0ca8a2809d179c13c0d4f42b63126ed1c3b49
Reviewed-on: https://go-review.googlesource.com/37880
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The runtime.writeBarrier variable tries to be helpful by telling you
that the compiler also knows about this variable, which you could
probably guess, but doesn't say how the compiler knows about it. In
fact, the compiler has a complete copy in builtin/runtime.go that
needs to be kept in sync. Say so.
Change-Id: Ia7fb0c591cb6f9b8230decce01008b417dfcec89
Reviewed-on: https://go-review.googlesource.com/40150
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
They are dead code already, but the verifier is still not happy.
Don't assemble them at all.
Looks like it has been like that for long. I don't know why it
was ok. Maybe the verifier is now more picky?
Fixes#19884.
Change-Id: Ib806fb73ca469789dec56f52d484cf8baf7a245c
Reviewed-on: https://go-review.googlesource.com/40111
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reduces the number of cases that need to be tested and
reduces size of the evconst function by 101 bytes.
Change-Id: Ie56055a89d0dadd311fb940b51c488fc003694b9
Reviewed-on: https://go-review.googlesource.com/39950
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
pkgByPath was added in d78c84c4 to eliminate the differences between the
export formats around the time of Go 1.7.
The last remnants of the textual export format was removed by Josh in
39850 making the pkgByPath sorting type unused.
Change-Id: I168816d6401f45119475a4fe5ada00d9ce571a9e
Reviewed-on: https://go-review.googlesource.com/40050
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This is a re-roll of CL 39710,
which broke deterministic builds.
typenamesym is called from three places:
typename, ngotype, and Type.Symbol.
Only in typename do we actually need a Node.
ngotype and Type.Symbol require only a Sym.
And writing the newly created Node to
Sym.Def is unsafe in a concurrent backend.
Rather than use a mutex protect to Sym.Def,
make typenamesym not touch Sym.Def.
The assignment to Sym.Def was serving a second purpose,
namely to prevent duplicate entries on signatlist.
Preserve that functionality by switching signatlist to a map.
This in turn requires that we sort signatlist
when exporting it, to preserve reproducibility.
We sort using exactly the same mechanism
that the export code (dtypesym) uses.
Failure to do that led to non-deterministic builds (#19872).
Since we've already calculated the Type's export name,
we could pass it to dtypesym, sparing it a bit of work.
That can be done as a future optimization.
Updates #15756
name old alloc/op new alloc/op delta
Template 39.2MB ± 0% 39.3MB ± 0% ~ (p=0.075 n=10+10)
Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.393 n=10+10)
GoTypes 113MB ± 0% 113MB ± 0% +0.06% (p=0.027 n=10+8)
SSA 1.25GB ± 0% 1.25GB ± 0% +0.05% (p=0.000 n=8+10)
Flate 25.3MB ± 0% 25.3MB ± 0% ~ (p=0.105 n=10+10)
GoParser 31.7MB ± 0% 31.8MB ± 0% ~ (p=0.165 n=10+10)
Reflect 78.2MB ± 0% 78.2MB ± 0% ~ (p=0.190 n=10+10)
Tar 26.6MB ± 0% 26.6MB ± 0% ~ (p=0.481 n=10+10)
XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.968 n=10+9)
name old allocs/op new allocs/op delta
Template 384k ± 1% 386k ± 1% +0.43% (p=0.019 n=10+10)
Unicode 320k ± 0% 321k ± 0% +0.36% (p=0.015 n=10+10)
GoTypes 1.14M ± 0% 1.14M ± 0% +0.33% (p=0.000 n=10+8)
SSA 9.69M ± 0% 9.71M ± 0% +0.18% (p=0.000 n=10+9)
Flate 233k ± 1% 233k ± 1% ~ (p=0.481 n=10+10)
GoParser 315k ± 1% 316k ± 1% ~ (p=0.113 n=9+10)
Reflect 979k ± 0% 979k ± 0% ~ (p=0.971 n=10+10)
Tar 250k ± 1% 250k ± 1% ~ (p=0.481 n=10+10)
XML 391k ± 1% 392k ± 0% ~ (p=1.000 n=10+9)
Change-Id: Ia9f21cc29c047021fa8a18c2a3d861a5146aefac
Reviewed-on: https://go-review.googlesource.com/39915
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Given code such as
type T struct {
_ string
}
func f() {
var x = T{"space"}
// ...
}
the compiler rewrote the 'var x' line as
var x T
x._ = "space"
The compiler then rejected the assignment to
a blank field, thus rejecting valid code.
It also failed to catch a number of invalid assignments.
And there were insufficient checks for validity
when emitting static data, leading to ICEs.
To fix, check earlier for explicit blanks field names,
explicitly handle legit blanks in sinit,
and don't try to emit static data for nodes
for which typechecking has failed.
Fixes#19482
Change-Id: I594476171d15e6e8ecc6a1749e3859157fe2c929
Reviewed-on: https://go-review.googlesource.com/38006
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This dowidth currently happens during AST to SSA conversion.
As such, it is a concurrency pinch point.
It's a bit silly, but do it here in walk instead.
This appears (fingers crossed) to be the last
unresolved dowidth concurrency problem.
Updates #15756
Change-Id: I87cbf718a14ad21aca74586003d79320cca75953
Reviewed-on: https://go-review.googlesource.com/39994
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
queuemethod was unused. As queuemethod is unused, nothing appends to the
methodqueue global. As methodqueue is always nil or empty, there are no
live callers of domethod, so it can be removed.
Change-Id: Ic7427ac4621bbf403947815e3988c3a1113487f2
Reviewed-on: https://go-review.googlesource.com/39931
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I had too many failed attempts trying to remove iterFields that I
decided to overhaul this function. Much simpler and easier to
understand now (at least IMO).
Passes toolstash-check -all.
Change-Id: I41d00642a969698df3f4689e41a386346b966638
Reviewed-on: https://go-review.googlesource.com/39856
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Current code doesn't support floating point #define macros.
This CL compiles floats to a object file and retrive values from it.
That approach is the same work as we've already done for integers.
Updates #18720
Change-Id: I88b7ab174d0f73bda975cf90c5aeb797961fe034
Reviewed-on: https://go-review.googlesource.com/35511
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There are some LSyms that are lazily initialized,
and which cannot be made eagerly initialized,
such as elements of a constant pool.
To avoid needing a mutex to protect the internals of
those LSyms, this CL introduces LookupInit,
which allows an LSym to be initialized only once.
By itself this is not fully concurrency-safe,
but Ctxt.Hash will need mutex protection anyway,
and that will be enough to support one-time LSym initialization.
Passes toolstash-check -all.
Updates #15756
Change-Id: Id7248dfdc4dfbdfe425fa31d0c0045018eeea1fa
Reviewed-on: https://go-review.googlesource.com/39990
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This reverts commit c8b889cc48.
Reason for revert: broke noopt build, compiler performance regression, new Curfn uses
Let's fix those and then try this again.
Change-Id: Icc3cad1365d04cac8fd09da9dbb0bbf55c13ef44
Reviewed-on: https://go-review.googlesource.com/39991
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change compiler and linker to emit DWARF lexical blocks in debug_info.
Version of debug_info is updated from DWARF v.2 to DWARF v.3 since version 2
does not allow lexical blocks with discontinuous ranges.
Second attempt at https://go-review.googlesource.com/#/c/29591/
Remaining open problems:
- scope information is removed from inlined functions
- variables in debug_info do not have DW_AT_start_scope attributes so a
variable will shadow other variables with the same name as soon as its
containing scope begins, before its declaration.
Updates golang/go#12899, golang/go#6913
Change-Id: I0e260a45b564d14a87b88974eb16c5387cb410a5
Reviewed-on: https://go-review.googlesource.com/36879
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 38662 changed the x86 assembler to be eagerly
initialized, for a concurrent backend.
This CL puts in place a proper mechanism for doing so,
and switches all architectures to use it.
Passes toolstash-check -all.
Updates #15756
Change-Id: Id2aa527d3a8259c95797d63a2f0d1123e3ca2a1c
Reviewed-on: https://go-review.googlesource.com/39917
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently we expand comparison with small constant strings into len check
and a sequence of byte comparisons. Generate 16/32/64-bit comparisons,
instead of bytewise on 386 and amd64. Also increase limits on what is
considered small constant string.
Shaves ~30kb (0.5%) from go executable.
This also updates test/prove.go to keep test case valid.
Change-Id: I99ae8871a1d00c96363c6d03d0b890782fa7e1d9
Reviewed-on: https://go-review.googlesource.com/38776
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
- created new package cmd/compile/internal/types
- moved Pkg, Sym, Type to new package
- to break cycles, for now we need the (ugly) types/utils.go
file which contains a handful of functions that must be installed
early by the gc frontend
- to break cycles, for now we need two functions to convert between
*gc.Node and *types.Node (the latter is a dummy type)
- adjusted the gc's code to use the new package and the conversion
functions as needed
- made several Pkg, Sym, and Type methods functions as needed
- renamed constructors typ, typPtr, typArray, etc. to types.New,
types.NewPtr, types.NewArray, etc.
Passes toolstash-check -all.
Change-Id: I8adfa5e85c731645d0a7fd2030375ed6ebf54b72
Reviewed-on: https://go-review.googlesource.com/39855
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Followup to previous typenod CL. Changes export data format, but only
the compiler-specific section, so no version bump.
Change-Id: I0c21737141f3d257366b29b2a9211bc7217c39ee
Reviewed-on: https://go-review.googlesource.com/39797
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
typenamesym is called from three places:
typename, ngotype, and Type.Symbol.
Only in typename do we actually need a Node.
ngotype and Type.Symbol require only a Sym.
And writing the newly created Node to
Sym.Def is unsafe in a concurrent backend.
Rather than use a mutex protect to Sym.Def,
make typenamesym not touch Sym.Def.
The assignment to Sym.Def was serving a second purpose,
namely to prevent duplicate entries on signatlist.
Preserve that functionality by switching signatlist to a map.
This in turn requires that we sort signatlist
when exporting it, to preserve reproducibility.
We'd like to use Type.cmp for sorting,
but that causes infinite recursion at the moment;
see #19869.
For now, use Type.LongString as the sort key,
which is a complete description of the type.
Type.LongString is relatively expensive,
but we calculate it only once per type,
and signatlist is generally fairly small,
so the performance impact is minimal.
Updates #15756
name old alloc/op new alloc/op delta
Template 39.4MB ± 0% 39.4MB ± 0% ~ (p=0.222 n=5+5)
Unicode 29.8MB ± 0% 29.8MB ± 0% ~ (p=0.151 n=5+5)
GoTypes 113MB ± 0% 113MB ± 0% ~ (p=0.095 n=5+5)
SSA 1.25GB ± 0% 1.25GB ± 0% +0.04% (p=0.008 n=5+5)
Flate 25.3MB ± 0% 25.4MB ± 0% ~ (p=0.056 n=5+5)
GoParser 31.8MB ± 0% 31.8MB ± 0% ~ (p=0.310 n=5+5)
Reflect 78.3MB ± 0% 78.3MB ± 0% ~ (p=0.690 n=5+5)
Tar 26.7MB ± 0% 26.7MB ± 0% ~ (p=0.548 n=5+5)
XML 42.2MB ± 0% 42.2MB ± 0% ~ (p=0.222 n=5+5)
name old allocs/op new allocs/op delta
Template 387k ± 0% 388k ± 0% ~ (p=0.056 n=5+5)
Unicode 320k ± 0% 321k ± 0% +0.32% (p=0.032 n=5+5)
GoTypes 1.14M ± 0% 1.15M ± 0% ~ (p=0.095 n=5+5)
SSA 9.70M ± 0% 9.72M ± 0% +0.18% (p=0.008 n=5+5)
Flate 234k ± 0% 235k ± 0% +0.60% (p=0.008 n=5+5)
GoParser 317k ± 0% 317k ± 0% ~ (p=1.000 n=5+5)
Reflect 982k ± 0% 983k ± 0% ~ (p=0.841 n=5+5)
Tar 252k ± 1% 252k ± 0% ~ (p=0.310 n=5+5)
XML 393k ± 0% 392k ± 0% ~ (p=0.548 n=5+5)
Change-Id: I53a3b95d19cf1a7b7511a94fba896706addf84fb
Reviewed-on: https://go-review.googlesource.com/39710
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a straightforward refactoring,
to reduce the scope of upcoming changes.
The symbol size and AttrLocal=true was not
set universally, but it appears not to matter,
since toolstash -cmp is happy.
Passes toolstash-check -all.
Change-Id: I7f8392f939592d3a1bc6f61dec992f5661f42fca
Reviewed-on: https://go-review.googlesource.com/39791
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was simply a wrapper around Link.Lookup.
Unwrap everything.
CL prepared using eg with template:
package p
import "cmd/internal/obj"
func before(ctxt *obj.Link, name string, version int) *obj.LSym {
return obj.Linklookup(ctxt, name, version)
}
func after(ctxt *obj.Link, name string, version int) *obj.LSym {
return ctxt.Lookup(name, version)
}
Then one comment in cmd/asm/internal/asm/parse.go
was manually updated (and gofmt'ed!),
and func Linklookup deleted.
Passes toolstash-check (as a sanity measure).
Change-Id: Icc4d56b0b2b5c8888d3184c1898c48359ea1e638
Reviewed-on: https://go-review.googlesource.com/39715
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In particular, this lead to the code accepting invalid ETags as long as
they finished with a '"'.
Also remove a duplicate test case.
Change-Id: Id59db3ebc4e4969562f891faef29111e77ee0e65
Reviewed-on: https://go-review.googlesource.com/39690
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When a constant is both MOVCON (can fit into a MOV instruction)
and BITCON (can fit into a logical instruction), the assembler
chooses to use the MOVCON encoding, which is actually longer for
logical instructions. We add MBCON rules explicitly to make sure
it uses the BITCON encoding.
Updates #19857.
Change-Id: Ib9881be363cbc491ac2a0792b36b87e74eff34a8
Reviewed-on: https://go-review.googlesource.com/39652
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
For an AND that masks out leading or trailing bits, generic rules
rewrite it to a pair of shifts. On ARM64, the mask actually can
fit into an AND instruction. So we rewrite it back to AND.
Fixes#19857.
Change-Id: I479d7320ae4f29bb3f0056d5979bde4478063a8f
Reviewed-on: https://go-review.googlesource.com/39651
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Plugin support is patchy at the moment, so disable the test for
now until the test can be fixed. This way, we can get builders
for ARMv5 running for the rest of the code.
Updates #19674
Change-Id: I08aa211c08a85688656afe2ad2e680a2a6e5dfac
Reviewed-on: https://go-review.googlesource.com/39716
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This code was added recently, and it doesn't seem like the parameter
will be useful in the near future.
Change-Id: I5d64dadb6820c159b588262ab90df2461b5fdf04
Reviewed-on: https://go-review.googlesource.com/39692
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Stack spans don't internally use many of the fields of the mspan,
which means things like the size class and element size get left over
from whatever last used the mspan. This can lead to confusing crashes
and debugging.
Zero these fields or initialize them to something reasonable. This
also lets us simplify some code that currently has to distinguish
between heap and stack spans.
Change-Id: I9bd114e76c147bb32de497045b932f8bf1988bbf
Reviewed-on: https://go-review.googlesource.com/38573
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
This was fixed in CL 37598 but the test was (rightly) dropped
because it modified $GOROOT. Here's a variant that does not.
For #19151.
Change-Id: Iccdbbf9ae8ac4c252e52f4f8ff996963573c4682
Reviewed-on: https://go-review.googlesource.com/39592
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit 44ed88a5a7 moved printing of the "sweep done" gcpacertrace
message so that it is printed when the final sweeper finishes.
However, by this point some other thread has often already observed
that there are no more spans to sweep and zeroed sweepPagesPerByte.
Avoid printing a 0 sweep ratio in the trace when this race happens by
getting the value of the sweep ratio upon entry to sweepone and
printing that.
Change-Id: Iac0c48ae899e12f193267cdfb012c921f8b71c85
Reviewed-on: https://go-review.googlesource.com/39492
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The comments in this package state that users should be
migrating code that uses the syscall package to its
corresponding package in x/sys. However, the syscall.Signal
and syscall.Errno types and the syscall.SysProcAttr struct is
not defined in the x/sys package and still need to be referenced
from within syscall. This adds a change to the comments to
clarify that the migration will need to continue to use some
references to syscall for now.
Fixes#19560
Change-Id: I8abb96b93bea90070ce461da16dc7bcf7b4b29c1
Reviewed-on: https://go-review.googlesource.com/39450
Reviewed-by: Rob Pike <r@golang.org>
This is a holdover from the days when we did not
have full SSA coverage and compiled things optimistically,
and catching the panic obscures useful information.
Change-Id: I196790cb6b97419d92b318a2dfa7f1e1097cefb7
Reviewed-on: https://go-review.googlesource.com/39534
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Providing size hint when creating a map allows avoiding re-allocating
underlying data structure if we know how many elements are going to
be inserted. This can be used for example during decoding maps in
gob.
Fixes#19599
Change-Id: I108035fec29391215d2261a73eaed1310b46bab1
Reviewed-on: https://go-review.googlesource.com/38335
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This was a subtle bug introduced in the previous release's fix for
issue 16156.
The definition of empty template was broken, causing the answer
to depend on the order of templates in the map.
Fixes#16156 (for real).
Fixes#19294.
Fixes#19204.
Change-Id: I1cd915c94534cad3116d83bd158cbc28700510b9
Reviewed-on: https://go-review.googlesource.com/38420
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Popcount instructions on amd64 are not guaranteed to be
present, so we must guard their call. Rewrite rules can't
generate control flow at the moment, so the intrinsifier
needs to generate that code.
name old time/op new time/op delta
OnesCount-8 2.47ns ± 5% 1.04ns ± 2% -57.70% (p=0.000 n=10+10)
OnesCount16-8 1.05ns ± 1% 0.78ns ± 0% -25.56% (p=0.000 n=9+8)
OnesCount32-8 1.63ns ± 5% 1.04ns ± 2% -35.96% (p=0.000 n=10+10)
OnesCount64-8 2.45ns ± 0% 1.04ns ± 1% -57.55% (p=0.000 n=6+10)
Update #18616
Change-Id: I4aff2cc9aa93787898d7b22055fe272a7cf95673
Reviewed-on: https://go-review.googlesource.com/38320
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Note that this is a redo of an undo of the original buggy CL 38666.
We have lots of rewrite rules that vary only in the fact that
we have 2 versions for the 2 different orderings of various
commuting ops. For example:
(ADDL x (MOVLconst [c])) -> (ADDLconst [c] x)
(ADDL (MOVLconst [c]) x) -> (ADDLconst [c] x)
It can get unwieldly quickly, especially when there is more than
one commuting op in a rule.
Our existing "fix" for this problem is to have rules that
canonicalize the operations first. For example:
(Eq64 x (Const64 <t> [c])) && x.Op != OpConst64 -> (Eq64 (Const64 <t> [c]) x)
Subsequent rules can then assume if there is a constant arg to Eq64,
it will be the first one. This fix kinda works, but it is fragile and
only works when we remember to include the required extra rules.
The fundamental problem is that the rule matcher doesn't
know anything about commuting ops. This CL fixes that fact.
We already have information about which ops commute. (The register
allocator takes advantage of commutivity.) The rule generator now
automatically generates multiple rules for a single source rule when
there are commutative ops in the rule. We can now drop all of our
almost-duplicate source-level rules and the canonicalization rules.
I have some CLs in progress that will be a lot less verbose when
the rule generator handles commutivity for me.
I had to reorganize the load-combining rules a bit. The 8-way OR rules
generated 128 different reorderings, which was causing the generator
to put too much code in the rewrite*.go files (the big ones were going
from 25K lines to 132K lines). Instead I reorganized the rules to
combine pairs of loads at a time. The generated rule files are now
actually a bit (5%) smaller.
Make.bash times are ~unchanged.
Compiler benchmarks are not observably different. Probably because
we don't spend much compiler time in rule matching anyway.
I've also done a pass over all of our ops adding commutative markings
for ops which hadn't had them previously.
Fixes#18292
Change-Id: Ic1c0e43fbf579539f459971625f69690c9ab8805
Reviewed-on: https://go-review.googlesource.com/38801
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Instead of walking the list of nodes twice,
once to find static entries to add to an array
and once to find dynamic entries to generate code for,
do the split once up front, into two slices.
Then process each slice individually.
This makes the code easier to read
and more importantly, easier to modify.
While we're here, add a TODO to avoid
using temporaries for mapassign_fast calls.
It's not an important TODO;
the generated code would be basically identical.
It would just avoid a minor amount of
pointless SSA optimization work.
Passes toolstash-check.
No measureable compiler performance impact.
Updates #19751
Change-Id: I84a8f2c22f9025c718ef34639059d7bd02a3c406
Reviewed-on: https://go-review.googlesource.com/39351
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This triggers 119 times during make.bash.
This CL reduces the time it takes for the
compiler to panic while compiling the code in #19751
from 22 minutes to 15 minutes. Yay, I guess.
Updates #19751
Change-Id: I8ca7f1ae75f89d1eb2a361d67b3055a975221734
Reviewed-on: https://go-review.googlesource.com/39294
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Old buggy hardware incorrectly executes the shift-left-K
then shift-right-K idiom for clearing K leftmost bits.
Use a right rotate instead of shift to avoid triggering the
bug.
Fixes#19809.
Change-Id: I6dc646b183c29e9d01aef944729f34388dcc687d
Reviewed-on: https://go-review.googlesource.com/39310
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
In a concurrent backend, Ctxt.Lookup will need some
form of concurrency protection, which will make it
more expensive.
This CL changes the pcln table builder to track
filenames as strings rather than LSyms.
Those strings are then converted into LSyms
at the last moment, for writing the object file.
This CL removes over 85% of the calls to Ctxt.Lookup
in a run of make.bash.
Passes toolstash-check.
Updates #15756
Change-Id: I3c53deff6f16f2643169f3bdfcc7aca2ca58b0a4
Reviewed-on: https://go-review.googlesource.com/39291
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When generating a random int8, uint8, int16, uint16, int32, uint32,
quick.Value chooses among all possible values.
But when generating a random int64 or uint64, it only chooses
values in the range [-2⁶², 2⁶²) (even for uint64).
It should, like for all the other integers, use the full range.
If it had, this would have caught #19807 earlier.
Instead it let us discover the presence of #19809.
While we are here, also make the default source of
randomness not completely deterministic.
Fixes#19808.
Change-Id: I070f852531c92b3670bd76523326c9132bfc9416
Reviewed-on: https://go-review.googlesource.com/39152
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The header is literally
Key: Value
If the value or the key has leading or trailing spaces, those will
be lost by the round trip.
Found because testing/quick returns different values now.
Change-Id: I0f574bdbb5990689509c24309854d8f814b5efa0
Reviewed-on: https://go-review.googlesource.com/39211
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
nodfp is a global, so modifying it is unsafe in a concurrent backend.
It is also not necessary, since the Used marks
are only relevant for nodes in fn.Dcl.
For good measure, mark nodfp as always used.
Passes toolstash-check.
Updates #15756
Change-Id: I5320459f5eced2898615a17b395a10c1064bcaf5
Reviewed-on: https://go-review.googlesource.com/39200
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Dupok symbols may be defined in multiple packages. Its associated
package is chosen sort of arbitrarily (the first containing package
that the linker loads). Canonicalize its package to the package
with which it will be laid down in text, which is the first package
in dependency order that defines the symbol. So later passes (for
example, trampoline insertion pass) know that the dupok symbol
is laid down along with the package.
Fixes#19764.
Change-Id: I7cbc7474ff3016d5069c8b7be04af934abab8bc3
Reviewed-on: https://go-review.googlesource.com/39150
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: David Chase <drchase@google.com>
Each architecture's Rconv function is only used inside its
respective package, so it does not need to be exported.
Change-Id: Ifbd629964d7a9edd66501d7cdf4750621d66d646
Reviewed-on: https://go-review.googlesource.com/39110
Run-TryBot: Dave Cheney <dave@cheney.net>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A few gc.Node ops may be shared across functions.
The compiler is (mostly) already careful to avoid mutating them.
However, from a concurrency perspective, replacing (say)
an empty list with an empty list still counts as a mutation.
One place this occurs is orderinit. Avoid it.
This requires fixing one spot where shared nodes were mutated.
It doesn't result in any functional or performance changes.
Passes toolstash-check.
Updates #15756
Change-Id: I63c93b31baeeac62d7574804acb6b7f2bc9d14a9
Reviewed-on: https://go-review.googlesource.com/39196
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Round uses r+r < d to decide whether the remainder is
above or below half of d (to decide whether to round up or down).
This is wrong when r+r wraps negative, because it looks < d
but is really > d.
No one will ever care about rounding to a multiple of
d > 2⁶² (about 146 years), but might as well get it right.
Fixes#19807.
Change-Id: I1b55a742dc36e02a7465bc778bf5dd74fe71f7c0
Reviewed-on: https://go-review.googlesource.com/39151
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
newnamel is newname but with no dependency on lineno or Curfn.
This makes it suitable for use in a concurrent back end.
Use it now to make tempAt global-free.
The decision to push the assignment to n.Name.Curfn
to the caller of newnamel is based on mdempsky's
comments in #19683 that he'd like to do that
for callers of newname as well.
Passes toolstash-check. No compiler performance impact.
Updates #19683
Updates #15756
Change-Id: Idc461a1716916d268c9ff323129830d9a6e4a4d9
Reviewed-on: https://go-review.googlesource.com/39191
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Convert yyerrors into Fatals.
Remove the goto.
Move variable declaration closer to use.
Unify printing strings a bit.
Convert an int param into a bool.
Passes toolstash-check. No compiler performance impact.
Change-Id: I9017681417b785cf8693d18b124ac4f1ff37f2b5
Reviewed-on: https://go-review.googlesource.com/39170
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The names never occur more than once,
so interning the results is counterproductive.
The impact is not very big, but neither is the fix.
name old time/op new time/op delta
Unicode 90.2ms ± 3% 88.3ms ± 5% -2.10% (p=0.000 n=94+98)
Change-Id: I1e3a24433db4ae0c9a6e98166568941824ff0779
Reviewed-on: https://go-review.googlesource.com/39193
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this CL, the SSA backend reported violations
of the //go:nowritebarrier annotation immediately.
This necessitated emitting errors during SSA compilation,
which is not compatible with a concurrent backend.
Instead, check for such violations later.
We already save the data required to do a late check
for violations of the //go:nowritebarrierrec annotation.
Use the same data, and check //go:nowritebarrier at the same time.
One downside to doing this is that now only a single
violation will be reported per function.
Given that this is for the runtime only,
and violations are rare, this seems an acceptable cost.
While we are here, remove several 'nerrors != 0' checks
that are rendered pointless.
Updates #15756Fixes#19250 (as much as it ever can be)
Change-Id: Ia44c4ad5b6fd6f804d9f88d9571cec8d23665cb3
Reviewed-on: https://go-review.googlesource.com/38973
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We don't support stack frames over 2GB.
Rather than detect this during backend compilation,
check for it at the end of compilation.
This is arguably a more accurate check anyway,
since it takes into account the full frame,
including local stack, arguments, and arch-specific
rounding, although it's unlikely anyone would ever notice.
Also, rather than reporting the error right away,
take note of it and report it later, at the top level.
This is not relevant now, but it will help with making
the backend concurrent, as the append to the list of
oversized functions can be cheaply protected by a plain mutex.
Updates #15756
Updates #19250
Change-Id: Id3fa21906616d62e9dc66e27a17fd5f83304e96e
Reviewed-on: https://go-review.googlesource.com/38972
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
By checking GOARM in ssa/gen/ARM.rules, each intermediate operator
can be implemented via different instruction serials.
It is up to the user to choose between compitability and efficiency.
The Bswap32(x) is optimized to REV(x) when GOARM >= 6.
The CTZ(x) is optimized to CLZ(RBIT x) when GOARM == 7.
Change-Id: Ie9ee645fa39333fa79ad84ed4d1cefac30422814
Reviewed-on: https://go-review.googlesource.com/35610
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
User defined numeric types such as "type Int int64" have
been able to be scanned into without a custom scanner by
using the reflect scan code path used to convert between
various numeric types. Add in a path for string types
for symmetry and least surprise.
Fixes#18101
Change-Id: I00553bcf021ffe6d95047eca0067ee94b54ff501
Reviewed-on: https://go-review.googlesource.com/39031
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Rather than using arm64.Rconv directly in the archArm64 constructor
use the generic obj.Rconv helper. This removes the only use of
arm64.Rconv outside the arm64 package itself.
Change-Id: I99e9e7156b52cd26dc134f610f764ec794264e2c
Reviewed-on: https://go-review.googlesource.com/38756
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TestUnshareMountNameSpace fails on arm64 due to permission problems.
Skip that test for now when permission problems are encountered, so we
don't regress elsewhere in the meantime.
Updates #19698
Change-Id: I9058928afa474b813652c9489f343b8957160a6c
Reviewed-on: https://go-review.googlesource.com/39052
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Currently runtime.GC() triggers a STW GC. For common uses in tests and
benchmarks, it doesn't matter whether it's STW or concurrent, but for
uses in servers for things like collecting heap profiles and
controlling memory footprint, this pause can be a bit problem for
latency.
This changes runtime.GC() to trigger a concurrent GC. In order to
remain as close as possible to its current meaning, we define it to
always perform a full mark/sweep GC cycle before returning (even if
that means it has to finish up a cycle we're in the middle of first)
and to publish the heap profile as of the triggered mark termination.
While it must perform a full cycle, simultaneous runtime.GC() calls
can be consolidated into a single full cycle.
Fixes#18216.
Change-Id: I9088cc5deef4ab6bcf0245ed1982a852a01c44b5
Reviewed-on: https://go-review.googlesource.com/37520
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
sweepone returns ^uintptr(0) when there are no more spans to *start*
sweeping, but there may be spans being swept concurrently at the time
and there's currently no efficient way to tell when the sweeper is
done sweeping all the spans.
We'll need this for concurrent runtime.GC(), so add a count of the
number of active sweepone calls to make it possible to block until
sweeping is truly done.
This is also useful for more accurately printing the gcpacertrace,
since that should be printed after all of the sweeping stats are in
(currently we can print it slightly too early).
For #18216.
Change-Id: I06e6240c9e7b40aca6fd7b788bb6962107c10a0f
Reviewed-on: https://go-review.googlesource.com/37716
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Forced GCs don't provide good information about how to adjust the GC
trigger. Currently we avoid adjusting the trigger on forced GC because
forced GC is also STW and we don't adjust the trigger on STW GC.
However, this will become a problem when forced GC is concurrent.
Fix this by skipping trigger adjustment if the GC was user-forced.
For #18216.
Change-Id: I03dfdad12ecd3cfeca4573140a0768abb29aac5e
Reviewed-on: https://go-review.googlesource.com/38951
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently gcMode != gcBackgroundMode implies this was a user-forced GC
cycle. This is no longer going to be true when we make runtime.GC()
trigger a concurrent GC, so replace this with an explicit
work.userForced bit.
For #18216.
Change-Id: If7d71bbca78b5f0b35641b070f9d457f5c9a52bd
Reviewed-on: https://go-review.googlesource.com/37519
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently freeOSMemory calls gcStart directly, but we really just want
it to behave like runtime.GC() and then perform a scavenge, so make it
call runtime.GC() rather than gcStart.
For #18216.
Change-Id: I548ec007afc788e87d383532a443a10d92105937
Reviewed-on: https://go-review.googlesource.com/37518
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Now that the gcMode is no longer involved in the GC trigger condition,
we can simplify the triggering of forced GCs. By making the trigger
condition for forced GCs true even if gcphase is not _GCoff, we don't
need any special case path in gcStart to ensure that forced GCs don't
get consolidated.
Change-Id: I6067a13d76e40ff2eef8fade6fc14adb0cb58ee5
Reviewed-on: https://go-review.googlesource.com/37517
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently the GC triggering condition is an awkward combination of the
gcMode (whether or not it's gcBackgroundMode) and a boolean
"forceTrigger" flag.
Replace this with a new gcTrigger type that represents the range of
transition predicates we need. This has several advantages:
1. We can remove the awkward logic that affects the trigger behavior
based on the gcMode. Now gcMode purely controls whether to run a
STW GC or not and the gcTrigger controls whether this is a forced
GC that cannot be consolidated with other GC cycles.
2. We can lift the time-based triggering logic in sysmon to just
another type of GC trigger and move the logic to the trigger test.
3. This sets us up to have a cycle count-based trigger, which we'll
use to make runtime.GC trigger concurrent GC with the desired
consolidation properties.
For #18216.
Change-Id: If9cd49349579a548800f5022ae47b8128004bbfc
Reviewed-on: https://go-review.googlesource.com/37516
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently sysmon triggers periodic GC if GC is not currently running
and it's been long enough since the last GC. This misses some
important conditions; for example, whether GC is enabled at all by
GOGC. As a result, if GOGC is off, once we pass the timeout for
periodic GC, sysmon will attempt to trigger a GC every 10ms. This GC
will be a no-op because gcStart will check all of the appropriate
conditions and do nothing, but it still goes through the motions of
waking the forcegc goroutine and printing a gctrace line.
Fix this by making sysmon call gcShouldStart to check *all* of the
appropriate transition conditions before attempting to trigger a
periodic GC.
Fixes#19247.
Change-Id: Icee5521ce175e8419f934723849853d53773af31
Reviewed-on: https://go-review.googlesource.com/37515
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently the heap profile is flushed by *either* gcSweep in STW mode
or by gcMarkTermination in concurrent mode. Simplify this by making
gcMarkTermination always flush the heap profile and by making gcSweep
do one extra flush (instead of two) in STW mode.
Change-Id: I62147afb2a128e1f3d92ef4bb8144c8a345f53c4
Reviewed-on: https://go-review.googlesource.com/37715
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently we snapshot the heap profile just *after* mark termination
starts the world because it's a relatively expensive operation.
However, this means any alloc or free events that happen between
starting the world and snapshotting the heap profile can be accounted
to the wrong cycle. In the worst case, a free can be accounted to the
cycle before the alloc; if the heap is small, this can result
temporarily in a negative "in use" count in the profile.
Fix this without making STW more expensive by using a global heap
profile cycle counter. This lets us split up the operation into a two
parts: 1) a super-cheap snapshot operation that simply increments the
global cycle counter during STW, and 2) a more expensive cleanup
operation we can do after starting the world that frees up a slot in
all buckets for use by the next heap profile cycle.
Fixes#19311.
Change-Id: I6bdafabf111c48b3d26fe2d91267f7bef0bd4270
Reviewed-on: https://go-review.googlesource.com/37714
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently memRecord has the same set of four fields repeated three
times. Pull these into a type and use this type three times. This
cleans up and simplifies the code a bit and will make it easier to
switch to a globally tracked heap profile cycle for #19311.
Change-Id: I414d15673feaa406a8366b48784437c642997cf2
Reviewed-on: https://go-review.googlesource.com/37713
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The symExport flag tells whether a symbol is in the export list
already or not (and it's also used to avoid being added to that
list). Exporting is based on that export list - no need to check
again.
Change-Id: I6056f97aa5c24a19376957da29199135c8da35f9
Reviewed-on: https://go-review.googlesource.com/39033
Reviewed-by: Dave Cheney <dave@cheney.net>
Every time I modify heap profiling, I find myself redrawing this
diagram, so add it to the comments. This shows how allocations and
frees are accounted, how we arrive at consistent profile snapshots,
and when those snapshots are published to the user.
Change-Id: I106aba1200af3c773b46e24e5f50205e808e2c69
Reviewed-on: https://go-review.googlesource.com/37514
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Now that we have a nice predicate system, improve the tests performed
by TestMemStats. We add some more non-zero checks (now that we force a
GC, things like NumGC must be non-zero), checks for trivial boolean
fields, and a few more range checks.
Change-Id: I6da46d33fa0ce5738407ee57d587825479413171
Reviewed-on: https://go-review.googlesource.com/37513
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently most TestMemStats failures dump the whole MemStats object if
anything is amiss without telling you what is amiss, or even which
field is wrong. This makes it hard to figure out what the actual
problem is.
Replace this with a reflection walk over MemStats and a map of
predicates to check. If one fails, we can construct a detailed and
descriptive error message. The predicates are a direct translation of
the current tests.
Change-Id: I5a7cafb8e6a1eeab653d2e18bb74e2245eaa5444
Reviewed-on: https://go-review.googlesource.com/37512
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
cmd/link -H flag is stored in variable of type
cmd/internal/obj.HeadType. The HeadType type from cmd/internal/obj
accepts Hwindows and Hwindowsgui values, but these values have
same meaning - build PE executable, except for 2 places in
cmd/link/internal/ld package.
This CL introduces code to store cmd/link "windowsgui" -H flag
in cmd/link/internal/ld, so cmd/internal/obj.Hwindowsgui can be
removed in the next CL.
This CL also includes 2 changes to code where distinction
between Hwindows and Hwindowsgui is important.
Change-Id: Ie5ee1f374e50c834652a037f2770118d56c21a2a
Reviewed-on: https://go-review.googlesource.com/38760
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
During the review of CL 38801 it was noted that it would be nice
to have a bit more clarity on how-and-why SB addressing is handled
strangely on s390x. This additional comment should hopefully help.
In general SB is handled differently because not all instructions
have variants that use relative addressing.
Change-Id: I3379012ae3f167478c191c435939c3b876c645ed
Reviewed-on: https://go-review.googlesource.com/38952
Reviewed-by: Keith Randall <khr@golang.org>
TestDWARF has been added in CL 38855. This test is
failing on Plan 9 because executables don't have
a DWARF symbol table.
Fixes#19793.
Change-Id: I7fc547a7c877b58cc4ff6b4eb5b14852e8b4668b
Reviewed-on: https://go-review.googlesource.com/38931
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Even very large Types are not very big.
The haspointer cache looks like premature optimization.
Removing them has no detectable compiler performance impact,
and it removes mutable shared state used by the backend.
Updates #15756
Change-Id: I2d2cf03f470f5eef5bcd50ff693ef6a01d481700
Reviewed-on: https://go-review.googlesource.com/38912
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Flush file content to disk before diffing files,
may cause unpredictable results on Windows.
Convert from \r\n to \n when comparing diff result.
Change-Id: Ibcd6154a2382dba1338ee5674333611aea16bb65
Reviewed-on: https://go-review.googlesource.com/36750
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
REV/REV16/REVSH were introduced in ARMv6, they offered more efficient
byte reverse operatons.
MMUL/MMULA/MMULS were introduced in ARMv6, they simplified
a serial of mul->shift->add/sub operations into a single instruction.
RBIT was introduced in ARMv7, it inversed a 32-bit word's bit order.
MULS was introduced in ARMv7, it corresponded to MULA.
MULBB/MULABB were introduced in ARMv5TE, they performed 16-bit
multiplication (and accumulation).
Change-Id: I6365b17b3c4eaf382a657c210bb0094b423b11b8
Reviewed-on: https://go-review.googlesource.com/35565
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 38147 eliminated package gc globals in formatting routines.
However, tconv still used the Type field Trecur
to avoid infinite recursion when formatting recursive
interfaces types such as (test/fixedbugs398.go):
type i1 interface {
F() interface {
i1
}
}
type i2 interface {
F() interface {
i2
}
}
This CL changes the recursion prevention to use a parameter,
and threads it through the formatting routines.
Because this fundamentally limits the embedding depth
of all types, it sets the depth limit to be much higher.
In practice, it is unlikely to impact any code at all,
one way or the other.
The remaining uses of Type.Trecur are boolean in nature.
A future CL will change Type.Trecur to be a boolean flag.
The removal of a couple of mode.Sprintf calls
makes this a very minor net performance improvement:
name old alloc/op new alloc/op delta
Template 40.0MB ± 0% 40.0MB ± 0% -0.13% (p=0.032 n=5+5)
Unicode 30.0MB ± 0% 29.9MB ± 0% ~ (p=0.310 n=5+5)
GoTypes 114MB ± 0% 113MB ± 0% -0.25% (p=0.008 n=5+5)
SSA 856MB ± 0% 855MB ± 0% -0.04% (p=0.008 n=5+5)
Flate 25.5MB ± 0% 25.4MB ± 0% -0.27% (p=0.008 n=5+5)
GoParser 31.9MB ± 0% 31.9MB ± 0% ~ (p=0.222 n=5+5)
Reflect 79.0MB ± 0% 78.6MB ± 0% -0.45% (p=0.008 n=5+5)
Tar 26.8MB ± 0% 26.7MB ± 0% -0.25% (p=0.032 n=5+5)
XML 42.4MB ± 0% 42.4MB ± 0% ~ (p=0.151 n=5+5)
name old allocs/op new allocs/op delta
Template 395k ± 0% 391k ± 0% -1.00% (p=0.008 n=5+5)
Unicode 321k ± 1% 319k ± 0% -0.56% (p=0.008 n=5+5)
GoTypes 1.16M ± 0% 1.14M ± 0% -1.61% (p=0.008 n=5+5)
SSA 7.63M ± 0% 7.60M ± 0% -0.30% (p=0.008 n=5+5)
Flate 239k ± 0% 234k ± 0% -1.94% (p=0.008 n=5+5)
GoParser 320k ± 0% 317k ± 1% -0.86% (p=0.008 n=5+5)
Reflect 1.00M ± 0% 0.98M ± 0% -2.17% (p=0.016 n=4+5)
Tar 255k ± 1% 251k ± 0% -1.35% (p=0.008 n=5+5)
XML 398k ± 0% 395k ± 0% -0.89% (p=0.008 n=5+5)
Updates #15756
Change-Id: Id23e647d347aa841f9a69d51f7d2d7d27b259239
Reviewed-on: https://go-review.googlesource.com/38797
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Right now, at least with Xcode 8.3, we invoke dsymutil and dutifully
copy what it produces back into the binary, but it has actually dropped
all the DWARF information that we wanted, because it didn't like
the look of go.o.
Make it like the look of go.o.
DWARF is tested in other ways, but typically indirectly and not for cgo programs.
Add a direct test, and one that exercises cgo.
This detects missing dwarf information in cgo-using binaries on macOS,
at least with Xcode 8.3, and possibly earlier versions as well.
Fixes#19772.
Change-Id: I0082e52c0bc8fc4e289770ec3dc02f39fd61e743
Reviewed-on: https://go-review.googlesource.com/38855
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that we no longer generate dead code,
it is possible to follow block predecessors
into infinite loops with no variable definitions,
causing an infinite loop during phi insertion.
To fix that, check explicitly whether the predecessor
is dead in lookupVarOutgoing, and if so, bail.
The loop in lookupVarOutgoing is very hot code,
so I am wary of adding anything to it.
However, a long, CPU-only benchmarking run shows no
performance impact at all.
Fixes#19783
Change-Id: I8ef8d267e0b20a29b5cb0fecd7084f76c6f98e47
Reviewed-on: https://go-review.googlesource.com/38913
Reviewed-by: David Chase <drchase@google.com>
We use an "autogenerated" position in several places.
Rather than recreate it each time, make one early on and reuse it.
This removes the creation of new positions during the backend,
which was not concurrency-safe.
Updates #15756
Change-Id: Ic116b2e60f0e99de1a2ea87fe763831b50b645f8
Reviewed-on: https://go-review.googlesource.com/38915
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Without this, the load fails during kernel exec, which results in the
mysterious and completely uninformative "Killed: 9" error.
It appears that the stars (or at least the inputs) were properly aligned
with earlier versions of Xcode so that this happened accidentally.
Make it happen on purpose.
Gregory Man bisected the breakage to this change in LLVM,
which fits the theory nicely:
https://github.com/llvm-mirror/llvm/commit/9a41e59cFixes#19734.
Change-Id: Ice67a09af2de29d3c0d5e3fcde6a769580897c95
Reviewed-on: https://go-review.googlesource.com/38854
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Might as well provide a way around the mach-o munging
that doesn't require stripping all symbols.
After all, -w does mean no DWARF.
For #11887, #19734, and anyone else that needs to disable
this code path without losing the symbol table.
Change-Id: I254b7539f97fb9211fa90f446264b383e7f3980f
Reviewed-on: https://go-review.googlesource.com/38853
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The gold linker is used by default in the Android NDK, except on
arm64:
https://github.com/android-ndk/ndk/issues/148
The Go linker already forces the use of the gold linker on arm and
arm64 (CL 22141) for other reasons. However, the test.bash script in
testcshared doesn't, resulting in linker errors on android/arm64:
warning: liblog.so, needed by ./libgo.so, not found (try using -rpath or
-rpath-link)
Add -fuse-ld=gold when running testcshared on Android. Fixes the
android/arm64 builder.
Change-Id: I35ca96f01f136bae72bec56d71b7ca3f344df1ed
Reviewed-on: https://go-review.googlesource.com/38832
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
After https://golang.org/cl/31490 we break false
output dependency for CVTS.. in compiler generated code.
I've looked through asm code, which uses CVTS..
and added XOR to the only case where it affected performance.
Log-6 21.6ns ± 0% 19.9ns ± 0% -7.87% (p=0.000 n=10+10)
Change-Id: I25d9b405e3041a3839b40f9f9a52e708034bb347
Reviewed-on: https://go-review.googlesource.com/38771
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
There is always 128 bytes available below the stackguard. Allow functions
with medium-sized stack frames to use this, potentially allowing them to
avoid growing the stack.
This change makes all architectures use the same calculation as x86.
Change-Id: I2afb1a7c686ae5a933e50903b31ea4106e4cd0a0
Reviewed-on: https://go-review.googlesource.com/38734
Reviewed-by: Cherry Zhang <cherryyz@google.com>
By overwhelming popular demand, exclude vendored packages from ... matches,
by making ... never match the "vendor" element above a vendored package.
go help packages now reads:
An import path is a pattern if it includes one or more "..." wildcards,
each of which can match any string, including the empty string and
strings containing slashes. Such a pattern expands to all package
directories found in the GOPATH trees with names matching the
patterns.
To make common patterns more convenient, there are two special cases.
First, /... at the end of the pattern can match an empty string,
so that net/... matches both net and packages in its subdirectories, like net/http.
Second, any slash-separted pattern element containing a wildcard never
participates in a match of the "vendor" element in the path of a vendored
package, so that ./... does not match packages in subdirectories of
./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do.
Note, however, that a directory named vendor that itself contains code
is not a vendored package: cmd/vendor would be a command named vendor,
and the pattern cmd/... matches it.
Fixes#19090.
Change-Id: I985bf9571100da316c19fbfd19bb1e534a3c9e5f
Reviewed-on: https://go-review.googlesource.com/38745
Reviewed-by: Alan Donovan <adonovan@google.com>
This reverts commit 041ecb697f.
Reason for revert: Not working on S390x and some 386 archs.
I have a guess why the S390x is failing. No clue on the 386 yet.
Revert until I can figure it out.
Change-Id: I64f1ce78fa6d1037ebe7ee2a8a8107cb4c1db70c
Reviewed-on: https://go-review.googlesource.com/38790
Reviewed-by: Keith Randall <khr@golang.org>
rsc.io/toolstash is gone; use rsc.io/pprof_mac_fix.
This fixes a bug in the test. It turns out the code being tested here
is also broken, so the test still doesn't pass after this CL (filed #19769).
Change-Id: Ieb725c321d7fab600708e133ae28f531e55521ad
Reviewed-on: https://go-review.googlesource.com/38743
Reviewed-by: Alan Donovan <adonovan@google.com>
The uintptr-typed Data field in reflect.SliceHeader and
reflect.StringHeader needs special treatment because it is
really a pointer. Add the special treatment in walk for
bug #19168 to escape analysis.
Includes extra debugging that was helpful.
Fixes#19743.
Change-Id: I6dab5002f0d436c3b2a7cdc0156e4fc48a43d6fe
Reviewed-on: https://go-review.googlesource.com/38738
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously, an inlined call to wg.Done() in package main would have the
following incorrect symbol name:
main.(*sync.WaitGroup).Done
This change modifies methodname to return the correct symbol name:
sync.(*WaitGroup).Done
This fix was suggested by @mdempsky.
Fixes#19467.
Change-Id: I0117838679ac5353789299c618ff8c326712d94d
Reviewed-on: https://go-review.googlesource.com/37866
Reviewed-by: Austin Clements <austin@google.com>
The `skip` argument passed to runtime.Caller and runtime.Callers should
be interpreted as the number of logical calls to skip (rather than the
number of physical stack frames to skip). This changes runtime.Callers
to skip inlined calls in addition to physical stack frames.
The result value of runtime.Callers is a slice of program counters
([]uintptr) representing physical stack frames. If the `skip` parameter
to runtime.Callers skips part-way into a physical frame, there is no
convenient way to encode that in the resulting slice. To avoid changing
the API in an incompatible way, our solution is to store the number of
skipped logical calls of the first frame in the _second_ uintptr
returned by runtime.Callers. Since this number is a small integer, we
encode it as a valid PC value into a small symbol called:
runtime.skipPleaseUseCallersFrames
For example, if f() calls g(), g() calls `runtime.Callers(2, pcs)`, and
g() is inlined into f, then the frame for f will be partially skipped,
resulting in the following slice:
pcs = []uintptr{pc_in_f, runtime.skipPleaseUseCallersFrames+1, ...}
We store the skip PC in pcs[1] instead of pcs[0] so that `pcs[i:]` will
truncate the captured stack trace rather than grow it for all i.
Updates #19348.
Change-Id: I1c56f89ac48c29e6f52a5d085567c6d77d499cf1
Reviewed-on: https://go-review.googlesource.com/37854
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Previously, we could not run tests with -l=4 on NaCl since the buildrun
action is not supported on NaCl. This lets us run tests with build flags
on NaCl.
Change-Id: I103370c7b823b4ff46f47df97e802da0dc2bc7c3
Reviewed-on: https://go-review.googlesource.com/38170
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The aLongTimeAgo time value in net and net/http is used to cancel
in-flight read and writes. It was set to time.Unix(233431200, 0)
which seemed like far enough in the past.
But Raspberry Pis, lacking a real time clock, had to spoil the fun and
boot in 1970 at the Unix epoch time, breaking assumptions in net and
net/http.
So change aLongTimeAgo to time.Unix(1, 0), which seems like the
earliest safe value. I don't trust subsecond values on all operating
systems, and I don't trust the Unix zero time. The Raspberry Pis do
advance their clock at least. And the reported problem was that Hijack
on a ResponseWriter hung forever, waiting for the connection read
operation to finish. So now, even if kernel + userspace boots in under
a second (unlikely), the Hijack will just have to wait for up to a
second.
Fixes#19747
Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a
Reviewed-on: https://go-review.googlesource.com/38785
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We have lots of rewrite rules that vary only in the fact that
we have 2 versions for the 2 different orderings of various
commuting ops. For example:
(ADDL x (MOVLconst [c])) -> (ADDLconst [c] x)
(ADDL (MOVLconst [c]) x) -> (ADDLconst [c] x)
It can get unwieldly quickly, especially when there is more than
one commuting op in a rule.
Our existing "fix" for this problem is to have rules that
canonicalize the operations first. For example:
(Eq64 x (Const64 <t> [c])) && x.Op != OpConst64 -> (Eq64 (Const64 <t> [c]) x)
Subsequent rules can then assume if there is a constant arg to Eq64,
it will be the first one. This fix kinda works, but it is fragile and
only works when we remember to include the required extra rules.
The fundamental problem is that the rule matcher doesn't
know anything about commuting ops. This CL fixes that fact.
We already have information about which ops commute. (The register
allocator takes advantage of commutivity.) The rule generator now
automatically generates multiple rules for a single source rule when
there are commutative ops in the rule. We can now drop all of our
almost-duplicate source-level rules and the canonicalization rules.
I have some CLs in progress that will be a lot less verbose when
the rule generator handles commutivity for me.
I had to reorganize the load-combining rules a bit. The 8-way OR rules
generated 128 different reorderings, which was causing the generator
to put too much code in the rewrite*.go files (the big ones were going
from 25K lines to 132K lines). Instead I reorganized the rules to
combine pairs of loads at a time. The generated rule files are now
actually a bit (5%) smaller.
[Note to reviewers: check these carefully. Most of the other rule
changes are trivial.]
Make.bash times are ~unchanged.
Compiler benchmarks are not observably different. Probably because
we don't spend much compiler time in rule matching anyway.
I've also done a pass over all of our ops adding commutative markings
for ops which hadn't had them previously.
Fixes#18292
Change-Id: I999b1307272e91965b66754576019dedcbe7527a
Reviewed-on: https://go-review.googlesource.com/38666
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
reflect.callReflect heap-allocates a stack frame and then constructs
pointers to the arguments and result areas of that frame. However, if
there are no results, the results pointer will point past the end of
the frame allocation. If there are also no arguments, the arguments
pointer will also point past the end of the frame allocation. If the
GC observes either these pointers, it may panic.
Fix this by not constructing these pointers if these areas of the
frame are empty.
This adds a test of calling no-argument/no-result methods via reflect,
since nothing in std did this before. However, it's quite difficult to
demonstrate the actual failure because it depends on both exact
allocation patterns and on GC scanning the goroutine's stack while
inside one of the typedmemmovepartial calls.
I also audited other uses of typedmemmovepartial and
memclrNoHeapPointers in reflect, since these are the most susceptible
to this. These appear to be the only two cases that can construct
out-of-bounds arguments to these functions.
Fixes#19724.
Change-Id: I4b83c596b5625dc4ad0567b1e281bad4faef972b
Reviewed-on: https://go-review.googlesource.com/38736
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
"go env" prints Go environment information as a shell script format by
default but it's difficult for some tools (e.g. editor packages) to
interpret it.
The -json flag prints the environment in JSON format which
can be easily interpreted by a lot of tools.
$ go env -json
{
"CC": "gcc",
"CGO_CFLAGS": "-g -O2",
"CGO_CPPFLAGS": "",
"CGO_CXXFLAGS": "-g -O2",
"CGO_ENABLED": "1",
"CGO_FFLAGS": "-g -O2",
"CGO_LDFLAGS": "-g -O2",
"CXX": "g++",
"GCCGO": "gccgo",
"GOARCH": "amd64",
"GOBIN": "/home/haya14busa/go/bin",
"GOEXE": "",
"GOGCCFLAGS": "-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build498013955=/tmp/go-build -gno-record-gcc-switches",
"GOHOSTARCH": "amd64",
"GOHOSTOS": "linux",
"GOOS": "linux",
"GOPATH": "/home/haya14busa",
"GORACE": "",
"GOROOT": "/home/haya14busa/src/go.googlesource.com/go",
"GOTOOLDIR": "/home/haya14busa/src/go.googlesource.com/go/pkg/tool/linux_amd64",
"PKG_CONFIG": "pkg-config"
}
Also, it supports arguments with -json flag.
$ go env -json GOROOT GOPATH GOBIN
{
"GOBIN": "/home/haya14busa/go/bin",
"GOPATH": "/home/haya14busa",
"GOROOT": "/home/haya14busa/src/go.googlesource.com/go"
}
Fixes#12567
Change-Id: I75db3780f14a8ab8c7fa58cc3c9cc488ef7b66a1
Reviewed-on: https://go-review.googlesource.com/38757
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This was cherry-picked to 1.8 as CL 38587, but on master issue was fixed
by CL 37661. Add still relevant part (test) and close issue, since test passes.
Fixes#19201
Change-Id: I6415792e2c465dc6d9bd6583ba1e54b107bcf5cc
Reviewed-on: https://go-review.googlesource.com/37376
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
It is currently possible in the compiler to create a struct type,
calculate the widths of types that depend on it,
and then alter the struct type.
transformclosure has local protection against this.
Protect against it at a deeper level.
This is preparation to call dowidth automatically,
rather than explicitly.
This is a re-roll of CL 38469.
Change-Id: Ic5b4baa250618504611fc57cbf51ab01d1eddf80
Reviewed-on: https://go-review.googlesource.com/38534
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this CL, Type.Width != 0 was the mark
of a Type whose Width had been calculated.
As a result, dowidth always recalculated
the width of struct{}.
This, combined with the prohibition on calculating
the width of a FuncArgsStruct and the use of
struct{} as a function argument,
meant that there were circumstances in which
it was forbidden to call dowidth on a type.
This inhibits refactoring to call dowidth automatically,
rather than explicitly.
Instead add a helper method, Type.WidthCalculated,
and implement as Type.Align > 0.
Type.Width is not a good candidate for tracking
whether the width has been calculated;
0 is a value type width, and Width is subject to
too much magic value game-playing.
For good measure, add a test for #11354.
Change-Id: Ie9a9fb5d924e7a2010c1904ae5e38ed4a38eaeb2
Reviewed-on: https://go-review.googlesource.com/38468
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It is explicitly assigned in each of the
assemblers as needed.
I plan to remove Cursym entirely eventually,
but this is a helpful intermediate step.
Passes toolstash-check -all.
Updates #15756
Change-Id: Id7ddefae2def439af44d03053886ca8cc935731f
Reviewed-on: https://go-review.googlesource.com/38727
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Remove the global obj.Link.Curp.
In asmz.go, replace the only use by passing it as an argument.
In asm0.go and asm9.go, it was written but never read.
In asm5.go and asm7.go, thread it through as an argument.
Passes toolstash-check -all.
Updates #15756
Change-Id: I1a0faa89e768820f35d73a8b37ec8088d78d15f7
Reviewed-on: https://go-review.googlesource.com/38715
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If the user created an httptest.Server directly without using a
constructor it won't have the new unexported 'client' field. So don't
assume it's non-nil.
Fixes#19729
Change-Id: Ie92e5da66cf4e7fb8d95f3ad0f4e3987d3ae8b77
Reviewed-on: https://go-review.googlesource.com/38710
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Kevin Burke <kev@inburke.com>
We reused the old C stack check mechanism for the implementation of
//go:systemstack, so when we execute a //go:systemstack function on a
user stack, the system fails by calling morestackc. However,
morestackc's message still talks about "executing C code".
Fix morestackc's message to reflect its modern usage.
Change-Id: I7e70e7980eab761c0520f675d3ce89486496030f
Reviewed-on: https://go-review.googlesource.com/38572
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On Android, the thread local offset is found by looping through memory
starting at the TLS base address. The search is limited to
PTHREAD_KEYS_MAX, but issue 19472 made it clear that in some cases, the
slot is located further from the TLS base.
The limit is merely a sanity check in case our assumptions about the
thread-local storage layout are wrong, so this CL raises it to 384, which
is enough for the test case in issue 19472.
Fixes#19472
Change-Id: I89d1db3e9739d3a7fff5548ae487a7483c0a278a
Reviewed-on: https://go-review.googlesource.com/38636
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These fields are used to encode a single instruction.
Add them to AsmBuf, which is also per-instruction,
and which is not global.
Updates #15756
Change-Id: I0e5ea22ffa641b07291e27de6e2ff23b6dc534bd
Reviewed-on: https://go-review.googlesource.com/38668
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Empirically, p == ctxt.Curp here.
A scan of (the thousands of lines of) asm6.go
shows no clear opportunity for them to diverge.
Passes toolstash-check -all.
Updates #15756
Change-Id: I9f5ee9585a850fbe24be3b851d8fdc2c966c65ce
Reviewed-on: https://go-review.googlesource.com/38665
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The x86 assembler requires a buffer to build
variable-length instructions.
It used to be an obj.Link field.
That doesn't play nicely with concurrent assembly.
Move the AsmBuf type to the x86 package,
where it belongs anyway,
and make it a local variable.
Passes toolstash-check -all.
No compiler performance impact.
Updates #15756
Change-Id: I8014e52145380bfd378ee374a0c971ee5bada917
Reviewed-on: https://go-review.googlesource.com/38663
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Prior to this CL, instinit was called as needed.
This does not work well in a concurrent backend.
Initialization is very cheap; do it on startup instead.
Passes toolstash-check -all.
No compiler performance impact.
Updates #15756
Change-Id: Ifa5e82e8abf4504435e1b28766f5703a0555f42d
Reviewed-on: https://go-review.googlesource.com/38662
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now that we have consistent use of xOrNil parse methods, we don't
need a special missing_statement singleton to distinguish between
missing actually statements and other errors (which have returned
nil before).
For #19663.
Change-Id: I8364f1441bdf8dd966bcd6d8219b2a42d6b88abd
Reviewed-on: https://go-review.googlesource.com/38656
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- parser creates sensible nodes in case of syntax errors instead of nil
- a new BadExpr node is used in places where we can't do better
- fixed error message for incorrect type switch guard
- minor cleanups
Fixes#19663.
Change-Id: I028394c6db9cba7371f0e417ebf93f594659786a
Reviewed-on: https://go-review.googlesource.com/38653
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ONAME, OLITERAL, and OTYPE nodes can be shared between functions.
In a concurrent backend, such nodes might be walked concurrently
with being read in other functions.
Arrange for them to be unmodified by walk.
This is a follow-up to CL 38609.
Passes toolstash-check.
Updates #15756
Change-Id: I03ff1d2c0ad81dafac3fd55caa218939cf7c0565
Reviewed-on: https://go-review.googlesource.com/38655
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Concurrent compilation requires providing an
explicit position and curfn to temp.
This implementation of tempAt temporarily
continues to use the globals lineno and Curfn,
so as not to collide with mdempsky's
work for #19683 eliminating the Curfn dependency
from func nod.
Updates #15756
Updates #19683
Change-Id: Ib3149ca4b0740e9f6eea44babc6f34cdd63028a9
Reviewed-on: https://go-review.googlesource.com/38592
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If go doesn't have permission to run strace, this test hangs while
waiting for strace to run. Instead try invoking strace with
Run() first - on fail skip and report error, otherwise run
the test normally using strace.
Also fix link to open mips64 issue in same test.
Fixes#9711
Change-Id: Ibbc5fbb143ea6d0f8b6cfdca4b385ef4c8960b3d
Reviewed-on: https://go-review.googlesource.com/38633
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The type switch in walkexpr is giant.
Shrink it a little by coalescing identical cases
and removing some vertical whitespace.
No functional changes.
Passes toolstash-check.
Change-Id: I7f7efb4faae1f8657dfafac04585172f99d8b37d
Reviewed-on: https://go-review.googlesource.com/38652
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Sym.Fsym is used only to avoid adding duplicate
entries to funcsyms, but that is easily
accomplished by detecting the first lookup
vs subsequent lookups of the func sym name.
This avoids creating an unnecessary ONAME node
during funcsym, which eliminates a dependency
in the backend on Curfn and lineno.
It also makes the code a lot simpler and clearer.
Updates #15756
Passes toolstash-check -all.
No compiler performance changes.
funcsymname does generate garbage via string
concatenation, but it is not called very much,
and this CL also eliminates allocation of several
Nodes and Names.
Change-Id: I7116c78fa39d975b7bd2c65a1d228749cf0dd46b
Reviewed-on: https://go-review.googlesource.com/38605
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Clean up code that does interface equality. Avoid doing checks
in efaceeq/ifaceeq that we already did before calling those routines.
No noticeable performance changes for existing benchmarks.
name old time/op new time/op delta
EfaceCmpDiff-8 604ns ± 1% 553ns ± 1% -8.41% (p=0.000 n=9+10)
Fixes#18618
Change-Id: I3bd46db82b96494873045bc3300c56400bc582eb
Reviewed-on: https://go-review.googlesource.com/38606
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
In the future, walk will probably run concurrently
with SSA construction. It is possible for walk
to be walking a function node that is referred
to by another function undergoing SSA construction.
In that case, this particular assignment to n.Type
is race-y.
This assignment is also not necessary;
evconst does not change the type of n.
Both arguments to evconst must have the same type,
and at the end of evconst, n is replaced with n.Left.
Remove the assignment, and add a check to ensure
that its removal remains correct.
Updates #15756
Change-Id: Id95faaff42d5abd76be56445d1d3e285775de8bf
Reviewed-on: https://go-review.googlesource.com/38609
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change strips the port in mux.Handler before attempting to
match handlers and adds a test for a request with port.
CONNECT requests continue to use the original path and port.
Fixes#10463
Change-Id: Iff3a2ca2b7f1d884eca05a7262ad6b7dffbcc30f
Reviewed-on: https://go-review.googlesource.com/38194
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The section on map literals mentions constant map keys but doesn't say
what happens for equal non-constant map keys - that is covered in the
section on evaluation order. Added respective link for clarity.
Fixes#19689.
Change-Id: If9a5368ba02e8250d4bb0a1d60d0de26a1f37bbb
Reviewed-on: https://go-review.googlesource.com/38598
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Simple phi insertion already had a heuristic to check
for dead blocks, namely having no predecessors.
When we stopped generating code for dead blocks,
we eliminated some values contained in more subtle
dead blocks, which confused phi insertion.
Compensate by beefing up the reachability check.
Fixes#19678
Change-Id: I0081e4a46f7ce2f69b131a34a0553874a0cb373e
Reviewed-on: https://go-review.googlesource.com/38602
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
CL 37499 allows inlining more functions by ignoring dead code.
However, that dead code can contain non-exportable constructs.
Teach the exporter not to export dead code.
Fixes#19679
Change-Id: Idb1d3794053514544b6f1035d29262aa6683e1e7
Reviewed-on: https://go-review.googlesource.com/38601
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Almost never happens in practice.
The compiler will generate reasonable code anyway,
since assignments involving [0]T never do any work.
Fixes#19696Fixes#19671
Change-Id: I350d2e0c5bb326c4789c74a046ab0486b2cee49c
Reviewed-on: https://go-review.googlesource.com/38599
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The darwin linker for ARM does not allow PC-relative relocation
of external symbol in text section. Work around it by accessing
it indirectly: putting its address in a global variable (which is
not external), and accessing through that variable.
Fixes#19684.
Change-Id: I41361bbb281b5dbdda0d100ae49d32c69ed85a81
Reviewed-on: https://go-review.googlesource.com/38596
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Custom logic from request.go has been removed.
Created by running: “go run gen.go -core” from x/text
at fc7fa097411d30e6708badff276c4c164425590c.
Fixesgolang/go#17268
Change-Id: Ie440d6ae30288352283d303e5126e5837f11bece
Reviewed-on: https://go-review.googlesource.com/37111
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We already handle n << (uint64(c)&63).
This change also handles n << (uint8(c)&63)
where the SSA compiler promotes the counter to 32 bits.
Fixes#19681
Change-Id: I9327d64a994286aa0dbf76eb995578880be6923a
Reviewed-on: https://go-review.googlesource.com/38550
Run-TryBot: Alexandru Moșoi <alexandru@mosoi.ro>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Pass around the imported package explicitly instead of relying
on a global variable.
Unfortunately we still need a global variable to communicate to
the typechecker that we're in an import, but the semantic load
is significantly reduced as it's just a bool, set/reset in a
couple of places only.
Change-Id: I4ebeae4064eb76ca0c4e2a15e4ca53813f005c29
Reviewed-on: https://go-review.googlesource.com/38595
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Go uses CommandLineToArgV from shell32.dll to parse command
line parameters. But shell32.dll is slow to load. Implement
Windows command line parsing in Go. This should make starting
Go programs faster.
I can see these speed ups for runtime.BenchmarkRunningGoProgram
on my Windows 7 amd64:
name old time/op new time/op delta
RunningGoProgram-2 11.2ms ± 1% 10.4ms ± 2% -6.63% (p=0.000 n=9+10)
on my Windows XP 386:
name old time/op new time/op delta
RunningGoProgram-2 19.0ms ± 3% 12.1ms ± 1% -36.20% (p=0.000 n=10+10)
on @egonelbre Windows 10 amd64:
name old time/op new time/op delta
RunningGoProgram-8 17.0ms ± 1% 15.3ms ± 2% -9.71% (p=0.000 n=10+10)
This CL is based on CL 22932 by John Starks.
Fixes#15588.
Change-Id: Ib14be0206544d0d4492ca1f0d91fac968be52241
Reviewed-on: https://go-review.googlesource.com/37915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Verified that BenchmarkBitLen time went down from 2.25 ns/op to 0.65 ns/op
an a 2.3 GHz Intel Core i7, before removing that benchmark (now covered by
math/bits benchmarks).
Change-Id: I3890bb7d1889e95b9a94bd68f0bdf06f1885adeb
Reviewed-on: https://go-review.googlesource.com/38464
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is currently possible in the compiler to create a struct type,
calculate the widths of types that depend on it,
and then alter the struct type.
transformclosure has local protection against this.
Protect against it at a deeper level.
This is preparation to call dowidth automatically,
rather than explicitly.
Change-Id: Ic1578ca014610197cfe54a9f4d044d122a7217e8
Reviewed-on: https://go-review.googlesource.com/38469
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In livenessepilogue, if we save liveness information for instructions
before updating liveout, we can avoid an extra bitvector temporary and
some extra copying around.
Passes toolstash-check -all.
Change-Id: I10d5803167ef3eba2e9e95094adc7e3d33929cc7
Reviewed-on: https://go-review.googlesource.com/38408
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
In some newer Linux distros, systemd forces
all mount namespaces to be shared, starting
at /. This disables the CLONE_NEWNS
flag in unshare(2) and clone(2).
While this problem is most commonly seen
on systems with systemd, it can happen anywhere,
due to how Linux namespaces now work.
Hence, to create a private mount namespace,
it is not sufficient to just set
CLONE_NEWS; you have to call mount(2) to change
the behavior of namespaces, i.e.
mount("none", "/", NULL, MS_REC|MS_PRIVATE, NULL)
This is tested and working and we can now correctly
start child process with private namespaces on Linux
distros that use systemd.
The new test works correctly on Ubuntu 16.04.2 LTS.
It fails if I comment out the new Mount, and
succeeds otherwise. In each case it correctly
cleans up after itself.
Fixes#19661
Change-Id: I52240b59628e3772b529d9bbef7166606b0c157d
Reviewed-on: https://go-review.googlesource.com/38471
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A -0 constant is the same as 0. Use explicit negative zero
for float64 -0.0. Also, fix two test cases that were wrong.
Fixes#19673.
Change-Id: Ic09775f29d9bc2ee7814172e59c4a693441ea730
Reviewed-on: https://go-review.googlesource.com/38463
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 38337 modified canMergeLoad to reject loads with multiple uses
so it is no longer necessary to check this in the SSA rules.
Change-Id: I03498390e778da1be8cb59ae0948e99289008315
Reviewed-on: https://go-review.googlesource.com/38473
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Introduce a new type, gc.Progs, to manage
generation of Progs for a function.
Use it to replace globals pc and pcloc.
Passes toolstash-check -all.
Updates #15756
Change-Id: I2206998d7c58fe2a76b620904909f2e1cec8a57d
Reviewed-on: https://go-review.googlesource.com/38418
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We want to merge a load and op into a single instruction
l = LOAD ptr mem
y = OP x l
into
y = OPload x ptr mem
However, all of our OPload instructions require that y uses
the same register as x. If x is needed past this instruction, then
we must copy x somewhere else, losing the whole benefit of merging
the instructions in the first place.
Disable this optimization if x is live past the OP.
Also disable this optimization if the OP is in a deeper loop than the load.
Update #19595
Change-Id: I87f596aad7e91c9127bfb4705cbae47106e1e77a
Reviewed-on: https://go-review.googlesource.com/38337
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
As #19357 reported,
TST has 3 different sub forms
TST $imme, Rx
TST Ry << imme, Rx
TST Ry << Rz, Rx
just like CMP/CMN/TEQ has. But current arm assembler assembles all TST
instructions wrongly. This patch fixes it and adds more tests.
Fixes#19357
Change-Id: Iafedccfaab2cbb2631e7acf259837a782e2e8e2f
Reviewed-on: https://go-review.googlesource.com/37662
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It was already marked flaky for everything but the dashboard.
Remove that restriction. It's just flaky overall.
It's doing more harm than good.
Updates #13324
Change-Id: I36feff32a1b8681e77700f74b9c70cb4073268eb
Reviewed-on: https://go-review.googlesource.com/38459
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
CL 38446 introduced the use of the sys.ArchFamily type into the
cmd/internal/obj/mips package and redefined the mips.Mips32 and
mips.Mips64 constants in terms of their sys.ArchFamily counterparts.
This CL removes these local declarations and consolidates on sys.MIPS
and sys.MIPS64 respectively.
Change-Id: Id7aab6c7fd0de42ff43dde605df6bd4c85a3d895
Reviewed-on: https://go-review.googlesource.com/38287
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The step method implementations check directly if the next rune
only needs one byte to be decoded and avoid calling utf8.DecodeRune
for such ASCII characters.
Introduce the same fast path optimization for rune decoding
for the context methods.
Results for regexp benchmarks that use the context methods:
name old time/op new time/op delta
AnchoredLiteralShortNonMatch-4 97.5ns ± 1% 94.8ns ± 2% -2.80% (p=0.000 n=45+43)
AnchoredShortMatch-4 163ns ± 1% 160ns ± 1% -1.84% (p=0.000 n=46+47)
NotOnePassShortA-4 742ns ± 2% 742ns ± 2% ~ (p=0.440 n=49+50)
NotOnePassShortB-4 535ns ± 1% 533ns ± 2% -0.37% (p=0.005 n=46+48)
OnePassLongPrefix-4 169ns ± 2% 166ns ± 2% -2.06% (p=0.000 n=50+49)
Change-Id: Ib302d9e8c63333f02695369fcf9963974362e335
Reviewed-on: https://go-review.googlesource.com/38256
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This greatly improves the latency of starting a child process when
the Go process is using a lot of memory. Even though the kernel uses
copy-on-write, preparation for that can take up to several 100ms under
certain conditions. All other goroutines are suspended while starting
a subprocess so this latency directly affects total throughput.
With CLONE_VM the child process shares the same memory with the parent
process. On its own this would lead to conflicting use of the same
memory, so CLONE_VFORK is used to suspend the parent process until the
child releases the memory when switching to to the new program binary
via the exec syscall. When the parent process continues to run, one
has to consider the changes to memory that the child process did,
namely the return address of the syscall function needs to be restored
from a register.
A simple benchmark has shown a difference in latency of 16ms vs. 0.5ms
at 10GB memory usage. However, much higher latencies of several 100ms
have been observed in real world scenarios. For more information see
comments on #5838.
Fixes#5838
Change-Id: I6377d7bd8dcd00c85ca0c52b6683e70ce2174ba6
Reviewed-on: https://go-review.googlesource.com/37439
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When unmarshaling, if an element is empty, eg. '<tag></tag>', and
destination type is int, uint, float or bool, do not attempt to parse
value (""). Set to its zero value instead.
Fixes#13417
Change-Id: I2d79f6d8f39192bb277b1a9129727d5abbb2dd1f
Reviewed-on: https://go-review.googlesource.com/38386
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The DefaultServeMux included in net/http uses a map to store routes,
but iterates all keys for every request to allow longer paths.
This change checks the map for an exact match first.
To check performance was better, BenchmarkServeMux has been added -
this adds >100 routes and checks the matches.
Exact matches are faster and more predictable on this benchmark
and on most existing package benchmarks.
https://perf.golang.org/search?q=upload:20170312.1
ServeMux-4 2.02ms ± 2% 0.04ms ± 2% −98.08% (p=0.004 n=5+6)
https://perf.golang.org/search?q=upload:20170312.2
ReadRequestChrome-4 184MB/s ± 8% 186MB/s ± 1% ~
ReadRequestCurl-4 45.0MB/s ± 1% 46.2MB/s ± 1% +2.71%
Read...Apachebench-4 45.8MB/s ±13% 48.7MB/s ± 1% ~
ReadRequestSiege-4 63.6MB/s ± 5% 69.2MB/s ± 1% +8.75%
ReadRequestWrk-4 30.9MB/s ± 9% 34.4MB/s ± 2% +11.25%
Change-Id: I8afafcb956f07197419d545a9f1c03ecaa307384
Reviewed-on: https://go-review.googlesource.com/38057
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This simplifies the code and removes a premature optimization.
It increases the amount of allocated syntax.Node space by ~0.4%
for parsing all of std lib, which is negligible.
Before the change (best of 5 runs):
$ go test -run StdLib -fast
parsed 1517022 lines (3394 files) in 793.487886ms (1911840 lines/s)
allocated 387.086Mb (267B/line, 487.828Mb/s)
After the change (best of 5 runs):
$ go test -run StdLib -fast
parsed 1516911 lines (3392 files) in 805.028655ms (1884294 lines/s)
allocated 388.466Mb (268B/line, 482.549Mb/s)
Change-Id: Id19d6210fdc62393862ba3b04913352d95c599be
Reviewed-on: https://go-review.googlesource.com/38439
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change adds position information for { and } braces in the
source. There's a 1.9% increase in memory use for syntax.Nodes,
which is negligible relative to overall compiler memory consumption.
Parsing the std library (using syntax package only) and memory
consumption before this change (fastest of 5 runs):
$ go test -run StdLib -fast
parsed 1516827 lines (3392 files) in 780.612335ms (1943124 lines/s)
allocated 379.903Mb (486.673Mb/s)
After this change (fastest of 5 runs):
$ go test -run StdLib -fast
parsed 1517022 lines (3394 files) in 793.487886ms (1911840 lines/s)
allocated 387.086Mb (267B/line, 487.828Mb/s)
While not an exact apples-to-apples comparison (the syntax package
has changed and is also parsed), the overall impact is small.
Also: Small improvements to nodes_test.go.
Change-Id: Ib8a7f90bbe79de33d83684e33b1bf8dbc32e644a
Reviewed-on: https://go-review.googlesource.com/38435
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Starting in go1.9, the minimum processor requirement for ppc64 is POWER8.
Therefore, the checks for OldArch and the code enabled by it are not necessary
anymore.
Updates #19074
Change-Id: I33d6a78b2462c80d57c5dbcba2e13424630afab4
Reviewed-on: https://go-review.googlesource.com/38404
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Starting in go1.9, the minimum processor requirement for ppc64 is POWER8. This
means the checks for GOARCH_ppc64 in asm_ppc64x.s can be removed, since we can
assume LBAR and STBCCC instructions (both from ISA 2.06) will always be
available.
Updates #19074
Change-Id: Ib4418169cd9fc6f871a5ab126b28ee58a2f349e2
Reviewed-on: https://go-review.googlesource.com/38406
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Asmode is always set to p.Mode,
which is always set based on the arch family.
Instead, use the arch family directly.
Passes toolstash-check -all.
Change-Id: Id982472dcc8eeb6dd22cac5ad2f116b54a44caee
Reviewed-on: https://go-review.googlesource.com/38451
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Replace Ctxt.Mode with a method, Ctxt.RegWidth,
which is calculated directly off the arch info.
I believe that Prog.Mode can also be removed; future CL.
This is a step towards obj.Link immutability.
Passes toolstash-check -all.
Updates #15756
Change-Id: Ifd7f8f6ed0a2fdc032d1dd306fcd695a14aa5bc5
Reviewed-on: https://go-review.googlesource.com/38446
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TestOnlyWriteTimeout assumes wrongly that:
- the Accept method of trackLastConnListener is called only once
- the shared variable conn never becomes nil
and crashes on some circumstances.
Updates #19032.
Change-Id: I61de22618cd90b84a2b6401afdb6e5d9b3336b12
Reviewed-on: https://go-review.googlesource.com/36735
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
To enable this, inline the call to nod and simplify.
Eliminates a reference to lineno from the backend.
Passes toolstash-check -all.
Updates #15756
Change-Id: I9c4bd77d10d727aa8f5e6c6bb16b0e05de165631
Reviewed-on: https://go-review.googlesource.com/38441
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
AMODE appears to have been intended to allow
a Prog to switch between 16 (!), 32, or 64 bit x86.
It is unused anywhere in the tree.
Passes toolstash-check -all.
Updates #15756
Change-Id: Ic57b257cfe580f29dad81d97e4193bf3c330c598
Reviewed-on: https://go-review.googlesource.com/38445
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
By analogy with the handling of methods on types, show the documentation
for a single field of a struct.
% go doc ast.structtype.fields
struct StructType {
Fields *FieldList // list of field declarations
}
%
Fixes#19169.
Change-Id: I002f992e4aa64bee667e2e4bccc7082486149842
Reviewed-on: https://go-review.googlesource.com/38438
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The pipe2 syscall exists in all officially supported FreeBSD
versions: 10, 11 and future 12.
The pipe syscall no longer exists in 11 and 12. To build and
run Go on these versions, kernel needs COMPAT_FREEBSD10 option.
Based on Gleb Smirnoff's https://golang.org/cl/38422Fixes#18854
Change-Id: I8e201ee1b15dca10427c3093b966025d160aaf61
Reviewed-on: https://go-review.googlesource.com/38426
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
During AllocFrame, we drop unused variables from Curfn.Func.Dcl, but
there might still be OpVarFoo instructions that reference those
variables. This wasn't a problem though because gvardefx used to emit
ANOP for unused variables instead of AVARFOO.
As an easy fix, if we see OpVarFoo (or OpKeepAlive) referencing an
unused variable, we can ignore it.
Fixes#19632.
Change-Id: I4e9ffabdb4058f7cdcc4663b540f5a5a692daf8b
Reviewed-on: https://go-review.googlesource.com/38400
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The chanrecv funcs don't use it at all. The chansend ones do, but the
element type is now part of the hchan struct, which is already a
parameter.
hchan can be nil in chansend when sending to a nil channel, so when
instrumenting we must copy to the stack to be able to read the channel
type.
name old time/op new time/op delta
ChanUncontended 6.42µs ± 1% 6.22µs ± 0% -3.06% (p=0.000 n=19+18)
Initially found by github.com/mvdan/unparam.
Fixes#19591.
Change-Id: I3a5e8a0082e8445cc3f0074695e3593fd9c88412
Reviewed-on: https://go-review.googlesource.com/38351
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Removing stray xori that came from big endian copy/paste.
Adding atomicand8 check to runtime.check() that would have revealed
this error.
Might fix#19396.
Change-Id: If8d6f25d3e205496163541eb112548aa66df9c2a
Reviewed-on: https://go-review.googlesource.com/38257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The old implementation of Jar made the assumption that the host names
in the URLs given to SetCookies() and Cookies() methods are well-formed.
This is not an unreasonable assumption as malformed host names do not
trigger calls to SetCookies or Cookies (at least not from net/http)
as the HTTP request themselves are not executed. But there can be other
invocations of these methods and at least on Linux it was possible to
make DNS lookup to domain names with two trailing dots (see issue #7122).
This is an old bug and this CL revives an old change (see
https://codereview.appspot.com/52100043) to fix the issue. The discussion
around 52100043 focused on the interplay between the jar and the
public suffix list and who is responsible for which type if domain name
canonicalization. The new bug report in issue #19384 used a nil public
suffix list which demonstrates that the package cookiejar alone exhibits
this problem and any solution cannot be fully delegated to the
implementation of the used PublicSuffixList: Package cookiejar itself
needs to protect against host names of the form ".." which triggered an
out-of-bounds error.
This CL does not address the issue of host name canonicalization and
the question who is responsible for it. This CL just prevents the
out-of-bounds error: It is a very conservative change, i.e. one might
still set and retrieve cookies for host names like "weird.stuf...".
Several more test cases document how the current code works.
Fixes#19384.
Change-Id: I14be080e8a2a0b266ced779f2aeb18841b730610
Reviewed-on: https://go-review.googlesource.com/37843
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
I would like to use BenchmarkRunningGoProgram to measure
changes for issue #15588. So the program in the benchmark
should import "os" package.
It is also reasonable that basic Go program includes
"os" package.
For #15588.
Change-Id: Ida6712eab22c2e79fbe91b6fdd492eaf31756852
Reviewed-on: https://go-review.googlesource.com/37914
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Prior to this CL, the function's position was used.
The dottype Node's position is clearly better.
I'm not thrilled about introducing a reference to
lineno in the middle of SSA construction;
I will have to remove it later.
My immediate goal is stability and correctness of positions,
though, since that aids refactoring, so this is an improvement.
An example from package io:
func (t *multiWriter) WriteString(s string) (n int, err error) {
var p []byte // lazily initialized if/when needed
for _, w := range t.writers {
if sw, ok := w.(stringWriter); ok {
n, err = sw.WriteString(s)
The w.(stringWriter) type assertion includes loading
the address of static type data for stringWriter:
LEAQ type."".stringWriter(SB), R10
Prior to this CL, this instruction was given the line number
of the function declaration.
After this CL, this instruction is given the line number
of the type assertion itself.
Change-Id: Ifcca274b581a5a57d7e3102c4d7b7786bf307210
Reviewed-on: https://go-review.googlesource.com/38389
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This paragraph has been added, as the notion was missing from the
documentation.
If a value is passed to Encode and the type is not a struct (or pointer to struct,
etc.), for simplicity of processing it is represented as a struct of one field.
The only visible effect of this is to encode a zero byte after the value, just as
after the last field of an encoded struct, so that the decode algorithm knows when
the top-level value is complete.
Fixes#16978
Change-Id: I5f008e792d1b6fe80d2e026a7ff716608889db32
Reviewed-on: https://go-review.googlesource.com/38414
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Any method that affects the parse must happen before parsing.
This obvious point is clear, but it's not clear to some that the
set of defined functions affect the parse.
Fixes#18971
Change-Id: I8b7f8c8cf85b028c18e5ca3b9797de92ea910669
Reviewed-on: https://go-review.googlesource.com/38413
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, we handled recursive interfaces by deferring typechecking
of interface methods, while eagerly expanding interface embeddings.
This CL switches to eagerly evaluating interface methods, and
deferring expanding interface embeddings to dowidth. This allows us to
detect recursive interface embeddings with the same mechanism used for
detecting recursive struct embeddings.
Updates #16369.
Change-Id: If4c0320058047f8a2d9b52b9a79de47eb9887f95
Reviewed-on: https://go-review.googlesource.com/38391
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Given an entry in $no_proxy like ":1" we would interpret it as an empty
host name and a port number, then check the first character of the host
name for dots. This would then cause an index out of range panic. This
change simply skips these entries, as the following checks would anyway
have returned false.
Fixes#19536
Change-Id: Iafe9c7a77ad4a6278c8ccb00a1575b56e4bdcd79
Reviewed-on: https://go-review.googlesource.com/38067
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
JSON decoding performs poorly for unmapped and ignored fields. We noticed better
performance when unmarshalling unused fields. The loss comes mostly from calls
to scanner.error as described at #17914.
benchmark old ns/op new ns/op delta
BenchmarkIssue10335-8 431 408 -5.34%
BenchmarkUnmapped-8 1744 1314 -24.66%
benchmark old allocs new allocs delta
BenchmarkIssue10335-8 4 3 -25.00%
BenchmarkUnmapped-8 18 4 -77.78%
benchmark old bytes new bytes delta
BenchmarkIssue10335-8 320 312 -2.50%
BenchmarkUnmapped-8 568 344 -39.44%
Fixes#17914, improves #10335
Change-Id: I7d4258a94eb287c0fe49e7334795209b90434cd0
Reviewed-on: https://go-review.googlesource.com/33276
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a workaround for a FreeBSD kernel bug. It can be removed when
we are confident that all people are using the fixed kernel. See #15658.
Updates #15658.
Change-Id: I0ecdccb77ddd0c270bdeac4d3a5c8abaf0449075
Reviewed-on: https://go-review.googlesource.com/38325
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL changes the order that liveness analysis visits CFG blocks to
PC order, rather than RPO. This doesn't meaningfully change anything
except that the PCDATA_StackMapIndex values will be assigned in PC
order too.
However, this does have the benefit that the subsequent CL to port
liveness analysis to the SSA CFG (which has blocks in PC order) will
now pass toolstash-check.
Change-Id: I1de5a2eecb8027723a6e422d46186d0c63d48c8d
Reviewed-on: https://go-review.googlesource.com/38086
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This CL deletes some unnecessary code in objz.go that existed to
support instruction scheduling. It's likely instruction scheduling
will never be done in this part of the backend so this code can
just be deleted.
This file can probably be cleaned up a bit more, but I think this
is a good start.
Passes: go build -toolexec 'toolstash -cmp' -a std.
Change-Id: I1645632ac551a90a4f4be418045c046b488e9469
Reviewed-on: https://go-review.googlesource.com/38394
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Teach the backend to recognize that the address of a symbol
is equal with itself, and that the addresses of two different
symbols are different.
Some examples of where this rule hits in the standard library:
- inlined uses of (*time.Time).setLoc (e.g. time.UTC)
- inlined uses of bufio.NewReader (via type assertion)
Change-Id: I23dcb068c2ec333655c1292917bec13bbd908c24
Reviewed-on: https://go-review.googlesource.com/38338
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When optimizations are disabled, the compiler
cannot eliminate enough write barriers to satisfy
the runtime's nowritebarrier and nowritebarrierrec
annotations.
Enforce that requirement, and for convenience,
have cmd/go elide -N when compiling the runtime.
This came up in practice for me when running
toolstash -cmp. When toolstash -cmp detected
mismatches, it recompiled with -N, which caused
runtime compilation failures.
Change-Id: Ifcdef22c725baf2c59a09470f00124361508a8f3
Reviewed-on: https://go-review.googlesource.com/38380
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 27254 changed a constant string to a byte array
in encoding/hex and got significant performance
improvements.
hex.Encode used the string twice in a single function.
The rewrite rules lower constant strings into components.
The pointer component requires an aux symbol.
The existing implementation created a new aux symbol every time.
As a result, constant string pointers were never CSE'd.
Tighten then moved the pointer calculation next to the uses, i.e.
into the loop.
The re-use of aux syms enabled by this CL
occurs 3691 times during make.bash.
This CL should not go in without CL 38338
or something like it.
Change-Id: Ibbf5b17283c0e31821d04c7e08d995c654de5663
Reviewed-on: https://go-review.googlesource.com/28219
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Since "columns of alignment" are terminated whenever indentation
changes from one line to the next, alignment with spaces will work
independent of the actually chosen tab width. Don't mention tab width
anymore.
Follow-up on https://golang.org/cl/38374/.
For #19618.
Change-Id: I58e47dfde57834f56a98d9119670757a12fb9c41
Reviewed-on: https://go-review.googlesource.com/38379
Reviewed-by: Rob Pike <r@golang.org>
As noted in https://github.com/golang/go/issues/19161#issuecomment-287554171,
CL 37771 (adding use of the new httptest.Server.Client to all net/http
tests) accidentally reverted DisableKeepAlives for this test. For
many tests, DisableKeepAlives was just present to prevent goroutines
from staying active after the test exited. In this case it might
actually be important. (We'll see)
Updates #19161
Change-Id: I11f889f86c932b51b11846560b68dbe5993cdfc3
Reviewed-on: https://go-review.googlesource.com/38373
Reviewed-by: Michael Munday <munday@ca.ibm.com>
Mallocs and panics in the scavenge path are particularly nasty because
they're likely to silently self-deadlock on the mheap.lock. Avoid
sinking lots of time into debugging these issues in the future by
turning these into immediate throws.
Change-Id: Ib36fdda33bc90b21c32432b03561630c1f3c69bc
Reviewed-on: https://go-review.googlesource.com/38293
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The lfstack API is still a C-style API: lfstacks all have unhelpful
type uint64 and the APIs are package-level functions. Make the code
more readable and Go-style by creating an lfstack type with methods
for push, pop, and empty.
Change-Id: I64685fa3be0e82ae2d1a782a452a50974440a827
Reviewed-on: https://go-review.googlesource.com/38290
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
I noted in CL 38327 that the SSA test API felt a bit
clunky after the ssa.Func/ssa.Cache/ssa.Config refactoring,
and promised to clean it up once the dust settled.
The dust has settled.
Along the way, this CL fixes a potential latent bug,
in which the amd64 test context was used for all dummy Syslook calls.
The lone SSA test using the s390x context did not depend on the
Syslook context being correct, so the bug did not arise in practice.
Change-Id: If964251d1807976073ad7f47da0b1f1f77c58413
Reviewed-on: https://go-review.googlesource.com/38346
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mapping all empty interfaces onto the same Type
allows better reuse of the ptrTo and sliceOf
Type caches for *interface{} and []interface{}.
This has little compiler performance impact now,
but it will be helpful in the future,
when we will eagerly populate some of those caches.
Passes toolstash-check.
Change-Id: I17daee599a129b0b2f5f3025c1be43d569d6782c
Reviewed-on: https://go-review.googlesource.com/38344
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reduces the number of calls back into the
gc Type routines, which will help performance
in a concurrent backend.
It also reduces the number of callsites
that must be considered in making the transition.
Passes toolstash-check -all. No compiler performance changes.
Updates #15756
Change-Id: Ic7a8f1daac7e01a21658ae61ac118b2a70804117
Reviewed-on: https://go-review.googlesource.com/38340
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Prior to this CL, the ssa.Frontend field was responsible
for providing types to the backend during compilation.
However, the types needed by the backend are few and static.
It makes more sense to use a struct for them
and to hang that struct off the ssa.Config,
which is the correct home for readonly data.
Now that Types is a struct, we can clean up the names a bit as well.
This has the added benefit of allowing early construction
of all types needed by the backend.
This will be useful for concurrent backend compilation.
Passes toolstash-check -all. No compiler performance change.
Updates #15756
Change-Id: I021658c8cf2836d6a22bbc20cc828ac38c7da08a
Reviewed-on: https://go-review.googlesource.com/38336
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, this second line is treated a pre-formatted text as it's
indented relatively to the BUG() line.
The current state can be seen at:
https://golang.org/cmd/gofmt/#pkg-note-BUG
Unindenting makes the rest of the sentence part of the same paragraph.
Change-Id: I6dee55c9c321b1a03b41c7124c6a1ea15772c878
Reviewed-on: https://go-review.googlesource.com/38353
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
While we're here, also eliminate a few more Curfn uses.
Passes toolstash -cmp. No compiler performance impact.
Updates #15756
Change-Id: Ib8db9e23467bbaf16cc44bf62d604910f733d6b8
Reviewed-on: https://go-review.googlesource.com/38331
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a first step towards eliminating the
Curfn global in the backend.
There's more to do.
Passes toolstash -cmp. No compiler performance impact.
Updates #15756
Change-Id: Ib09f550a001e279a5aeeed0f85698290f890939c
Reviewed-on: https://go-review.googlesource.com/38232
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Suggested by mdempsky in CL 38232.
This allows us to use the Frontend field
to associate frontend state and information
with a function.
See the following CL in the series for examples.
This is a giant CL, but it is almost entirely routine refactoring.
The ssa test API is starting to feel a bit unwieldy.
I will clean it up separately, once the dust has settled.
Passes toolstash -cmp.
Updates #15756
Change-Id: I71c573bd96ff7251935fce1391b06b1f133c3caf
Reviewed-on: https://go-review.googlesource.com/38327
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Prior to this CL, config was an explicit argument
to the SSA rewrite rules, and rules that needed
a Frontend got at it via config.
An upcoming CL moves Frontend from Config to Func,
so rules can no longer reach Frontend via Config.
Passing a Frontend as an argument to the rewrite rules
causes a 2-3% regression in compile times.
This CL takes a different approach:
It treats the variable names "config" and "fe"
as special and calculates them as needed.
The "as needed part" is also important to performance:
If they are calculated eagerly, the nilchecks themselves
cause a regression.
This introduces a little bit of magic into the rewrite
generator. However, from the perspective of the rules,
the config variable was already more or less magic.
And it makes the upcoming changes much clearer.
Passes toolstash -cmp.
Change-Id: I173f2bcc124cba43d53138bfa3775e21316a9107
Reviewed-on: https://go-review.googlesource.com/38326
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL changes the GOARCH.Init functions to take gc.Thearch as a
parameter, which gc.Main supplies.
Additionally, the x86 backend is refactored to decide within Init
whether to use the 387 or SSE2 instruction generators, rather than for
each individual SSA Value/Block.
Passes toolstash-check -all.
Change-Id: Ie6305a6cd6f6ab4e89ecbb3cbbaf5ffd57057a24
Reviewed-on: https://go-review.googlesource.com/38301
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This reduces memory use yet still provides the significant
performance gain seen when using a fast path for small integers.
Improvement of this CL comparing to code without fast path:
name old time/op new time/op delta
FormatIntSmall-8 35.6ns ± 1% 4.5ns ± 1% -87.30% (p=0.008 n=5+5)
AppendIntSmall-8 17.4ns ± 1% 9.4ns ± 3% -45.70% (p=0.008 n=5+5)
For comparison, here's the improvement before this CL to code without
fast path (1% better for FormatIntSmall):
name old time/op new time/op delta
FormatIntSmall-8 35.6ns ± 1% 4.0ns ± 3% -88.64% (p=0.008 n=5+5)
AppendIntSmall-8 17.4ns ± 1% 8.2ns ± 1% -52.80% (p=0.008 n=5+5)
Thus, the code in this CL performs slower for small integers using fast
path then the prior version, but this is relative to an already very fast
version:
name old time/op new time/op delta
FormatIntSmall-8 4.05ns ± 3% 4.52ns ± 1% +11.81% (p=0.008 n=5+5)
AppendIntSmall-8 8.21ns ± 1% 9.45ns ± 3% +15.05% (p=0.008 n=5+5)
Measured on 2.3 GHz Intel Core i7 running macOS Sierra 10.12.3.
Overall, it's still ~88% faster than without fast path for small integers,
so probably worth it as it removes 100 global string slices in favor of
a single string.
Credits: This is based on the original (but cleaned up) version of the
code by Aliaksandr Valialkin (https://go-review.googlesource.com/c/37963/).
Change-Id: Icda78679c8c14666d46257894e9fa3d7f35e58b8
Reviewed-on: https://go-review.googlesource.com/38319
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Its godoc says that path must not be empty or dot, while the existing
implementation happily accepts both.
Change-Id: I64766271c35152dc7adb21ff60eb05c52237e6b6
Reviewed-on: https://go-review.googlesource.com/38262
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
`go test -i -race` adds the "sync/atomic" package to every package dependency tree
that makes buildIDs different from packages installed with `go install -race`
and causes cache rebuilding.
Fixes#19133Fixes#19151
Change-Id: I0536c6fa41b0d20fe361b5d35b3c0937b146d07d
Reviewed-on: https://go-review.googlesource.com/37598
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes it's necessary to deal with emails that do not follow the specification; in particular, it's possible to download such email via gmail.
When the existing implementation handle invalid mime media parameters, it returns nils and error, although there is a valid media type, which may be returned.
If this behavior changes, it may not affect any existing programs, but it will help to parse some emails.
Fixes#19498
Change-Id: Ieb2fdbddfd93857faee941d2aa49d59e286d57fd
Reviewed-on: https://go-review.googlesource.com/38190
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes ssa.Func, ssa.Cache, and ssa.Config fulfill
the roles laid out for them in CL 38160.
The only non-trivial change in this CL is how cached
values and blocks get IDs. Prior to this CL, their IDs were
assigned as part of resetting the cache, and only modified
IDs were reset. This required knowing how many values and
blocks were modified, which required a tight coupling between
ssa.Func and ssa.Config. To eliminate that coupling,
we now zero values and blocks during reset,
and assign their IDs when they are used.
Since unused values and blocks have ID == 0,
we can efficiently find the last used value/block,
to avoid zeroing everything.
Bulk zeroing is efficient, but not efficient enough
to obviate the need to avoid zeroing everything every time.
As a happy side-effect, ssa.Func.Free is no longer necessary.
DebugHashMatch and friends now belong in func.go.
They have been left in place for clarity and review.
I will move them in a subsequent CL.
Passes toolstash -cmp. No compiler performance impact.
No change in 'go test cmd/compile/internal/ssa' execution time.
Change-Id: I2eb7af58da067ef6a36e815a6f386cfe8634d098
Reviewed-on: https://go-review.googlesource.com/38167
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This is an evolution of https://go-review.googlesource.com/33616, as discussed
via email with Robert (gri):
$ cat foobar.go
package main
func main() {
a := "foo", "bar"
}
before:
./foobar.go:4:4: assignment count mismatch: want 1 values, got 2
after:
./foobar.go:4:4: assignment count mismatch: cannot assign 2 values to 1 variables
We could likely also eliminate the "assignment count mismatch" prefix now
without losing any information, but that string is matched by a number of
tests.
Change-Id: Ie6fc8a7bbd0ebe841d53e66e5c2f49868decf761
Reviewed-on: https://go-review.googlesource.com/38313
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
name old time/op new time/op delta
LeadingZeros-4 2.00ns ± 0% 1.34ns ± 1% -33.02% (p=0.000 n=8+10)
LeadingZeros16-4 1.62ns ± 0% 1.57ns ± 0% -3.09% (p=0.001 n=8+9)
LeadingZeros32-4 2.14ns ± 0% 1.48ns ± 0% -30.84% (p=0.002 n=8+10)
LeadingZeros64-4 2.06ns ± 1% 1.33ns ± 0% -35.08% (p=0.000 n=8+8)
8-bit args is a special case - the Go code is really fast because
it is just a single table lookup. So I've disabled that for now.
Intrinsics were actually slower:
LeadingZeros8-4 1.22ns ± 3% 1.58ns ± 1% +29.56% (p=0.000 n=10+10)
Update #18616
Change-Id: Ia9c289b9ba59c583ea64060470315fd637e814cf
Reviewed-on: https://go-review.googlesource.com/38311
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Remove size AuxInt in Store, and alignment in Move/Zero. We still
pass size AuxInt to Move/Zero, as it is used for partial Move/Zero
lowering (e.g. cmd/compile/internal/ssa/gen/386.rules:288).
SizeAndAlign is gone.
Passes "toolstash -cmp" on std.
Change-Id: I1ca34652b65dd30de886940e789fcf41d521475d
Reviewed-on: https://go-review.googlesource.com/38150
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The old writebarrier implementation fails to handle single-block
loop where a memory Phi value depends on the write barrier store
in the same block. The new implementation (CL 36834) doesn't have
this problem. Add a test to ensure it.
Fix#19067.
Change-Id: Iab13c6817edc12be8a048d18699b4450fa7ed712
Reviewed-on: https://go-review.googlesource.com/36940
Reviewed-by: David Chase <drchase@google.com>
When the compiler insert write barriers, the frontend makes
conservative decisions at an early stage. This sometimes have
false positives because of the lack of information, for example,
writes on stack. SSA's writebarrier pass identifies writes on
stack and eliminates write barriers for them.
This CL moves write barrier insertion into SSA. The frontend no
longer makes decisions about write barriers, and simply does
normal assignments and emits normal Store ops when building SSA.
SSA writebarrier pass inserts write barrier for Stores when needed.
There, it has better information about the store because Phi and
Copy propagation are done at that time.
This CL only changes StoreWB to Store in gc/ssa.go. A followup CL
simplifies SSA building code.
Updates #17583.
Change-Id: I4592d9bc0067503befc169c50b4e6f4765673bec
Reviewed-on: https://go-review.googlesource.com/36839
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
For SSA Store/Move/Zero ops, attach the type of the value being
stored to the op as the Aux field. This type will be used for
write barrier insertion (in a followup CL). Since SSA passes
do not accurately propagate types of values (because of type
casting), we can't simply use type of the store's arguments
for write barrier insertion.
Passes "toolstash -cmp" on std.
Updates #17583.
Change-Id: I051d5e5c482931640d1d7d879b2a6bb91f2e0056
Reviewed-on: https://go-review.googlesource.com/36838
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Implement math/bits.TrailingZerosX using intrinsics.
Generally reorganize the intrinsic spec a bit.
The instrinsics data structure is now built at init time.
This will make doing the other functions in math/bits easier.
Update sys.CtzX to return int instead of uint{64,32} so it
matches math/bits.TrailingZerosX.
Improve the intrinsics a bit for amd64. We don't need the CMOV
for <64 bit versions.
Update #18616
Change-Id: Ic1c5339c943f961d830ae56f12674d7b29d4ff39
Reviewed-on: https://go-review.googlesource.com/38155
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, when printing tracebacks of other threads during
GOTRACEBACK=crash, if the thread is on the system stack we print only
the header for the user goroutine and fail to print its stack. This
happens because we passed the g0 to traceback instead of curg. The g0
never has anything set in its gobuf, so traceback doesn't print
anything.
Fix this by passing _g_.m.curg to traceback instead of the g0.
Fixes#19494.
Change-Id: Idfabf94d6a725e9cdf94a3923dead6455ef3b217
Reviewed-on: https://go-review.googlesource.com/38012
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GOTRACEBACK=crash works by bouncing a SIGQUIT around the process
sched.mcount times. However, sched.mcount includes the extra Ms
allocated by oneNewExtraM for cgo callbacks. Hence, if there are any
extra Ms that don't have real OS threads, we'll try to send SIGQUIT
more times than there are threads to catch it. Since nothing will
catch these extra signals, we'll fall back to blocking for five
seconds before aborting the process.
Avoid this five second delay by subtracting out the number of extra Ms
when sending SIGQUITs.
Of course, in a cgo binary, it's still possible for the SIGQUIT to go
to a cgo thread and cause some other failure mode. This does not fix
that.
Change-Id: I4fbf3c52dd721812796c4c1dcb2ab4cb7026d965
Reviewed-on: https://go-review.googlesource.com/38182
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The line between ssa.Func and ssa.Config has blurred.
Concurrent compilation in the backend will require more precision.
This CL lays out an (aspirational) organization.
The implementation will come in follow-up CLs,
once the organization is settled.
ssa.Config holds basic compiler configuration,
mostly arch-specific information.
It is configured once, early on, and is readonly,
so it is safe for concurrent use.
ssa.Func is a single-shot object used for
compiling a single Func. It is not concurrency-safe
and not re-usable.
ssa.Cache is a multi-use object used to avoid
expensive allocations during compilation.
Each ssa.Func is given an ssa.Cache to use.
ssa.Cache is not concurrency-safe.
Change-Id: Id02809b6f3541541cac6c27bbb598834888ce1cc
Reviewed-on: https://go-review.googlesource.com/38160
Reviewed-by: Keith Randall <khr@golang.org>
Previously we always issued a spill right after the op
that was being spilled. This CL pushes spills father away
from the generator, hopefully pushing them into unlikely branches.
For example:
x = ...
if unlikely {
call ...
}
... use x ...
Used to compile to
x = ...
spill x
if unlikely {
call ...
restore x
}
It now compiles to
x = ...
if unlikely {
spill x
call ...
restore x
}
This is particularly useful for code which appends, as the only
call is an unlikely call to growslice. It also helps for the
spills needed around write barrier calls.
The basic algorithm is walk down the dominator tree following a
path where the block still dominates all of the restores. We're
looking for a block that:
1) dominates all restores
2) has the value being spilled in a register
3) has a loop depth no deeper than the value being spilled
The walking-down code is iterative. I was forced to limit it to
searching 100 blocks so it doesn't become O(n^2). Maybe one day
we'll find a better way.
I had to delete most of David's code which pushed spills out of loops.
I suspect this CL subsumes most of the cases that his code handled.
Generally positive performance improvements, but hard to tell for sure
with all the noise. (compilebench times are unchanged.)
name old time/op new time/op delta
BinaryTree17-12 2.91s ±15% 2.80s ±12% ~ (p=0.063 n=10+10)
Fannkuch11-12 3.47s ± 0% 3.30s ± 4% -4.91% (p=0.000 n=9+10)
FmtFprintfEmpty-12 48.0ns ± 1% 47.4ns ± 1% -1.32% (p=0.002 n=9+9)
FmtFprintfString-12 85.6ns ±11% 79.4ns ± 3% -7.27% (p=0.005 n=10+10)
FmtFprintfInt-12 91.8ns ±10% 85.9ns ± 4% ~ (p=0.203 n=10+9)
FmtFprintfIntInt-12 135ns ±13% 127ns ± 1% -5.72% (p=0.025 n=10+9)
FmtFprintfPrefixedInt-12 167ns ± 1% 168ns ± 2% ~ (p=0.580 n=9+10)
FmtFprintfFloat-12 249ns ±11% 230ns ± 1% -7.32% (p=0.000 n=10+10)
FmtManyArgs-12 504ns ± 7% 506ns ± 1% ~ (p=0.198 n=9+9)
GobDecode-12 6.95ms ± 1% 7.04ms ± 1% +1.37% (p=0.001 n=10+10)
GobEncode-12 6.32ms ±13% 6.04ms ± 1% ~ (p=0.063 n=10+10)
Gzip-12 233ms ± 1% 235ms ± 0% +1.01% (p=0.000 n=10+9)
Gunzip-12 40.1ms ± 1% 39.6ms ± 0% -1.12% (p=0.000 n=10+8)
HTTPClientServer-12 227µs ± 9% 221µs ± 5% ~ (p=0.114 n=9+8)
JSONEncode-12 16.1ms ± 2% 15.8ms ± 1% -2.09% (p=0.002 n=9+8)
JSONDecode-12 61.8ms ±11% 57.9ms ± 1% -6.30% (p=0.000 n=10+9)
Mandelbrot200-12 4.30ms ± 3% 4.28ms ± 1% ~ (p=0.203 n=10+8)
GoParse-12 3.18ms ± 2% 3.18ms ± 2% ~ (p=0.579 n=10+10)
RegexpMatchEasy0_32-12 76.7ns ± 1% 77.5ns ± 1% +0.92% (p=0.002 n=9+8)
RegexpMatchEasy0_1K-12 239ns ± 3% 239ns ± 1% ~ (p=0.204 n=10+10)
RegexpMatchEasy1_32-12 71.4ns ± 1% 70.6ns ± 0% -1.15% (p=0.000 n=10+9)
RegexpMatchEasy1_1K-12 383ns ± 2% 390ns ±10% ~ (p=0.181 n=8+9)
RegexpMatchMedium_32-12 114ns ± 0% 113ns ± 1% -0.88% (p=0.000 n=9+8)
RegexpMatchMedium_1K-12 36.3µs ± 1% 36.8µs ± 1% +1.59% (p=0.000 n=10+8)
RegexpMatchHard_32-12 1.90µs ± 1% 1.90µs ± 1% ~ (p=0.341 n=10+10)
RegexpMatchHard_1K-12 59.4µs ±11% 57.8µs ± 1% ~ (p=0.968 n=10+9)
Revcomp-12 461ms ± 1% 462ms ± 1% ~ (p=1.000 n=9+9)
Template-12 67.5ms ± 1% 66.3ms ± 1% -1.77% (p=0.000 n=10+8)
TimeParse-12 314ns ± 3% 309ns ± 0% -1.56% (p=0.000 n=9+8)
TimeFormat-12 340ns ± 2% 331ns ± 1% -2.79% (p=0.000 n=10+10)
The go binary is 0.2% larger. Not really sure why the size
would change.
Change-Id: Ia5116e53a3aeb025ef350ffc51c14ae5cc17871c
Reviewed-on: https://go-review.googlesource.com/34822
Reviewed-by: David Chase <drchase@google.com>
Interface wrapper functions now get compiled eagerly in some cases.
Consequently, they may be present in multiple translation units.
Mark them as DUPOK, just like closures.
Fixes#19548Fixes#19550
Change-Id: Ibe74adb5a62dbf6447db37fde22dcbb3479969ef
Reviewed-on: https://go-review.googlesource.com/38156
Reviewed-by: David Chase <drchase@google.com>
In the SSA CFG, TEXT, RET, and JMP instructions correspond to Blocks,
not Values. Rework liveness analysis so that progeffects only cares
about Progs that result from Values, and handle Blocks separately.
Passes toolstash-check -all.
Change-Id: Ic23719c75b0421fdb51382a08dac18c3ba042b32
Reviewed-on: https://go-review.googlesource.com/38085
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
POSIX Shell only supports = to compare variables inside '[' tests. But
this is Bash, where == is an alias for =. In practice they're the same,
but the current form is inconsisnent and breaks POSIX for no good
reason.
Change-Id: I38fa7a5a90658dc51acc2acd143049e510424ed8
Reviewed-on: https://go-review.googlesource.com/38031
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The fmtmode and fmtpkgpfx globals stand in the
way of making the compiler more concurrent (#15756).
This CL removes them.
The natural way to eliminate a global is to explicitly
thread it as a parameter through all function calls.
However, most of the functions in gc/fmt.go
get called indirectly, by way of fmt format strings,
so there's nowhere natural to add a parameter.
Since there are only a few fmtmode modes,
use named types to distinguish between modes.
For example, fmtNodeErr, fmtNodeDbg, and fmtNodeTypeId
are all gc.Node, but they print in different modes.
Varying the type allows us to thread mode through fmt.
Handle fmtpkgpfx by converting it to a printing mode,
FTypeIdName, and using the same type-based approach.
To avoid a loss of readability and danger of bugs
from introducing conversions at all call sites,
instead add a helper that systematically modifies the args.
The only remaining gc/fmt.go global is dumpdepth.
Since that is used for debugging only,
it that can be handled with a global mutex,
or some similarly basic, if inefficient, protection.
Passes toolstash -cmp. No compiler performance impact.
For future reference, other options for threading state
that were considered and rejected:
* Wrapping values in structs, such as:
type fmtNode struct {
n *Node
mode fmtMode
}
This reduces the proliferation of types, and supports
easily adding extra local parameters.
However, putting such a struct into an interface{} allocates.
This is unacceptable in this particular area of code.
* Passing state via precision, such as:
fmt.Fprintf("%*v", mode, n)
where mode is the state encoded as an integer.
This avoids extra allocations, but it is out of keeping
with the intended semantics of precision, and is less readable.
* Modify the fmt package to support setting/getting context
via fmt.State. Unavailable due to Go 1 compatibility,
and probably the wrong solution anyway.
* Give up on package fmt. This would be a huge readability
regression and cause high code churn.
* Attempt a de-novo rewrite that circumvents these problems.
Too high a risk of bugs, with insufficient reward for the effort,
particularly since long term plans call for elimination
of gc.Node.
Change-Id: Iea2440d5a34a938e64273707de27e3a897cb41d1
Reviewed-on: https://go-review.googlesource.com/38147
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
With this change, code like
h := sha1.New()
h.Write(buf)
sum := h.Sum()
gets compiled into static calls rather than
interface calls, because the compiler is able
to prove that 'h' is really a *sha1.digest.
The InterCall re-write rule hits a few dozen times
during make.bash, and hundreds of times during all.bash.
The most common pattern identified by the compiler
is a constructor like
func New() Interface { return &impl{...} }
where the constructor gets inlined into the caller,
and the result is used immediately. Examples include
{sha1,md5,crc32,crc64,...}.New, base64.NewEncoder,
base64.NewDecoder, errors.New, net.Pipe, and so on.
Some existing benchmarks that change on darwin/amd64:
Crc64/ISO4KB-8 2.67µs ± 1% 2.66µs ± 0% -0.36% (p=0.015 n=10+10)
Crc64/ISO1KB-8 694ns ± 0% 690ns ± 1% -0.59% (p=0.001 n=10+10)
Adler32KB-8 473ns ± 1% 471ns ± 0% -0.39% (p=0.010 n=10+9)
On architectures like amd64, the reduction in code size
appears to contribute more to benchmark improvements than just
removing the indirect call, since that branch gets predicted
accurately when called in a loop.
Updates #19361
Change-Id: I57d4dc21ef40a05ec0fbd55a9bb0eb74cdc67a3d
Reviewed-on: https://go-review.googlesource.com/38139
Run-TryBot: Philip Hofer <phofer@umich.edu>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Changes to ${GOARCH}Ops.go files were mechanically produced using
github.com/mdempsky/ssa-symops, a one-off tool that inserts
"SymEffect: X" elements by pattern matching against the Op names.
Change-Id: Ibf3e481ffd588647f2a31662d72114b740ccbfcf
Reviewed-on: https://go-review.googlesource.com/38084
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
There were a surprising number of places
in the tree that used yyerror for failed internal
consistency checks. Switch them to Fatalf.
Updates #15756
Updates #19250
Change-Id: Ie4278148185795a28ff3c27dacffc211cda5bbdd
Reviewed-on: https://go-review.googlesource.com/38153
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reverts commit 4e0c7c3f61.
Reason for revert: The presence-of-optimization test program is fragile, breaks under noopt, and might break if the Go libraries are tweaked. It needs to be (re)written without reference to other packages.
Change-Id: I3aaf1ab006a1a255f961a978e9c984341740e3c7
Reviewed-on: https://go-review.googlesource.com/38097
Reviewed-by: Keith Randall <khr@golang.org>
This abstracts creation of ACALL Progs into package gc. The main
benefit of this today is we can refactor away a lot of common
boilerplate code.
Later, once liveness analysis happens on the SSA graph, this will also
provide an easy insertion point for emitting the PCDATA Progs
immediately before call instructions.
Passes toolstash-check -all.
Change-Id: Ia15108ace97201cd84314f1ca916dfeb4f09d61c
Reviewed-on: https://go-review.googlesource.com/38081
Reviewed-by: Keith Randall <khr@golang.org>
Tinkering with the gob package shows that is currently possible to
*completely destroy* Int slices encoding without triggering a single
test failure.
The various encInt{8,16,32,64}Slice methods are only called during the
execution of the GobMapInterfaceEncode test, which only encodes a few
slices of length exactly 1 and then just checks that the error
returned by Encode is nil (without trying to Decode back the data).
This patch adds a few tests for signed integer slices encoding.
Change-Id: Ifaaee2f32132873118b241f79aa8203e4ad31416
Reviewed-on: https://go-review.googlesource.com/38066
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Move the zeroing of results earlier. In particular, they need to
come before any move-to-heap operations, as those require allocation.
Those allocations are points at which the GC can see the uninitialized
result slots.
For the function:
func f() (x, y, z *int) {
defer(){}()
escape(&y)
return
}
We used to generate code like this:
x = nil
y = nil
&y = new(int)
z = nil
Now we will generate:
x = nil
y = nil
z = nil
&y = new(int)
Since the fix for #18860, the return slots are always live if there
is a defer, so the former ordering allowed the GC to see junk
in the z slot.
Fixes#19078
Change-Id: I71554ae437549725bb79e13b2c100b2911d47ed4
Reviewed-on: https://go-review.googlesource.com/38133
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The existing implementation started by eliminating
nil checks for OpAddr, OpAddPtr, and OpPhis with
all non-nil args.
However, some OpPhis had all non-nil args,
but their args had not been processed yet.
Pull the OpPhi checks into their own loop,
and repeat until stabilization.
Eliminates a dozen additional nilchecks during make.bash.
Negligible compiler performance impact.
Change-Id: If7b803c3ad7582af7d9867d05ca13e03e109d864
Reviewed-on: https://go-review.googlesource.com/37999
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
With this change, code like
h := sha1.New()
h.Write(buf)
sum := h.Sum()
gets compiled into static calls rather than
interface calls, because the compiler is able
to prove that 'h' is really a *sha1.digest.
The InterCall re-write rule hits a few dozen times
during make.bash, and hundreds of times during all.bash.
The most common pattern identified by the compiler
is a constructor like
func New() Interface { return &impl{...} }
where the constructor gets inlined into the caller,
and the result is used immediately. Examples include
{sha1,md5,crc32,crc64,...}.New, base64.NewEncoder,
base64.NewDecoder, errors.New, net.Pipe, and so on.
Some existing benchmarks that change on darwin/amd64:
Crc64/ISO4KB-8 2.67µs ± 1% 2.66µs ± 0% -0.36% (p=0.015 n=10+10)
Crc64/ISO1KB-8 694ns ± 0% 690ns ± 1% -0.59% (p=0.001 n=10+10)
Adler32KB-8 473ns ± 1% 471ns ± 0% -0.39% (p=0.010 n=10+9)
On architectures like amd64, the reduction in code size
appears to contribute more to benchmark improvements than just
removing the indirect call, since that branch gets predicted
accurately when called in a loop.
Updates #19361
Change-Id: Ia9d30afdd5f6b4d38d38b14b88f308acae8ce7ed
Reviewed-on: https://go-review.googlesource.com/37751
Run-TryBot: Philip Hofer <phofer@umich.edu>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The (original) section on "Operators and Delimiters" introduced
superfluous terminology ("delimiter", "special token") which
didn't matter and was used inconsistently.
Removed any mention of "delimiter" or "special token" and now
simply group the special character tokens into "operators"
(clearly defined via links), and "punctuation" (everything else).
Fixes#19450.
Change-Id: Ife31b24b95167ace096f93ed180b7eae41c66808
Reviewed-on: https://go-review.googlesource.com/38073
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Fix last proxy in TestProxyFromEnvironment bleeds into other tests
Change ResetProxyEnv to use the newer os.Unsetenv, instead of hard
coding as ""
Change-Id: I67cf833dbcf4bec2e10ea73c354334160cf05f84
Reviewed-on: https://go-review.googlesource.com/38115
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In Go 1.7 and earlier, gc.exportsize tracked the number of bytes
written through exportf. With the removal of the old exporter in Go 1.8
exportf is only used for printing the build id, and the header and
trailer of the binary export format. The size of the export data is
now returned directly from the exporter and exportsize is never
referenced. Remove it.
Change-Id: Id301144b3c26c9004c722d0c55c45b0e0801a88c
Reviewed-on: https://go-review.googlesource.com/38116
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
selectTag has been hard coded to only understand the tag `go1` since
CL 6112060 which landed in 2012. The commit message asserted;
Right now (before go1.0.1) there is only one possible tag,
"go1", and I'd like to keep it that way.
Remove goTag and the unused matching code in selectTag.
Change-Id: I85f7c10f95704e22f8e8681266afd72bbcbe8fbd
Reviewed-on: https://go-review.googlesource.com/38112
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 32219 added precomputed sizeclass tables.
Remove the unused sizeToClass method which was previously only
called from initSizes.
Change-Id: I907bf9ed78430ecfaabbec7fca77ef2375010081
Reviewed-on: https://go-review.googlesource.com/38113
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some of the changes in CL golang.org/cl/38071/ assumed that / and %
could always be combined to use only one DIV instruction. However,
this is not the case for 64bit operands on a 32bit platform which use
seperate runtime functions to calculate division and modulo.
This CL restores the original optimizations that help on 32bit platforms
with negligible impact on 64bit platforms.
386:
name old time/op new time/op delta
FormatInt-2 6.06µs ± 0% 6.02µs ± 0% -0.70% (p=0.000 n=20+20)
AppendInt-2 4.98µs ± 0% 4.98µs ± 0% ~ (p=0.747 n=18+18)
FormatUint-2 1.93µs ± 0% 1.85µs ± 0% -4.19% (p=0.000 n=20+20)
AppendUint-2 1.71µs ± 0% 1.64µs ± 0% -3.68% (p=0.000 n=20+20)
amd64:
name old time/op new time/op delta
FormatInt-2 2.41µs ± 0% 2.41µs ± 0% -0.09% (p=0.010 n=18+18)
AppendInt-2 1.77µs ± 0% 1.77µs ± 0% +0.08% (p=0.000 n=18+18)
FormatUint-2 653ns ± 1% 653ns ± 0% ~ (p=0.178 n=20+20)
AppendUint-2 514ns ± 0% 513ns ± 0% -0.13% (p=0.000 n=20+17)
Change-Id: I574a18e54fb41b25fbe51ce696e7a8765abc79a6
Reviewed-on: https://go-review.googlesource.com/38051
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This appears to be leftover from when instruction selection happened
in the linker. Many of the morestackX functions listed don't even
exist anymore.
Now that we select instructions within the compiler and assembler,
normal deadcode elimination mechanisms should suffice for these
symbols.
Change-Id: I2cb1e435101392e7c983957c4acfbbcc87a5ca7d
Reviewed-on: https://go-review.googlesource.com/38077
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Determine int, uint and uintptr bit sizes from GOARCH environment
variable if it is set. Otherwise use host-specific sizes.
Fixes#19321
Change-Id: I494b8e4b49b59d32794f50ff2ce06ba040cb8460
Reviewed-on: https://go-review.googlesource.com/37950
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This avoids a problem that occurs on FreeBSD 11, in which the clang
3.8 assembler issues a pointless warning when invoked with -g on a
file that contains an empty .note.GNU-stack section.
No test because there is no reasonable way to write one, but should
fix the build on FreeBSD 11.
Fixes#14705.
Change-Id: I8c49bbf79a2c715c0e75495da19045fc92280e81
Reviewed-on: https://go-review.googlesource.com/38072
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
nat.setUint64 is nicely generic.
By assuming 32- or 64-bit words, however,
we can write simpler code,
and eliminate some shifts
in dead code that vet complains about.
Generated code for 64 bit systems is unaltered.
Generated code for 32 bit systems is much better.
For 386, the routine length drops from 325
bytes of code to 271 bytes of code, with fewer loops.
Change-Id: I1bc14c06272dee37a7fcb48d33dd1e621eba945d
Reviewed-on: https://go-review.googlesource.com/38070
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The compiler recognizes that in a sequence q = x/y; r = x%y only
one division is required. Remove prior work-arounds and write
more readable straight-line code (this also results in fewer
instructions, though it doesn't appear to affect the benchmarks
significantly).
name old time/op new time/op delta
FormatInt-8 2.95µs ± 1% 2.92µs ± 5% ~ (p=0.952 n=5+5)
AppendInt-8 1.91µs ± 1% 1.89µs ± 2% ~ (p=0.421 n=5+5)
FormatUint-8 795ns ± 2% 782ns ± 4% ~ (p=0.444 n=5+5)
AppendUint-8 557ns ± 1% 557ns ± 2% ~ (p=0.548 n=5+5)
https://perf.golang.org/search?q=upload:20170310.1
Also:
- use uint instead of uintptr where we want to guarantee single-
register operations
- remove some unnecessary conversions (before indexing)
- add more comments and fix some comments
Change-Id: I04858dc2d798a6495879d9c7cfec2fdc2957b704
Reviewed-on: https://go-review.googlesource.com/38071
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In FreeBSD when run Go proc under a given sub-list of
processors(e.g. 'cpuset -l 0 ./a.out' in multi-core system),
runtime.NumCPU() still return all physical CPUs from sysctl
hw.ncpu instead of account from sub-list.
Fix by use syscall cpuset_getaffinity to account the number of sub-list.
Fixes#15206
Change-Id: If87c4b620e870486efa100685db5debbf1210a5b
Reviewed-on: https://go-review.googlesource.com/29341
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
We are vendoring pprof from github.com/google/pprof, which comes with
a main package. If we don't explicitly skip that main package, then
`go install cmd` will install the compiled program in $GOROOT/bin.
Fixes#19441.
Change-Id: Ib268ffd16d4be65f7d80e4f8d9dc6e71523a94de
Reviewed-on: https://go-review.googlesource.com/38007
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Raul Silvera <rsilvera@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It appears that this test is particularly
sensitive to resource starvation.
Returning it to non-parallel should reduce flakiness,
by giving it the full system resources to run.
Fixes#19161
Change-Id: I6e8906516629badaa0cffeb5712af649dc197f39
Reviewed-on: https://go-review.googlesource.com/38005
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Compiler errors now show the exact line and line byte offset (sometimes
called "column") of where an error occured. For `go tool compile x.go`:
package p
const c int = false
//line foo.go:123
type t intg
reports
x.go:2:7: cannot convert false to type int
foo.go:123[x.go:4:8]: undefined: intg
(Some errors use the "wrong" position for the error message; arguably
the byte offset for the first error should be 15, the position of 'false',
rathen than 7, the position of 'c'. But that is an indepedent issue.)
The byte offset (column) values are measured in bytes; they start at 1,
matching the convention used by editors and IDEs.
Positions modified by //line directives show the line offset only for the
actual source location (in square brackets), not for the "virtual" file and
line number because that code is likely generated and the //line directive
only provides line information.
Because the new format might break existing tools or scripts, printing
of line offsets can be disabled with the new compiler flag -C. We plan
to remove this flag eventually.
Fixes#10324.
Change-Id: I493f5ee6e78457cf7b00025aba6b6e28e50bb740
Reviewed-on: https://go-review.googlesource.com/37970
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We could leave it alone and fix line offset (column) numbers when
reporting errors, but that is likely to cause confusion (internal
numbers don't match reported numbers). Instead, switch to default
numbering starting at 1.
For package syntax-internal use only, introduced constants defining
the line and column bases, and use them throughout the code and its
tests. It is possible to change these constants and package syntax
will continue to work. But changing them is going to break any client
that makes explicit assumptions about line and column numbers (which
is "all of them").
Change-Id: Ia3d136a8ec8d9372ed9c05ca47d3dff222cf030e
Reviewed-on: https://go-review.googlesource.com/37996
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When LookupIP is performing multiple subqueries, this option causes a
timeout/servfail affecting a single query to abort the whole operation,
instead of returning a partial (IPv4/IPv6-only) result.
Similarly, operations that walk the DNS search list will also abort when
encountering one of these errors.
Fixes#17448
Change-Id: Ice22e4aceb555c5a80d19bd1fde8b8fe87ac9517
Reviewed-on: https://go-review.googlesource.com/32572
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds a method to replace expressions
of the form
v.Args[len(v.Args)-1]
so that the code's intention to walk memory arguments
is explicit.
Passes toolstash-check.
Change-Id: I0c80d73bc00989dd3cdf72b4f2c8e1075a2515e0
Reviewed-on: https://go-review.googlesource.com/37757
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
make.bash used mostly tabs and buildall.bash used mostly spaces, but
they were both mixing them. Be consistent and use tabs, as that's what's
more common and what the Go code uses.
Change-Id: Ia6affbfccfe64fda800c1ac400965df364d2c545
Reviewed-on: https://go-review.googlesource.com/37967
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The type of the OffPtr for the first field was incorrect. It should
have been a pointer to the field type, rather than the field
type itself.
Fixes#19475.
Change-Id: I3960b404da0f4bee759331126cce6140d2ce1df7
Reviewed-on: https://go-review.googlesource.com/37869
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
A typo in the previous revision ("act" instead of "oldact") caused us
to return the sa_flags from the new (or zeroed) sigaction rather than
the old one.
In the presence of a signal handler registered before
runtime.libpreinit, this caused setsigstack to erroneously zero out
important sa_flags (such as SA_SIGINFO) in its attempt to re-register
the existing handler with SA_ONSTACK.
Change-Id: I3cd5152a38ec0d44ae611f183bc1651d65b8a115
Reviewed-on: https://go-review.googlesource.com/37852
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are a few problems from change 35494, discovered during testing
of change 37852.
1. I was confused about the usage of n.key in the sema variant, so we
were looping on the wrong condition. The error was not caught by
the TryBots (presumably due to missing TSAN coverage in the BSD and
darwin builders?).
2. The sysmon goroutine sometimes skips notetsleep entirely, using
direct usleep syscalls instead. In that case, we were not calling
_cgo_yield, leading to missed signals under TSAN.
3. Some notetsleep calls have long finite timeouts. They should be
broken up into smaller chunks with a yield at the end of each
chunk.
updates #18717
Change-Id: I91175af5dea3857deebc686f51a8a40f9d690bcc
Reviewed-on: https://go-review.googlesource.com/37867
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The tzdata 2017a update (2017-02-28) changed the abbreviation of the
Asia/Baghdad time zone (used in TestParseInLocation) from 'AST' to the
numeric '+03'.
Update the test so that it skips the checks if we're using a recent
tzdata release.
Fixes#19457
Change-Id: I45d705a5520743a611bdd194dc8f8d618679980c
Reviewed-on: https://go-review.googlesource.com/37964
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously the base register was unset, which lead to the disassembler
using "FP" instead of "SP" as the base register. That lead to some
confusion as to what the difference betweeen the two was.
Be consistent and always use SP.
Fixes#19458
Change-Id: Ie8f8ee54653bd202c0cf6fbf1d350e3c8c8b67a0
Reviewed-on: https://go-review.googlesource.com/37971
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On Android devices where the stub fallback for Current fails to
extract a User from the environment, return a dummy fallback instead
of failing.
While we're here, use / instead of /home/nacl for the NaCL fallback.
Hopefully fixes the Android builder.
Change-Id: Ia29304fbc224ee5f9c0f4e706d1756f765a7eae5
Reviewed-on: https://go-review.googlesource.com/37960
Run-TryBot: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
After benchmarking with a compiler modified to have better
spill location, it became clear that this method of checking
was actually faster on (at least) two different architectures
(ppc64 and amd64) and it also provides more timely interruption
of loops.
This change adds a modified FOR loop node "FORUNTIL" that
checks after executing the loop body instead of before (i.e.,
always at least once). This ensures that a pointer past the
end of a slice or array is not made visible to the garbage
collector.
Without the rescheduling checks inserted, the restructured
loop from this change apparently provides a 1% geomean
improvement on PPC64 running the go1 benchmarks; the
improvement on AMD64 is only 0.12%.
Inserting the rescheduling check exposed some peculiar bug
with the ssa test code for s390x; this was updated based on
initial code actually generated for GOARCH=s390x to use
appropriate OpArg, OpAddr, and OpVarDef.
NaCl is disabled in testing.
Change-Id: Ieafaa9a61d2a583ad00968110ef3e7a441abca50
Reviewed-on: https://go-review.googlesource.com/36206
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The position information recorded now consists of the line-
directive relative filename and line number. It would be
relatively easy to also encode absolute position information
as necessary (by serializing src.PosBase data).
For example, given $GOROOT/src/tmp/x.go:
package p
const C0 = 0
//line c.go:10
const C1 = 1
//line t.go:20
type T int
//line v.go:30
var V T
//line f.go:40
func F() {}
The recorded positions for the exported entities are:
C0 $GOROOT/src/tmp/x.go 3
C1 c.go 10
T t.go 20
V v.go 30
F f.go 40
Fix verified by manual inspection. There's currently no easy way
to test this, but it will eventually be tested when we fix#7311.
Fixes#19391.
Change-Id: I6269067ea58358250fe6dd1f73bdf9e5d2adfe3d
Reviewed-on: https://go-review.googlesource.com/37936
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change was originally written by Marko Tiikkaja <marko@joh.to>.
https://go-review.googlesource.com/#/c/2035/
Previously *Tx.Stmt always prepared a new statement, even if an
existing one was available on the connection the transaction was on.
Now we first see if the statement is already available on the
connection and only prepare if it isn't. Additionally, when we do
need to prepare one, we store it in the parent *Stmt to allow it to be
later reused by other calls to *Tx.Stmt on that statement or just
straight up by *Stmt.Exec et al.
To make sure that the statement doesn't disappear unexpectedly, we
record a dependency from the statement returned by *Tx.Stmt to the
*Stmt it came from and set a new field, parentStmt, to point to the
originating *Stmt. When the transaction's *Stmt is closed, we remove
the dependency. This way the "parent" *Stmt can be closed by the user
without her having to know whether any transactions are still using it
or not.
Fixes#15606
Change-Id: I41b5056847e117ac61130328b0239d1e000a4a08
Reviewed-on: https://go-review.googlesource.com/35476
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
After merging https://go-review.googlesource.com/c/34639/,
it was pointed out to me that a lot of tests under net/http
could use the new functionality to simplify and unify testing.
Using the httptest.Server provided Client removes the need to
call CloseIdleConnections() on all Transports created, as it
is automatically called on the Transport associated with the
client when Server.Close() is called.
Change the transport used by the non-TLS
httptest.Server to a new *http.Transport rather than using
http.DefaultTransport implicitly. The TLS version already
used its own *http.Transport. This change is to prevent
concurrency problems with using DefaultTransport implicitly
across several httptest.Server's.
Add tests to ensure the httptest.Server.Client().Transport
RoundTripper interface is implemented by a *http.Transport,
as is now assumed across large parts of net/http tests.
Change-Id: I9f9d15f59d72893deead5678d314388718c91821
Reviewed-on: https://go-review.googlesource.com/37771
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This helps systems that maintain an external database mapping
build ID to symbol information for the given binary, especially
in the case where /proc/self/maps lists many different files
(for example, many shared libraries).
Avoid importing debug/elf to avoid dragging in that whole
package (and its dependencies like debug/dwarf) into the
build of every program that generates a profile.
Fixes#19431.
Change-Id: I6d4362a79fe23e4f1726dffb0661d20bb57f766f
Reviewed-on: https://go-review.googlesource.com/37855
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The old code simply printed the position of the line directive in
square brackets for a position modified by a line directive. Now
we print the corresponding actual source file position instead.
Fixes#19392.
Change-Id: I933f3e435d03a6ee8269df36ae35f9202b7b2e76
Reviewed-on: https://go-review.googlesource.com/37932
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently selectgo is just a wrapper around selectgoImpl. This keeps
the hard-coded frame skip counts for tracing the same between the
channel implementation and the select implementation.
However, this is fragile and confusing, so pass a skip parameter to
send and recv, join selectgo and selectgoImpl into one function, and
use decrease all of the skips in selectgo by one.
Change-Id: I11b8cbb7d805b55f5dc6ab4875ac7dde79412ff2
Reviewed-on: https://go-review.googlesource.com/37860
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Several SSA ops will always behave identically regardless of target
architecture, so handle those within gc/ssa.go instead.
Passes toolstash-check -all.
Change-Id: I54d514e80ab86723e44332a5a38e3054cbca8c5d
Reviewed-on: https://go-review.googlesource.com/37931
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This commit reworks multiway select statements to use normal control
flow primitives instead of the previous setjmp/longjmp-like behavior.
This simplifies liveness analysis and should prevent issues around
"returns twice" function calls within SSA passes.
test/live.go is updated because liveness analysis's CFG is more
representative of actual control flow. The case bodies are the only
real successors of the selectgo call, but previously the selectsend,
selectrecv, etc. calls were included in the successors list too.
Updates #19331.
Change-Id: I7f879b103a4b85e62fc36a270d812f54c0aa3e83
Reviewed-on: https://go-review.googlesource.com/37661
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
It's only ever called with the value it was using, but the code was
counterintuitive. Use the parameter instead, like the other funcs near
it.
Found by github.com/mvdan/unparam.
Change-Id: I45855e11d749380b9b2a28e6dd1d5dedf119a19b
Reviewed-on: https://go-review.googlesource.com/37893
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When defining an int const, the compiler tries to cast the RHS
expression to int. The cast may fail for three reasons:
1. expr is an integer constant that overflows int
2. expr is a floating point constant
3. expr is a complex constant, or not a number
In the second case, in order to print a sensible error message, we
must distinguish between a floating point constant that should be
included in the error message and a floating point constant that
cannot be reasonably formatted for inclusion in an error message.
For example, in:
const a int = 1.1
const b int = 1 + 1e-100
a is in the former group, while b is in the latter, since the floating
point value resulting from the evaluation of the rhs of the assignment
(1.00...01) is too long to be fully printed in an error message, and
cannot be shortened without making the error message misleading
(rounding or truncating it would result in a "1", which looks like an
integer constant, and it makes little sense in an error message about
an invalid floating point expression).
To fix this problem, we try to format the float value using fconv
(which is used by the error reporting mechanism to format float
arguments), and then parse the resulting string back to a
big.Float. If the result is an integer, we assume that expr is a float
value that cannot be reasonably be formatted as a string, and we emit
an error message that does not include its string representation.
Also, change the error message for overflows to a more conservative
"integer too large", which does not mention overflows that are only
caused by an internal implementation restriction.
Also, change (*Mpint) SetFloat so that it returns a bool (instead of
0/-1 for success/failure).
Fixes#11371
Change-Id: Ibbc73e2ed2eaf41f07827b0649d0eb637150ecaa
Reviewed-on: https://go-review.googlesource.com/35411
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Instead of skipping them based on string matching much later in the
compilation process, skip them up front using the proper API.
Passes toolstash-check.
Change-Id: Ibd4c0448a0701ba0de3235d4689ef300235fa1d9
Reviewed-on: https://go-review.googlesource.com/37930
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Replace 'does not contains' with 'does not contain' where it appears
in the source code.
Change-Id: Ie7266347c429512c8a41a7e19142afca7ead3922
Reviewed-on: https://go-review.googlesource.com/37887
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For consistency with the other named types in this package, this
change renames the unexported rsaPublicKey struct to pkcs1PublicKey
and positions the declaration up with the other similarly-named
types in pkcs1.go.
See the final comment of #19355 for discussion.
Change-Id: I1fa0366a8efa01602b81bc69287ef747abce84f5
Reviewed-on: https://go-review.googlesource.com/37885
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes asm code in 2 different packages name its global
symbols with the same name. When these symbols are passed
to gcc, it refuses to link them thinking they are duplicate.
Mark these symbols with IMAGE_SYM_CLASS_STATIC.
Fixes#19198.
Change-Id: Ia5f59ede47354a2b48ce60b7d406c9f097ff2000
Reviewed-on: https://go-review.googlesource.com/37810
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
rfc2047 says:
White space between adjacent 'encoded-word's is not displayed.
Although, mime package already have that feature,
we cannot simply reuse that code,
because there is a subtle difference in quoted-string handling.
Fixes#19363
Change-Id: I754201aa3c6b701074ad78fe46818af5b96cbd00
Reviewed-on: https://go-review.googlesource.com/37811
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Document and check that the alphabet cannot contain '\n' or '\r'.
Document that the alphabet cannot contain the padding character.
Document that the padding character must be equal or bellow '\xff'.
Document that the padding character must not be '\n' or '\r'.
Fixes#19343Fixes#19318
Change-Id: I6de0034d347ffdf317d7ea55d6fe38b01c2c4c03
Reviewed-on: https://go-review.googlesource.com/37838
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts commit cb6e0639fb.
The fix is incorrect as it's perfectly fine to refer to an
identifier 'init' inside a function, and 'init' may even be
a variable of function value. Misspelling 'init' in that
context would lead to an incorrect error message.
Reopened#8481.
Change-Id: I49787fdf7738213370ae6f0cab54013e9e3394a8
Reviewed-on: https://go-review.googlesource.com/37876
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Given
(Store [c] (OffPtr <T1> [0] (Addr <T> _)) _
(Store [c] (Addr <T> _) _ _))
dead store elimination doesn't eliminate the inner
Store, because it addresses a type of a different width
than the first store.
When decomposing StructMake operations, always generate
an OffPtr to address struct fields so that dead stores to
the first field of the struct can be optimized away.
benchmarks affected on darwin/amd64:
HTTPClientServer-8 73.2µs ± 1% 72.7µs ± 1% -0.69% (p=0.022 n=9+10)
TimeParse-8 304ns ± 1% 300ns ± 0% -1.61% (p=0.000 n=9+9)
RegexpMatchEasy1_32-8 80.1ns ± 0% 79.5ns ± 1% -0.84% (p=0.000 n=8+9)
GobDecode-8 6.78ms ± 0% 6.81ms ± 1% +0.46% (p=0.000 n=9+10)
Gunzip-8 36.1ms ± 1% 36.2ms ± 0% +0.37% (p=0.019 n=10+10)
JSONEncode-8 15.6ms ± 0% 15.7ms ± 0% +0.69% (p=0.000 n=9+10)
Change-Id: Ia80d73fd047f9400c616ca64fdee4f438a0e7f21
Reviewed-on: https://go-review.googlesource.com/37769
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Shrinks LSym somewhat for non-STEXT LSyms, which are much more common.
While here, switch to tracking Automs in a slice instead of a linked
list. (Previously, this would have made LSyms larger.)
Passes toolstash-check.
Change-Id: I082e50e1d1f1b544c9e06b6e412a186be6a4a2b5
Reviewed-on: https://go-review.googlesource.com/37872
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
By clearing out t.nod in copytype, we effectively lose the reference
from a Type back to its declaring OTYPE Node. This means later in
typenamesym when we add typenod(t) to signatlist, we end up creating a
new OTYPE Node. Moreover, this Node's position information will depend
on whatever context it happens be needed, and will be used for the
Type's position in the export data.
Updates #19391.
Change-Id: Ied93126449f75d7c5e3275cbdcc6fa657a8aa21d
Reviewed-on: https://go-review.googlesource.com/37870
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For historical reasons, it's still commonplace to iterate over the
slice returned by runtime.Callers and call FuncForPC on each PC. This
is broken in gccgo and somewhat broken in gc and will become more
broken in gc with mid-stack inlining.
In Go 1.7, we introduced runtime.CallersFrames to deal with these
problems, but didn't strongly direct people toward using it. Reword
the documentation on runtime.Callers to more strongly encourage people
to use CallersFrames and explicitly discourage them from iterating
over the PCs or using FuncForPC on the results.
Fixes#19426.
Change-Id: Id0d14cb51a0e9521c8fdde9612610f2c2b9383c4
Reviewed-on: https://go-review.googlesource.com/37726
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We're passed a pkg, so it makes little sense to not use it. This was
probably a typo and not the intended behaviour.
Fixes#19407.
Change-Id: Ia1c9130c0e474daf47753cf51914a2d7db272c96
Reviewed-on: https://go-review.googlesource.com/37839
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently almost every function that deals with a *_func has to first
look up the *moduledata for the module containing the function's entry
point. This means we almost always do at least two identical module
lookups whenever we deal with a *_func (one to get the *_func and
another to get something from its module data) and sometimes several
more.
Fix this by making findfunc return a new funcInfo type that embeds
*_func, but also includes the *moduledata, and making all of the
functions that currently take a *_func instead take a funcInfo and use
the already-found *moduledata.
This transformation is trivial for the most part, since the *_func
type is usually inferred. The annoying part is that we can no longer
use nil to indicate failure, so this introduces a funcInfo.valid()
method and replaces nil checks with calls to valid.
Change-Id: I9b8075ef1c31185c1943596d96dec45c7ab5100f
Reviewed-on: https://go-review.googlesource.com/37331
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
This will make type-checking more robust in the presence of import errors.
Also:
- import is now relative to directory containing teh file containing the import
(matters for relative imports)
- factored out package import code from main resolver loop
- fixed a couple of minor bugs
Fixes#16088.
Change-Id: I1ace45c13cd0fa675d1762877cec0a30afd9ecdc
Reviewed-on: https://go-review.googlesource.com/37697
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently we acquire a global lock for every newMarkBits call. This is
unfortunate since every span sweep operation calls newMarkBits.
However, most allocations are simply linear allocations from the
current arena. Take advantage of this to add a lock-free fast path for
allocating from the current arena. With this change, the global lock
only protects the lists of arenas, not the free offset in the current
arena.
Change-Id: I6cf6182af8492c8bfc21276114c77275fe3d7826
Reviewed-on: https://go-review.googlesource.com/34595
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently, newArena holds the gcBitsArenas lock across allocating
memory from the OS for a new gcBits arena. This is a global lock and
allocating physical memory can be expensive, so this has the potential
to cause high lock contention, especially since every single span
sweep operation calls newArena (via newMarkBits).
Improve the situation by temporarily dropping the lock across
allocation. This means the caller now has to revalidate its
assumptions after the lock is dropped, so this also factors out that
code path and reinvokes it after the lock is acquired.
Change-Id: I1113200a954ab4aad16b5071512583cfac744bdc
Reviewed-on: https://go-review.googlesource.com/34594
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
This makes Sym flags consistent with the rest of the code after
the CL 37445.
No functional changes.
Passes toolstash -cmp.
Change-Id: Ica919f2ab98581371c717fff9a70aeb11058ca17
Reviewed-on: https://go-review.googlesource.com/37847
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On overloaded machines once we get to big N, the machine slowness dominates.
But we only retry once we get to a big N.
Instead, retry for small N too, and die on the first big N that fails.
Change-Id: I3ab9cfb88832ad86e2ba1389a926045091268aeb
Reviewed-on: https://go-review.googlesource.com/37543
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Found by github.com/mvdan/unparam. Small performance win when the
utf8.RuneLen call is removed.
name old time/op new time/op delta
AppendQuoteRune-4 21.7ns ± 0% 21.4ns ± 0% -1.38% (p=0.008 n=5+5)
Change-Id: Ieb3b3e1148db7a3d854c81555a491edeff549f43
Reviewed-on: https://go-review.googlesource.com/37831
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The assembler back end uses F15 as a temporary register in these
instructions.
Checked the assembler back end and made sure that this is the
only case clobbering F15.
Fixes#19403.
Change-Id: I02b9e00fdd9229db899f501c8e9b306e02912d83
Reviewed-on: https://go-review.googlesource.com/37792
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If you cross compile for a Unix target and call user.Lookup("root")
or user.LookupId("0"), we'll try to read the answer out of
/etc/passwd instead of returning an "unimplemented" error.
The equivalent cgo function calls getpwuid_r in glibc, which
may reach out to the NSS database or allow callers to register
extensions. The pure Go implementation only reads from /etc/passwd.
Change-Id: I56a302d634b15ba5097f9f0d6a758c68e486ba6d
Reviewed-on: https://go-review.googlesource.com/37664
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Match more patterns generated by the compiler where the index for
a bound check is bounded through a AND operation, with different
register sizes.
These rules trigger a dozen of times in a bootstrap.
Change-Id: Ic9fff16f21d08580f19a366c3ee1a372e58357d1
Reviewed-on: https://go-review.googlesource.com/37442
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently ReadMemStats stops the world for ~1.7 ms/GB of heap because
it collects statistics from every single span. For large heaps, this
can be quite costly. This is particularly unfortunate because many
production infrastructures call this function regularly to collect and
report statistics.
Fix this by tracking the necessary cumulative statistics in the
mcaches. ReadMemStats still has to stop the world to stabilize these
statistics, but there are only O(GOMAXPROCS) mcaches to collect
statistics from, so this pause is only 25µs even at GOMAXPROCS=100.
Fixes#13613.
Change-Id: I3c0a4e14833f4760dab675efc1916e73b4c0032a
Reviewed-on: https://go-review.googlesource.com/34937
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The gcstats structure is no longer consumed by anything and no longer
tracks statistics that are particularly relevant to the concurrent
garbage collector. Remove it. (Having statistics is probably a good
idea, but these aren't the stats we need these days and we don't have
a way to get them out of the runtime.)
In preparation for #13613.
Change-Id: Ib63e2f9067850668f9dcbfd4ed89aab4a6622c3f
Reviewed-on: https://go-review.googlesource.com/34936
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
The iOS test harness was recently changed in response to lldb bugs
to replace breakpoints with the SIGUSR2 signal (CL 34926), and to
pass the current directory in the test binary arguments (CL 35152).
Both the signal sending and working directory setup is done from
the go test driver.
However, the new method doesn't work with tests where a C program is
the test driver instead of go test: the current working directory
will not be changed and SIGUSR2 is not raised.
Instead of copying that logic into any C test program, rework the
test harness (again) to move the setup logic to the early runtime
cgo setup code. That way, the harness will run even in the library
build modes.
Then, use the app Info.plist file to pass the working
directory, removing the need to alter the arguments after running.
Finally, use the SIGINT signal instead of SIGUSR2 to avoid
manipulating the signal masks or handlers.
Fixes the testcarchive tests on iOS.
With this CL, both darwin/arm and darwin/arm64 passes all.bash.
This CL replaces CL 34926, CL 35152 as well as the fixup CL
35123 and CL 35255. They are reverted in CLs earlier in the
relation chain.
Change-Id: I8485c7db1404fbd8daa261efd1ea89e905121a3e
Reviewed-on: https://go-review.googlesource.com/36090
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When calling build.Import, normally, an error is returned if the
directory doesn't exist. However, that didn't happen for local
import paths when build.FindOnly ImportMode was used.
This change fixes that, and adds tests. It also makes the error
value more consistent in all scenarios where it occurs.
When calling build.Import with a local import path, the package
can only exist in a single deterministic directory. That makes
it possible verify that directory exists earlier in the path,
and return a "cannot find package" error if it doesn't.
Previously, this occurred only when build.FindOnly ImportMode
was not set. It occurred quite late, after getting past Found
label, to line that calls ctxt.readDir. Doing so would return
an error like "no such file or directory" when the directory
does not exist.
Fixes#17863.
Updates #17888 (relevant issue I ran into while working on this CL).
Change-Id: If6a6996ac6176ac203a88bd31419748f88d89d7c
Reviewed-on: https://go-review.googlesource.com/33158
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reverts commit 593ea3b360.
Replaced by a improved strategy later in the CL relation chain.
Change-Id: I6963e4d1bf38e7028cf545a953e28054d83548
Change-Id: I6963e4d1bf38e7028cf545a953e28054d8354870
Reviewed-on: https://go-review.googlesource.com/36067
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Since switching to SSA, the only remaining use for the Ullman field
was in tracking whether or not an expression contained a function
call. Give it a new name and encode it in our fancy new bitset field.
Passes toolstash-check.
Change-Id: I95b7f9cb053856320c0d66efe14996667e6011c2
Reviewed-on: https://go-review.googlesource.com/37721
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The meaning of Version=1 was overloaded: it was reserved for file name
symbols (to avoid conflicts with non-file name symbols), but was also
used to mean "give me a fresh version number for this symbol."
With the new inlining tree, the same file name symbol can appear in
multiple entries, but each one would become a distinct symbol with its
own version number.
Now, we avoid duplicating symbols by using Version=0 for file name
symbols and we avoid conflicts with other symbols by prefixing the
symbol name with "gofile..".
Change-Id: I8d0374053b8cdb6a9ca7fb71871b69b4dd369a9c
Reviewed-on: https://go-review.googlesource.com/37234
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Without this, literals keep their original source positions through
inlining, which results in strange jumps in line numbers of inlined
function bodies. By copying literals, inlining can update their source
position like other nodes.
Fixes#15453.
Change-Id: Iad5d9bbfe183883794213266dc30e31bab89ee69
Reviewed-on: https://go-review.googlesource.com/37232
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
In order to generate accurate tracebacks, the runtime needs to know the
inlined call stack for a given PC. This creates two tables per function
for this purpose. The first table is the inlining tree (stored in the
function's funcdata), which has a node containing the file, line, and
function name for every inlined call. The second table is a PC-value
table that maps each PC to a node in the inlining tree (or -1 if the PC
is not the result of inlining).
To give the appearance that inlining hasn't happened, the runtime also
needs the original source position information of inlined AST nodes.
Previously the compiler plastered over the line numbers of inlined AST
nodes with the line number of the call. This meant that the PC-line
table mapped each PC to line number of the outermost call in its inlined
call stack, with no way to access the innermost line number.
Now the compiler retains line numbers of inlined AST nodes and writes
the innermost source position information to the PC-line and PC-file
tables. Some tools and tests expect to see outermost line numbers, so we
provide the OutermostLine function for displaying line info.
To keep track of the inlined call stack for an AST node, we extend the
src.PosBase type with an index into a global inlining tree. Every time
the compiler inlines a call, it creates a node in the global inlining
tree for the call, and writes its index to the PosBase of every inlined
AST node. The parent of this node is the inlining tree index of the
call. -1 signifies no parent.
For each function, the compiler creates a local inlining tree and a
PC-value table mapping each PC to an index in the local tree. These are
written to an object file, which is read by the linker. The linker
re-encodes these tables compactly by deduplicating function names and
file names.
This change increases the size of binaries by 4-5%. For example, this is
how the go1 benchmark binary is impacted by this change:
section old bytes new bytes delta
.text 3.49M ± 0% 3.49M ± 0% +0.06%
.rodata 1.12M ± 0% 1.21M ± 0% +8.21%
.gopclntab 1.50M ± 0% 1.68M ± 0% +11.89%
.debug_line 338k ± 0% 435k ± 0% +28.78%
Total 9.21M ± 0% 9.58M ± 0% +4.01%
Updates #19348.
Change-Id: Ic4f180c3b516018138236b0c35e0218270d957d3
Reviewed-on: https://go-review.googlesource.com/37231
Run-TryBot: David Lazar <lazard@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Adds a function for easily accessing the x509.Certificate
of a Server, if there is one. Also adds a helper function
for getting a http.Client suitable for use with the server.
This makes the steps required to test a httptest
TLS server simpler.
Fixes#18411
Change-Id: I2e78fe1e54e31bed9c641be2d9a099f698c7bbde
Reviewed-on: https://go-review.googlesource.com/34639
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The Zero op right after newobject has been removed. But this rule
does not cover Store of constant zero (for SSA-able types). Add
rules to cover Store op as well.
Updates #19027.
Change-Id: I5d2b62eeca0aa9ce8dc7205b264b779de01c660b
Reviewed-on: https://go-review.googlesource.com/36836
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
On amd64p32, PtrSize and RegSize don't agree, and function return
value is aligned with RegSize. Fix this rule. Other architectures
are not affected, where PtrSize and RegSize are the same.
Change-Id: If187d3dfde3dc3b931b8e97db5eeff49a781551b
Reviewed-on: https://go-review.googlesource.com/37720
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Previously the compiler rewrote constant division into OHMUL
operations, but that rewriting was moved to SSA in CL 37015. Now OHMUL
is unused, so we can get rid of it.
Change-Id: Ib6fc7c2b6435510bafb5735b3b4f42cfd8ed8cdb
Reviewed-on: https://go-review.googlesource.com/37750
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
There are two accesses to mheap_.busy that are guarded by checks
against len(mheap_.free). This works because both lists are (and must
be) the same length, but it makes the code less clear. Change these to
use len(mheap_.busy) so the access more clearly parallels the check.
Fixes#18944.
Change-Id: I9bacbd3663988df351ed4396ae9018bc71018311
Reviewed-on: https://go-review.googlesource.com/36354
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently sweep counts the number of allocated objects, computes the
number of free objects from that, then re-computes the number of
allocated objects from that. Simplify and clean this up by skipping
these intermediate steps.
Change-Id: I3ed98e371eb54bbcab7c8530466c4ab5fde35f0a
Reviewed-on: https://go-review.googlesource.com/34935
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently we scan the finalizers queue both during concurrent mark and
during mark termination. This costs roughly 20ns per queued finalizer
and about 1ns per unused finalizer queue slot (allocated queue length
never decreases), which can drive up STW time if there are many
finalizers.
However, we only add finalizers to this queue during sweeping, which
means that the second scan will never find anything new. Hence, we can
fix this by simply not scanning the finalizers queue during mark
termination. This brings the STW time under the 100µs goal even with
1,000,000 queued finalizers.
Fixes#18869.
Change-Id: I4ce5620c66fb7f13ebeb39ca313ce57047d1d0fb
Reviewed-on: https://go-review.googlesource.com/36013
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Since workbuf is now marked go:notinheap, the write barrier-preventing
wrapper type wbufptr is no longer necessary. Remove it.
Change-Id: I3e5b5803a1547d65de1c1a9c22458a38e08549b7
Reviewed-on: https://go-review.googlesource.com/35971
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The compiler's -d flag accepts string-valued flags, but currently only
for SSA debug flags. Extend it to support string values for other
flags. This also makes the syntax somewhat more sane so flag=value and
flag:value now both accept integers and strings.
Change-Id: Idd144d8479a430970cc1688f824bffe0a56ed2df
Reviewed-on: https://go-review.googlesource.com/37345
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
A value is "volatile" if it is a pointer to the argument region
on stack which will be clobbered by function call. This is used
to make sure the value is safe when inserting write barrier calls.
The writebarrier pass can tell whether a value is such a pointer.
Therefore no need to mark it when building SSA and thread this
information through.
Passes "toolstash -cmp" on std.
Updates #17583.
Change-Id: Idc5fc0d710152b94b3c504ce8db55ea9ff5b5195
Reviewed-on: https://go-review.googlesource.com/36835
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This changes the decoder's behaviour when there is stray/extra data
found after an image is decompressed (e.g., data sub-blocks after an LZW
End of Information Code). Instead of raising an error, we silently skip
over such data until we find the end of the image data marked by a Block
Terminator. We skip at most one byte as sample problem GIFs exhibit this
property.
GIFs should not have and do not need such stray data (though the
specification is arguably ambiguous). However GIFs with such properties
have been seen in the wild.
Fixes#16146
Change-Id: Ie7e69052bab5256b4834992304e6ca58e93c1879
Reviewed-on: https://go-review.googlesource.com/37258
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There's no good reason to exclude it and it only makes the code more
complicated and less consistent. Having it in the list provides an
easy way to detect if a package uses operations from package unsafe.
Change-Id: I2f9b0485db0a680bd82f3b93a350b048db3f7701
Reviewed-on: https://go-review.googlesource.com/37694
Reviewed-by: Alan Donovan <adonovan@google.com>
- renamed -a flag to -t
- added -x flag to specify external test files
- improved documentation and usage string
Change-Id: I7c850bd28a10ceaa55d599c22db07774147aa3f7
Reviewed-on: https://go-review.googlesource.com/37656
Reviewed-by: Alan Donovan <adonovan@google.com>
The old code may have reported different errors given an
erroneous package depending on the order in which files
were parsed concurrently. The new code always reports
errors in "file order", independent of processing order.
Also:
- simplified parsing code and internal concurrency control
- removed -seq flag which didn't really add useful functionality
Change-Id: I18e24e630f458f2bc107a7b83926ae761d63c334
Reviewed-on: https://go-review.googlesource.com/37655
Reviewed-by: Alan Donovan <adonovan@google.com>
If I put a 10 millisecond sleep at testHookWaitResLoop, before the big
select in (*persistConn).roundTrip, two flakes immediately started
happening, TestTransportBodyReadError (#19231) and
TestTransportPersistConnReadLoopEOF.
The problem was that there are many ways for a RoundTrip call to fail
(errors reading from Request.Body while writing the response, errors
writing the response, errors reading the response due to server
closes, errors due to servers sending malformed responses,
cancelations, timeouts, etc.), and many of those failures then tear
down the TCP connection, causing more failures, since there are always
at least three goroutines involved (reading, writing, RoundTripping).
Because the errors were communicated over buffered channels to a giant
select, the error returned to the caller was a function of which
random select case was called, which was why a 10ms delay before the
select brought out so many bugs. (several fixed in my previous CLs the past
few days).
Instead, track the error explicitly in the transportRequest, guarded
by a mutex.
In addition, this CL now:
* differentiates between the two ways writing a request can fail: the
io.Copy reading from the Request.Body or the io.Copy writing to the
network. A new io.Reader type notes read errors from the
Request.Body. The read-from-body vs write-to-network errors are now
prioritized differently.
* unifies the two mapRoundTripErrorFromXXX methods into one
mapRoundTripError method since their logic is now the same.
* adds a (*Request).WithT(*testing.T) method in export_test.go, usable
by tests, to call t.Logf at points during RoundTrip. This is disabled
behind a constant except when debugging.
* documents and deflakes TestClientRedirectContext
I've tested this CL with high -count values, with/without -race,
with/without delays before the select, etc. So far it seems robust.
Fixes#19231 (TestTransportBodyReadError flake)
Updates #14203 (source of errors unclear; they're now tracked more)
Updates #15935 (document Transport errors more; at least understood more now)
Change-Id: I3cccc3607f369724b5344763e35ad2b7ea415738
Reviewed-on: https://go-review.googlesource.com/37495
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Using GetClientCertificate with the http client is currently completely
broken because inside the transport we clone the tls.Config and pass it
off to the tls.Client. Since tls.Config.Clone() does not pass forward
the GetClientCertificate field, GetClientCertificate is ignored in this
context.
Fixes#19264
Change-Id: Ie214f9f0039ac7c3a2dab8ffd14d30668bdb4c71
Signed-off-by: Mike Danese <mikedanese@google.com>
Reviewed-on: https://go-review.googlesource.com/37541
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Now that vet loads from source,
fmt can always be correctly resolved,
so the fmt.Formatter type is always available,
so we can reinstate the check.
Change-Id: I17f0c7fccf6960c9415de8774b15123135d57be8
Reviewed-on: https://go-review.googlesource.com/37692
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This simplifies the code and speeds it up.
It also allows us to eliminate some other TODOs;
those will come in a follow-up CL.
Running for the host platform, before:
real 0m9.907s
user 0m14.566s
sys 0m1.058s
After:
real 0m7.841s
user 0m12.339s
sys 0m0.572s
Running for a single non-host platform, before:
real 0m8.784s
user 0m15.451s
sys 0m3.445s
After:
real 0m7.681s
user 0m12.122s
sys 0m0.577s
Running for all platforms, before:
real 7m4.480s
user 8m43.398s
sys 1m15.683s
After:
real 4m37.596s
user 7m30.729s
sys 0m18.533s
It also makes my laptop considerably more
responsive while running for all platforms.
Change-Id: I748689fea0d2d4ef61aca2ce5524d03d8fafa5ca
Reviewed-on: https://go-review.googlesource.com/37691
Reviewed-by: Rob Pike <r@golang.org>
Instead of constructing the importer in init, do it lazily as needed.
This lets us select the importer using a command line flag.
The addition of the command line flag will come in a follow-up CL.
Change-Id: Ieb3a5f01a34fb5bd220a95086daf5d6b37e83bb5
Reviewed-on: https://go-review.googlesource.com/37669
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There's no guarantee that all in-progress mark assists will finish
before the trace does. Don't crash if that happens.
I haven't added a test because there's quite a bit of ceremony involved
and the bug is fairly straightforward.
Change-Id: Ia1369a8e2260fc6a328ad204a1eab1063d2e2c90
Reviewed-on: https://go-review.googlesource.com/37540
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current StdSizes most closely matches
the gc compiler, and the uses I know of that care
which compiler the sizes are for are all for
the gc compiler, so call the existing
implementation "gc".
Updates #17586Fixes#19351
Change-Id: I2bdd694518fbe233473896321a1f9758b46ed79b
Reviewed-on: https://go-review.googlesource.com/37666
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The original analysis of the Go corpus assumed that these
stripped monotonic time. During the design discussion we
decided to try not stripping monotonic time here, but existing
code works better if we do.
See the discussion on golang.org/issue/18991 for more details.
For #18991.
Change-Id: I04d355ffe56ca0317acdd2ca76cb3033c277f6d1
Reviewed-on: https://go-review.googlesource.com/37542
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test assumed that passing an unknown option to the Fortran
compiler would cause the compiler to fail. Unfortunately it appears
that some succeed. It's irrelevant to the actual test, which is
verifying that the flag was indeed passed.
Fixes#19080.
Change-Id: Ib9e89447a2104e4742f4b98938373fc2522772aa
Reviewed-on: https://go-review.googlesource.com/37658
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Make sure that if we encode an explicit base register, we print it.
That will ensure that if we make an Addr with an auto variable but
a base that isn't SP, then it will be obvious from the disassembly.
Update #19184
Change-Id: If5556a5183f344d719ec7197aa935a0166061e6f
Reviewed-on: https://go-review.googlesource.com/37255
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This adds the necessary changes so that atomics are treated as
intrinsics on ppc64x.
The implementations of And8 and Or8 require power8 for
both ppc64 and ppc64le. This is a new requirement
for ppc64.
Fixes#8739
Change-Id: Icb85e2755a49166ee3652668279f6ed5ebbca901
Reviewed-on: https://go-review.googlesource.com/36832
Reviewed-by: Keith Randall <khr@golang.org>
Previously the code didn't check for extra data after the final five
dashes of the ending line of a PEM block.
Fixes#19147Fixes#7042
Change-Id: Idaab2390914a2bed8c2c12b14dfb6d68233fdfec
Reviewed-on: https://go-review.googlesource.com/37147
Reviewed-by: Adam Langley <agl@golang.org>
Some debugging code was recently added to:
1) provide more detail for the stale reason when it is
determined that a package is stale
2) provide file and package time and date information when
it is determined that runtime.a is stale
This backs out those those debugging messages.
Fixes#19116
Change-Id: I8dd0cbe29324820275b481d8bbb78ff2c5fbc362
Reviewed-on: https://go-review.googlesource.com/37382
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes a change in the SSA code generated for OpPPC64Xf2i64
and OpPPC64Xi2f64 to use register based instructions to convert
between float and integer. This will require at least power8.
Currently the conversion is done by storing to and loading
from memory, which is more expensive.
This improves some of the math functions:
BenchmarkExp-128 74.1 66.8 -9.85%
BenchmarkExpGo-128 87.4 66.3 -24.14%
BenchmarkExp2-128 72.2 64.3 -10.94%
BenchmarkExp2Go-128 74.3 65.9 -11.31%
BenchmarkLgamma-128 51.0 39.7 -22.16%
BenchmarkLog-128 42.9 40.6 -5.36%
BenchmarkLogb-128 11.5 9.16 -20.35%
BenchmarkLog1p-128 38.9 36.2 -6.94%
BenchmarkSin-128 29.5 23.7 -19.66%
BenchmarkTan-128 32.8 27.4 -16.46%
Fixes#18922
Change-Id: I8e1cf14d3880d7cd720dc5188dd174cba1f7fef7
Reviewed-on: https://go-review.googlesource.com/36725
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
This was a t.Parallel test but it was using the global DefaultTransport
via the global Get func.
Use a private Transport that won't have its CloseIdleConnections etc
methods called by other tests.
(I hit this flake myself while testing a different change.)
Change-Id: If0665e3e8580ee198f8e5f3079bfaea55f036eca
Reviewed-on: https://go-review.googlesource.com/37624
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The run1 call removed in golang.org/cl/36990 was necessary to
initialize the duration of the benchmark. With it gone, the math in
launch() starts from 100. This doesn't work out well for second-long
benchmark methods. Put it back.
Updates #18815
Change-Id: I461f3466c805d0c61124a2974662f7ad45335794
Reviewed-on: https://go-review.googlesource.com/37530
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
The builtin runtime package definitions intentionally diverge from the
actual runtime package's, but this only works as long as they never
overlap.
To make it easier to expand the builtin runtime package, this CL now
loads their definitions into a logically separate "go.runtime"
package. By resetting the package's Prefix field to "runtime", any
references to builtin definitions will still resolve against the real
package runtime.
Fixes#14482.
Passes toolstash -cmp.
Change-Id: I539c0994deaed4506a331f38c5b4d6bc8c95433f
Reviewed-on: https://go-review.googlesource.com/37538
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Link.Plists never contained more than one Plist, and sometimes none.
Passing around the Plist being worked on is straightforward and makes
the data flow easier to follow.
Change-Id: I79cb30cb2bd3d319fdbb1dfa5d35b27fcb748e5c
Reviewed-on: https://go-review.googlesource.com/37169
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Removes an extra function call for TrailingZeroes and thus may
increase chances for inlining.
Change-Id: Iefd8d4402dc89b64baf4e5c865eb3dadade623af
Reviewed-on: https://go-review.googlesource.com/37613
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Nobody intends to have duplicates anyway because it's so undefined
and everything handles it so poorly.
Removing duplicates automatically simplifies code and makes existing
code do what people already expect.
Fixes#12868
Change-Id: I95eeba8c59ff94d0f018012a6f4e031aaabfd5d9
Reviewed-on: https://go-review.googlesource.com/37586
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The new Map implementation introduced in golang.org/cl/33201
did not differentiate if an invalid UTF-8 sequence was decoded
or the RuneError rune. It would therefore always advance by
3 bytes (which is the length of the RuneError rune) instead
of 1 for an invalid sequences. This cl adds a check to correctly
determine the length of bytes needed to advance to the next rune.
Fixes#19330.
Change-Id: I1e7f9333f3ef6068ffc64015bb0a9f32b0b7111d
Reviewed-on: https://go-review.googlesource.com/37597
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
There's no need to use @block rules, as canMergeLoad makes sure that
the load and op are already in the same block.
With no @block needed, we also don't need to set the type explicitly.
It can just be inherited from the op being rewritten.
Noticed while working on #19284.
Change-Id: Ied8bcc8058260118ff7e166093112e29107bcb7e
Reviewed-on: https://go-review.googlesource.com/37585
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
SizesFor returns a Sizes implementation for a supported architecture.
Use functionality in srcimporter.
Change-Id: I197e641b419c678030dfaab5c5b8c569fd0410f3
Reviewed-on: https://go-review.googlesource.com/37583
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
runtime.memclr* functions have signatures
func memclrNoHeapPointers(ptr unsafe.Pointer, n uintptr)
func memclrHasPointers(ptr unsafe.Pointer, n uintptr)
Update compiler's copy. Also teach gc/mkbuiltin.go to handle
unsafe.Pointer. The import statement and its support is not
really necessary, but just to make it look like real Go code.
Fixes#19185.
Change-Id: I251d02571fde2716d4727e31e04d56ec04b6f22a
Reviewed-on: https://go-review.googlesource.com/37257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This is an inconsequential consequence of updating
math/big to use math/bits.
Better would be to teach the vet shift test
to size int/uint/uintptr to the platform in use,
eliminating the whole category of "might be too small".
Filed #19321 for that.
Change-Id: I7e0b837bd329132d7a564468c18502dd2e724fc6
Reviewed-on: https://go-review.googlesource.com/37576
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes the vetall builder friendly to auto-sharding by the build
coordinator.
Change-Id: I0893f5051ec90e7a6adcb89904ba08cd2d590549
Reviewed-on: https://go-review.googlesource.com/37572
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Explcitly block fused multiply-add pattern matching when a cast is used
after the multiplication, for example:
- (a * b) + c // can emit fused multiply-add
- float64(a * b) + c // cannot emit fused multiply-add
float{32,64} and complex{64,128} casts of matching types are now kept
as OCONV operations rather than being replaced with OCONVNOP operations
because they now imply a rounding operation (and therefore aren't a
no-op anymore).
Operations (for example, multiplication) on complex types may utilize
fused multiply-add and -subtract instructions internally. There is no
way to disable this behavior at the moment.
Improves the performance of the floating point implementation of
poly1305:
name old speed new speed delta
64 246MB/s ± 0% 275MB/s ± 0% +11.48% (p=0.000 n=10+8)
1K 312MB/s ± 0% 357MB/s ± 0% +14.41% (p=0.000 n=10+10)
64Unaligned 246MB/s ± 0% 274MB/s ± 0% +11.43% (p=0.000 n=10+10)
1KUnaligned 312MB/s ± 0% 357MB/s ± 0% +14.39% (p=0.000 n=10+8)
Updates #17895.
Change-Id: Ia771d275bb9150d1a598f8cc773444663de5ce16
Reviewed-on: https://go-review.googlesource.com/36963
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The checkAVX2 test doesn't appear to be correct,
because it always returns the value of support_bmi2,
even if the value of support_avx2 is false.
Consequently, checkAVX2 always returns true, as long
as BMI2 is supported, even if AVX2 is not supported.
We change checkAVX2 to return false when support_avx2
is false.
Fixes#19316.
Change-Id: I2ec9dfaa09f4b54c4a03d60efef891b955d60578
Reviewed-on: https://go-review.googlesource.com/37590
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
A type conversion inserted between MOVD{LT,LE,GT,GE,EQ,NE} and CMPWconst
by CL 36256 broke the rewrite rule designed to merge the two.
This results in simple for loops (e.g. for i := 0; i < N; i++ {})
emitting two comparisons instead of one, plus a conditional move.
This CL explicitly types the input to CMPWconst so that the type conversion
can be omitted. It also adds a test to check that conditional moves aren't
emitted for loops with 'less than' conditions (i.e. i < N) on s390x.
Fixes#19227.
Change-Id: Ia39e806ed723791c3c755951aef23f957828ea3e
Reviewed-on: https://go-review.googlesource.com/37334
Reviewed-by: Keith Randall <khr@golang.org>
Changes made:
* Adjust the documented form for a URL to make it more obvious what
happens when the scheme is missing.
* Remove references to Go1.5. We are sufficiently far along enough
that this distinction no longer matters.
* Remove the "Opaque" example which provides a hacky and misleading
use of the Opaque field. This workaround is no longer necessary
since RawPath was added in Go1.5 and the obvious approach just works:
// The raw string "/%2f/" will be sent as expected.
req, _ := http.NewRequest("GET", "https://example.com/%2f/")
Fixes#18824
Change-Id: Ie33d27222e06025ce8025f8a0f04b601aaee1513
Reviewed-on: https://go-review.googlesource.com/36127
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The comments in cmd/internal/obj/funcdata.go are identical to the
comments in runtime/funcdata.h, but the majority of the definitions
they refer to don't apply to Go sources and have been stripped out of
funcdata.go.
Remove these stale comments from funcdata.go and clean up the
references to other copies of the PCDATA and FUNCDATA indexes.
Change-Id: I5d6e49a6e586cc9aecd7c3ce1567679f2a605884
Reviewed-on: https://go-review.googlesource.com/37330
Reviewed-by: Keith Randall <khr@golang.org>
If cgo is not available, parse /etc/group in Go to find the name/gid
we need. This does not consult the Network Information System (NIS),
/etc/nsswitch.conf or any other libc extensions to /etc/group.
Fixes#18102.
Change-Id: I6ae4fe0e2c899396c45cdf243d5483113932657c
Reviewed-on: https://go-review.googlesource.com/33713
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is the escape analysis analog of CL 37499.
Fixes#12397Fixes#16871
The only "moved to heap" decisions eliminated by this
CL in std+cmd are:
cmd/compile/internal/gc/const.go:1514: moved to heap: ac
cmd/compile/internal/gc/const.go:1515: moved to heap: bd
cmd/compile/internal/gc/const.go:1516: moved to heap: bc
cmd/compile/internal/gc/const.go:1517: moved to heap: ad
cmd/compile/internal/gc/const.go:1546: moved to heap: ac
cmd/compile/internal/gc/const.go:1547: moved to heap: bd
cmd/compile/internal/gc/const.go:1548: moved to heap: bc
cmd/compile/internal/gc/const.go:1549: moved to heap: ad
cmd/compile/internal/gc/const.go:1550: moved to heap: cc_plus
cmd/compile/internal/gc/export.go:162: moved to heap: copy
cmd/compile/internal/gc/mpfloat.go:66: moved to heap: b
cmd/compile/internal/gc/mpfloat.go:97: moved to heap: b
Change-Id: I0d420b69c84a41ba9968c394e8957910bab5edea
Reviewed-on: https://go-review.googlesource.com/37508
Reviewed-by: David Chase <drchase@google.com>
Keep liveness bit vectors as simple live-variable vectors during
liveness analysis. We can defer expanding them into runtime heap
bitmaps until we're actually writing out the symbol data, and then we
only need temporary memory to expand one bitmap at a time.
This is logically cleaner (e.g., we no longer depend on stack frame
layout during analysis) and saves a little bit on allocations.
name old alloc/op new alloc/op delta
Template 41.4MB ± 0% 41.3MB ± 0% -0.28% (p=0.000 n=60+60)
Unicode 32.6MB ± 0% 32.6MB ± 0% -0.11% (p=0.000 n=59+60)
GoTypes 119MB ± 0% 119MB ± 0% -0.35% (p=0.000 n=60+59)
Compiler 483MB ± 0% 481MB ± 0% -0.47% (p=0.000 n=59+60)
name old allocs/op new allocs/op delta
Template 381k ± 1% 380k ± 1% -0.32% (p=0.000 n=60+60)
Unicode 325k ± 1% 325k ± 1% ~ (p=0.867 n=60+60)
GoTypes 1.16M ± 0% 1.15M ± 0% -0.40% (p=0.000 n=60+59)
Compiler 4.22M ± 0% 4.19M ± 0% -0.61% (p=0.000 n=59+60)
Passes toolstash -cmp.
Change-Id: I8175efe55201ffb5017f79ae6cb90df03f1b7e99
Reviewed-on: https://go-review.googlesource.com/37458
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Constant evaluation provides some rudimentary
knowledge of dead code at inlining decision time.
Use it.
This CL addresses only dead code inside if statements.
For statements are never inlined anyway,
and dead code inside for statements is rare.
Analyzing switch statements is worth doing,
but it is more complicated, since we would have
to evaluate each case; leave it for later.
Fixes#9274
After this CL, the following functions in std+cmd
can be newly inlined:
cmd/internal/obj/x86/asm6.go:3122: can inline subreg
cmd/vendor/golang.org/x/arch/x86/x86asm/decode.go:172: can inline instPrefix
cmd/vendor/golang.org/x/arch/x86/x86asm/decode.go:202: can inline truncated
go/constant/value.go:234: can inline makeFloat
go/types/labels.go:52: can inline (*block).insert
math/big/float.go:231: can inline (*Float).Sign
math/bits/bits.go:57: can inline OnesCount
net/http/server.go:597: can inline (*Server).newConn
runtime/hashmap.go:1165: can inline reflect_maplen
runtime/proc.go:207: can inline os_beforeExit
runtime/signal_unix.go:55: can inline init.5
runtime/stack.go:1081: can inline gostartcallfn
Change-Id: I4c92fb96aa0c3d33df7b3f2da548612e79b56b5b
Reviewed-on: https://go-review.googlesource.com/37499
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If the caller passes a large number to Profile.Add,
the list of pcs is empty, which results in junk
(a nil pc) being recorded. Check for that explicitly,
and replace such stack traces with a lostProfileEvent.
Fixes#18836.
Change-Id: I99c96aa67dd5525cd239ea96452e6e8fcb25ce02
Reviewed-on: https://go-review.googlesource.com/36891
Reviewed-by: Russ Cox <rsc@golang.org>
In another CL, I'll add a pure Go implementation of lookupGroup and
lookupGroupId in lookup_unix.go, but attempting that in one CL makes
the diff too difficult to read.
Updates #18102.
Change-Id: If8e26cee5efd30385763430f34304c70165aef32
Reviewed-on: https://go-review.googlesource.com/37497
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Follow-up to CL 37270.
This considerably reduces the time to run the test.
Before:
real 0m7.638s
user 0m14.341s
sys 0m2.244s
After:
real 0m4.867s
user 0m7.107s
sys 0m1.842s
Change-Id: I8837a5da0979a1c365e1ce5874d81708249a4129
Reviewed-on: https://go-review.googlesource.com/37461
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
New special case for booleans and byte-sized integer types
converted to interfaces needs to ensure that the operand is
not too complex, if it were to appear in a parameter list
for example.
Added test, also increased the recursive node dump depth to
a level that was actually useful for an actual bug.
Fixes#19275.
Change-Id: If36ac3115edf439e886703f32d149ee0a46eb2a5
Reviewed-on: https://go-review.googlesource.com/37470
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The number of open file descriptors reported by lsof is unreliable
because it depends on whether the parent process (the test) closed
the file descriptors it passed into the child process (lsof) before
lsof runs.
Reading /proc/self/fd directly on Linux appears to be much more
reliable and still detects any file descriptor leaks originating
from attempting to run an executable that cannot be found (issue
#5071). If /proc/self/fd is not available (e.g. on Darwin) then we
fall back to lsof and tolerate small differences in open file
descriptor counts.
Fixes#19243.
Change-Id: I052b0c129e609010f1083e43a9911cba154117bf
Reviewed-on: https://go-review.googlesource.com/37343
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add Set3 function to complement existing Set1 and Set2 functions.
Consistently use Set1, Set2 and Set3 for []*Node instead of Set where applicable.
Add SetFirst and SetSecond for setting elements of []*Node to mirror
First and Second for accessing elements in []*Node.
Replace uses of Index by First and Second and
SetIndex with SetFirst and SetSecond where applicable.
Passes toolstash -cmp.
Change-Id: I8255aae768cf245c8f93eec2e9efa05b8112b4e5
Reviewed-on: https://go-review.googlesource.com/37430
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TestAssembly was very slow, leading to it being skipped by default.
This is not surprising, it separately invoked the compiler and
parsed the result many times.
Now the test assembles one source file for arch/os combination,
containing the relevant functions.
Tests for each arch/os run in parallel.
Now the test runs approximately 10x faster on my Intel(R) Core(TM)
i5-6600 CPU @ 3.30GHz.
Fixes#18966
Change-Id: I45ab97630b627a32e17900c109f790eb4c0e90d9
Reviewed-on: https://go-review.googlesource.com/37270
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This should help on the openbsd systems where the test mostly passes.
I don't expect it to help on s390x where the test reliably fails.
But it should give more information when it does fail.
For #19276.
Change-Id: I496c291f2b4b0c747b8dd4315477d87d03010059
Reviewed-on: https://go-review.googlesource.com/37348
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The profiles are self-contained now.
Check that they work by themselves in the tests that invoke pprof,
but also keep checking that the old command lines work.
Change-Id: I24c74b5456f0b50473883c3640625c6612f72309
Reviewed-on: https://go-review.googlesource.com/37166
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
The existing code builds a full profile in memory.
Then it translates that profile into a data structure (in memory).
Then it marshals that data structure into a protocol buffer (in memory).
Then it gzips that marshaled form into the underlying writer.
So there are three copies of the full profile data in memory
at the same time before we're done. This is obviously dumb.
This CL implements a fully streaming conversion from
the original in-memory profile to the underlying writer.
There is now only one copy of the profile in memory.
For the non-CPU profiles, this is optimal, since we have to
have a full copy in memory to start with.
For the CPU profiles, we could still try to bound the profile
size stored in memory and stream fragments out during
the actual profiling, as Go 1.7 did (with a simpler format),
but so far that hasn't been necessary.
Change-Id: Ic36141021857791bf0cd1fce84178fb5e744b989
Reviewed-on: https://go-review.googlesource.com/37164
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds math/bits as a new dependency of math/big.
- use bits.LeadingZeroes instead of local implementation
(they are identical, so there's no performance loss here)
- leave other functionality local (ntz, bitLen) since there's
faster implementations in math/big at the moment
Change-Id: I1218aa8a1df0cc9783583b090a4bb5a8a145c4a2
Reviewed-on: https://go-review.googlesource.com/37141
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Import the github.com/google/pprof and github.com/ianlancetaylor/demangle
packages, without modification.
Build the golang version of pprof from cmd/pprof/pprof.go
by importing the packages from src/cmd/vendot/github.com/google/pprof
The versions upstreamed are:
github.com/ianlancetaylor/demangle 4883227f66371e02c4948937d3e2be1664d9be38
github.com/google/pprof 7eb5ba977f28f2ad8dd5f6bb82cc9b454e123cdc
Update misc/nacl/testzip.proto for new tests.
Change-Id: I076584856491353607a3b98b67d0ca6838be50d6
Reviewed-on: https://go-review.googlesource.com/36798
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Wait a short period between trying commands. Many commands
will return a non-zero exit code if the browser couldn't be launched.
For example, google-chrome returns quickly with a non-zero
exit code in a headless environment.
Updates #19131.
Change-Id: I0ae5356dd4447969d9e216615449cead7a8fd5c9
Reviewed-on: https://go-review.googlesource.com/37391
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
CL 35562 substituted zerobase for the pointer for
interfaces containing zero-sized values.
However, it failed to evaluate the zero-sized value
expression for side-effects. Fix that.
The other similar interface value optimizations
are not affected, because they all actually use the
value one way or another.
Fixes#19246
Change-Id: I1168a99561477c63c29751d5cd04cf81b5ea509d
Reviewed-on: https://go-review.googlesource.com/37395
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The new syntax tree introduced with 1.8 represents send statements
(ch <- x) as statements; the old syntax tree represented them as
expressions (and parsed them as such) but complained if they were
used in expression context. As a consequence, some of the errors
that in the past were of the form "ch <- x used as value" now look
like "unexpected <- ..." because a "<-" is not valid according to
Go syntax in those situations. Accept the new error message.
Also: Fine-tune handling of misformed for loop headers.
Also: Minor cleanups/better comments.
Fixes#17590.
Change-Id: Ia541dea1f2f015c1b21f5b3ae44aacdec60a8aba
Reviewed-on: https://go-review.googlesource.com/37386
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Set $GOPATH to a semantically valid, non-empty string that cannot
conflict with $GOROOT to avoid false test failures that occur when
$GOROOT resides under $GOPATH. Unsetting GOPATH is no longer viable
as Go now defines a default $GOPATH that may conflict with $GOROOT.
Fixes#19237
Change-Id: I376a2ad3b18e9c4098211b988dde7e76bc4725d2
Reviewed-on: https://go-review.googlesource.com/37396
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old hash table was a place holder that allocates memory
during every lookup for key generation, even for keys that hit
in the the table.
Change-Id: I4f601bbfd349f0be76d6259a8989c9c17ccfac21
Reviewed-on: https://go-review.googlesource.com/37163
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This doesn't change the functionality of the current code,
but it sets us up for exporting the profiling labels into the profile.
The old code had a hash table of profile samples maintained
during the signal handler, with evictions going into a log.
The new code just logs every sample directly, leaving the
hash-based deduplication to an ordinary goroutine.
The new code also avoids storing the entire profile in two
forms in memory, an unfortunate regression introduced
when binary profile support was added. After this CL the
entire profile is only stored once in memory. We'd still like
to get back down to storing it zero times (streaming it to
the underlying io.Writer).
Change-Id: I0893a1788267c564aa1af17970d47377b2a43457
Reviewed-on: https://go-review.googlesource.com/36712
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
It's common for some goroutines to loop calling time.Sleep.
Allocate once per goroutine, not every time.
This comes up in runtime/pprof's background reader.
Change-Id: I89d17dc7379dca266d2c9cd3aefc2382f5bdbade
Reviewed-on: https://go-review.googlesource.com/37162
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Some field-lists (especially in generated code) can be excessively long.
In the one-line printout, it does not make sense to print all elements
of the list if line-wrapping causes the "one-line" to become multi-line.
// Before:
var LongLine = newLongLine("someArgument1", "someArgument2", "someArgument3", "someArgument4", "someArgument5", "someArgument6", "someArgument7", "someArgument8")
// After:
var LongLine = newLongLine("someArgument1", "someArgument2", "someArgument3", "someArgument4", ...)
Change-Id: I4bbbe2dbd1d7be9f02d63431d213088c3dee332c
Reviewed-on: https://go-review.googlesource.com/36031
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The loop-A-encloses-loop-C code did not properly handle the
case where really C was already known to be enclosed by B,
and A was nearest-outer to B, not C.
Fixes#19217.
Change-Id: I755dd768e823cb707abdc5302fed39c11cdb34d4
Reviewed-on: https://go-review.googlesource.com/37340
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The existing CPU profiling buffer is a slice of uintptr, but we want to
start including profiling label data in the profiles, and those labels need
to be pointers in order to let them describe rich information.
This CL implements a new profBuf type that holds both a slice of uint64
for data and a slice of unsafe.Pointer for profiling labels (aka tags).
Making the runtime use these buffers will happen in followup CLs.
Change-Id: I9ff16b532d8edaf4ce0cbba1098229a561834efc
Reviewed-on: https://go-review.googlesource.com/36713
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
xdg-open's man page says:
> xdg-open is for use inside a desktop session only.
Use the DISPLAY environment variable to detect this.
Updates #19131.
Change-Id: I3926b3e1042393939b2ec6aacd9b63ac8192df3b
Reviewed-on: https://go-review.googlesource.com/37390
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When running on the host platform,
the standard library has almost certainly already been built.
However, all other platforms will probably need building.
Use the new -dolinkobj=false flag to cmd/compile
to only build the export data instead of doing a full compile.
Having partial object files could be confusing for people
doing subsequent cross-compiles, depending on what happens with #18369.
However, cmd/vet/all will mainly be run by builders
and core developers, who are probably fairly well-placed
to handle any such confusion.
This reduces the time on my machine for a cold run of
'go run main.go -all' by almost half:
benchmark old ns/op new ns/op delta
BenchmarkVetAll 240670814551 130784517074 -45.66%
Change-Id: Ieb866ffb2cb714b361b0a6104077652f8eacd166
Reviewed-on: https://go-review.googlesource.com/37385
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When set to false, the -dolinkobj flag instructs the compiler
not to generate or emit linker information.
This is handy when you need the compiler's export data,
e.g. for use with go/importer,
but you want to avoid the cost of full compilation.
This must be used with care, since the resulting
files are unusable for linking.
This CL interacts with #18369,
where adding gcflags and ldflags to buildid has been mooted.
On the one hand, adding gcflags would make safe use of this
flag easier, since if the full object files were needed,
a simple 'go install' would fix it.
On the other hand, this would mean that
'go install -gcflags=-dolinkobj=false' would rebuild the object files,
although any existing object files would probably suffice.
Change-Id: I8dc75ab5a40095c785c1a4d2260aeb63c4d10f73
Reviewed-on: https://go-review.googlesource.com/37384
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Replaces pairs of shifts with sign/zero extension where possible.
For example:
(uint64(x) << 32) >> 32 -> uint64(uint32(x))
Reduces the execution time of the following code by ~4.5% on s390x:
for i := 0; i < N; i++ {
x += (uint64(i)<<32)>>32
}
Change-Id: Idb2d56f27e80a2e1366bc995922ad3fd958c51a7
Reviewed-on: https://go-review.googlesource.com/37292
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
ExampleSliceStable echoes the sort.Slice example, to demonstrate sorting
on two fields together preserving order between sorts.
Change-Id: I8afc20c0203991bfd57260431eda73913c165355
Reviewed-on: https://go-review.googlesource.com/37196
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix the encoding of the SH field for rldimi.
The SH field of rldimi is 6-bit wide and it is not contiguous in the instruction.
Bits 0-4 are placed in bit fields 16-20 in the instruction, while bit 5 is
placed in bit field 30. The current implementation does not consider this and,
therefore, any SH field between 32 and 63 are encoded wrongly in the instruciton.
Change-Id: I4d25a0a70f4219569be0e18160dea5505bd7fff0
Reviewed-on: https://go-review.googlesource.com/37350
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Removes init function from the math package.
Allows stripping of arrays with pre-computed values
used for Pow10 from binaries if Pow10 is not used.
cmd/go shrinks by 128 bytes.
Fixed small values like 10**-323 being 0 instead of 1e-323.
Overall precision is increased but still not as good as
predefined constants for some inputs.
Samples:
Pow10(208)
before: 1.0000000000000006662e+208
after: 1.0000000000000000959e+208
Pow10(202)
before 1.0000000000000009895e+202
after 1.0000000000000001193e+202
Pow10(60)
before 1.0000000000000001278e+60
after 0.9999999999999999494e+60
Pow10(-100)
before 0.99999999999999938551e-100
after 0.99999999999999989309e-100
Pow10(-200)
before 0.9999999999999988218e-200
after 1.0000000000000001271e-200
name old time/op new time/op delta
Pow10Pos-4 44.6ns ± 2% 1.2ns ± 1% -97.39% (p=0.000 n=19+17)
Pow10Neg-4 50.8ns ± 1% 4.1ns ± 2% -92.02% (p=0.000 n=17+19)
Change-Id: If094034286b8ac64be3a95fd9e8ffa3d4ad39b31
Reviewed-on: https://go-review.googlesource.com/36331
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#19012.
Fallback to return signatures without detailed types.
These error message will be of the form of issue:
* https://golang.org/issues/4215
* https://golang.org/issues/6750
So:
func f(x int, y uint) {
return x > y
}
f(10, "a" < 3)
will give errors:
too many errors to return
too many arguments in call to f
instead of:
too many errors to return
have (<T>)
want ()
too many arguments in call to f
have (number, <T>)
want (number, number)
Change-Id: I680abc7cdd8444400e234caddf3ff49c2d69f53d
Reviewed-on: https://go-review.googlesource.com/36806
Reviewed-by: Robert Griesemer <gri@golang.org>
Test finite negative x with Y0(-1), Y1(-1), Yn(2,-1), Yn(-3,-1).
Also test the special case Yn(0,0).
Fixes#19130.
Change-Id: I95f05a72e1c455ed8ddf202c56f4266f03f370fd
Reviewed-on: https://go-review.googlesource.com/37310
Reviewed-by: Robert Griesemer <gri@golang.org>
It could have been defined the other way, but since the behavior has
been unspecified, this is the conservative approach for people writing
different implementations of the Context interface.
Change-Id: I7334a4c674bc2330cca6874f7cac1eb0eaea3cff
Reviewed-on: https://go-review.googlesource.com/37375
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Keith pointed out that these rules should zero extend during the review
of CL 36845. In practice the generic rules are responsible for eliminating
most load-hit-stores and they do not have this problem. When the s390x
rules are triggered any cast following the elided load-hit-store is
kept because of the sequence the rules are applied in (i.e. the load is
removed before the zero extension gets a chance to be merged into the load).
It is therefore not clear that this issue results in any functional bugs.
This CL includes a test, but it only tests the generic rules currently.
Change-Id: Idbc43c782097a3fb159be293ec3138c5b36858ad
Reviewed-on: https://go-review.googlesource.com/37154
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Added a flag to generic and various architectures' atomic
operations that are judged to have observable side effects
and thus cannot be dead-code-eliminated.
Test requires GOMAXPROCS > 1 without preemption in loop.
Fixes#19182.
Change-Id: Id2230031abd2cca0bbb32fd68fc8a58fb912070f
Reviewed-on: https://go-review.googlesource.com/37333
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The gcdata field only records ptrdata entries, not size entries.
Also fix an obsolete comment: the enforced limit on pointer maps is
now 2048 bytes, not 16 bytes.
I wasn't able to contruct a test case for this. It would require
building a type whose size is greater than 64 bytes but less than 128
bytes, with at least one pointer in first 64 bytes but no pointers
after the first 64 bytes, such that the linker arranges for the one
byte gcbits value to be immediately followed by a non-zero byte.
Change-Id: I9118d3e4ec6f07fd18b72f621c1e5f4fdfe5f80b
Reviewed-on: https://go-review.googlesource.com/37142
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The definition of writeBarrier in the runtime was changed in CL 22855
to include padding. Update the definition built in to the compiler to match.
This doesn't affect the generated code, as the compiler sets the type
to use anyhow, but having them be different seems clearly wrong.
Change-Id: I8eac05bf70a424a0b2338ba5e9e41af231316de0
Reviewed-on: https://go-review.googlesource.com/37377
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For compatibility with math/bits uint operations.
When math/big was written originally, the Go compiler used 32bit
int/uint values even on a 64bit machine. uintptr was the type that
represented the machine register size. Now, the int/uint types are
sized to the native machine register size, so they are the natural
machine Word type.
On most machines, the size of int/uint correspond to the size of
uintptr. On platforms where uint and uintptr have different sizes,
this change may lead to performance differences (e.g., amd64p32).
Change-Id: Ief249c160b707b6441848f20041e32e9e9d8d8ca
Reviewed-on: https://go-review.googlesource.com/37372
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The type of the OffPtr should be consistent with the type of the
following load. Before this CL it was typed as a pointer to the
struct.
Fixes#19164.
Change-Id: Ibcdec4411c6f719702f76f8dba3cce8691bfbe0c
Reviewed-on: https://go-review.googlesource.com/37254
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
doEncryptKeyAsm is tail-called from other assembly routines.
Give it a proper prototype so that vet can check it.
Adjust one assembly FP reference accordingly.
Change-Id: I263fcb0191529214b16e6bd67330fadee492eef4
Reviewed-on: https://go-review.googlesource.com/37305
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/vet has a known deficiency in its handling of fmt.Formatters.
This causes a spurious printf error only for non-host platforms.
Since cmd/vet/all may get run on any given platform,
whitelists cannot help here.
Work around the issue by skipping printf tests entirely
for non-host platforms.
Work around the one known acceptable false positive from vet
by whitelisting the file that contains it.
Change-Id: Id74b3d4db0519cf9a670a065683715f856266e45
Reviewed-on: https://go-review.googlesource.com/36936
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
dwarf writing code assumes that dwarf sections follow
.data and .bss, not .ctors. Make pe section writing code
match that assumption.
For #10776.
Change-Id: I128c3ad125f7d0db19e922f165704a054b2af7ba
Reviewed-on: https://go-review.googlesource.com/36980
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The symbols get in a way when using external linker. They are
not associated with a section. And linker fails when
generating relocations for them.
__image_base__ and _image_base__ have been added long time ago.
I do not think they are needed anymore. If I delete them, all
tests still PASS. I tried going back to the commit that added
them to see if I can reproduce original error, but I cannot
build it. I don't have hg version of go repo, and my gcc is
complaining about cc source code.
I wasted too much time with this, so I decided to leave them only
for internal linker. That is what they were originally added for.
For #10776.
Change-Id: Ibb72b04f3864947c782f964a7badc69f4b074e25
Reviewed-on: https://go-review.googlesource.com/36979
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dwarf relocations refer to dwarf section symbols, so dwarf
section symbols must be present in pe symbol table before we
write dwarf relocations.
.ctors pe section already refer to .text symbol.
Write all pe section name symbols into symbol table, so we
can use them whenever we need them.
This CL also simplified some code.
For #10776.
Change-Id: I9b8c680ea75904af90c797a06bbb1f4df19e34b6
Reviewed-on: https://go-review.googlesource.com/36978
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Introduce a slice that keeps long pe section names as we add them.
It will be used later to output pe symbol table and dwarf relocations.
For #10776.
Change-Id: I02f808a456393659db2354031baf1d4f9e0b2d61
Reviewed-on: https://go-review.googlesource.com/36977
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is what gcc does when it generates object files.
And pecoff.doc says: "for simplicity, compilers should
set this to zero". It is easier to count everything,
when it starts from 0. Make go linker do the same.
For #10776.
Change-Id: Iffa4b3ad86160624ed34adf1c6ba13feba34c658
Reviewed-on: https://go-review.googlesource.com/36976
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
XCHG needs to allow the stack pointer as an argument because we have a
rewrite that incorporates the address of a local variable into the
instruction.
Fixes#19184
Change-Id: Ic438e6e1946332cdce3864d15abecd41b911b2a9
Reviewed-on: https://go-review.googlesource.com/37253
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Before the change, `go env` reports PKG_CONFIG in between the
CGO env group:
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/jbd"
GORACE=""
GOROOT="/Users/jbd/go"
GOTOOLDIR="/Users/jbd/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lq/qcn67khn4_1b41_g48x3zchh005d21/T/go-build184491598=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
The change makes PKG_CONFIG to be reported as the final item,
and not breaking the CGO_* group apart.
Change-Id: I1e7ed6bdec83009ff118f85c9f0f7b78a67fdd76
Reviewed-on: https://go-review.googlesource.com/37228
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Added an alternate form of printing floats and complex values
by specifying the sharp flag.
Output formatted using the the verbs v, e, E, f, F, g and G in
combination with the sharp flag will always include a decimal point.
The alternate form specified by the sharp flag for %g and %G verbs
will not truncate trailing zeros and assume a default precision of 6.
Fixes#18857.
Change-Id: I4d776239e06d7a6a90f2d8556240a359888cb7c3
Reviewed-on: https://go-review.googlesource.com/37051
Reviewed-by: Rob Pike <r@golang.org>
Add exported global variables and store the results of benchmarked
functions in them. This prevents the current compiler optimizations
from removing the instructions that are needed to compute the return
values of the benchmarked functions.
Change-Id: If8b08424e85f3796bb6dd73e761c653abbabcc5e
Reviewed-on: https://go-review.googlesource.com/37195
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The below range loop will not stop when encountering
the first '.' character in a Darwin version string like "15.6.0".
for i = range osver {
if osver[i] != '.' {
continue
}
}
}
Therefore, the condition i > 2 was always satisfied and
supportsCloseOnExec was always set to true.
Since the minimum supported version of OSX for go is currently 10.8
and O_CLOEXEC is implemented from OSX 10.7 on the detection code
can be removed and support for O_CLOEXEC is always assumed to exist.
Change-Id: Idd10094d8385dd4adebc8d7a6d9e9a8f29455867
Reviewed-on: https://go-review.googlesource.com/37193
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The emphasize function used a complex regexp to find URLs, which
truncated some types of URL and did not match others.
This has been simplified and adjusted to allow valid punctuation
like :: or ! in the path part and :[] in the host part.
Comments were added to clarify what this regexp allows.
The path part matches query and fragment also so document this.
Removed news, telnet, wais, and prospero protocols.
Tests were added for:
IPV6 URLs
URLs surrounded by brackets
URLs containing ::
URLs containing :;!- in the path
In order to allow punctuation and yet preserve current behaviour,
URLs are not permitted to end in .,:;?! to allow the use of
normal punctuation surrounding URLs in comments.
Fixes#18139
Change-Id: I38b2d7a85fe0d171e4bf4aac420f8c2d3ced8a2f
Reviewed-on: https://go-review.googlesource.com/37192
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On AMD64 Most operation can have one operand in memory.
Combine load and dependand operation into one new operation,
where possible. I've seen no significant performance changes on go1,
but this allows to remove ~1.8kb code from go tool. And in math package
I see e. g.:
Remainder-6 70.0ns ± 0% 64.6ns ± 0% -7.76% (p=0.000 n=9+1
Change-Id: I88b8602b1d55da8ba548a34eb7da4b25d59a297e
Reviewed-on: https://go-review.googlesource.com/36793
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The type of an intermediate multiply was wrong. When that
intermediate multiply was spilled, the top 32 bits were lost.
Fixes#19153
Change-Id: Ib29350a4351efa405935b7f7ee3c112668e64108
Reviewed-on: https://go-review.googlesource.com/37212
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
- moved from: x&m>>k | x&^m<<k to: x&m>>k | x<<k&m
This permits use of the same constant m twice (*) which may be
better for machines that can't use large immediate constants
directly with an AND instruction and have to load them explicitly.
*) CPUs don't usually have a &^ instruction, so x&^m becomes x&(^m)
- simplified returns
This improves the generated code because the compiler recognizes
x>>k | x<<k as ROT when k is the bitsize of x.
The 8-bit versions of these instructions can be significantly faster
still if they are replaced with table lookups, as long as the table
is in cache. If the table is not in cache, table-lookup is probably
slower, hence the choice of an explicit register-only implementation
for now.
BenchmarkReverse-8 8.50 6.86 -19.29%
BenchmarkReverse8-8 2.17 1.74 -19.82%
BenchmarkReverse16-8 2.89 2.34 -19.03%
BenchmarkReverse32-8 3.55 2.95 -16.90%
BenchmarkReverse64-8 6.81 5.57 -18.21%
BenchmarkReverseBytes-8 3.49 2.48 -28.94%
BenchmarkReverseBytes16-8 0.93 0.62 -33.33%
BenchmarkReverseBytes32-8 1.55 1.13 -27.10%
BenchmarkReverseBytes64-8 2.47 2.47 +0.00%
Reverse-8 8.50ns ± 0% 6.86ns ± 0% ~ (p=1.000 n=1+1)
Reverse8-8 2.17ns ± 0% 1.74ns ± 0% ~ (p=1.000 n=1+1)
Reverse16-8 2.89ns ± 0% 2.34ns ± 0% ~ (p=1.000 n=1+1)
Reverse32-8 3.55ns ± 0% 2.95ns ± 0% ~ (p=1.000 n=1+1)
Reverse64-8 6.81ns ± 0% 5.57ns ± 0% ~ (p=1.000 n=1+1)
ReverseBytes-8 3.49ns ± 0% 2.48ns ± 0% ~ (p=1.000 n=1+1)
ReverseBytes16-8 0.93ns ± 0% 0.62ns ± 0% ~ (p=1.000 n=1+1)
ReverseBytes32-8 1.55ns ± 0% 1.13ns ± 0% ~ (p=1.000 n=1+1)
ReverseBytes64-8 2.47ns ± 0% 2.47ns ± 0% ~ (all samples are equal)
Change-Id: I0064de8c7e0e568ca7885d6f7064344bef91a06d
Reviewed-on: https://go-review.googlesource.com/37215
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We can immediately emit static assignment data rather than queueing
them up to be processed during SSA building.
Passes toolstash -cmp.
Change-Id: I8bcea4b72eafb0cc0b849cd93e9cde9d84f30d5e
Reviewed-on: https://go-review.googlesource.com/37024
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The rules for folding addresses into load/stores checks sym1 is
not on stack (because the stack offset is not known at that point).
But sym1 could be nil, which invalidates the check. Check merged
sym instead.
Fixes#19137.
Change-Id: I8574da22ced1216bb5850403d8f08ec60a8d1005
Reviewed-on: https://go-review.googlesource.com/37145
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
SSA's writebarrier pass requires WB store ops are always at the
end of a block. If we move write barrier insertion into SSA and
emits normal Store ops when building SSA, this requirement becomes
impractical -- it will create too many blocks for all the Store
ops.
Redo SSA's writebarrier pass, explicitly order values in store
order, so it no longer needs this requirement.
Updates #17583.
Fixes#19067.
Change-Id: I66e817e526affb7e13517d4245905300a90b7170
Reviewed-on: https://go-review.googlesource.com/36834
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Nil check removal in the same block is disabled due to issue 18725:
because the values are not ordered, a nilcheck may influence a
value that is logically before it. This CL re-enables same-block
nilcheck removal by ordering values in store order first.
Updates #18725.
Change-Id: I287a38525230c14c5412cbcdbc422547dabd54f6
Reviewed-on: https://go-review.googlesource.com/35496
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If the caller set ups a Credential in os/exec.Command,
os/exec.Command.Start will end up calling setgroups(2), even if no
supplementary groups were given.
Only root can call setgroups(2) on BSD kernels, which causes Start to
fail for non-root users when they try to set uid and gid for the new
process.
We fix by introducing a new field to syscall.Credential named
NoSetGroups, and setgroups(2) is only called if it is false.
We make this field with inverted logic to preserve backward
compatibility.
RELNOTES=yes
Change-Id: I3cff1f21c117a1430834f640ef21fd4e87e06804
Reviewed-on: https://go-review.googlesource.com/36697
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently the conversion from constant divides to multiplies is mostly
done during the walk pass. This is suboptimal because SSA can
determine that the value being divided by is constant more often
(e.g. after inlining).
Change-Id: If1a9b993edd71be37396b9167f77da271966f85f
Reviewed-on: https://go-review.googlesource.com/37015
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Currently, whether we need a write barrier is simply a property of the
pointer slot being written to.
The only optimization we currently apply using the value being written
is that pointers to stack variables can omit write barriers because
they're only written to stack slots... but we already omit write
barriers for all writes to the stack anyway.
Passes toolstash -cmp.
Change-Id: I7f16b71ff473899ed96706232d371d5b2b7ae789
Reviewed-on: https://go-review.googlesource.com/37109
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Suggested by Dmitry in CL 36792 review.
Clearly safe since there are many different semaRoots
that could all have profiled sudogs calling mutexevent.
Change-Id: I45eed47a5be3e513b2dad63b60afcd94800e16d1
Reviewed-on: https://go-review.googlesource.com/37104
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
This is what gcc does when it generates object files.
And it is easier to count everything, when it starts from 0.
Make go linker do the same.
gcc also does not output IMAGE_OPTIONAL_HEADER or
PE64_IMAGE_OPTIONAL_HEADER for object files.
Perhaps we should do the same, but not in this CL.
For #10776.
Change-Id: I9789c337648623b6cfaa7d18d1ac9cef32e180dc
Reviewed-on: https://go-review.googlesource.com/36974
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change removes the punitive language and anonymous reporting mechanism
from the Code of Conduct document. Read on for the rationale.
More than a year has passed since the Go Code of Conduct was introduced.
In that time, there have been a small number (<30) of reports to the Working Group.
Some reports we handled well, with positive outcomes for all involved.
A few reports we handled badly, resulting in hurt feelings and a bad
experience for all involved.
On reflection, the reports that had positive outcomes were ones where the
Working Group took the role of advisor/facilitator, listening to complaints and
providing suggestions and advice to the parties involved.
The reports that had negative outcomes were ones where the subject of the
report felt threatened by the Working Group and Code of Conduct.
After some discussion among the Working Group, we saw that we are most
effective as facilitators, rather than disciplinarians. The various Go spaces
already have moderators; this change to the CoC acknowledges their authority
and places the group in a purely advisory role. If an incident is
reported to the group we may provide information to or make a
suggestion the moderators, but the Working Group need not (and should not) have
any authority to take disciplinary action.
In short, we want it to be clear that the Working Group are here to help
resolve conflict, period.
The second change made here is the removal of the anonymous reporting mechanism.
To date, the quality of anonymous reports has been low, and with no way to
reach out to the reporter for more information there is often very little we
can do in response. Removing this one-way reporting mechanism strengthens the
message that the Working Group are here to facilitate a constructive dialogue.
Change-Id: Iee52aff5446accd0dae0c937bb3aa89709ad5fb4
Reviewed-on: https://go-review.googlesource.com/37014
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We have seen one instance of a production job suddenly spinning to
100% CPU and becoming unresponsive. In that one instance, a SIGQUIT
was sent after 328 minutes of spinning, and the stacks showed a single
goroutine in "IO wait (scan)" state.
Looking for things that might get stuck if a goroutine got stuck in
scanning a stack, we found that injectglist does:
lock(&sched.lock)
var n int
for n = 0; glist != nil; n++ {
gp := glist
glist = gp.schedlink.ptr()
casgstatus(gp, _Gwaiting, _Grunnable)
globrunqput(gp)
}
unlock(&sched.lock)
and that casgstatus spins on gp.atomicstatus until the _Gscan bit goes
away. Essentially, this code locks sched.lock and then while holding
sched.lock, waits to lock gp.atomicstatus.
The code that is doing the scan is:
if castogscanstatus(gp, s, s|_Gscan) {
if !gp.gcscandone {
scanstack(gp, gcw)
gp.gcscandone = true
}
restartg(gp)
break loop
}
More analysis showed that scanstack can, in a rare case, end up
calling back into code that acquires sched.lock. For example:
runtime.scanstack at proc.go:866
calls runtime.gentraceback at mgcmark.go:842
calls runtime.scanstack$1 at traceback.go:378
calls runtime.scanframeworker at mgcmark.go:819
calls runtime.scanblock at mgcmark.go:904
calls runtime.greyobject at mgcmark.go:1221
calls (*runtime.gcWork).put at mgcmark.go:1412
calls (*runtime.gcControllerState).enlistWorker at mgcwork.go:127
calls runtime.wakep at mgc.go:632
calls runtime.startm at proc.go:1779
acquires runtime.sched.lock at proc.go:1675
This path was found with an automated deadlock-detecting tool.
There are many such paths but they all go through enlistWorker -> wakep.
The evidence strongly suggests that one of these paths is what caused
the deadlock we observed. We're running those jobs with
GOTRACEBACK=crash now to try to get more information if it happens
again.
Further refinement and analysis shows that if we drop the wakep call
from enlistWorker, the remaining few deadlock cycles found by the tool
are all false positives caused by not understanding the effect of calls
to func variables.
The enlistWorker -> wakep call was intended only as a performance
optimization, it rarely executes, and if it does execute at just the
wrong time it can (and plausibly did) cause the deadlock we saw.
Comment it out, to avoid the potential deadlock.
Fixes#19112.
Unfixes #14179.
Change-Id: I6f7e10b890b991c11e79fab7aeefaf70b5d5a07b
Reviewed-on: https://go-review.googlesource.com/37093
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This changes the os package to use the runtime poller for file I/O
where possible. When a system call blocks on a pollable descriptor,
the goroutine will be blocked on the poller but the thread will be
released to run other goroutines. When using a non-pollable
descriptor, the os package will continue to use thread-blocking system
calls as before.
For example, on GNU/Linux, the runtime poller uses epoll. epoll does
not support ordinary disk files, so they will continue to use blocking
I/O as before. The poller will be used for pipes.
Since this means that the poller is used for many more programs, this
modifies the runtime to only block waiting for the poller if there is
some goroutine that is waiting on the poller. Otherwise, there is no
point, as the poller will never make any goroutine ready. This
preserves the runtime's current simple deadlock detection.
This seems to crash FreeBSD systems, so it is disabled on FreeBSD.
This is issue 19093.
Using the poller on Windows requires opening the file with
FILE_FLAG_OVERLAPPED. We should only do that if we can remove that
flag if the program calls the Fd method. This is issue 19098.
Update #6817.
Update #7903.
Update #15021.
Update #18507.
Update #19093.
Update #19098.
Change-Id: Ia5197dcefa7c6fbcca97d19a6f8621b2abcbb1fe
Reviewed-on: https://go-review.googlesource.com/36800
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Until now, the parser set the position for each Node to the position of
the first token belonging to that node. For compatibility with the now
defunct gc parser, in many places that position information was modified
when the gcCompat flag was set (which it was, by default). Furthermore,
in some places, position information was not set at all.
This change removes the gcCompat flag and all associated code, and sets
position information for all nodes in a more principled way, as proposed
by mdempsky (see #16943 for details). Specifically, the position of a
node may not be at the very beginning of the respective production. For
instance for an Operation `a + b`, the position associated with the node
is the position of the `+`. Thus, for `a + b + c` we now get different
positions for the two additions.
This change does not pass toolstash -cmp because position information
recorded in export data and pcline tables is different. There are no
other functional changes.
Added test suite testing the position of all nodes.
Fixes#16943.
Change-Id: I3fc02bf096bc3b3d7d2fa655dfd4714a1a0eb90c
Reviewed-on: https://go-review.googlesource.com/37017
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The new tests in this CL have been checked against Go 1.7 as well
and all pass in Go 1.7, with the one exception noted in a comment
(an intentional change to omitempty already present before this CL).
CL 15684 made the intentional change to omitempty.
This CL fixes bugs introduced along the way.
Most of these are corner cases that are arguably not that important,
but they've always worked all the way back to Go 1, and someone
cared enough to file #19063. The most significant problem found
while adding tests is that in the case of a nil *string field with
`xml:",chardata"`, the existing code silently stops processing not just
that field but the entire remainder of the struct.
Even if #19063 were not worth fixing, this chardata bug would be.
Fixes#19063.
Change-Id: I318cf8f9945e1a4615982d9904e109fde577ebf9
Reviewed-on: https://go-review.googlesource.com/36954
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
... and same for stores. This does for binary.BigEndian.Uint16() what
was already done for Uint32 and Uint64 with BSWAP in 10f75748 (CL 32222).
Here is how generated code changes e.g. for the following function
(omitting saying the same prologue/epilogue):
func get16(b [2]byte) uint16 {
return binary.BigEndian.Uint16(b[:])
}
"".get16 t=1 size=21 args=0x10 locals=0x0
// before
0x0000 00000 (x.go:15) MOVBLZX "".b+9(FP), AX
0x0005 00005 (x.go:15) MOVBLZX "".b+8(FP), CX
0x000a 00010 (x.go:15) SHLL $8, CX
0x000d 00013 (x.go:15) ORL CX, AX
// after
0x0000 00000 (x.go:15) MOVWLZX "".b+8(FP), AX
0x0005 00005 (x.go:15) ROLW $8, AX
encoding/binary is speedup overall a bit:
name old time/op new time/op delta
ReadSlice1000Int32s-4 4.83µs ± 0% 4.83µs ± 0% ~ (p=0.206 n=4+5)
ReadStruct-4 1.29µs ± 2% 1.28µs ± 1% -1.27% (p=0.032 n=4+5)
ReadInts-4 384ns ± 1% 385ns ± 1% ~ (p=0.968 n=4+5)
WriteInts-4 534ns ± 3% 526ns ± 0% -1.54% (p=0.048 n=4+5)
WriteSlice1000Int32s-4 5.02µs ± 0% 5.11µs ± 3% ~ (p=0.175 n=4+5)
PutUint16-4 0.59ns ± 0% 0.49ns ± 2% -16.95% (p=0.016 n=4+5)
PutUint32-4 0.52ns ± 0% 0.52ns ± 0% ~ (all equal)
PutUint64-4 0.53ns ± 0% 0.53ns ± 0% ~ (all equal)
PutUvarint32-4 19.9ns ± 0% 19.9ns ± 1% ~ (p=0.556 n=4+5)
PutUvarint64-4 54.5ns ± 1% 54.2ns ± 0% ~ (p=0.333 n=4+5)
name old speed new speed delta
ReadSlice1000Int32s-4 829MB/s ± 0% 828MB/s ± 0% ~ (p=0.190 n=4+5)
ReadStruct-4 58.0MB/s ± 2% 58.7MB/s ± 1% +1.30% (p=0.032 n=4+5)
ReadInts-4 78.0MB/s ± 1% 77.8MB/s ± 1% ~ (p=0.968 n=4+5)
WriteInts-4 56.1MB/s ± 3% 57.0MB/s ± 0% ~ (p=0.063 n=4+5)
WriteSlice1000Int32s-4 797MB/s ± 0% 783MB/s ± 3% ~ (p=0.190 n=4+5)
PutUint16-4 3.37GB/s ± 0% 4.07GB/s ± 2% +20.83% (p=0.016 n=4+5)
PutUint32-4 7.73GB/s ± 0% 7.72GB/s ± 0% ~ (p=0.556 n=4+5)
PutUint64-4 15.1GB/s ± 0% 15.1GB/s ± 0% ~ (p=0.905 n=4+5)
PutUvarint32-4 201MB/s ± 0% 201MB/s ± 0% ~ (p=0.905 n=4+5)
PutUvarint64-4 147MB/s ± 1% 147MB/s ± 0% ~ (p=0.286 n=4+5)
( "a bit" only because most of the time is spent in reflection-like things
there, not actual bytes decoding. Even for direct PutUint16 benchmark the
looping adds overhead and lowers visible benefit. For code-generated encoders /
decoders actual effect is more than 20% )
Adding Uint32 and Uint64 raw benchmarks too for completeness.
NOTE I had to adjust load-combining rule for bswap case to match first 2 bytes
loads as result of "2-bytes load+shift" -> "loadw + rorw 8" rewrite. Reason is:
for loads+shift, even e.g. into uint16 var
var b []byte
var v uin16
v = uint16(b[1]) | uint16(b[0])<<8
the compiler eventually generates L(ong) shift - SHLLconst [8], probably
because it is more straightforward / other reasons to work on the whole
register. This way 2 bytes rewriting rule is using SHLLconst (not SHLWconst) in
its pattern, and then it always gets matched first, even if 2-byte rule comes
syntactically after 4-byte rule in AMD64.rules because 4-bytes rule seemingly
needs more applyRewrite() cycles to trigger. If 2-bytes rule gets matched for
inner half of
var b []byte
var v uin32
v = uint32(b[3]) | uint32(b[2])<<8 | uint32(b[1])<<16 | uint32(b[0])<<24
and we keep 4-byte load rule unchanged, the result will be MOVW + RORW $8 and
then series of byte loads and shifts - not one MOVL + BSWAPL.
There is no such problem for stores: there compiler, since it probably knows
store destination is 2 bytes wide, uses SHRWconst 8 (not SHRLconst 8) and thus
2-byte store rule is not a subset of rule for 4-byte stores.
Fixes#17151 (int16 was last missing piece there)
Change-Id: Idc03ba965bfce2b94fef456b02ff6742194748f6
Reviewed-on: https://go-review.googlesource.com/34636
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add a benchmark for setting a String value, which we may
want to treat differently from Int or Float due to the need to support
Add methods for the latter.
Update tests to use only the exported API instead of making (fragile)
assumptions about unexported fields.
The existing Map benchmarks construct a new Map for each iteration, which
focuses the benchmark results on the initial allocation costs for the
Map and its entries. This change adds variants of the benchmarks which
use a long-lived map in order to measure steady-state performance for
Map updates on existing keys.
Updates #18177
Change-Id: I62c920991d17d5898c592446af382cd5c04c528a
Reviewed-on: https://go-review.googlesource.com/36959
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 35261 introduces special handling of zero-valued STRUCTLIT for
efficient struct zeroing. But it didn't cover all use cases, for
example, CONVNOP STRUCTLIT is not handled.
On the other hand, CL 34566 handles zeroing earlier, so we don't
need the change in CL 35261 for efficient zeroing. Other uses of
zero-valued struct literals are very rare. So undo the change in
walk.go in CL 35261.
Add a test for efficient zeroing.
Fixes#19084.
Change-Id: I0807f7423fb44d47bf325b3c1ce9611a14953853
Reviewed-on: https://go-review.googlesource.com/36955
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Since we're no longer stealing space for the stack barrier array from
the stack allocation, the stack allocation is simply
g.stack.hi-g.stack.lo.
Updates #17503.
Change-Id: Id9b450ae12c3df9ec59cfc4365481a0a16b7c601
Reviewed-on: https://go-review.googlesource.com/36621
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Now that we don't rescan stacks, stack barriers are unnecessary. This
removes all of the code and structures supporting them as well as
tests that were specifically for stack barriers.
Updates #17503.
Change-Id: Ia29221730e0f2bbe7beab4fa757f31a032d9690c
Reviewed-on: https://go-review.googlesource.com/36620
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With the hybrid barrier, rescanning stacks is no longer necessary so
the rescan list is no longer necessary. Remove it.
This leaves the gcrescanstacks GODEBUG variable, since it's useful for
debugging, but changes it to simply walk all of the Gs to rescan
stacks rather than using the rescan list.
We could also remove g.gcscanvalid, which is effectively a distributed
rescan list. However, it's still useful for gcrescanstacks mode and it
adds little complexity, so we'll leave it in.
Fixes#17099.
Updates #17503.
Change-Id: I776d43f0729567335ef1bfd145b75c74de2cc7a9
Reviewed-on: https://go-review.googlesource.com/36619
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The wbshadow implementation was removed a year and a half ago in
1635ab7dfe, but the GODEBUG setting remained. Remove the GODEBUG
setting since it doesn't do anything.
Change-Id: I19cde324a79472aff60acb5cc9f7d4aa86c0c0ed
Reviewed-on: https://go-review.googlesource.com/36618
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
The current implementation does not account for Dir being
initialized with an absolute path on systems that start
paths with filepath.Separator. In this scenario, the
original error is returned, and not checked for file
segments.
This change adds a test for this case, and corrects the
behavior by ignoring blank path segments in the loop.
Refs #18984
Change-Id: I9b79fd0a73a46976c8e2feda0283ef0bb2b62ea1
Reviewed-on: https://go-review.googlesource.com/36804
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Use distinction between explicit and automatically inserted semicolons
to provide a better error message if the condition in an 'if' statement
is missing.
For #18747.
Change-Id: Iac167ae4e5ad53d2dc73f746b4dee9912434bb59
Reviewed-on: https://go-review.googlesource.com/36930
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It is not always obvious from the first glance when looking at
TestAssembly failure in which context the code was generated. For
example x86 and x86-64 are similar, and those of us who do not work with
assembly every day can even take s390x version as something similar to x86.
So when something fails lets print the whole test context - this
includes os and arch which were previously missing. An example failure:
before:
--- FAIL: TestAssembly (40.48s)
asm_test.go:46: expected: MOVWZ \(.*\),
go:
import "encoding/binary"
func f(b []byte) uint32 {
return binary.LittleEndian.Uint32(b)
}
asm:"".f t=1 size=160 args=0x20 locals=0x0
...
after:
--- FAIL: TestAssembly (40.43s)
asm_test.go:46: linux/s390x: expected: MOVWZ \(.*\),
go:
import "encoding/binary"
func f(b []byte) uint32 {
return binary.LittleEndian.Uint32(b)
}
asm:"".f t=1 size=160 args=0x20 locals=0x0
Motivated-by: #18946#issuecomment-279491071
Change-Id: I61089ceec05da7a165718a7d69dec4227dd0e993
Reviewed-on: https://go-review.googlesource.com/36881
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Extend period of fastrand from (1<<31)-1 to (1<<32)-1 by
choosing other polynom and reacting on high bit before shift.
Polynomial is taken at https://users.ece.cmu.edu/~koopman/lfsr/index.html
from 32.dat.gz . It is referred as F7711115 cause this list of
polynomials is for LFSR with shift to right (and fastrand uses shift to
left). (old polynomial is referred in 31.dat.gz as 7BB88888).
There were couple of places with conversation of fastrand to int, which
leads to negative values on 32bit platforms. They are fixed.
Change-Id: Ibee518a3f9103e0aea220ada494b3aec77babb72
Reviewed-on: https://go-review.googlesource.com/36875
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
I noticed that Content-Length may appear in http.Response.Header, but the docs
say it should be omitted. Per discussion with bradfitz@, updating the docs to
indicate that the struct fields are authoritative.
Change-Id: Id1807ff9d4ba5de425d8b147205f29b18351230f
Reviewed-on: https://go-review.googlesource.com/36842
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
MOVD{reg,nop} operations (added in CL 36256) inserted to preserve
type information were blocking the load-combining rules. Fix this
by merging type changes into loads wherever possible.
Fixes#19059.
Change-Id: I8a1df06eb0f231b40ae43107d4a3bd0b9c441b59
Reviewed-on: https://go-review.googlesource.com/36843
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Delete use stub from asm.s, leaving only a dummy file.
Deleting the file causes Windows build to fail.
Fixes#16607
Change-Id: Ic5a55e042e588f1e1bc6605a3d309d1eabdeb288
Reviewed-on: https://go-review.googlesource.com/36716
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When installing a package to a different directory using `go build`,
`mv` cannot be used if the destination directory has the group sticky
bit set. Instead, `cp` should be used to make sure the destination
file has the correct permissions.
Fixesgolang/go#18878.
Change-Id: I5423f559e7f84df080ed47816e19a22c6d00ab6d
Reviewed-on: https://go-review.googlesource.com/36797
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When testing context cancelation behavior do not rely on context
timeouts. Use explicit checks in all such tests. In closeDB
convert the simple check for zero open conns with a wait loop
for zero open conns.
Fixes#19024Fixes#19041
Change-Id: Iecfcc4467e91249fceb21ffd1f7c62c58140d8e9
Reviewed-on: https://go-review.googlesource.com/36902
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL 33632 reorders args of commutative ops in order to make
CSE for commutative ops more robust. Unfortunately, that
broke the load-combining rules which depend on a certain ordering
of OR ops' arguments.
Introduce some additional rules that order OR ops' arguments
consistently so that the load-combining rules fire.
Note: there's also something else wrong with the s390x rules.
I've filed #19059 for that.
Fixes#18946
Change-Id: I0a5447196bd88a55ccee683c69a57b943a9972e1
Reviewed-on: https://go-review.googlesource.com/36911
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The tutorial ends without mentioning how to use the generated
pprof-like profile with the pprof tool. This may be very trivial
for users who are already very familiar with the Go tools, but
for the newcomers, it saves a lot of time to finalize the tutorial
with an example of `go tool pprof` invocation.
Change-Id: Idf034eb4bfb9672ef10190e66fcbf873e8f08f6a
Reviewed-on: https://go-review.googlesource.com/36803
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
When doing i.(T) for non-empty-interface i and concrete type T,
there's no need to read the type out of the itab. Just compare the
itab to the itab we expect for that interface/type pair.
Also optimize type switches by putting the type hash of the
concrete type in the itab. That way we don't need to load the
type pointer out of the itab.
Update #18492
Change-Id: I49e280a21e5687e771db5b8a56b685291ac168ce
Reviewed-on: https://go-review.googlesource.com/34810
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Added missing nil-check. We will get rid of the gcCompat corrections
shortly but it's still worthwhile having the new test case added.
Fixes#19056.
Change-Id: I35bd938a4d789058da15724e34c05e5e631ecad0
Reviewed-on: https://go-review.googlesource.com/36908
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
bytes.Equal is written in assembly and is slightly faster than the
current Go bytesEqual from the net package.
benchcmp:
benchmark old ns/op new ns/op delta
BenchmarkIPCompare4-8 7.74 7.01 -9.43%
BenchmarkIPCompare6-8 8.47 6.86 -19.01%
Change-Id: I2a7ad35867489b46f0943aef5776a2fe1b46e2df
Reviewed-on: https://go-review.googlesource.com/36850
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If there are many goroutines contending for two different locks
and both locks hash to the same semaRoot, the scans to find the
goroutines for a particular lock can end up being O(n), making
n lock acquisitions quadratic.
As long as only one actively-used lock hashes to each semaRoot
there's no problem, since the list operations in that case are O(1).
But when the second actively-used lock hits the same semaRoot,
then scans for entries with for a given lock have to scan over the
entries for the other lock.
Fix this problem by changing the semaRoot to hold only one sudog
per unique address. In the running example, this drops the length of
that list from O(n) to 2. Then attach other goroutines waiting on the
same address to a separate list headed by the sudog in the semaRoot list.
Those "same address list" operations are still O(1), so now the
example from above works much better.
There is still an assumption here that in real programs you don't have
many many goroutines queueing up on many many distinct addresses.
If we end up with that problem, we can replace the top-level list with
a treap.
Fixes#17953.
Change-Id: I78c5b1a5053845275ab31686038aa4f6db5720b2
Reviewed-on: https://go-review.googlesource.com/36792
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change allows greatly reducing memory allocations with a slightly
performance improvement as well.
Instances of (*png).Encoder can have a optional BufferPool attached to
them. This allows reusing temporary buffers used when encoding a new
image. This buffers include instances to zlib.Writer and bufio.Writer.
Also, buffers for current and previous rows are saved in the encoder
instance and reused as long as their cap() is enough to fit the current
image row.
A new benchmark was added to demonstrate the performance improvement
when setting a BufferPool to an Encoder instance:
$ go test -bench BenchmarkEncodeGray -benchmem
BenchmarkEncodeGray-4 1000 2349584 ns/op 130.75 MB/s 852230 B/op 32 allocs/op
BenchmarkEncodeGrayWithBufferPool-4 1000 2241650 ns/op 137.04 MB/s 900 B/op 3 allocs/op
Change-Id: I4488201ae53cb2ad010c68c1e0118ee12beae14e
Reviewed-on: https://go-review.googlesource.com/34150
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make the comments a bit clearer and more accurate,
in anticipation of updating the code.
Change-Id: I1111e6c3405a8688fcd29b809a48a762ff41edaa
Reviewed-on: https://go-review.googlesource.com/36833
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add temporaries to reorder the assignment for OAS2XXX nodes.
This makes orderstmt(), rewrite
a, b, c = ...
as
tmp1, tmp2, tmp3 = ...
a, b, c = tmp1, tmp2, tmp3
and
a, ok = ...
as
t1, t2 = ...
a = t1
ok = t2
Fixes#13433.
Change-Id: Id0f5956e3a254d0a6f4b89b5f7b0e055b1f0e21f
Reviewed-on: https://go-review.googlesource.com/34713
Run-TryBot: Dhananjay Nakrani <dhananjayn@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Encourage people towards the various help forums as a first port of
call. Better sign-posting will reduce the incidence or questions being
asked in the issue tracker that should otherwise be handled elsewhere,
thereby keeping the issue tracker email traffic more focussed.
Change-Id: I13b2e498d88be010fca421067ae6fb579a46d6b7
Reviewed-on: https://go-review.googlesource.com/34250
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Using 'sep' as parameter name for strings functions that take a
separator argument is fine, but for functions like Index or Count that
look for a substring it's better to use 'substr' (like Contains
already does).
Fixes#19039
Change-Id: Idd557409c8fea64ce830ab0e3fec37d3d56a79f0
Reviewed-on: https://go-review.googlesource.com/36874
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The environment variables used in those tests override the default
OS ones. However, one of them (SystemRoot) seems to be required on
some Windows systems for invoking cmd.exe properly.
This fixes#4930 and #6568.
Change-Id: I23dfb67c1de86020711a3b59513f6adcbba12561
Reviewed-on: https://go-review.googlesource.com/36873
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When running benchmarks with -cpuprofile,
the entire process gets profiled,
and ReadMemStats is surprisingly expensive.
Running the sort benchmarks right now with
-cpuprofile shows almost half of all execution
time in ReadMemStats.
Since ReadMemStats is not required if the benchmark
does not need allocation stats, simply skip it.
This will make cpu profiles nicer to read
and significantly speed up the process of running benchmarks.
It might also make sense to toggle cpu profiling
on/off as we begin/end individual benchmarks,
but that wouldn't get us the time savings of
skipping ReadMemStats, so this CL is useful in itself.
Change-Id: I425197b1ee11be4bc91d22b929e2caf648ebd7c5
Reviewed-on: https://go-review.googlesource.com/36791
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The 0x10101 magic constant is a little more principled than 0x10100, as
the rounding adjustment now spans the complete range [0, 0xffff] instead
of [0, 0xff00].
Consider this round-tripping code:
y, cb, cr := color.RGBToYCbCr(r0, g0, b0)
r1, g1, b1 := color.YCbCrToRGB(y, cb, cr)
Due to rounding errors both ways, we often but not always get a perfect
round trip (where r0 == r1 && g0 == g1 && b0 == b1). This is true both
before and after this commit. In some cases we got luckier, in others we
got unluckier.
For example, before this commit, (180, 135, 164) doesn't round trip
perfectly (it's off by 1) but (180, 135, 165) does. After this commit,
both cases are reversed: the former does and the latter doesn't (again
off by 1). Over all possible (r, g, b) triples, there doesn't seem to be
a big change for better or worse.
There is some history in these CLs:
image/color: tweak the YCbCr to RGBA conversion formula.
https://go-review.googlesource.com/#/c/12220/2/src/image/color/ycbcr.go
image/color: have YCbCr.RGBA work in 16-bit color, per the Color
interface.
https://go-review.googlesource.com/#/c/8073/2/src/image/color/ycbcr.go
Change-Id: Ib25ba7039f49feab2a9d1a4141b86db17db7b3e1
Reviewed-on: https://go-review.googlesource.com/36732
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Instead we can just call needwritebarrier when constructing the SSA
representation.
Change-Id: I6fefaad49daada9cdb3050f112889e49dca0047b
Reviewed-on: https://go-review.googlesource.com/34566
Reviewed-by: Cherry Zhang <cherryyz@google.com>
So it could be inlined.
Using bit-tricks it could be implemented without condition
(improved trick version by Minux Ma).
Simple benchmark shows it is faster on i386 and x86_64, though
I don't know will it be faster on other architectures?
benchmark old ns/op new ns/op delta
BenchmarkFastrand-3 2.79 1.48 -46.95%
BenchmarkFastrandHashiter-3 25.9 24.9 -3.86%
Change-Id: Ie2eb6d0f598c0bb5fac7f6ad0f8b5e3eddaa361b
Reviewed-on: https://go-review.googlesource.com/34782
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If the user is calling SetGCPercent(-1), they intend to disable GC.
They probably don't intend to run one. If they do, they can call
runtime.GC themselves.
Change-Id: I40ef40dfc7e15193df9ff26159cd30e56b666f73
Reviewed-on: https://go-review.googlesource.com/34013
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
During the mark phase of garbage collection, goroutines that allocate
may be recruited to assist. This change creates trace events for mark
assists and displays them similarly to sweep assists in the trace
viewer.
Mark assists are different than sweeps in that they can be preempted, so
displaying them in the trace viewer is a little tricky -- we may need to
synthesize multiple slices for one mark assist. This could have been
done in the parser instead, but I thought it might be preferable to keep
the parser as true to the event stream as possible.
Change-Id: I381dcb1027a187a354b1858537851fa68a620ea7
Reviewed-on: https://go-review.googlesource.com/36015
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The other expvar tests are already parallelized, and this will help to
measure the impact of potential implementations for #18177.
updates #18177
Change-Id: I0f4f1a16a0285556cbcc8339855b6459af412675
Reviewed-on: https://go-review.googlesource.com/36717
Reviewed-by: Russ Cox <rsc@golang.org>
The code previously tested only whether DNS-name SANs were present in a
certificate which is only approximately correct. In fact, /any/ SAN
extension, including one with no DNS names, should cause the CN to be
ignored.
Change-Id: I3d9824918975be6d4817e7cbb48ed1b0c5a2fc8b
Reviewed-on: https://go-review.googlesource.com/36696
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The s390x port was based on the ppc64 port and, because of the way the
port was done, inherited some instructions from it. ppc64 supports
3-operand (4-operand for FMADD etc.) floating point instructions
but s390x doesn't (the destination register is always an input) and
so these were emulated.
There is a bug in the emulation of FMADD whereby if the destination
register is also a source for the multiplication it will be
clobbered. This doesn't break any assembly code in the std lib but
could affect future work.
To fix this I have gone through the floating point instructions and
removed all unnecessary 3-/4-operand emulation. The compiler doesn't
need it and assembly writers don't need it, it's just a source of
bugs.
I've also deleted the FNMADD family of emulated instructions. They
aren't used anywhere.
Change-Id: Ic07cedcf141a6a3b43a0c84895460f6cfbf56c04
Reviewed-on: https://go-review.googlesource.com/33350
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Unlike the pure go implementation used by every other architecture,
the amd64 asm implementation of Exp does not fail early if the
argument is known to overflow. Make it fail early.
Cost of the check is < 1ns (on an old Sandy Bridge machine):
name old time/op new time/op delta
Exp-4 18.3ns ± 1% 18.7ns ± 1% +2.08% (p=0.000 n=18+20)
Fixes#14932Fixes#18912
Change-Id: I04b3f9b4ee853822cbdc97feade726fbe2907289
Reviewed-on: https://go-review.googlesource.com/36271
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously if a connection was requested but timed out during the
request and when acquiring the db.Lock the connection request
is fulfilled and the request is unable to be returned to the
connection pool, then then driver connection would not be closed.
No tests were added or modified because I was unable to determine
how to trigger this situation without something invasive.
Change-Id: I9d4dc680e3fdcf63d79d212174a5b8b313f363f1
Reviewed-on: https://go-review.googlesource.com/36641
Reviewed-by: Russ Cox <rsc@golang.org>
This is a re-roll of a previous commit,
a855da29db, which was rolled back in
14347ee480.
It was rolled back because it broke a unit test in image/gif. The
image/gif code was fixed by 9ef65dbe06
"image/gif: fix frame-inside-image bounds checking".
The original commit message:
image: fix the overlap check in Rectangle.Intersect.
The doc comment for Rectangle.Intersect clearly states, "If the two
rectangles do not overlap then the zero rectangle will be returned."
Prior to this fix, calling Intersect on adjacent but non-overlapping
rectangles would return an empty but non-zero rectangle.
The fix essentially changes
if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc }
to
if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc }
(note that the > signs have become >= signs), but changing that line to:
if r.Empty() { etc }
seems clearer (and equivalent).
Change-Id: I2e3af1f1686064a573b2e513b39246fe60c03631
Reviewed-on: https://go-review.googlesource.com/36734
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 35554 taught order.go to use static variables
for constants that needed to be addressable for runtime routines.
However, there is one class of runtime routines that
do not actually need an addressable value: fast map access routines.
This CL teaches order.go to avoid using static variables
for addressability in those cases.
Instead, it avoids introducing a temp at all,
which the backend would just have to optimize away.
Fixes#19015.
Change-Id: I5ef780c604fac3fb48dabb23a344435e283cb832
Reviewed-on: https://go-review.googlesource.com/36693
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The semantics of the Go image.Rectangle type is that the In and
Intersects methods treat empty rectangles specially. There are multiple
valid representations of an empty image.Rectangle. One of them is the
zero image.Rectangle but there are others. They're obviously not all
equal in the == sense, so we shouldn't use != to check GIF's semantics.
This change will allow us to re-roll
a855da29db "image: fix the overlap check
in Rectangle.Intersect" which was rolled back in
14347ee480.
Change-Id: Ie1a0d092510a7bb6170e61adbf334b21361ff9e6
Reviewed-on: https://go-review.googlesource.com/36639
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The current implementation fails to produce an "IsNotExist" error on some
platforms (unix) for certain situations where it would be expected. This causes
downstream consumers, like FileServer, to emit 500 errors instead of a 404 for
some non-existant paths on certain platforms but not others.
As an example, os.Open("/index.html/foo") on a unix-type system will return
syscall.ENOTDIR, which os.IsNotExist cannot return true for (because the
error code is ambiguous without context). On windows, this same example
would result in os.IsNotExist returning true -- since the returned error is
specific.
This change alters Dir.Open to look up the tree for an "IsPermission" or
"IsNotExist" error to return, or a non-directory, returning os.ErrNotExist in
the last case. For all other error scenarios, the original error is returned.
This ensures that downstream code, like FileServer, receive errors that behave
the same across all platforms.
Fixes#18984
Change-Id: Id7d16591c24cd96afddb6d8ae135ac78da42ed37
Reviewed-on: https://go-review.googlesource.com/36635
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The gcCompat mode was introduced to match the new parser's node position
setup exactly with the positions used by the original parser. Some of the
gcCompat adjustments were required to satisfy syntax error test cases,
and the rest were required to make toolstash cmp pass.
This change removes the former gcCompat adjustments and instead adjusts
the respective test cases as necessary. In some cases this makes the error
lines consistent with the ones reported by gccgo.
Where it has changed, the position associated with a given syntactic construct
is the position (line/col number) of the left-most token belonging to the
construct.
Change-Id: I5b60c00c5999a895c4d6d6e9b383c6405ccf725c
Reviewed-on: https://go-review.googlesource.com/36695
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
go:systemstack works by tweaking the stack check prologue to check
against a different bound, while go:nosplit removes the stack check
prologue entirely. Hence, they can't be used together. Make the build
fail if they are.
Change-Id: I2d180c4b1d31ff49ec193291ecdd42921d253359
Reviewed-on: https://go-review.googlesource.com/36710
Run-TryBot: Austin Clements <austin@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TestRPC writes to newServer and newServerAddr guarded with a
sync.Once.
TestAcceptExitAfterListenerClose was overwriting those variables,
which caused the second invocation of TestRPC within a single process
to fail.
A second invocation can occur as a result of running the test with
multiple values for the -cpu flag.
fixes#19001.
Change-Id: I291bacf44aefb49c2264ca0290a28248c026f80e
Reviewed-on: https://go-review.googlesource.com/36624
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Add asm implementation for AES in order to make use of VMX cryptographic
acceleration instructions for POWER8. There is a speed boost of over 10
times using those instructions:
Fixes#18076
old ns/op new ns/op delta
BenchmarkEncrypt-20 337 30.3 -91.00%
BenchmarkDecrypt-20 347 30.5a -91.21%
BenchmarkExpand-20 1180 130 -88.98%
old MB/s new MB/s speedup
BenchmarkEncrypt-20 47.38 527.68 11.13x
BenchmarkDecrypt-20 46.05 524.45 11.38x
Change-Id: Ifa4d1b508f4803cc72dcaad97acc8495d651b019
Reviewed-on: https://go-review.googlesource.com/33587
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
There's no need to hold the handshake lock across this call and it can
lead to deadlocks if the net.Conn calls back into the tls.Conn.
Fixes#18426.
Change-Id: Ib1b2813cce385949d970f8ad2e52cfbd1390e624
Reviewed-on: https://go-review.googlesource.com/36561
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently there are cases where an XOR with -1 followed by an AND
is generanted when it could be done with just an ANDN instruction.
Changes to PPC64.rules and required files allows this change
in generated code. Examples of this occur in sha3 among others.
Fixes: #18918
Change-Id: I647cb9b4a4aaeebb27db85f8bf75487d78f720c9
Reviewed-on: https://go-review.googlesource.com/36218
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
This ensures that SIGPROF is handled correctly when using
runtime/pprof in a c-archive or c-shared library.
Separate profiler handling into pre-process changes and per-thread
changes. Simplify the Windows code slightly accordingly.
Fixes#18220.
Change-Id: I5060f7084c91ef0bbe797848978bdc527c312777
Reviewed-on: https://go-review.googlesource.com/34018
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
The AuthorityKeyId value from the template was used by
CreateCertificate, but that wasn't documented. Also, CreateCertificate
would stash a value in the template if it needed to override it, which
was wrong: template should be read-only.
Fixes#18962.
Change-Id: Ida15c54c341e5bbf553756e8aa65021d8085f453
Reviewed-on: https://go-review.googlesource.com/36556
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It seems that it is not needed to import the pseudo package "C"
for the plugin to be built correctly.
Removing it to avoid confusion.
Change-Id: I62838a953ad2889881bfbfd1a36141661565f033
Reviewed-on: https://go-review.googlesource.com/36638
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Update syscall code generators to set build tags.
Regenerate zsyscall files, which makes the following changes:
- remove calls to "use"
- update build tags, adding missing ones in some cases
- "stat" renamed to "st" in some cases
- "libc_Utimes" renamed "libc_utimes" in one case
I'll mirror this change to x/sys/unix once committed.
Change-Id: Ic07e0ae1433dd133eb57e8dd2a3b86a62aab4eda
Reviewed-on: https://go-review.googlesource.com/36616
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change adds instructions from ISA 2.05, 2.06 and 2.07 that are frequently
used in assembly optimizations for ppc64.
It also fixes two problems:
* the implementation of RLDICR[CC]/RLDICL[CC] did not consider all possible
cases for the bit mask.
* removed two non-existing instructions that were added by mistake in the VMX
implementation (VORL/VANDL).
Change-Id: Iaef4e5c6a5240c2156c6c0f28ad3bcd8780e9830
Reviewed-on: https://go-review.googlesource.com/36230
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Fetch both monotonic and wall time together when possible.
Avoids skew and is cheaper.
Also shave a few ns off in conversion in package time.
Compared to current implementation (after monotonic changes):
name old time/op new time/op delta
Now 19.6ns ± 1% 9.7ns ± 1% -50.63% (p=0.000 n=41+49) darwin/amd64
Now 23.5ns ± 4% 10.6ns ± 5% -54.61% (p=0.000 n=30+28) windows/amd64
Now 54.5ns ± 5% 29.8ns ± 9% -45.40% (p=0.000 n=27+29) windows/386
More importantly, compared to Go 1.8:
name old time/op new time/op delta
Now 9.5ns ± 1% 9.7ns ± 1% +1.94% (p=0.000 n=41+49) darwin/amd64
Now 12.9ns ± 5% 10.6ns ± 5% -17.73% (p=0.000 n=30+28) windows/amd64
Now 15.3ns ± 5% 29.8ns ± 9% +94.36% (p=0.000 n=30+29) windows/386
This brings time.Now back in line with Go 1.8 on darwin/amd64 and windows/amd64.
It's not obvious why windows/386 is still noticeably worse than Go 1.8,
but it's better than before this CL. The windows/386 speed is not too
important; the changes just keep the two architectures similar.
Change-Id: If69b94970c8a1a57910a371ee91e0d4e82e46c5d
Reviewed-on: https://go-review.googlesource.com/36428
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Starting the error message with "expecting" rather than "missing"
causes the syntax error mechanism to add additional helpful info
(it recognizes "expecting" but not "missing").
Fixes#17328.
Change-Id: I8482ca5e5a6a6b22e0ed0d831b7328e264156334
Reviewed-on: https://go-review.googlesource.com/36637
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Towards better syntax error messages: With this change, the parser knows whether
a semicolon was an actual ';' in the source, or whether it was an automatically
inserted semicolon as result of a '\n' or EOF. Using this information in error
messages makes them more understandable.
For #17328.
Change-Id: I8cd9accee8681b62569d0ecef922d38682b401eb
Reviewed-on: https://go-review.googlesource.com/36636
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previously if a context was canceled while it was waiting for a
connection request, that connection request would leak.
To prevent this remove the pending connection request if the
context is canceled and ensure no connection has been sent on the channel.
This requires a change to how the connection requests are represented in the DB.
Fixes#18995
Change-Id: I9a274b48b8f4f7ca46cdee166faa38f56d030852
Reviewed-on: https://go-review.googlesource.com/36563
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Updates Profile and Trace handlers to reject requests for durations >=
WriteTimeout.
Modifies go tool pprof to print the body of the http response when
status != 200.
Fixes#18755
Change-Id: I6faed21685693caf39f315f003039538114937b0
Reviewed-on: https://go-review.googlesource.com/35564
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Link in the description of TLSUnique field of ConnectionState struct
leads to an article that is no longer available, so this commit
replaces it with link to a copy of the very same article on another
site.
Fixes#18842.
Change-Id: I8f8d298c4774dc0fbbad5042db0684bb3220aee8
Reviewed-on: https://go-review.googlesource.com/36052
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>
CL (change list) pops out of nowhere and confuses the
reader. Use "change" instead to be consistent with the
rest of the document.
Fixes#18989.
Change-Id: I525a63a195dc6bb992c8ad0f10c2f2e1b2b952df
Reviewed-on: https://go-review.googlesource.com/36564
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some rules insert MOVDreg ops to ensure that type changes are kept.
If there is no type change (or the input is constant) then the MOVDreg
can be omitted, allowing further optimization.
Reduces the size of the .text section in the asm tool by ~33KB.
Change-Id: I386883bb35b843c7b99a269cd6840dca77cf4371
Reviewed-on: https://go-review.googlesource.com/36547
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
By using actual filename, diff output of "gofmt -d" can be used with
other commands like "diffstat" and "patch".
Example:
$ gofmt -d path/to/file.go | diffstat
$ gofmt -d path/to/file.go > gofmt.patch
$ patch -u -p0 < gofmt.patch
Fixes#18932
Change-Id: I21ce15eb77870d72f2c14bfd5e7c21e2c77dc9ab
Reviewed-on: https://go-review.googlesource.com/36374
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously it was intended that Rows.Scan would return
an error and Rows.Err would return nil. This was problematic
because drivers could not differentiate between a normal
Rows.Close or a context cancel close.
The alternative is to require drivers to return a Scan to return
an error if the driver is closed while there are still rows to be read.
This is currently not how several drivers currently work and may be
difficult to detect when there are additional rows.
At the same time guard the the Rows.lasterr and prevent a close
while a Rows operation is active.
For the drivers that do not have Context methods, do not check for
context cancelation after the operation, but before for any operation
that may modify the database state.
Fixes#18961
Change-Id: I49a25318ecd9f97a35d5b50540ecd850c01cfa5e
Reviewed-on: https://go-review.googlesource.com/36485
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change clarifies that only ticket-based resumption is supported by
crypto/tls. It's not clear where to document this for a server,
although perhaps it's obvious there because there's nowhere to plug in
the storage that would be needed by SessionID-based resumption.
Fixes#18607
Change-Id: Iaaed53e8d8f2f45c2f24c0683052df4be6340922
Reviewed-on: https://go-review.googlesource.com/36560
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We need to clear the pattern match map after the recursive rewrite
applications, otherwise there might be lingering entries that cause
match to fail.
Fixes#18987.
Change-Id: I7913951c455c98932bda790861db6a860ebad032
Reviewed-on: https://go-review.googlesource.com/36546
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The fwdSig array is accessed by the signal handler, which may run in
parallel with other threads manipulating it via the os/signal package.
Use atomic accesses to ensure that there are no problems.
Move the _SigHandling flag out of the sigtable array. This makes sigtable
immutable and safe to read from the signal handler.
Change-Id: Icfa407518c4ebe1da38580920ced764898dfc9ad
Reviewed-on: https://go-review.googlesource.com/36321
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Apparently the current documentation is confusing users that
quickly skim the flags list at the top. Make very clear that
build tags are space-separated.
Updates #18800
Change-Id: I473552c5a2b70ca03d8bbbd2c76805f7f82b49a2
Reviewed-on: https://go-review.googlesource.com/35951
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 20845 changed Stdin.Stat() so it returns ModeNamedPipe.
But introduced TestStatStdin does not test what Stdin.Stat()
returns when Stdin is console.
This CL adjusts both TestStatStdin and Stdin.Stat
implementations to handle console. Return ModeCharDevice
from Stdin.Stat() when Stdin is console on windows,
just like it does on unix.
Fixes#14853.
Change-Id: I54d73caee2aea45a99618d11600d8e82fe20d0c0
Reviewed-on: https://go-review.googlesource.com/34090
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In cmd/compile, we can directly construct obj.Auto to represent local
variables and attach them to the function's obj.LSym.
In preparation for being able to emit more precise DWARF info based on
other compiler available information (e.g., lexical scoping).
Change-Id: I9c4225ec59306bec42552838493022e0e9d70228
Reviewed-on: https://go-review.googlesource.com/36420
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Currently both _MaxMem and _MaxArena32 represent the maximum arena
size on 32-bit hosts (except on MIPS32 where _MaxMem is confusingly
smaller than _MaxArena32).
Clean up sysAlloc so that it always uses _MaxMem, which is the maximum
arena size on both 32- and 64-bit architectures and is the arena size
we allocate auxiliary structures for. This lets us simplify and unify
some code paths and eliminate _MaxArena32.
Fixes#18651. mheap.sysAlloc currently assumes that if the arena is
small, we must be on a 32-bit machine and can therefore grow the arena
to _MaxArena32. This breaks down on darwin/arm64, where _MaxMem is
only 2 GB. As a result, on darwin/arm64, we only reserve spans and
bitmap space for a 2 GB heap, and if the application tries to allocate
beyond that, sysAlloc takes the 32-bit path, tries to grow the arena
beyond 2 GB, and panics when it tries to grow the spans array
allocation past its reserved size. This has probably been a problem
for several releases now, but was only noticed recently because
mapSpans didn't check the bounds on the span reservation until
recently. Most likely it corrupted the bitmap before. By using _MaxMem
consistently, we avoid thinking that we can grow the arena larger than
we have auxiliary structures for.
Change-Id: Ifef28cb746a3ead4b31c1d7348495c2242fef520
Reviewed-on: https://go-review.googlesource.com/35253
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
mallocinit has evolved organically. Make a pass to clean it up in
various ways:
1. Merge the computation of spansSize and bitmapSize. These were
computed on every loop iteration of two different loops, but always
have the same value, which can be derived directly from _MaxMem.
This also avoids over-reserving these on MIPS, were _MaxArena32 is
larger than _MaxMem.
2. Remove the ulimit -v logic. It's been disabled for many releases
and the dead code paths to support it are even more wrong now than
they were when it was first disabled, since now we *must* reserve
spans and bitmaps for the full address space.
3. Make it clear that we're using a simple linear allocation to lay
out the spans, bitmap, and arena spaces. Previously there were a
lot of redundant pointer computations. Now we just bump p1 up as we
reserve the spaces.
In preparation for #18651.
Updates #5049 (respect ulimit).
Change-Id: Icbe66570d3a7a17bea227dc54fb3c4978b52a3af
Reviewed-on: https://go-review.googlesource.com/35252
Reviewed-by: Russ Cox <rsc@golang.org>
Currently _MaxMem is a uintptr, which is going to complicate some
further changes. Make it untyped so we'll be able to do untyped math
on it before truncating it to a uintptr.
The runtime assembly is identical before and after this change on
{linux,windows}/{amd64,386}.
Updates #18651.
Change-Id: I0f64511faa9e0aa25179a556ab9f185ebf8c9cf8
Reviewed-on: https://go-review.googlesource.com/35251
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The compiler did not emit write barrier for assigning global with
struct literal, like global = T{} where T contains pointer.
The relevant code path is:
walkexpr OAS var_ OSTRUCTLIT
oaslit
anylit OSTRUCTLIT
walkexpr OAS var_ nil
return without adding write barrier
return true
break (without adding write barrier)
This CL makes oaslit not apply to globals. See also CL
https://go-review.googlesource.com/c/36355/ for an alternative
fix.
The downside of this is that it generates static data for zeroing
struct now. Also this only covers global. If there is any lurking
bug with implicit zeroing other than globals, this doesn't fix.
Fixes#18956.
Change-Id: Ibcd27e4fae3aa38390ffa94a32a9dd7a802e4b37
Reviewed-on: https://go-review.googlesource.com/36410
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
to the list in response to #17549 - not being able to find any certs otherwise.
Now we have #18813, where CentOS 6 apparently has both that file
and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while
the former is not.
Moving the new CentOS 7 file to the bottom of the list should fix both
problems: the CentOS 7 system that didn't have any of the other files
in the list will still find the new one, and existing systems will still
keep using what they were using instead of preferring the new path
that may or may not be complete on some systems.
Fixes#18813.
Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba
Reviewed-on: https://go-review.googlesource.com/36429
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
It looks like this conditional may have been refactored at some point,
but the logic was still very confusing. The outer conditional checks if
the function is variadic, so there's no need to verify that in the
result. Additionally, since the function isn't variadic, there is no
reason to permit the function call if the number of input arguments is
less than the function signature requires.
Change-Id: Ia957cf83d1c900c08dd66384efcb74f0c368422e
Reviewed-on: https://go-review.googlesource.com/35491
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The doc comment for Rectangle.Intersect clearly states, "If the two
rectangles do not overlap then the zero rectangle will be returned."
Prior to this fix, calling Intersect on adjacent but non-overlapping
rectangles would return an empty but non-zero rectangle.
The fix essentially changes
if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc }
to
if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc }
(note that the > signs have become >= signs), but changing that line to:
if r.Empty() { etc }
seems clearer (and equivalent).
Change-Id: Ia654e4b9dc805978db3e94d7a9718b6366005360
Reviewed-on: https://go-review.googlesource.com/34853
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is a follow-up on https://go-review.googlesource.com/36470
and leads to a more stable fix. The above CL relied on filtering
of multiple errors on the same line to avoid more than one error
for an `if` statement of the form `if a := 10 {}`. This CL avoids
the secondary error ("missing condition in if statement") in the
first place.
For #18915.
Change-Id: I8517f485cc2305965276c17d8f8797d61ef9e999
Reviewed-on: https://go-review.googlesource.com/36479
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When running benchmarks, print "goos", "goarch", and "pkg"
labels. This makes it easier to refer to benchmark logs and understand
how they were generated. "pkg" is printed only for benchmarks located
in GOPATH.
Change-Id: I397cbdd57b9fe8cbabbb354ec7bfba59f5625c42
Reviewed-on: https://go-review.googlesource.com/36356
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
To avoid confusion caused by the term "named type" (which now just
means a type with a name, but formerly meant a type declared with
a non-alias type declaration), a type declaration now comes in two
forms: alias declarations and type definitions. Both declare a type
name, but type definitions also define new types.
Replace the use of "named type" with "defined type" elsewhere in
the spec.
For #18130.
Change-Id: I49f5ddacefce90354eb65ee5fbf10ba737221995
Reviewed-on: https://go-review.googlesource.com/36213
Reviewed-by: Rob Pike <r@golang.org>
For code such as
if a := 10 { ...
the 1.7 compiler reported
a := 10 used as value
while the 1.8 compiler reported
invalid condition, tag, or type switch guard
Changed the error message to match the 1.7 compiler.
Fixes#18915.
Change-Id: I01308862e461922e717f9f8295a9db53d5a914eb
Reviewed-on: https://go-review.googlesource.com/36470
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Removes all external uses of Linksym and Pkglookup, which are the only
two exported functions that return Syms.
Also add Duffcopy and Duffzero since they're used often enough across
SSA backends.
Passes toolstash -cmp.
Change-Id: I8d3fd048ad5cd676fc46378f09a917569ffc9b2c
Reviewed-on: https://go-review.googlesource.com/36418
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Gc's Sym type represents a package-qualified identifier, which is a
frontend concept and doesn't belong in SSA. Bonus: we can replace some
interface{} types with *obj.LSym.
Passes toolstash -cmp.
Change-Id: I456eb9957207d80f99f6eb9b8eab4a1f3263e9ed
Reviewed-on: https://go-review.googlesource.com/36415
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This change defines runtime/pprof.SetGoroutineLabels and runtime/pprof.Do, which
are used to set profiler labels on goroutines. The change defines functions
in the runtime for setting and getting profile labels, and sets and unsets
profile labels when goroutines are created and deleted. The change also adds
the package runtime/internal/proflabel, which defines the structure the runtime
uses to store profile labels.
Change-Id: I747a4400141f89b6e8160dab6aa94ca9f0d4c94d
Reviewed-on: https://go-review.googlesource.com/34198
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/35010
We shouldn't use CONVNOP for conversions between two different
nonempty interface types, because we want to update the itab
in those situations.
Fixes#18595
After this CL, we are guaranteed that itabs are unique, that is
there is only one itab per compile-time-type/concrete type pair.
See also the tests in CL 35115 and 35116 which make sure this
invariant holds even for shared libraries and plugins.
Unique itabs are required for CL 34810 (faster type switch code).
R=go1.9
Change-Id: Id27d2e01ded706680965e4cb69d7c7a24ac2161b
Reviewed-on: https://go-review.googlesource.com/35119
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Use fewer instructions to calculate the average of i and j without
overflowing at the addition.
Even if both i and j are math.MaxInt{32,64}, the sum fits into a
uint{32,64}. Because the sum of i and j is always ≥ 0, the right
shift by one does the same as a division by two. The result of the
shift operation is at most math.MaxInt{32,64} and fits again into
an int{32,64}.
name old time/op new time/op delta
SearchWrappers-4 153ns ± 3% 143ns ± 6% -6.33% (p=0.000 n=90+100)
This calculation is documented in:
https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html
Change-Id: I2be7922afc03b3617fce32e59364606c37a83678
Reviewed-on: https://go-review.googlesource.com/36332
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change defines WithLabels, Labels, Label, and ForLabels.
This is the first step of the profile labels implemention for go 1.9.
Updates #17280
Change-Id: I2dfc9aae90f7a4aa1ff7080d5747f0a1f0728e75
Reviewed-on: https://go-review.googlesource.com/34198
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
CL 18057 added underscore to most external pe symbols
on windows/386/cgo. The CL changed runtime.epclntab and
runtime.pclntab pe symbols into _runtime.pclntab and
_runtime.epclntab, and now cmd/nm cannot find them.
Revert correspondent CL 18057 changes, because most pe
symbols do not need underscore prefix.
This CL also removes code that added obj.SHOSTOBJ symbols
explicitly, because each of those was also added via
genasmsym call. These created duplicate pe symbols (like
_GetProcAddress@8 and __GetProcAddress@8), and external
linker would complain.
This CL adds new test in cmd/nm to verify go programs
built with cgo.
Fixes#18416
Change-Id: I68b1be8fb631d95ec69bd485c77c79604fb23f26
Reviewed-on: https://go-review.googlesource.com/35076
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Avoid confusing use of $(( in non-arithmetic context.
Permit added targets linux-386-387 linux-arm-arm5 to be correctly
matched against pattern argument.
Change-Id: Ib004c926457acb760c7e270fdd2f4095b1787a6d
Reviewed-on: https://go-review.googlesource.com/33492
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently the net/rpc/jsonrpc package only implements JSON-RPC version
1.0. This change updates the package's documentation with link to find
packages for JSON-RPC 2.0.
Fixes#10929
Change-Id: I3b6f1d17738a1759d7b62ab7b3ecef5b248d30ca
Reviewed-on: https://go-review.googlesource.com/36330
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL fixes two issues:
1. Load ops were initially always lowered to unsigned loads, even
for signed types. This was fine by itself however LoadReg ops
(used to re-load spilled values) were lowered to signed loads
for signed types. This meant that spills could invalidate
optimizations that assumed the original unsigned load.
2. Types were not always being maintained correctly through rules
designed to eliminate unnecessary zero and sign extensions.
Fixes#18906.
Change-Id: I95785dcadba03f7e3e94524677e7d8d3d3b9b737
Reviewed-on: https://go-review.googlesource.com/36256
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Address review comments from earlier CLs.
These are changes I was too scared to try to push
down into the original CLs (thanks, Git).
Change-Id: I0e428fad73d71bd2a7d08178cf2e856de3cef19f
Reviewed-on: https://go-review.googlesource.com/36257
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: Ib22fc435827d4a05a77a5200ac437ce00e2a4da3
Reviewed-on: https://go-review.googlesource.com/36204
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I05629567cc33fef41bc74eba4f7ff66e4851343c
Reviewed-on: https://go-review.googlesource.com/36203
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: Iec17bf2243de129942ae5fba126ec5f217be7303
Reviewed-on: https://go-review.googlesource.com/36202
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I2f349150659b6ddf6be4c675abba38dfe57ff652
Reviewed-on: https://go-review.googlesource.com/36201
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I28b20d53d20dff06eede574eb5c20359db0d3991
Reviewed-on: https://go-review.googlesource.com/36200
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I8e325d75f553b5d0b6224b56a705d2e2cb895de4
Reviewed-on: https://go-review.googlesource.com/36199
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I2d0ccdb84814537ab8b8842aa1b5f5bc0a88a0fc
Reviewed-on: https://go-review.googlesource.com/36198
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: Icdd181098f9f0e81f68bf201e6867cdd8f820300
Reviewed-on: https://go-review.googlesource.com/36197
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: Ic802483e50598def638f1e2e706d5fdf7822d32d
Reviewed-on: https://go-review.googlesource.com/36196
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I20dbc352c3df3c83a75811dd8e78c580a46b2202
Reviewed-on: https://go-review.googlesource.com/36195
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I4cf05b076d81b780c87a31378523929b5da8964b
Reviewed-on: https://go-review.googlesource.com/36194
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I7c5dde6e7fe4f390e6607303b4d42535c674eac3
Reviewed-on: https://go-review.googlesource.com/36193
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I6ee5b053683034ea9462a9a0a4ea4f5ad24fa5a1
Reviewed-on: https://go-review.googlesource.com/36192
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: Icb3f168ade91e7da5fcab89ac75b768daefff359
Reviewed-on: https://go-review.googlesource.com/36191
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This is one CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I63f578f5ac99c707b599ac5659293c46b275567d
Reviewed-on: https://go-review.googlesource.com/36190
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This CL makes a few naming changes to break dependencies
between different parts of the go command, to make it easier
to split into different packages.
This is the first CL in a long sequence of changes to break up the
go command from one package into a plausible group of packages.
This sequence is concerned only with moving code, not changing
or cleaning up code. There will still be more cleanup after this sequence.
The entire sequence will be submitted together: it is not a goal
for the tree to build at every step.
For #18653.
Change-Id: I69a98b9ea48e61b1e1cda95273d29860b525415f
Reviewed-on: https://go-review.googlesource.com/36129
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, Go programs in c-archive or c-shared buildmodes
would not handle SIGPIPE. That leads to surprising behaviour where
writes on a closed pipe or socket would raise SIGPIPE and terminate
the program. This CL changes the Go runtime to handle
SIGPIPE regardless of buildmode. In addition, SIGPIPE from non-Go
code is forwarded.
This is a refinement of CL 32796 that fixes the case where a non-default
handler for SIGPIPE is installed by the host C program.
Fixes#17393
Change-Id: Ia41186e52c1ac209d0a594bae9904166ae7df7de
Reviewed-on: https://go-review.googlesource.com/35960
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If there is a defer, and that defer recovers, then the caller
can see all of the output parameters. That means that we must
mark all the output parameters live at any point which might panic.
If there is no defer then this is not necessary. This is implemented.
We could also detect whether there is a recover in any of the defers.
If not, we would need to mark only output params that the defer
actually references (and the closure mechanism already does that).
This is not implemented.
Fixes#18860.
Change-Id: If984fe6686eddce9408bf25e725dd17fc16b8578
Reviewed-on: https://go-review.googlesource.com/36030
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
sigtramp was calling sigtrampgo and depending on the fact that
the 3rd argument slot will not be modified on return. Our calling
convention doesn't guarantee that. Avoid that assumption.
There's no actual bug here, as sigtrampgo does not in fact modify its
argument slots. But I found this while working on the dead stack slot
clobbering tool. https://go-review.googlesource.com/c/23924/
Change-Id: Ia7e791a2b4c1c74fff24cba8169e7840b4b06ffc
Reviewed-on: https://go-review.googlesource.com/36216
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The name lookups are unrooted; the test should be unrooted too.
Correctly skips the tests if the DNS config specifies a domain
suffix that has a wildcard entry causing all unrooted names to resolve.
Change-Id: I80470326a5d332f3b8d64663f765fd304c5e0811
Reviewed-on: https://go-review.googlesource.com/36253
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Use (-x)>>63 instead of ((x-1)>>63)^-1 to get a mask that
is 0 when x is 0 and all ones when x is positive.
Saves one instruction when slicing.
Change-Id: Ib46d53d3aac6530ac481fa2f265a6eadf3df0567
Reviewed-on: https://go-review.googlesource.com/35641
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Instead of always appending to c.Values,
choose whichever slice is larger;
b.Values will be set to nil anyway.
Appending once instead of in a loop also
limits slice growth to once per function call
and is more efficient.
Reduces max rss for the program in #18602 by 6.5%,
and eliminates fuseBlockPlain from the alloc_space
pprof output. fuseBlockPlain previously accounted
for 16.74% of allocated memory.
Updates #18602.
Change-Id: I417b03722d011a59a679157da43dc91f4425210e
Reviewed-on: https://go-review.googlesource.com/35114
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Remove rotate generation from walk. Remove OLROT and ssa.Lrot* opcodes.
Generate rotates during SSA lowering for architectures that have them.
This CL will allow rotates to be generated in more situations,
like when the shift values are determined to be constant
only after some analysis.
Fixes#18254
Change-Id: I8d6d684ff5ce2511aceaddfda98b908007851079
Reviewed-on: https://go-review.googlesource.com/34232
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When we discover a relation x <= len(s), also discover the relation
x <= cap(s). That way, in situations like:
a := s[x:] // tests 0 <= x <= len(s)
b := s[:x] // tests 0 <= x <= cap(s)
the second check can be eliminated.
Fixes#16813
Change-Id: Ifc037920b6955e43bac1a1eaf6bac63a89cfbd44
Reviewed-on: https://go-review.googlesource.com/33633
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexandru Moșoi <alexandru@mosoi.ro>
Reviewed-by: David Chase <drchase@google.com>
CSE opportunities were being missed for commutative ops. We used to
order the args of commutative ops (by arg ID) once at the start of CSE.
But that may not be enough.
i1 = (Load ptr mem)
i2 = (Load ptr mem)
x1 = (Add i1 j)
x2 = (Add i2 j)
Equivalent commutative ops x1 and x2 may not get their args ordered in
the same way because because at the start of CSE, we don't know that
the i values will be CSEd. If x1 and x2 get opposite orders we won't
CSE them.
Instead, (re)order the args of commutative operations by their
equivalence class IDs each time we partition an equivalence class.
Change-Id: Ic609fa83b85299782a5e85bf93dc6023fccf4b0c
Reviewed-on: https://go-review.googlesource.com/33632
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>
Fixes#10561.
Provides a better diagnostic message for failed type switch
satisfaction in the case that a value receiver is being used
in place of the pointer receiver that implements and satisfies
the interface.
Change-Id: If8c13ba13f2a8d81bf44bac7c3a66c12921ba921
Reviewed-on: https://go-review.googlesource.com/35235
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Tests that use TestMain might never call m.Run(), and simply return
from TestMain. In that case, the iOS test harness never sees the
PASS from the testing framework and assumes the test failed.
Allow an exit with exit code 0 to also mean test success, thereby
fixing the objdump test on iOS.
Change-Id: I1fe9077b05931aa0905e41b88945cd153c5b35b6
Reviewed-on: https://go-review.googlesource.com/36065
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#15055.
Updates exprfmt printing using fmt verb "%v" to check that n.Left
is non-nil before attempting to print it, otherwise we'll print
the nodes in the list using verb "%.v".
Credit to @mdempsky for this approach and for finding
the root cause of the issue.
Change-Id: I20a6464e916dc70d5565e145164bb9553e5d3865
Reviewed-on: https://go-review.googlesource.com/25361
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The binary export format embeds type definitions inline as necessary,
so there's no need to add them to exportlist. Also, constants are
embedded directly by value, so they can be omitted too.
Change-Id: Id1879eb97c298a5a52f615cf9883c346c7f7bd69
Reviewed-on: https://go-review.googlesource.com/36170
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
When switching to the new parser, I changed cmd/compile to handle iota
per an intuitive interpretation of how nested constant declarations
should work (which also matches go/types).
Note: if we end up deciding that the current spec wording is
intentional (i.e., confirming gccgo's current behavior), the test will
need to be updated to expect 4 instead of 1.
Updates #15550.
Change-Id: I441f5f13209f172b73ef75031f2a9daa5e985277
Reviewed-on: https://go-review.googlesource.com/36122
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sometimes STEXT symbols point to the first byte of .data
section, instead of the end of .text section. But, while writing
pe symbol table, we should treat them as if they belong to the
.text section. Change pe symbol table records for these symbols.
Fixes#14710
Change-Id: I1356e61aa8fa37d590d7b1677b2bac214ad0ba4e
Reviewed-on: https://go-review.googlesource.com/35272
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The comment for maxPtrmaskBytes implied that the value was still 16,
but that changed in CL 10815.
Change-Id: I86e304bc7d9d1a0a6b22b600fefcc1325e4372d9
Reviewed-on: https://go-review.googlesource.com/36120
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Adds helper function to auto-skip tests when DNS returns
a successful response for a domain known not to exist.
The error from `net.LookupHost` is intentionally ignored
because the DNS tests will fail anyway if there are issues
unrelated to NXDOMAIN responses.
Fixes#17884
Change-Id: I729391bd702218507561818668f791331295299e
Reviewed-on: https://go-review.googlesource.com/34516
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If -test.timeout is not specified to go test, it will time out after
a default 10 minutes.
The iOS exec wrapper also contains a fail safe timeout mechanism for
a stuck device. However, if no explicit -test.timeout is specified,
it will use a timeout of 0, plus some constant amount.
Use the same default timeout in the exec wrapper as for go test,
10 minutes.
Change-Id: I6465ccd9f7b9ce08fa302e6697f7938a0ea9af34
Reviewed-on: https://go-review.googlesource.com/36062
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Notably, this change fixes the TestTCPReadWriteAllocs test because
the errnoErr wrapper is now used, elimitating the allocation for
common errnos.
The change to Dup is caused by a CL 8095 that changed the Dup* calls
to use Syscall instead of RawSyscall.
Found while working on the new iOS builders.
Change-Id: I44ab9dcad27db190e175aa149865b33944f48674
Reviewed-on: https://go-review.googlesource.com/36061
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The iOS exec wrapper use the constant bundle id "golang.gotest" for
running Go programs on iOS. However, that only happens to work on
the old iOS builders where their provisioning profile covers
that bundle id.
Expand the detection script to list all available provisioning
profiles for the attached device and include the bundle id in the
GOIOS_APP_ID environment variable.
To allow the old builders to continue, the "golang.gotest" bundle
id is used as a fallback if only the app id prefix is specified in
GOIOS_APP_ID.
For the new builders.
Change-Id: I8baa1d4d57f845de851c3fad3f178e05e9a01b17
Reviewed-on: https://go-review.googlesource.com/36060
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On (at least) macOS 10.12, the `security cms` subcommand used by the
iOS detection script will output an error to stderr. The command
otherwise succeeds, but the extra line confuses a later parsing step.
To fix it, use only stdout and ignore stderr from every command run
by detect.go.
For the new iOS builders.
Change-Id: Iee426da7926d7f987ba1be061fa92ebb853ef53d
Reviewed-on: https://go-review.googlesource.com/36059
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
X.509v1 certificates are ancient and should be dead. (They are even
prohibited by the Baseline requirements, section 7.1.1.)
However, there are a number of v1 roots from the 1990's that are still
in operation. Thus crypto/x509.Certificate.CheckSignatureFrom allows
X.509v1 certificates to sign other certificates.
The chain building code, however, only allows v1 certificates to sign
others if they're a root. This change adds a test to check that.
Change-Id: Ib8d81e522f30d41932b89bdf3b19ef3782d8ec12
Reviewed-on: https://go-review.googlesource.com/34383
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
ConnectionState.NegotiatedProtocol's documentation implies that it will
always be from Config.NextProtos. This commit clarifies that there is no
guarantee.
This commit also adds a note to
ConnectionState.NegotiatedProtocolIsMutual, making it clear that it is
client side only.
Fixes#18841
Change-Id: Icd028af8042f31e45575f1080c5e9bd3012e03d7
Reviewed-on: https://go-review.googlesource.com/35917
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing implementation falls back to using image.At()
for each pixel when encoding an *image.YCbCr which is
inefficient and causes many memory allocations.
This change makes the jpeg encoder directly read Y, Cb, and Cr
pixel values.
benchmark old ns/op new ns/op delta
BenchmarkEncodeYCbCr-4 43990846 24201148 -44.99%
benchmark old MB/s new MB/s speedup
BenchmarkEncodeYCbCr-4 20.95 38.08 1.82x
Fixes#18487
Change-Id: Iaf2ebc646997e3e1fffa5335f1b0d642e15bd453
Reviewed-on: https://go-review.googlesource.com/34773
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
Whoever called toint() is expecting the {Mpint, Mpflt, Mpcplx} arg to
be converted to an integer expression, so it never makes sense to
report an error as "constant X truncated to real".
Fixes#11580
Change-Id: Iadcb105f0802358a7f77188c2b1e63fe80c5580c
Reviewed-on: https://go-review.googlesource.com/34638
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
As per RFC 2046, the boundary for multipart MIME is allowed up to 70
characters. The old SetBoundary implementation only allowed up to 69 so
this bumps it to the correct value of 70.
The relevant RFC is at https://www.ietf.org/rfc/rfc2046.txt and section
5.1.1 defines the boundary specification.
Fixes#18793
Change-Id: I91d2ed4549c3d27d6049cb473bac680a750fb520
Reviewed-on: https://go-review.googlesource.com/35830
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
By grouping all the logic into constDecl, we're able to get rid of the
lastconst and lasttype globals, and simplify the logic slightly. Still
clunky, but much easier to reason about.
Change-Id: I446696c31084b3bfc1fd5d3651655a81ddd159ab
Reviewed-on: https://go-review.googlesource.com/36023
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Algorithmic improvements here are hard.
Lifting a lookup out of the loop helps a little, though.
To compile the code in #17926:
name old s/op new s/op delta
Real 146 ± 3% 140 ± 4% -3.87% (p=0.002 n=10+10)
User 143 ± 3% 139 ± 4% -3.08% (p=0.005 n=10+10)
Sys 8.28 ±35% 8.08 ±28% ~ (p=0.684 n=10+10)
Updates #17926.
Change-Id: Ic255ac8b7b409c1a53791058818b7e2cf574abe3
Reviewed-on: https://go-review.googlesource.com/33305
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Prior to this change it was possible to see interleaved messages:
<<<
=== RUN Test/LongLongLongLongName48
=== RUN Test/LongLon=== RUN Test/LongLongLongLongName50
gLongLongName49
=== RUN Test/LongLongLongLongName51
>>>
This change fixes it such that you see:
<<<
=== RUN Test/LongLongLongLongName48
=== RUN Test/LongLongLongLongName49
=== RUN Test/LongLongLongLongName50
=== RUN Test/LongLongLongLongName51
>>>
Fixes#18741
Change-Id: I2529d724065dc65b3e9eb3d7cbeeda82a2d0cfd4
Reviewed-on: https://go-review.googlesource.com/35556
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Make the documentation more explicit that it is not safe to directly
compare Value. Get straight to the point on how to do it correctly.
Updates #18871
Change-Id: I2aa3253f779636b2f72a1aae8c9bb45d3c32c902
Reviewed-on: https://go-review.googlesource.com/36018
Reviewed-by: Keith Randall <khr@golang.org>
For #18130.
f8b4123613 [dev.typealias] spec: use term 'embedded field' rather than 'anonymous field'
9ecc3ee252 [dev.typealias] cmd/compile: avoid false positive cycles from type aliases
49b7af8a30 [dev.typealias] reflect: add test for type aliases
9bbb07ddec [dev.typealias] cmd/compile, reflect: fix struct field names for embedded byte, rune
43c7094386 [dev.typealias] reflect: fix StructOf use of StructField to match StructField docs
9657e0b077 [dev.typealias] cmd/doc: update for type alias
de2e5459ae [dev.typealias] cmd/compile: declare methods after resolving receiver type
9259f3073a [dev.typealias] test: match gccgo error messages on alias2.go
5d92916770 [dev.typealias] cmd/compile: change Func.Shortname to *Sym
a7c884efc1 [dev.typealias] go/internal/gccgoimporter: support for type aliases
5802cfd900 [dev.typealias] cmd/compile: export/import test cases for type aliases
d7cabd40dd [dev.typealias] go/types: clarified doc string
cc2dcce3d7 [dev.typealias] cmd/compile: a few better comments related to alias types
5c160b28ba [dev.typealias] cmd/compile: improved error message for cyles involving type aliases
b2386dffa1 [dev.typealias] cmd/compile: type-check type alias declarations
ac8421f9a5 [dev.typealias] cmd/compile: various minor cleanups
f011e0c6c3 [dev.typealias] cmd/compile, go/types, go/importer: various alias related fixes
49de5f0351 [dev.typealias] cmd/compile, go/importer: define export format and implement importing of type aliases
5ceec42dc0 [dev.typealias] go/types: export TypeName.IsAlias so clients can use it
aa1f0681bc [dev.typealias] go/types: improved Object printing
c80748e389 [dev.typealias] go/types: remove some more vestiges of prior alias implementation
80d8b69e95 [dev.typealias] go/types: implement type aliases
a917097b5e [dev.typealias] go/build: add go1.9 build tag
3e11940437 [dev.typealias] cmd/compile: recognize type aliases but complain for now (not yet supported)
e0a05c274a [dev.typealias] cmd/gofmt: added test cases for alias type declarations
2e5116bd99 [dev.typealias] go/ast, go/parser, go/printer, go/types: initial type alias support
Change-Id: Ia65f2e011fd7195f18e1dce67d4d49b80a261203
First steps towards defining type aliases in the spec.
This is a nomenclature clarification, not a language change.
The spec used all three terms 'embedded type', 'anonymous field',
and 'embedded field'. Users where using the terms inconsistently.
The notion of an 'anonymous' field was always misleading since they
always had a de-facto name. With type aliases that name becomes even
more important because we may have different names for the same type.
Use the term 'embedded field' consistently and remove competing
terminology.
For #18130.
Change-Id: I2083bbc85788cab0b2e2cb1ff58b2f979491f001
Reviewed-on: https://go-review.googlesource.com/35108
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The test.bash script in misc/cgo/testsanitizers use GOOS, not GOHOSTOS.
Fix the dist check from gohostos to goos accordingly.
The error was masked on the builders because they run on a darwin host
where the sanitizers tests never ran.
With this change, the Android test suite completes successfully on
Android/amd64.
Change-Id: Id7690429f78c6ac7a26fc9118d913b719b565bb2
Reviewed-on: https://go-review.googlesource.com/35959
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This avoids errors like
./traceback.go:80:2: call of non-function C.f1
I filed https://gcc.gnu.org/PR79289 for the GCC problem. I think this
is a bug in GCC, and it may be fixed before the final GCC 7 release.
This CL is correct either way.
Fixes#18855.
Change-Id: I0785a7b7c5b1d0ca87b454b5eca9079f390fcbd4
Reviewed-on: https://go-review.googlesource.com/35919
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Author of CL 35150 forgot to run mkalldocs.sh to update
the autogenerated alldocs.go
Change-Id: Ib824562db6044702456a221a8c6f9af412927a98
Reviewed-on: https://go-review.googlesource.com/35952
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously the following could happen, though in practice it would
be rare.
Goroutine 1:
(*Tx).QueryContext begins a query, passing in userContext
Goroutine 2:
(*Tx).awaitDone starts to wait on the context derived from the passed in context
Goroutine 1:
(*Tx).grabConn returns a valid (*driverConn)
The (*driverConn) passes to (*DB).queryConn
Goroutine 3:
userContext is canceled
Goroutine 2:
(*Tx).awaitDone unblocks and calls (*Tx).rollback
(*driverConn).finalClose obtains dc.Mutex
(*driverConn).finalClose sets dc.ci = nil
Goroutine 1:
(*DB).queryConn obtains dc.Mutex in withLock
ctxDriverPrepare accepts dc.ci which is now nil
ctxCriverPrepare panics on the nil ci
The fix for this is to guard the Tx methods with a RWLock
holding it exclusivly when closing the Tx and holding a read lock
when executing a query.
Fixes#18719
Change-Id: I37aa02c37083c9793dabd28f7f934a1c5cbc05ea
Reviewed-on: https://go-review.googlesource.com/35550
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fix is less pervasive than it seems. The only change affecting
formatting is on printer.go:760. The remaining changes have no effect
on formatting since the value of p.level is ignored except on this
specific line.
The remaining changes are:
- renamed adjBlock to funcBody since that's how it is used
- introduced new printer field 'level' tracking the composite
literal nesting level
- update/restore the composite literal nesting level as needed
Fixes#18782.
Change-Id: Ie833a9b5a559c4ec0f2eef2c5dc97aa263dca53a
Reviewed-on: https://go-review.googlesource.com/35811
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Modules appear in the moduledata linked list in the order they are
loaded by the dynamic loader, with one exception: the
firstmoduledata itself the module that contains the runtime.
This is not always the first module (when using -buildmode=shared,
it is typically libstd.so, the second module).
The order matters for typelinksinit, so we swap the first module
with whatever module contains the main function.
Updates #18729
This fixes the test case extracted with -linkshared, and now
go test -linkshared encoding/...
passes. However the original issue about a plugin failure is not
yet fixed.
Change-Id: I9f399ecc3518e22e6b0a350358e90b0baa44ac96
Reviewed-on: https://go-review.googlesource.com/35644
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Slower builders were failing TestQueryContext because the cancel
and return to conn pool happens async. TestQueryContext already
uses a wait method for this reason. Use the same method for
other context tests.
Fixes#18759
Change-Id: I84cce697392b867e4ebdfadd38027a06ca14655f
Reviewed-on: https://go-review.googlesource.com/35750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The runtime internal structField interprets name=="" as meaning anonymous,
but the exported reflect.StructField has always set Name, even for anonymous
fields, and also set Anonymous=true.
The initial implementation of StructOf confused the internal and public
meanings of the StructField, expecting the runtime representation of
anonymous fields instead of the exported reflect API representation.
It also did not document this fact, so that users had no way to know how
to create an anonymous field.
This CL changes StructOf to use the previously documented interpretation
of reflect.StructField instead of an undocumented one.
The implementation of StructOf also, in some cases, allowed creating
structs with unexported fields (if you knew how to ask) but set the
PkgPath incorrectly on those fields. Rather than try to fix that, this CL
changes StructOf to reject attempts to create unexported fields.
(I think that may be the right design choice, not just a temporary limitation.
In any event, it's not the topic for today's work.)
For #17766.
Fixes#18780.
Change-Id: I585a4e324dc5a90551f49d21ae04d2de9ea04b6c
Reviewed-on: https://go-review.googlesource.com/35731
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Update docs on correspondence between Go releases and GCC releases.
Update C type that corresponds to Go type `int`.
Drop out of date comments about Ubuntu and RTEMS.
Change-Id: Ic1b5ce9f242789af23ec3b7e7a64c9d257d6913e
Reviewed-on: https://go-review.googlesource.com/35631
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The presence of Request.GetBody being set on a request was causing all
redirected requests to have a body, even if the redirect status didn't
warrant one.
This bug came from 307/308 support (https://golang.org/cl/29852) which
removed the line that set req.Body to nil after POST/PUT redirects.
Change-Id: I2a4dd5320f810ae25cfd8ea8ca7c9700e5dbd369
Reviewed-on: https://go-review.googlesource.com/35633
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Otherwise we don't emit any required ELF relocations when doing an
external link, because elfrelocsect skips unreachable symbols.
Fixes#18745.
Change-Id: Ia3583c41bb6c5ebb7579abd26ed8689370311cd6
Reviewed-on: https://go-review.googlesource.com/35590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
memmove used to use 2 2-byte load/store pairs to move 4 bytes.
When the result is loaded with a single 4-byte load, it caused
a store to load fowarding stall. To avoid the stall,
special case memmove to use 4 byte ops for the 4 byte copy case.
We already have a special case for 8-byte copies.
386 already specializes 4-byte copies.
I'll do 2-byte copies also, but not for 1.8.
benchmark old ns/op new ns/op delta
BenchmarkIssue18740-8 7567 4799 -36.58%
3-byte copies get a bit slower. Other copies are unchanged.
name old time/op new time/op delta
Memmove/3-8 4.76ns ± 5% 5.26ns ± 3% +10.50% (p=0.000 n=10+10)
Fixes#18740
Change-Id: Iec82cbac0ecfee80fa3c8fc83828f9a1819c3c74
Reviewed-on: https://go-review.googlesource.com/35567
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The constant propagation rules selected the wrong operand to
propagate. So MOVDNE (move if not equal) propagated operands as if
it were a MOVDEQ (move if equal).
Fixes#18735.
Change-Id: I87ac469172f9df7d5aabaf7106e2936ce54ae202
Reviewed-on: https://go-review.googlesource.com/35498
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is needed for typical tests with gccgo, as it passes the
LD_LIBRARY_PATH environment variable to the new program.
Change-Id: I9bf4b0dbdff63f5449c7fcb8124eaeab10ed7f34
Reviewed-on: https://go-review.googlesource.com/35481
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
With GCC 7 (not yet released), cgo fails with errors like
./sigaltstack.go:65:8: call of non-function C.restoreSignalStack
I do not know precisely why. Explicitly declaring that there are no
arguments to the static function is a simple fix for the debug info.
Change-Id: Id96e1cb1e55ee37a9f1f5ad243d7ee33e71584ac
Reviewed-on: https://go-review.googlesource.com/35480
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When nilcheck runs, the values in a block are not in any particular
order. So any facts derived from examining the blocks shouldn't be
used until we reach the next block.
This is suboptimal as it won't eliminate nil checks within a block.
But it's probably a better fix for now as it is a much smaller change
than other strategies for fixing this bug.
nilptr3.go changes are mostly because for this pattern:
_ = *p
_ = *p
either nil check is fine to keep, and this CL changes which one
the compiler tends to keep.
There are a few regressions from code like this:
_ = *p
f()
_ = *p
For this pattern, after this CL we issue 2 nil checks instead of one.
(For the curious, this happens because intra-block nil check
elimination now falls to CSE, not nilcheck proper. The former
pattern has two nil checks with the same store argument. The latter
pattern has two nil checks with different store arguments.)
Fixes#18725
Change-Id: I3721b494c8bc9ba1142dc5c4361ea55c66920ac8
Reviewed-on: https://go-review.googlesource.com/35485
Reviewed-by: Cherry Zhang <cherryyz@google.com>
pprof.WriteHeapProfile is shorthand for
pprof.Lookup("heap").WriteTo(f, 0).
The second parameter is debug.
If it is non-zero, pprof writes legacy-format
pprof output, which compilebench can parse.
Fixes#18641
Change-Id: Ica69adeb9809e9b5933aed943dcf4a07910e43fc
Reviewed-on: https://go-review.googlesource.com/35484
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently we check that all roots are marked as soon as gcMarkDone
decides to transition from mark 1 to mark 2. However, issue #16083
indicates that there may be a race where we try to complete mark 1
while a worker is still scanning a stack, causing the root mark check
to fail.
We don't yet understand this race, but as a simple mitigation, move
the root check to after gcMarkDone performs a ragged barrier, which
will force any remaining workers to finish their current job.
Updates #16083. This may "fix" it, but it would be better to
understand and fix the underlying race.
Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2
Reviewed-on: https://go-review.googlesource.com/35353
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
We already do this for shared libraries. Do it for plugins also.
Suggestions on how to test this would be welcome.
I'd like to get this in for 1.8. It could lead to mysterious
hangs when using plugins.
Fixes#18676
Change-Id: I03209b096149090b9ba171c834c5e59087ed0f92
Reviewed-on: https://go-review.googlesource.com/35117
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
The bug subcommand opens up the browser instead of printing information.
Fixes help message to reflect that.
Fixes#18630.
Change-Id: I660c94bc65ef1994292cfd72d08a544699545701
Reviewed-on: https://go-review.googlesource.com/35150
Reviewed-by: Russ Cox <rsc@golang.org>
As is, they were fully vulnerable to the Lucky13 attack. The SHA1
variants implement limited countermeasures (see f28cf8346c) but the
SHA256 ones are apparently used rarely enough (see 8741504888) that
it's not worth the extra code.
Instead, disable them by default and update the warning.
Updates #13385
Updates #15487
Change-Id: I45b8b716001e2fa0811b17e25be76e2512e5abb2
Reviewed-on: https://go-review.googlesource.com/35290
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It looks like it should be there, although I couldn't find a test
case that fails without it. ZeroWB is probably never generated now:
zeroing an initialized heap object is done by making an autotmp on
stack, zeroing it, and copying (typedmemmove) to heap.
Passes "toolstash -cmp" on std.
Change-Id: I702a59759e33fb8cc2a34a3b3029e7540aca080a
Reviewed-on: https://go-review.googlesource.com/35250
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 5232 added TestServerHijackGetsBackgroundByte, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.
Updates #17906.
Updates #18657.
Change-Id: I3c2f73760b0f767f3f9ed2698c855372170e0481
Reviewed-on: https://go-review.googlesource.com/35178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 35234 added TestServerHijackGetsBackgroundByte_big, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.
Updates #17906.
Updates #18658.
Change-Id: Icaf3fe3600d586515ecd92aca874104ea81ce6b9
Reviewed-on: https://go-review.googlesource.com/35179
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The working directory is now adjusted to match the typical Go test
working directory in main, as the old trick for adjusting earlier
stopped working with the latest version of LLDB bugs.
That means the small number of places where testdata files are
read before main is called no longer work. This CL adjusts those
reads to happen after main is called. (This has the bonus effect of
not reading some benchmark testdata files in all.bash.)
Fixes compress/bzip2, go/doc, go/parser, os, and time package
tests on the iOS builder.
Change-Id: If60f026aa7848b37511c36ac5e3985469ec25209
Reviewed-on: https://go-review.googlesource.com/35255
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previously, if the Hijack called stopped the background read call
which read a byte, that byte was sitting in memory, buffered, ready to
be Read by Hijack's returned bufio.Reader, but it wasn't yet in the
bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1
byte fewer.
This matters for callers who wanted to stitch together any buffered
data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's
returned net.Conn. Otherwise there was no way for callers to know a
byte was read.
Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13
Reviewed-on: https://go-review.googlesource.com/35232
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Previously, mkpackage jumbled together three unrelated tasks: handling
package declarations, clearing imports from processing previous source
files, and assigning a default value to outfile.
Change-Id: I1e124335768aeabfd1a6d9cc2499fbb980d951cf
Reviewed-on: https://go-review.googlesource.com/35124
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Another change in behvaior (bug) in LLDB. Despite the fact that
LLDB can dump the symtab of our test binaries and show the function
addresses, it can no longer call the functions. This means the chdir
trick on signal is failing.
This CL uses a new trick. For iOS, the exec script passes the change
in directory as an argument, and it is processed early by the test
harness generated by cmd/go.
For the iOS builders.
Change-Id: I8f5d0f831fe18de99f097761f89c5184d5bf2afb
Reviewed-on: https://go-review.googlesource.com/35152
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
mkpost.go replaces all variables prefixed with 'X_' with '_' on s390x
because most of them do not need to be exposed. X__val is being used
by a third party library so it turns out we do need to expose it on
s390x (it is already exposed on all other Linux architectures).
Fixes#17298 and updates #18632.
Change-Id: Ic03463229a5f75ca41a4a4b50300da4b4d892d45
Reviewed-on: https://go-review.googlesource.com/30130
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Make sure that the same type and itab generated in two
different plugins are actually the same thing.
See also CL 35115
Change-Id: I0c1ecb039d7e2bf5a601d58dfa162a435ae4ef76
Reviewed-on: https://go-review.googlesource.com/35116
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
When traceback sees reflect.makeFuncStub (or reflect.methodValueCall)
on the stack, it expects to be able to get the *reflect.makeFuncImpl
(or *reflect.methodValue) for that call from the first outgoing
argument slot of makeFuncStub/methodValueCall.
However, currently this object isn't necessarily kept live across
makeFuncStub. This means it may get garbage collected while in a
reflect call and reused for something else. If we then try to
traceback, the runtime will see a corrupted makeFuncImpl object and
panic. This was not a problem in previous releases because we always
kept arguments live across the whole function. This became a problem
when we stopped doing this.
Fix this by using reflect.KeepAlive to keep the
makeFuncImpl/methodValue live across all of callReflect/callMethod,
which in turn keeps it live as long as makeFuncStub/methodValueCall
are on the stack.
Fixes#18635.
Change-Id: I91853efcf17912390fddedfb0230648391c33936
Reviewed-on: https://go-review.googlesource.com/35151
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
C-only symbols are excluded from pclntab because of a quirk of darwin,
where functions are referred to by an exported symbol so dynamic
relocations de-duplicate to the host binary module and break unwinding.
This doesn't happen on ELF systems because the linker always refers to
unexported module-local symbols, so we don't need this condition.
And the current logic for excluding some functions breaks the module
verification code in moduledataverify1. So disable this for plugins
on linux.
(In 1.9, it will probably be necessary to introduce a module-local
symbol reference system on darwin to fix a different bug, so all of
this onlycsymbol code made be short-lived.)
With this CL, the tests in CL 35116 pass.
Change-Id: I517d7ca4427241fa0a91276c462827efb9383be9
Reviewed-on: https://go-review.googlesource.com/35190
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Known issues:
- needs many more tests
- duplicate method declarations via type alias names are not detected
- type alias cycle error messages need to be improved
- need to review setup of byte/rune type aliases
For #18130.
Change-Id: Icc2fefad6214e5e56539a9dcb3fe537bf58029f8
Reviewed-on: https://go-review.googlesource.com/35121
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Ranging over an array causes the array to be copied over to the
stack, which cause large re-growths. Instead, we should iterate
over slices of the array.
Also, assigning a large struct literal uses the stack even
though the actual fields being populated are small in comparison
to the entirety of the struct (see #18636).
Fixing the stack growth does not alter CPU-time performance much
since the stack-growth and copying was such a tiny portion of the
compression work:
name old time/op new time/op delta
Encode/Digits/Default/1e4-8 332µs ± 1% 332µs ± 1% ~ (p=0.796 n=10+10)
Encode/Digits/Default/1e5-8 5.07ms ± 2% 5.05ms ± 1% ~ (p=0.815 n=9+8)
Encode/Digits/Default/1e6-8 53.7ms ± 1% 53.9ms ± 1% ~ (p=0.075 n=10+10)
Encode/Twain/Default/1e4-8 380µs ± 1% 380µs ± 1% ~ (p=0.684 n=10+10)
Encode/Twain/Default/1e5-8 5.79ms ± 2% 5.79ms ± 1% ~ (p=0.497 n=9+10)
Encode/Twain/Default/1e6-8 61.5ms ± 1% 61.8ms ± 1% ~ (p=0.247 n=10+10)
name old speed new speed delta
Encode/Digits/Default/1e4-8 30.1MB/s ± 1% 30.1MB/s ± 1% ~ (p=0.753 n=10+10)
Encode/Digits/Default/1e5-8 19.7MB/s ± 2% 19.8MB/s ± 1% ~ (p=0.795 n=9+8)
Encode/Digits/Default/1e6-8 18.6MB/s ± 1% 18.5MB/s ± 1% ~ (p=0.072 n=10+10)
Encode/Twain/Default/1e4-8 26.3MB/s ± 1% 26.3MB/s ± 1% ~ (p=0.616 n=10+10)
Encode/Twain/Default/1e5-8 17.3MB/s ± 2% 17.3MB/s ± 1% ~ (p=0.484 n=9+10)
Encode/Twain/Default/1e6-8 16.3MB/s ± 1% 16.2MB/s ± 1% ~ (p=0.238 n=10+10)
Updates #18636Fixes#18625
Change-Id: I471b20339bf675f63dc56d38b3acdd824fe23328
Reviewed-on: https://go-review.googlesource.com/35122
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The iOS test harness has set a breakpoint early in the life of Go
programs so that it can change the current working directory using
information only available from the host debugger. Somewhere in the
upgrade to iOS 10 / XCode 8.2, breakpoints stopped working. This
may be an LLDB bug, or a bug in the ios-deploy LLDB scripts, it's
not clear.
Work around the problem by giving up on breakpoints. Instead, early
in the life of every test binary built for iOS, send (and ignore) a
SIGUSR2 signal. The debugger will catch this, giving the script
go_darwin_arm_exec a chance to change the working directory.
For the iOS builders.
Change-Id: I7476531985217d0c76bc176904c48379210576c2
Reviewed-on: https://go-review.googlesource.com/34926
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make sure that the same type and itab generated in two
different shared library are actually the same thing.
Change-Id: Ica45862d65ff8bc7ad04d59a41f57223f71224cd
Reviewed-on: https://go-review.googlesource.com/35115
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Use R11 (a caller-saved temp register) instead of RBX (a callee-saved
register).
I believe this only affects linux/amd64, since it is the only platform
with a non-trivial cgoSigtramp implementation.
Updates #18328.
Change-Id: I3d35c4512624184d5a8ece653fa09ddf50e079a2
Reviewed-on: https://go-review.googlesource.com/35068
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The test was previously an integration test, relying on luck and many
goroutines and lots of time to hit the path to be tested.
Instead, rewrite the test to exactly hit the path to be tested, in one
try, in one goroutine.
Fixes#18205
Change-Id: I63cd513316344bfd7375dcc452c1c396dec0e49f
Reviewed-on: https://go-review.googlesource.com/35107
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
cmd/compile:
- remove crud from prior alias implementation
- better comments in places
go/types:
- fix TypeName.IsAlias predicate
- more tests
go/importer (go/internal/gcimporter15):
- handle "@" format for anonymous fields using aliases
(currently tested indirectly via x/tools/gcimporter15 tests)
For #18130.
Change-Id: I23a6d4e3a4c2a5c1ae589513da73fde7cad5f386
Reviewed-on: https://go-review.googlesource.com/35101
Reviewed-by: Alan Donovan <adonovan@google.com>
This defines the (tentative) export/import format for type aliases.
The compiler doesn't support type aliases yet, so while the code is present
it is guarded with a flag.
The export format for embedded (anonymous) fields now has three modes (mode 3 is new):
1) The original type name and the anonymous field name are the same, and the name is exported:
we don't need the field name and write "" instead
2) The original type name and the anonymous field name are the same, and the name is not exported:
we don't need the field name and write "?" instead, indicating that there is package info
3) The original type name and the anonymous field name are different:
we do need the field name and write "@" followed by the field name (and possible package info)
For #18130.
Change-Id: I790dad826757233fa71396a210f966c6256b75d3
Reviewed-on: https://go-review.googlesource.com/35100
Reviewed-by: Alan Donovan <adonovan@google.com>
- added internal isAlias predicated and test
- use it for improved Object printing
- when printing a basic type object, don't repeat type name
(i.e., print "type int" rather than "type int int")
- added another test to testdata/decls4.src
For #18130.
Change-Id: Ice9517c0065a2cc465c6d12f87cd27c01ef801e6
Reviewed-on: https://go-review.googlesource.com/35093
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Now a TypeName is just that: a name for a type (not just Named and Basic types
as before). If it happens to be an alias, its type won't be a Named or Basic type,
or it won't have the same name. We can determine this externally.
It may be useful to provide a helper predicate to make that test easily accessible,
but we can get to that if there's an actual need.
The field/method lookup code has become more general an simpler, which is a good sign.
The changes in methodset.go are symmetric to the changes in lookup.go.
Known issue: Cycles created via alias types are not properly detected at the moment.
For #18130.
Change-Id: I90a3206be13116f89c221b5ab4d0f577eec6c78a
Reviewed-on: https://go-review.googlesource.com/35091
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The test is inherently racy and vulnerable to starvation,
and within all.bash on some platforms that means it flakes.
Test is kept because it can be useful standalone to verify
behavior of GOEXPERIMENT=preeemptibleloops, and there is
likely to be further development of this feature in the
future.
There's also some question as to why it is flaking, because
though technically this is permitted, it's very odd in this
simple case.
Fixes#18589.
Change-Id: Ia0dd9037285c4a03122da4012c96981c9cc43b60
Reviewed-on: https://go-review.googlesource.com/35051
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It's earlier than usual but this will help us put the type alias-aware
code into x/tools without breaking clients on go1.6, go1.7,
or (eventually) go1.8.
Change-Id: I43e7ea804922de07d153c7e356cf95e2a11fc592
Reviewed-on: https://go-review.googlesource.com/35050
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Parsing and printing support for type aliases complete.
go/types recognizes them an issues an "unimplemented" error for now.
For #18130.
Change-Id: I9f2f7b1971b527276b698d9347bcd094ef0012ee
Reviewed-on: https://go-review.googlesource.com/34986
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
XPos is a compact (8 instead of 16 bytes on a 64bit machine) source
position representation. There is a 1:1 correspondence between each
XPos and each regular Pos, translated via a global table.
In some sense this brings back the LineHist, though positions can
track line and column information; there is a O(1) translation
between the representations (no binary search), and the translation
is factored out.
The size increase with the prior change is brought down again and
the compiler speed is in line with the master repo (measured on
the same "quiet" machine as for prior change):
name old time/op new time/op delta
Template 256ms ± 1% 262ms ± 2% ~ (p=0.063 n=5+4)
Unicode 132ms ± 1% 135ms ± 2% ~ (p=0.063 n=5+4)
GoTypes 891ms ± 1% 871ms ± 1% -2.28% (p=0.016 n=5+4)
Compiler 3.84s ± 2% 3.89s ± 2% ~ (p=0.413 n=5+4)
MakeBash 47.1s ± 1% 46.2s ± 2% ~ (p=0.095 n=5+5)
name old user-ns/op new user-ns/op delta
Template 309M ± 1% 314M ± 2% ~ (p=0.111 n=5+4)
Unicode 165M ± 1% 172M ± 9% ~ (p=0.151 n=5+5)
GoTypes 1.14G ± 2% 1.12G ± 1% ~ (p=0.063 n=5+4)
Compiler 5.00G ± 1% 4.96G ± 1% ~ (p=0.286 n=5+4)
Change-Id: Icc570cc60ab014d8d9af6976f1f961ab8828cc47
Reviewed-on: https://go-review.googlesource.com/34506
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This replaces the src.Pos LineHist-based position tracking with
the syntax.Pos implementation and updates all uses.
The LineHist table is not used anymore - the respective code is still
there but should be removed eventually. CL forthcoming.
Passes toolstash -cmp when comparing to the master repo (with the
exception of a couple of swapped assembly instructions, likely due
to different instruction scheduling because the line-based sorting
has changed; though this is won't affect correctness).
The sizes of various important compiler data structures have increased
significantly (see the various sizes_test.go files); this is probably
the reason for an increase of compilation times (to be addressed). Here
are the results of compilebench -count 5, run on a "quiet" machine (no
apps running besides a terminal):
name old time/op new time/op delta
Template 256ms ± 1% 280ms ±15% +9.54% (p=0.008 n=5+5)
Unicode 132ms ± 1% 132ms ± 1% ~ (p=0.690 n=5+5)
GoTypes 891ms ± 1% 917ms ± 2% +2.88% (p=0.008 n=5+5)
Compiler 3.84s ± 2% 3.99s ± 2% +3.95% (p=0.016 n=5+5)
MakeBash 47.1s ± 1% 47.2s ± 2% ~ (p=0.841 n=5+5)
name old user-ns/op new user-ns/op delta
Template 309M ± 1% 326M ± 2% +5.18% (p=0.008 n=5+5)
Unicode 165M ± 1% 168M ± 4% ~ (p=0.421 n=5+5)
GoTypes 1.14G ± 2% 1.18G ± 1% +3.47% (p=0.008 n=5+5)
Compiler 5.00G ± 1% 5.16G ± 1% +3.12% (p=0.008 n=5+5)
Change-Id: I241c4246cdff627d7ecb95cac23060b38f9775ec
Reviewed-on: https://go-review.googlesource.com/34273
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Loop breaking with a counter. Benchmarked (see comments),
eyeball checked for sanity on popular loops. This code
ought to handle loops in general, and properly inserts phi
functions in cases where the earlier version might not have.
Includes test, plus modifications to test/run.go to deal with
timeout and killing looping test. Tests broken by the addition
of extra code (branch frequency and live vars) for added
checks turn the check insertion off.
If GOEXPERIMENT=preemptibleloops, the compiler inserts reschedule
checks on every backedge of every reducible loop. Alternately,
specifying GO_GCFLAGS=-d=ssa/insert_resched_checks/on will
enable it for a single compilation, but because the core Go
libraries contain some loops that may run long, this is less
likely to have the desired effect.
This is intended as a tool to help in the study and diagnosis
of GC and other latency problems, now that goal STW GC latency
is on the order of 100 microseconds or less.
Updates #17831.
Updates #10958.
Change-Id: I6206c163a5b0248e3f21eb4fc65f73a179e1f639
Reviewed-on: https://go-review.googlesource.com/33910
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
In Go1.7, a 301, 302, or 303 redirect on a HEAD method, would still
cause the following redirects to still use a HEAD.
In CL/29852 this behavior was changed such that those codes always
caused a redirect with the GET method. Fix this such that both
GET and HEAD will preserve the method.
Fixes#18570
Change-Id: I4bfe69872a30799419e3fad9178f907fe439b449
Reviewed-on: https://go-review.googlesource.com/34981
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CALLPART of STRUCTLIT did not check for incomplete initialization
of struct; modify PTRLIT treatment to force zeroing.
Test for structlit, believe this might have also failed for
arraylit.
Fixes#18410.
Change-Id: I511abf8ef850e300996d40568944665714efe1fc
Reviewed-on: https://go-review.googlesource.com/34622
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
To implement the blocking of a select, a goroutine builds a list of
offers to communicate (pseudo-g's, aka sudog), one for each case,
queues them on the corresponding channels, and waits for another
goroutine to complete one of those cases and wake it up. Obviously it
is not OK for two other goroutines to complete multiple cases and both
wake the goroutine blocked in select. To make sure that only one
branch of the select is chosen, all the sudogs contain a pointer to a
shared (single) 'done uint32', which is atomically cas'ed by any
interested goroutines. The goroutine that wins the cas race gets to
wake up the select. A complication is that 'done uint32' is stored on
the stack of the goroutine running the select, and that stack can move
during the select due to stack growth or stack shrinking.
The relevant ordering to block and unblock in select is:
1. Lock all channels.
2. Create list of sudogs and queue sudogs on all channels.
3. Switch to system stack, mark goroutine as asleep,
unlock all channels.
4. Sleep until woken.
5. Wake up on goroutine stack.
6. Lock all channels.
7. Dequeue sudogs from all channels.
8. Free list of sudogs.
9. Unlock all channels.
There are two kinds of stack moves: stack growth and stack shrinking.
Stack growth happens while the original goroutine is running.
Stack shrinking happens asynchronously, during garbage collection.
While a channel listing a sudog is locked by select in this process,
no other goroutine can attempt to complete communication on that
channel, because that other goroutine doesn't hold the lock and can't
find the sudog. If the stack moves while all the channel locks are
held or when the sudogs are not yet or no longer queued in the
channels, no problem, because no goroutine can get to the sudogs and
therefore to selectdone. We only need to worry about the stack (and
'done uint32') moving with the sudogs queued in unlocked channels.
Stack shrinking can happen any time the goroutine is stopped.
That code already acquires all the channel locks before doing the
stack move, so it avoids this problem.
Stack growth can happen essentially any time the original goroutine is
running on its own stack (not the system stack). In the first half of
the select, all the channels are locked before any sudogs are queued,
and the channels are not unlocked until the goroutine has stopped
executing on its own stack and is asleep, so that part is OK. In the
second half of the select, the goroutine wakes up on its own goroutine
stack and immediately locks all channels. But the actual call to lock
might grow the stack, before acquiring any locks. In that case, the
stack is moving with the sudogs queued in unlocked channels. Not good.
One goroutine has already won a cas on the old stack (that goroutine
woke up the selecting goroutine, moving it out of step 4), and the
fact that done = 1 now should prevent any other goroutines from
completing any other select cases. During the stack move, however,
sudog.selectdone is moved from pointing to the old done variable on
the old stack to a new memory location on the new stack. Another
goroutine might observe the moved pointer before the new memory
location has been initialized. If the new memory word happens to be
zero, that goroutine might win a cas on the new location, thinking it
can now complete the select (again). It will then complete a second
communication (reading from or writing to the goroutine stack
incorrectly) and then attempt to wake up the selecting goroutine,
which is already awake.
The scribbling over the goroutine stack unexpectedly is already bad,
but likely to go unnoticed, at least immediately. As for the second
wakeup, there are a variety of ways it might play out.
* The goroutine might not be asleep.
That will produce a runtime crash (throw) like in #17007:
runtime: gp: gp=0xc0422dcb60, goid=2299, gp->atomicstatus=8
runtime: g: g=0xa5cfe0, goid=0, g->atomicstatus=0
fatal error: bad g->status in ready
Here, atomicstatus=8 is copystack; the second, incorrect wakeup is
observing that the selecting goroutine is in state "Gcopystack"
instead of "Gwaiting".
* The goroutine might be sleeping in a send on a nil chan.
If it wakes up, it will crash with 'fatal error: unreachable'.
* The goroutine might be sleeping in a send on a non-nil chan.
If it wakes up, it will crash with 'fatal error: chansend:
spurious wakeup'.
* The goroutine might be sleeping in a receive on a nil chan.
If it wakes up, it will crash with 'fatal error: unreachable'.
* The goroutine might be sleeping in a receive on a non-nil chan.
If it wakes up, it will silently (incorrectly!) continue as if it
received a zero value from a closed channel, leaving a sudog queued on
the channel pointing at that zero vaue on the goroutine's stack; that
space will be reused as the goroutine executes, and when some other
goroutine finally completes the receive, it will do a stray write into
the goroutine's stack memory, which may cause problems. Then it will
attempt the real wakeup of the goroutine, leading recursively to any
of the cases in this list.
* The goroutine might have been running a select in a finalizer
(I hope not!) and might now be sleeping waiting for more things to
finalize. If it wakes up, as long as it goes back to sleep quickly
(before the real GC code tries to wake it), the spurious wakeup does
no harm (but the stack was still scribbled on).
* The goroutine might be sleeping in gcParkAssist.
If it wakes up, that will let the goroutine continue executing a bit
earlier than we would have liked. Eventually the GC will attempt the
real wakeup of the goroutine, leading recursively to any of the cases
in this list.
* The goroutine cannot be sleeping in bgsweep, because the background
sweepers never use select.
* The goroutine might be sleeping in netpollblock.
If it wakes up, it will crash with 'fatal error: netpollblock:
corrupted state'.
* The goroutine might be sleeping in main as another thread crashes.
If it wakes up, it will exit(0) instead of letting the other thread
crash with a non-zero exit status.
* The goroutine cannot be sleeping in forcegchelper,
because forcegchelper never uses select.
* The goroutine might be sleeping in an empty select - select {}.
If it wakes up, it will return to the next line in the program!
* The goroutine might be sleeping in a non-empty select (again).
In this case, it will wake up spuriously, with gp.param == nil (no
reason for wakeup), but that was fortuitously overloaded for handling
wakeup due to a closing channel and the way it is handled is to rerun
the select, which (accidentally) handles the spurious wakeup
correctly:
if cas == nil {
// This can happen if we were woken up by a close().
// TODO: figure that out explicitly so we don't need this loop.
goto loop
}
Before looping, it will dequeue all the sudogs on all the channels
involved, so that no other goroutine will attempt to wake it.
Since the goroutine was blocked in select before, being blocked in
select again when the spurious wakeup arrives may be quite likely.
In this case, the spurious wakeup does no harm (but the stack was
still scribbled on).
* The goroutine might be sleeping in semacquire (mutex slow path).
If it wakes up, that is taken as a signal to try for the semaphore
again, not a signal that the semaphore is now held, but the next
iteration around the loop will queue the sudog a second time, causing
a cycle in the wakeup list for the given address. If that sudog is the
only one in the list, when it is eventually dequeued, it will
(due to the precise way the code is written) leave the sudog on the
queue inactive with the sudog broken. But the sudog will also be in
the free list, and that will eventually cause confusion.
* The goroutine might be sleeping in notifyListWait, for sync.Cond.
If it wakes up, (*Cond).Wait returns. The docs say "Unlike in other
systems, Wait cannot return unless awoken by Broadcast or Signal,"
so the spurious wakeup is incorrect behavior, but most callers do not
depend on that fact. Eventually the condition will happen, attempting
the real wakeup of the goroutine and leading recursively to any of the
cases in this list.
* The goroutine might be sleeping in timeSleep aka time.Sleep.
If it wakes up, it will continue running, leaving a timer ticking.
When that time bomb goes off, it will try to ready the goroutine
again, leading to any one of the cases in this list.
* The goroutine cannot be sleeping in timerproc,
because timerproc never uses select.
* The goroutine might be sleeping in ReadTrace.
If it wakes up, it will print 'runtime: spurious wakeup of trace
reader' and return nil. All future calls to ReadTrace will print
'runtime: ReadTrace called from multiple goroutines simultaneously'.
Eventually, when trace data is available, a true wakeup will be
attempted, leading to any one of the cases in this list.
None of these fatal errors appear in any of the trybot or dashboard
logs. The 'bad g->status in ready' that happens if the goroutine is
running (the most likely scenario anyway) has happened once on the
dashboard and eight times in trybot logs. Of the eight, five were
atomicstatus=8 during net/http tests, so almost certainly this bug.
The other three were atomicstatus=2, all near code in select,
but in a draft CL by Dmitry that was rewriting select and may or may
not have had its own bugs.
This bug has existed since Go 1.4. Until then the select code was
implemented in C, 'done uint32' was a C stack variable 'uint32 done',
and C stacks never moved. I believe it has become more common recently
because of Brad's work to run more and more tests in net/http in
parallel, which lengthens race windows.
The fix is to run step 6 on the system stack,
avoiding possibility of stack growth.
Fixes#17007 and possibly other mysterious failures.
Change-Id: I9d6575a51ac96ae9d67ec24da670426a4a45a317
Reviewed-on: https://go-review.googlesource.com/34835
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
This adds high-level descriptions of the scheduler structures, the
user and system stacks, error handling, and synchronization.
Change-Id: I1eed97c6dd4a6e3d351279e967b11c6e64898356
Reviewed-on: https://go-review.googlesource.com/34290
Reviewed-by: Rick Hudson <rlh@golang.org>
The comment describing the overall GC algorithm at the top of mgc.go
has gotten woefully out-of-date (and was possibly never
correct/complete). Update it to reflect the current workings of the
GC and the set of phases that we now divide it into.
Change-Id: I02143c0ebefe9d4cd7753349dab8045f0973bf95
Reviewed-on: https://go-review.googlesource.com/34711
Reviewed-by: Rick Hudson <rlh@golang.org>
If one of the c.Get(ts.URL) results in an error, the child goroutine
calls t.Errorf, but the test goroutine gets stuck waiting for <-gotReqCh,
so the test hangs and the program is eventually killed (after 10 minutes!).
Whatever might have been printed to t.Errorf is never seen.
Adjust test so that the test fails cleanly in this case.
Still trying to debug why c.Get might fail.
It seems to have something to do with occasional connection
failures on macOS Sierra.
Change-Id: Ia797787bd51ea7cd6deb1192aec89c331c4f2c48
Reviewed-on: https://go-review.googlesource.com/34836
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Currently, the check for legal pointers in stack copying uses
_PageSize (8K) as the minimum legal pointer. By default, Linux won't
let you map under 64K, but
1) it's less clear what other OSes allow or will allow in the future;
2) while mapping the first page is a terrible idea, mapping anywhere
above that is arguably more justifiable;
3) the compiler only assumes the first physical page (4K) is never
mapped.
Make the runtime consistent with the compiler and more robust by
changing the bad pointer check to use 4K as the minimum legal pointer.
This came out of discussions on CLs 34663 and 34719.
Change-Id: Idf721a788bd9699fb348f47bdd083cf8fa8bd3e5
Reviewed-on: https://go-review.googlesource.com/34890
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fixes#18392.
Avoid nil dereferencing n.Right when dealing with non-existent
self referenced interface methods e.g.
type A interface{
Fn(A.Fn)
}
Instead, infer the symbol name from n.Sym itself.
Change-Id: I60d5f8988e7318693e5c8da031285d8d7347b771
Reviewed-on: https://go-review.googlesource.com/34817
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change uses runtime.support_bmi2 as an additional condition
to examine the usability of AVX2 version algorithm, fixes
the crash on the platfrom which supports AVX2 but not support BMI2.
Fixes#18512
Change-Id: I408c0844ae2eb242dacf70cb9e8cec1b8f3bd941
Reviewed-on: https://go-review.googlesource.com/34851
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing implementations on AMD64 only detects AVX2 usability,
when they also contains BMI (bit-manipulation instructions).
These instructions crash the running program as 'unknown instructions'
on the architecture, e.g. i3-4000M, which supports AVX2 but not
support BMI.
This change added the detections for BMI1 and BMI2 to AMD64 runtime with
two flags as the result, `support_bmi1` and `support_bmi2`,
in runtime/runtime2.go. It also completed the condition to run AVX2 version
in packages crypto/sha1 and crypto/sha256.
Fixes#18512
Change-Id: I917bf0de365237740999de3e049d2e8f2a4385ad
Reviewed-on: https://go-review.googlesource.com/34850
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When I wrote the lines
bin/
pkg/
I was trying to match just the top-level bin and pkg directories, and I put the
final slash in because 'git help gitignore' says:
o If the pattern does not contain a slash /, Git treats it as a shell
glob pattern and checks for a match against the pathname relative
to the location of the .gitignore file (relative to the toplevel of
the work tree if not from a .gitignore file).
o Otherwise, Git treats the pattern as a shell glob suitable for
consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in
the pattern will not match a / in the pathname. For example,
"Documentation/*.html" matches "Documentation/git.html" but not
"Documentation/ppc/ppc.html" or
"tools/perf/Documentation/perf.html".
Putting a trailing slash was my way of opting in to the "rooted path" semantics
without looking different from the surrounding rooted paths like "src/go/build/zcgo.go".
But HA HA GIT FOOLED YOU! above those two bullets the docs say:
o If the pattern ends with a slash, it is removed for the purpose of
the following description, ...
Change all the patterns to use a leading slash for "rooted" behavior.
This bit me earlier today because I had a perfectly reasonable source
code directory go/src/cmd/go/testdata/src/empty/pkg that was
not added by 'git add empty'.
Change-Id: I6f8685b3c5be22029c33de9ccd735487089a1c03
Reviewed-on: https://go-review.googlesource.com/34832
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Android on ChromeOS uses a restrictive seccomp filter that blocks
sched_getaffinity, leading this code to index a slice by -errno.
Change-Id: Iec09a4f79dfbc17884e24f39bcfdad305de75b37
Reviewed-on: https://go-review.googlesource.com/34794
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Given
var t struct{ lock sync.Mutex }
var fntab []func(t)
f(a(), b(&t), c(), fntab[0](t))
Before:
function call copies lock value: struct{lock sync.Mutex} contains sync.Mutex
After:
call of fntab[0] copies lock value: struct{lock sync.Mutex} contains sync.Mutex
This will make diagnosis easier when there are multiple function calls per line.
Change-Id: I9881713c5671b847b84a0df0115f57e7cba17d72
Reviewed-on: https://go-review.googlesource.com/34730
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Clean up the phrasing a little bit, make the comment fit in 80
characters, and fix the spelling of "guard."
Change-Id: I688a3e760b8d67ea83830635f64dff04dd9a5911
Reviewed-on: https://go-review.googlesource.com/34792
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously Tx.done was being set in close, but in a Tx
rollback and Commit are the real closing methods,
and Tx.close is just a helper common to both. Prior to this
change a multiple rollback statements could be called, one
would enter close and begin closing it while the other was
still in rollback breaking it. Fix that by setting done
in rollback and Commit, not in Tx.close.
Fixes#18429
Change-Id: Ie274f60c2aa6a4a5aa38e55109c05ea9d4fe0223
Reviewed-on: https://go-review.googlesource.com/34716
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It doesn't work if the package name includes a '.' or a non-ASCII
character (or '%', '"', or a control character). See #16710 and CL 31970.
Update #18246.
Change-Id: I1487f462a3dc7b0016fce3aa1ea6239b226e6e39
Reviewed-on: https://go-review.googlesource.com/34791
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Current handling of WriteTimeout for http2 does not
extend the timeout on new streams. Disable the WriteTimeout
in http2 for 1.8 release.
Updates #18437
Change-Id: I20480432ab176f115464434645defb56ebeb6ece
Reviewed-on: https://go-review.googlesource.com/34723
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Avoid potential race conditions by clarifying to implemntors of the
ReverseProxy interface, the lifetime of provided http.Request structs.
Fixes#18456
Change-Id: I46aa60322226ecc3a0d30fa1ef108e504171957a
Reviewed-on: https://go-review.googlesource.com/34720
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#6772.
Lock-in test for invalid range loop: repeated variables in range declaration.
Change-Id: I37dd8b1cd7279abe7810deaf8a5d485c5c3b73ca
Reviewed-on: https://go-review.googlesource.com/34714
Reviewed-by: Keith Randall <khr@golang.org>
Fixes#5790.
Fixes#18421.
* Lock in _ = x1/x2 divide by zero runtime panics since
it is actually evaluated and not discarded as in previous
versions before Go1.8.
* Update a test that was skipping over zerodivide tests
that expected runtime panics, enabling us to check for
the expected panics.
Change-Id: I0af0a6ecc19345fa9763ab2e35b275fb2d9d0194
Reviewed-on: https://go-review.googlesource.com/34712
Reviewed-by: Keith Randall <khr@golang.org>
Previous changes started using the full filename for object files
on graph nodes, instead of just the file basename. The basename
was still being used when selecting mappings to disassemble for
weblist and disasm commands, causing a mismatch.
This fixes#18385. It was already fixed on the upstream pprof.
Change-Id: I1664503634f2c8cd31743561301631f12c4949c9
Reviewed-on: https://go-review.googlesource.com/34665
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In Go 1.8, we'd removed the Transport's Request.Body
one-byte-Read-sniffing to disambiguate between non-nil Request.Body
with a ContentLength of 0 or -1. Previously, we tried to see whether a
ContentLength of 0 meant actually zero, or just an unset by reading a
single byte of the Request.Body and then stitching any read byte back
together with the original Request.Body.
That historically has caused many problems due to either data races,
blocking forever (#17480), or losing bytes (#17071). Thus, we removed
it in both HTTP/1 and HTTP/2 in Go 1.8. Unfortunately, during the Go
1.8 beta, we've found that a few people have gotten bitten by the
behavior change on requests with methods typically not containing
request bodies (e.g. GET, HEAD, DELETE). The most popular example is
the aws-go SDK, which always set http.Request.Body to a non-nil value,
even on such request methods. That was causing Go 1.8 to send such
requests with Transfer-Encoding chunked bodies, with zero bytes,
confusing popular servers (including but limited to AWS).
This CL partially reverts the no-byte-sniffing behavior and restores
it only for GET/HEAD/DELETE/etc requests, and only when there's no
Transfer-Encoding set, and the Content-Length is 0 or -1.
Updates #18257 (aws-go) bug
And also private bug reports about non-AWS issues.
Updates #18407 also, but haven't yet audited things enough to declare
it fixed.
Change-Id: Ie5284d3e067c181839b31faf637eee56e5738a6a
Reviewed-on: https://go-review.googlesource.com/34668
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 33652 removed the fake auxv for Android, and replaced it with
a /proc/self/auxv fallback. When /proc/self/auxv is unreadable,
however, hardware capabilities detection won't work and the runtime
will mistakenly think that floating point hardware is unavailable.
Fix this by always assuming floating point hardware on Android.
Manually tested on a Nexus 5 running Android 6.0.1. I suspect the
android/arm builder has a readable /proc/self/auxv and therefore
does not trigger the failure mode.
Change-Id: I95c3873803f9e17333c6cb8b9ff2016723104085
Reviewed-on: https://go-review.googlesource.com/34641
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
On Windows, CreateThread occasionally fails with ERROR_ACCESS_DENIED.
We're not sure why this is, but the Wine source code suggests that
this can happen when there's a concurrent CreateThread and ExitProcess
in the same process.
Fix this by setting a flag right before calling ExitProcess and
halting if CreateThread fails and this flag is set.
Updates #18253 (might fix it, but we're not sure this is the issue and
can't reproduce it on demand).
Change-Id: I1945b989e73a16cf28a35bf2613ffab07577ed4e
Reviewed-on: https://go-review.googlesource.com/34616
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Commit 10f75748 (CL 32222) taught AMD64 backend to rewrite series of
byte loads or stores with corresponding shifts into a single long or
quad load or store + appropriate BSWAP. However it did not added test
for stores - only loads were tested.
Fix it.
NOTE Tests for indexed stores are not added because 10f75748 did not add
support for indexed stores - only indexed loads were handled then.
Change-Id: I48c867ebe7622ac8e691d43741feed1d40cca0d7
Reviewed-on: https://go-review.googlesource.com/34634
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Since commit cc62bed0 (CL 994043) the pipe deadlock when doing
Read+Close or Write+Close on same end was fixed, alas with test for
Read+Close case only.
Then commit 6d6f3381 (CL 4252057) made a thinko: in the writer path
p.werr is checked for != nil and then err is set but there is no break
from waiting loop unlike break is there in similar condition for reader.
Together with having only Read+Close case tested that made it to leave
reintroduced Write+Close deadlock unnoticed.
Fix it.
Implicitly this also fixes net.Pipe to conform to semantic of net.Conn
interface where Close is documented to unblock any blocked Read or Write
operations.
No test added to net/ since net.Pipe tests are "Assuming that the
underlying io.Pipe implementation is solid and we're just testing the
net wrapping". The test added in this patch should be enough to cover
the breakage.
Fixes#18401
Updates #18170
Change-Id: I9e9460b3fd7d220bbe60b726accf86f352aed8d4
Reviewed-on: https://go-review.googlesource.com/34637
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
In CL 34650, LookupCNAME was changed so it always returns
the canonical DNS host, even when there is no CNAME record.
Consequently, TestLookupCNAME was failing on Plan 9,
because www.google.com doesn't have a CNAME record.
We changed the implementation of lookupCNAME on Plan 9, so it
returns the canonical DNS host after a CNAME lookup failure.
Fixes#18391.
Change-Id: I59f361bfb2c9de3953e998e8ac58c054979210bd
Reviewed-on: https://go-review.googlesource.com/34633
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Stop-the-world and freeze-the-world (used for unhandled panics) are
currently not safe to do at the same time. While a regular unhandled
panic can't happen concurrently with STW (if the P hasn't been
stopped, then the panic blocks the STW), a panic from a _SigThrow
signal can happen on an already-stopped P, racing with STW. When this
happens, freezetheworld sets sched.stopwait to 0x7fffffff and
stopTheWorldWithSema panics because sched.stopwait != 0.
Fix this by detecting when freeze-the-world happens before
stop-the-world has completely stopped the world and freeze the STW
operation rather than panicking.
Fixes#17442.
Change-Id: I646a7341221dd6d33ea21d818c2f7218e2cb7e20
Reviewed-on: https://go-review.googlesource.com/34611
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Piping into security verify-cert only worked on macOS Sierra, and was
flaky for unknown reasons. Users reported that the number of trusted
root certs stopped randomly jumping around once they switched to using
verify-cert against files on disk instead of /dev/stdin.
But even using "security verify-cert" on 150-200 certs took too
long. It took 3.5 seconds on my machine. More than 4 goroutines
hitting verify-cert didn't help much, and soon started to hurt
instead.
New strategy, from comments in the code:
// 1. Run "security trust-settings-export" and "security
// trust-settings-export -d" to discover the set of certs with some
// user-tweaked trusy policy. We're too lazy to parse the XML (at
// least at this stage of Go 1.8) to understand what the trust
// policy actually is. We just learn that there is _some_ policy.
//
// 2. Run "security find-certificate" to dump the list of system root
// CAs in PEM format.
//
// 3. For each dumped cert, conditionally verify it with "security
// verify-cert" if that cert was in the set discovered in Step 1.
// Without the Step 1 optimization, running "security verify-cert"
// 150-200 times takes 3.5 seconds. With the optimization, the
// whole process takes about 180 milliseconds with 1 untrusted root
// CA. (Compared to 110ms in the cgo path)
Fixes#18203
Change-Id: I4e9c11fa50d0273c615382e0d8f9fd03498d4cb4
Reviewed-on: https://go-review.googlesource.com/34389
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
This change reverts the following CLs:
CL/18274: handle mtime in NTFS/UNIX/ExtendedTS extra fields
CL/30811: only use Extended Timestamp on non-zero MS-DOS timestamps
We are reverting support for extended timestamps since the support was not
not complete. CL/18274 added full support for reading extended timestamp fields
and minimal support for writing them. CL/18274 is incomplete because it made
no changes to the FileHeader struct, so timezone information was lost when
reading and/or writing.
While CL/18274 was a step in the right direction, we should provide full
support for high precision timestamps in both the reader and writer.
This will probably require that we add a new field of type time.Time.
The complete fix is too involved to add in the time remaining for Go 1.8
and will be completed in Go 1.9.
Updates #10242
Updates #17403
Updates #18359Fixes#18378
Change-Id: Icf6d028047f69379f7979a29bfcb319a02f4783e
Reviewed-on: https://go-review.googlesource.com/34651
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Parser doesn't attach some compiler directives to anything in the tree.
We have to explicitely retain them in the generated code. This change,
makes cover explicitely print out any compiler directive that wasn't
handled in the ast.Visitor.
Fixes#18285.
Change-Id: Ib60f253815e92d7fc85051a7f663a61116e40a91
Reviewed-on: https://go-review.googlesource.com/34563
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The runtime no longer hard-codes the offset of
reflect.methodValue.stack, so remove these obsolete comments. Also,
reflect.methodValue and runtime.reflectMethodValue must also agree
with reflect.makeFuncImpl, so update the comments on all three to
mention this.
This was pointed out by Minux on CL 31138.
Change-Id: Ic5ed1beffb65db76aca2977958da35de902e8e58
Reviewed-on: https://go-review.googlesource.com/34590
Reviewed-by: Keith Randall <khr@golang.org>
golang.org/issue/17594 was caused by additab being called more than once for
an itab. golang.org/cl/32131 fixed that by making the itabs local symbols,
but that in turn causes golang.org/issue/18252 because now there are now
multiple itab symbols in a process for a given (type,interface) pair and
different code paths can end up referring to different itabs which breaks
lots of reflection stuff. So this makes itabs global again and just takes
care to only call additab once for each itab.
Fixes#18252
Change-Id: I781a193e2f8dd80af145a3a971f6a25537f633ea
Reviewed-on: https://go-review.googlesource.com/34173
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
It takes me several minutes every time I want to find where the linker
writes out the _func structures. Add some comments to make this
easier.
Change-Id: Ic75ce2786ca4b25726babe3c4fe9cd30c85c34e2
Reviewed-on: https://go-review.googlesource.com/34390
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Confirm that a trivial executable can build and execute using
-fsanitize=memory.
Fixes#18335 (by skipping the tests when they don't work).
Change-Id: Icb7a276ba7b57ea3ce31be36f74352cc68dc89d5
Reviewed-on: https://go-review.googlesource.com/34505
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes Linux and the *BSD platforms on 386/amd64.
A few OS/arch combinations were already saving registers and/or doing
something that doesn't clearly resemble the SysV C ABI; those have
been left alone.
Fixes#18328.
Change-Id: I6398f6c71020de108fc8b26ca5946f0ba0258667
Reviewed-on: https://go-review.googlesource.com/34501
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I haven't been able to reproduce this one, but change a few suspect
things in this test. Notably, using the global "Get" function and thus
using the DefaultTransport was buggy in a parallel test. Then add some error
checks and close a TCP connection.
Hopefully the failure wasn't timing-related.
Fixes#18036 (I hope)
Change-Id: I4904e42e40b26d488cf82111424a1d4d46f42dae
Reviewed-on: https://go-review.googlesource.com/34490
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In Go 1.8, almost all the platforms except NaCl provide network
interface and address identification and applications can use IPv4
limited or directed broadcast addresses appropriately.
Fixes#18176.
Change-Id: Ie5de834d19c0aaeb4128a3ca655f6c4c9ae5e501
Reviewed-on: https://go-review.googlesource.com/34435
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Search the sample types in the profile being processed to map
sample type options to indices in the profile sample type array.
Previously these were hardcoded, which caused issues when the
sample types for a profile type changed. For instance, this was
triggered by the native generation of profiles in profile.proto
format.
This fixes#18230. A similar mechanism already exists on the upstream
pprof.
Change-Id: I945d8d842a0c2ca14299dabefe83124746ecd7e2
Reviewed-on: https://go-review.googlesource.com/34382
Reviewed-by: Michael Matloob <matloob@golang.org>
We are seeing a bad stack map in #18190. In a copystack, it is
mistaking a slot for a pointer.
Presumably this is caused either by our fledgling dynlink support on
darwin, or a consequence of having two copies of the runtime in the
process. But I have been unable to work out which in the 1.8 window,
so pushing darwin support to 1.9 or later.
Change-Id: I7fa4d2dede75033d9a428f24c1837a4613bd2639
Reviewed-on: https://go-review.googlesource.com/34391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Explicitly filter any C-only cgo functions out of pclntable,
which allows them to be duplicated with the host binary.
Updates #18190.
Change-Id: I50d8706777a6133b3e95f696bc0bc586b84faa9e
Reviewed-on: https://go-review.googlesource.com/34199
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The client code was using time.Now() (wall time) to determine whether
the cause of a non-nil error meant that a timeout had occured. But on
Windows, the clock used for timers (time.After, time.Sleep, etc) is
much more accurate than the time.Now clock, which doesn't update
often.
But it turns out that as of the recent https://golang.org/cl/32478 we
already have the answer available easily. It just wasn't in scope.
Instead of passing this information along by decorating the errors
(risky this late in Go 1.8, especially with #15935 unresolved), just
passing along the "didTimeout" func internally for now. We can remove
that later in Go 1.9 if we overhaul Transport errors.
Fixes#18287 (I hope)
Change-Id: Icbbfceaf02de6c7ed04fe37afa4ca16374b58f3c
Reviewed-on: https://go-review.googlesource.com/34381
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
document about the consecutive dialing introduced in Go 1.5.
If address is resolved to multiple addresses,
Dial will try each address in order until one succeeds.
Deadline is used to try each address (calculated based on
total number of resolved addresses)
Fixes: #17617
Change-Id: I56b6399edb640c8ef507675f98e0bd45a50d4e2d
Reviewed-on: https://go-review.googlesource.com/34176
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Now that we try to handle qualifiers correctly (as of CL 33325), don't
strip them from a void* pointer. Otherwise we break a case like "const
void**", as the "const" qualifier is dropped and the resulting
"void**" triggers a warning from the C compiler.
Fixes#18298.
Change-Id: If51df1889b0f6a907715298c152e6d4584747acb
Reviewed-on: https://go-review.googlesource.com/34370
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
A lot of things had to line up to make this break,
but the caching of download results interacted badly
with vendor directories, "go get -t -u", and wildcard
expansion.
Fixes#18219.
Change-Id: I2676498d2f714eaeb69f399e9ed527640c12e60d
Reviewed-on: https://go-review.googlesource.com/34201
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The check for duplicate struct field tags introduced in CL 16704
triggers a panic when an anonymous struct field with a duplicate name
is encountered. For such a field, the names slice of the ast.Field is
nil but accessed regardless to generate the warning message.
Additionally, the check produces false positives for XML tags in some
cases:
- When fields are encoded as XML attributes, a warning is produced when
an attribute reuses a name previously used for an element.
Example:
type Foo struct {
First int `xml:"a"`
NoDup int `xml:"a,attr"` // warning about reuse of "a"
}
- When XMLName is used to set the name of the enclosing struct element,
it is treated as a regular struct field.
Example:
type Bar struct {
XMLName xml.Name `xml:"a"`
NoDup int `xml:"a"` // warning about reuse of "a"
}
This commit addresses all three issues. The panic is avoided by using
the type name instead of the field name for anonymous struct fields when
generating the warning message. An additional namespace for checking XML
attribute names separately from element names is introduced. Lastly,
fields named XMLName are excluded from the check for duplicate tags.
Updates #18256
Change-Id: Ida48ea8584b56bd4d12ae3ebd588a66ced2594cc
Reviewed-on: https://go-review.googlesource.com/34070
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The test for the race detector itself had a race of a sort not
detected by the race detector.
Fixes#18286.
Change-Id: I3265eae275aaa2869a6b6d3e8675b0d88b25831b
Reviewed-on: https://go-review.googlesource.com/34287
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For the 1.8 release, go back to invoking the assembler once per .s
file, to avoid the problem in #18225. When the assembler is fixed, the
change to cmd/go/build.go can be rolled back, but the test in
cmd/go/go_test.go should remain.
Fixes#18225.
Update #15680.
Change-Id: Ibff8d0c638536efb50a2b2c280b41399332f4fe4
Reviewed-on: https://go-review.googlesource.com/34284
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is the simplest CL that I can make for Go 1.8. For Go 1.9, we can revisit it
and optimize the redundant address generation instructions or just fix#599 instead.
Fixes#18140.
Change-Id: Ie4804ab0e00dc6bb318da2bece8035c7c71caac3
Reviewed-on: https://go-review.googlesource.com/34193
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the openbsd runtime to use the current sys_kill and sys_thrkill
system calls.
Prior to OpenBSD 5.9 the sys_kill system call could be used with both
processes and threads. In OpenBSD 5.9 this functionality was split into
a sys_kill system call for processes (with a new syscall number) and a
sys_thrkill system call for threads. The original/legacy system call was
retained in OpenBSD 5.9 and OpenBSD 6.0, however has been removed and
will not exist in the upcoming OpenBSD 6.1 release.
Note: This change is needed to make Go work on OpenBSD 6.1 (to be
released in May 2017) and should be included in the Go 1.8 release.
This change also drops support for OpenBSD 5.8, which is already an
unsupported OpenBSD release.
Change-Id: I525ed9b57c66c0c6f438dfa32feb29c7eefc72b0
Reviewed-on: https://go-review.googlesource.com/34093
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The pclntable contains pointers to functions. If the function symbol
is exported in a plugin, and there is a matching symbol in the host
binary, then the pclntable of a plugin ends up pointing at the
function in the host module.
This doesn't work because the traceback code expects the pointer to
be in the same module space as the PC value.
So don't export functions that might overlap with the host binary.
This way the pointer stays in its module.
Updates #18190
Change-Id: Ifb77605b35fb0a1e7edeecfd22b1e335ed4bb392
Reviewed-on: https://go-review.googlesource.com/34196
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This moves syntax.Pos closer to cmd/internal/src.Pos so that
we can more easily replace src.Pos with syntax.Pos going forward.
Change-Id: I9f93a65fecb4c22591edca4b9d6cda39cf0e872e
Reviewed-on: https://go-review.googlesource.com/34270
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Specify that that LimitedReader returns EOF when the underlying
R returns EOF even if bytes remaining, N > 0.
Fixes#18271
Change-Id: I990a7135f1d31488d535238ae061d42ee96bacb7
Reviewed-on: https://go-review.googlesource.com/34249
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Made many minor changes so that the document is consistent with itself.
Some more noticeable changes:
* CL/34141: Revert "testing: add T.Context method"
* CL/33630: net/http: document restrictions on ETag as expected by ServeContent
Change-Id: I39ae5e55c56e374895c115e6852998c940beae35
Reviewed-on: https://go-review.googlesource.com/34243
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- use syntax.Pos in syntax.Error (rather than line, col)
- use syntax.Pos in syntax.PragmaHandler (rather than just line)
- update uses
- better documentation in various places
Also:
- make Pos methods use Pos receiver (rather than *Pos)
Reviewed in and cherry-picked from https://go-review.googlesource.com/#/c/33891/.
With minor adjustments to noder.go to make merge compile.
Change-Id: I5507cea6c2be46a7677087c1aeb69382d31033eb
Reviewed-on: https://go-review.googlesource.com/34236
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed in and cherry-picked from https://go-review.googlesource.com/#/c/33873/.
- simplify error handling in source.go
(move handling of first error into parser, where it belongs)
- clean up error handling in scanner.go
- move pragma and position base handling from scanner
to parser where it belongs
- have separate error methods in parser to avoid confusion
with handlers from scanner.go and source.go
- (source.go) and (scanner.go, source.go, tokens.go)
may be stand-alone packages if so desired, which means
these files are now less entangled and easier to maintain
Change-Id: I81510fc7ef943b78eaa49092c0eab2075a05878c
Reviewed-on: https://go-review.googlesource.com/34235
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Using a variable instead of a composite literal makes
the code independent of implementation changes of Pos.
Per David Lazar's suggestion.
Change-Id: I336967ac12a027c51a728a58ac6207cb5119af4a
Reviewed-on: https://go-review.googlesource.com/34148
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There is nothing notable to mention as far as users are concerned.
Fixes#17929 (another bug tracks the remaining TODO item)
Change-Id: Id39f787581ed9d2ecd493126bb7ca27836816d4b
Reviewed-on: https://go-review.googlesource.com/34145
Reviewed-by: Michael Matloob <matloob@golang.org>
This is a mostly mechanical rename followed by manual fixes where necessary.
Change-Id: Ie5c670b133db978f15dc03e50dc2da0c80fc8842
Reviewed-on: https://go-review.googlesource.com/34137
Reviewed-by: David Lazar <lazard@golang.org>
Adjust cmd/compile accordingly.
This will make it easier to replace the underlying implementation.
Change-Id: I33645850bb18c839b24785b6222a9e028617addb
Reviewed-on: https://go-review.googlesource.com/34133
Reviewed-by: David Lazar <lazard@golang.org>
This rolls back https://golang.org/cl/27117 partly, softening it so it
only retries POST/PUT/DELETE etc requests where there's no Body (nil
or NoBody). This is a little useless, since most idempotent requests
have a body (except maybe DELETE), but it's late in the Go 1.8 release
cycle and I want to do the proper fix.
The proper fix will look like what we did for http2 and only retrying
the request if Request.GetBody is defined, and then creating a new request
for the next attempt. See https://golang.org/cl/33971 for the http2 fix.
Updates #15723Fixes#18239
Updates #18241
Change-Id: I6ebaa1fd9b19b5ccb23c8d9e7b3b236e71cf57f3
Reviewed-on: https://go-review.googlesource.com/34134
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>
The combination of two prior CLs can cause panics:
* CL/17873: make chained multiReader Read more efficient
* CL/28533: make MultiReader nil exhausted Readers for earlier GC
The first CL allows MultiReader to "inherit" another MultiReader's list of Readers
for efficiency reasons. This is problematic when combined with the
later CL since that can set prior Readers in that list to nil for GC reasons.
This causes panics when two MultiReaders are used together (even synchronously).
To fix this, rather than setting consumed Readers as nil, we set them with
a special eofReader that always returns EOF.
Fixes#18232
Change-Id: I2a9357ab217e3d54d38ea9022d18e4d14f4182d3
Reviewed-on: https://go-review.googlesource.com/34140
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This adds a counter for the number of times the application forced a
GC by, e.g., calling runtime.GC(). This is useful for detecting
applications that are overusing/abusing runtime.GC() or
debug.FreeOSMemory().
Fixes#18217.
Change-Id: I990ab7a313c1b3b7a50a3d44535c460d7c54f47d
Reviewed-on: https://go-review.googlesource.com/34067
Reviewed-by: Russ Cox <rsc@golang.org>
While processing a symbol for a function, if it is determined
that a function would make the text section too large then
a new text section is created and the address of the function
is in the new text section. But the symbol for the function
is marked as being in the previous text section, causing
incorrect codegen for the function and leading to a segv if
that function is called. This adds code to set the sym.Sect
field to the new section if a new one is created. Note that
this problem only happens at the point where a new section is
created.
Fixes#18218
Change-Id: Ic21ae11368d9d88ff6d5d3977f9ea72fe6477ed1
Reviewed-on: https://go-review.googlesource.com/34069
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we copy the stack, we need to adjust all BPs.
We correctly adjust the ones on the stack, but we also
need to adjust the one that is in g.sched.bp.
Like CL 33754, no test as only kernel-gathered profiles will notice.
Tests will come (in 1.9) with the implementation of #16638.
The invariant should hold that every frame pointer points to
somewhere within its stack. After this CL, it is mostly true, but
something about cgo breaks it. The runtime checks are disabled
until I figure that out.
Update #16638Fixes#18174
Change-Id: I6023ee64adc80574ee3e76491d4f0fa5ede3dbdb
Reviewed-on: https://go-review.googlesource.com/33895
Reviewed-by: Austin Clements <austin@google.com>
Previously it was possible to craft a DSA private key that would cause
Sign() to loop forever because no signature could be valid. This change
does some basic sanity checks and ensures that Sign will always
terminate.
Thanks to Yolan Romailler for highing this.
Be aware, however, that it's still possible for an attacker to simply
craft a private key with enormous values and thus cause Sign to take an
arbitrary amount of time.
Change-Id: Icd53939e511eef513a4977305dd9015d9436d0ce
Reviewed-on: https://go-review.googlesource.com/33725
Reviewed-by: Yolan Romailler <y@romailler.ch>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
It is reported as failing for two people (issues #18202 and #18212).
The failure mode is that the system gets overloaded and other programs
fail to run.
Fixes#18202.
Change-Id: I1f1ca1f5d8eed6cc3a9dffac3289851e09fa662b
Reviewed-on: https://go-review.googlesource.com/34017
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mention that the best-effort race detector on maps
was upgraded to detect write/iterate races.
Fixes#18137
Change-Id: Ib6e0adde47e965126771ea712386031a2a55eba3
Reviewed-on: https://go-review.googlesource.com/33768
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Conditioning on the plugin.Open symbol existing before loading all
symbols means sometimes some packages don't have a hash value.
Fixes#17928
Change-Id: I2722449aa58eca08a25117d3ce976f11f805b5ac
Reviewed-on: https://go-review.googlesource.com/33925
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For reasons that I do not know, OpenBSD does not call pthread_create
directly, but instead looks it up in libpthread.so. That means that we
can't use the code used on other systems to retry pthread_create on
EAGAIN, since that code simply calls pthread_create.
This patch copies that code to an OpenBSD-specific version.
Also, check for an EAGAIN failure in the test, as that seems to be the
underlying cause of the test failure on several systems including OpenBSD.
Fixes#18146.
Change-Id: I3bceaa1e03a7eaebc2da19c9cc146b25b59243ef
Reviewed-on: https://go-review.googlesource.com/33905
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In writebarrier phase, a chain of StoreWBs is rewritten to branchy
code to invoke write barriers, and the last store in the chain is
spliced into a Phi op to join the memory of the two branches. We
must find the last store explicitly, since the values are not
scheduled and they may not come in dependency order.
Fixes#18169.
Change-Id: If547e3c562ef0669bc5622c1bb711904dc36314d
Reviewed-on: https://go-review.googlesource.com/33915
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Since ffd1c781b7 HTML templates check
MIME type in the "type" attribute of "script" tag to decide if contents
should be escaped as JavaScript. The whitelist of MIME types did not
include application/json. Include it in this CL.
Fixes#18159
Change-Id: I17a8a38f2b7789b4b7e941d14279de222eaf2b6a
Reviewed-on: https://go-review.googlesource.com/33899
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Internal linking on an ELF system creates two reloc sections, which
must be adjacent. The default is to base section alignment on the
section size, but doing that for ELF reloc sections can introduce a
gap. Set the reloc section alignment explicitly to avoid that.
Fixes#18044.
Change-Id: I8ccc131e60937d30c5f715a34c7803258833fc2f
Reviewed-on: https://go-review.googlesource.com/33872
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The introduction of NoBody and related body-peeking bug fixes also
added a "cleanup" of sorts to make NewRequest set the returned
Requests's ContentLength to -1 when it didn't know it.
Using -1 to mean unknown is what the documentation says, but then
people apparently(?) depended on it being zero so they could do this:
req, _ := http.NewRequest("POST", url, someNonNilReaderWithUnkownSize)
req.Body = nil
res, err := http.DefaultClient.Do(req)
... and expect it to work.
After https://golang.org/cl/31445 the contrived(?) code above stopped
working, since Body was nil and ContentLength was -1, which has been
disallowed since Go 1.0.
So this restores the old behavior of NewRequest, not setting it to -1.
That part of the fix isn't required as of https://golang.org/cl/31726
(which added NoBody)
I still don't know whether this bug is hypothetical or actually
affected people in practice.
Let's assume it's real for now.
Fixes#18117
Change-Id: I42400856ee92a1a4999b5b4668bef97d885fbb53
Reviewed-on: https://go-review.googlesource.com/33801
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This file is entirely about the implementation of LineHist, and I can
never remember which generic filename in cmd/internal/obj has it.
Rename to line.go to match the already existing line_test.go.
Change-Id: Id01f3339dc550c9759569d5610d808b17bca44d0
Reviewed-on: https://go-review.googlesource.com/33803
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
func f() {
g()
}
We mistakenly don't add a frame pointer for f. This means f
isn't seen when walking the frame pointer linked list. That
matters for kernel-gathered profiles, and is an impediment for
issues like #16638.
To fix, allocate a stack frame even for otherwise frameless functions
like f. It is a bit tricky because we need to avoid some runtime
internals that really, really don't want one.
No test at the moment, as only kernel CPU profiles would catch it.
Tests will come with the implementation of #16638.
Fixes#18103
Change-Id: I411206cc9de4c8fdd265bee2e4fa61d161ad1847
Reviewed-on: https://go-review.googlesource.com/33754
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Darwin separately stores bits indicating whether a root certificate
should be trusted; this changes Go to read and use those when
initializing SystemCertPool.
Unfortunately, the trust API is very slow. To avoid a delay of up to
0.5s in initializing the system cert pool, we assume that
the trust settings found in kSecTrustSettingsDomainSystem will always
indicate trust. (That is, all root certs Apple distributes are trusted.)
This is not guaranteed by the API but is true in practice.
In the non-cgo codepath, we do not have that benefit, so we must check
the trust status of every certificate. This causes about 0.5s of delay
in initializing the SystemCertPool.
On OS X 10.11 and older, the "security" command requires a certificate
to be provided in a file and not on stdin, so the non-cgo codepath
creates temporary files for each certificate, further slowing initialization.
Updates #18141.
Change-Id: If681c514047afe5e1a68de6c9d40ceabbce54755
Reviewed-on: https://go-review.googlesource.com/33721
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Commit 303b69fe packed bitvectors more tightly, but missed a comment
describing their old layout. Update that comment.
Change-Id: I095ccb01f245197054252545f37b40605a550dec
Reviewed-on: https://go-review.googlesource.com/33718
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This fixes a bug in -l=3 or higher.
To inline a variadic function, the compiler generates code that constructs
a slice of arguments for the variadic parameter. Consider the function
func Foo(xs ...string)
and the call Foo("hello", "world"). To inline the call to Foo, the
compiler used to generate
xs := [2]string{"hello", "world"}[:]
which doesn't type check:
invalid operation [2]string literal[:] (slice of unaddressable value).
Now, the compiler generates
xs := []string{"hello", "world"}
which does type check.
Fixes#18116.
Change-Id: I0ee531ef2e6cc276db6fb12602b25a46d6d5db21
Reviewed-on: https://go-review.googlesource.com/33671
Reviewed-by: Keith Randall <khr@golang.org>
From the garbage collector's perspective, time can move backwards in
cgocall. However, in the midst of this time warp, the pointer
arguments to cgocall can go from dead back to live. If a stack growth
happens while they're dead and then a GC happens when they become live
again, GC can crash with a bad heap pointer.
Specifically, the sequence that leads to a panic is:
1. cgocall calls entersyscall, which saves the PC and SP of its call
site in cgocall. Call this PC/SP "X". At "X" both pointer arguments
are live.
2. cgocall calls asmcgocall. Call the PC/SP of this call "Y". At "Y"
neither pointer argument is live.
3. asmcgocall calls the C code, which eventually calls back into the
Go code.
4. cgocallbackg remembers the saved PC/SP "X" in some local variables,
calls exitsyscall, and then calls cgocallbackg1.
5. The Go code causes a stack growth. This stack unwind sees PC/SP "Y"
in the cgocall frame. Since the arguments are dead at "Y", they are
not adjusted.
6. The Go code returns to cgocallbackg1, which calls reentersyscall
with the recorded saved PC/SP "X", so "X" gets stashed back into
gp.syscallpc/sp.
7. GC scans the stack. It sees there's a saved syscall PC/SP, so it
starts the traceback at PC/SP "X". At "X" the arguments are considered
live, so it scans them, but since they weren't adjusted, the pointers
are bad, so it panics.
This issue started as of commit ca4089ad, when the compiler stopped
marking arguments as live for the whole function.
Since this is a variable liveness issue, fix it by adding KeepAlive
calls that keep the arguments live across this whole time warp.
The existing issue7978 test has all of the infrastructure for testing
this except that it's currently up to chance whether a stack growth
happens in the callback (it currently only happens on the
linux-amd64-noopt builder, for example). Update this test to force a
stack growth, which causes it to fail reliably without this fix.
Fixes#17785.
Change-Id: If706963819ee7814e6705693247bcb97a6f7adb8
Reviewed-on: https://go-review.googlesource.com/33710
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Be consistent with the argument names already provided. Also
parameter is the variable, argument is the value.
Fixes#18099
Change-Id: Idb3f4e9ffc214036c721ddb4f614ec6c95bb7778
Reviewed-on: https://go-review.googlesource.com/33660
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The code was intended to test that mux handler should redirect at
most once, but the added loop condition defeated that. Remove the
loop condition and document the intention better.
Fixes#18068.
Change-Id: I2a4ea041eae27168b45a09aa46e740ac03921594
Reviewed-on: https://go-review.googlesource.com/33654
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The doc field is not yet used - remove it for now (we may end up
with a different solution for 1.9). This reduces memory consumption
for parsing all of std lib by about 40MB and makes parsing slightly
faster.
Change-Id: Iafb00b9c7f1be9c66fdfb29096d3da5049b2fcf5
Reviewed-on: https://go-review.googlesource.com/33661
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When context methods were initially added it was attempted to unify
behavior between drivers without Context methods and those with
Context methods to always return right away when the Context expired.
However in doing so the driver call could be executed outside of the
scope of the driver connection lock and thus bypassing thread safety.
The new behavior waits until the driver operation is complete. It then
checks to see if the context has expired and if so returns that error.
Change-Id: I4a5c7c3263420c57778f36a5ed6fa0ef8cb32b20
Reviewed-on: https://go-review.googlesource.com/32422
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Skip lines if they are empty or starting with "#" which are valid
legacy pprof output format.
Fixes#18025
Change-Id: I7aee439171496932637b8ae3188700911f569b16
Reviewed-on: https://go-review.googlesource.com/33454
Reviewed-by: Peter Weinberger <pjw@google.com>
Android's libc doesn't provide access to auxv, so currently the Go
runtime synthesizes a fake, minimal auxv when loaded as a library on
Android. This used to be sufficient, but now we depend on auxv to
retrieve the system physical page size and panic if we can't retrieve
it.
Fix this by falling back to reading auxv from /proc/self/auxv if the
loader-provided auxv is empty and removing the synthetic auxv vectors.
Fixes#18041.
Change-Id: Ia2ec2c764a6609331494a5d359032c56cbb83482
Reviewed-on: https://go-review.googlesource.com/33652
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Tested by running
GOTRACEBACK=2 CGO_CFLAGS="-Wa,--elf-stt-common=yes" go test -ldflags=-linkmode=internal
in misc/cgo/test. That failed before this CL, succeeded after.
I don't think it's worth doing that as a regular test, though,
especially since only recent versions of the GNU binutils support the
--elf-stt-common option.
Fixes#18088.
Change-Id: I893d86181faee217b1504c054b0ed3f7c8d977d3
Reviewed-on: https://go-review.googlesource.com/33653
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go 1.5 worked with Unicode console input but not ^Z.
Go 1.6 did not work with Unicode console input but did handle one ^Z case.
Go 1.7 did not work with Unicode console input but did handle one ^Z case.
The intent of this CL is for Go 1.8 to work with Unicode console input
and also handle all ^Z cases.
Here's a simple test program for reading from the console.
It prints a "> " prompt, calls read, prints what it gets, and repeats.
package main
import (
"fmt"
"os"
)
func main() {
p := make([]byte, 100)
fmt.Printf("> ")
for {
n, err := os.Stdin.Read(p)
fmt.Printf("[%d %q %v]\n> ", n, p[:n], err)
}
}
On Unix, typing a ^D produces a break in the input stream.
If the ^D is at the beginning of a line, then the 0 bytes returned
appear as an io.EOF:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello^D[5 "hello" <nil>]
> ^D[0 "" EOF]
> ^D[0 "" EOF]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
On Windows, the EOF character is ^Z, not ^D, and there has
been a long-standing problem that in Go programs, ^Z on Windows
does not behave in the expected way, namely like ^D on Unix.
Instead, the ^Z come through as literal ^Z characters:
C:\>c:\go1.5.4\bin\go run x.go
> ^Z
[3 "\x1a\r\n" <nil>]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
CL 4310 attempted to fix this bug, then known as #6303,
by changing the use of ReadConsole to ReadFile.
This CL was released as part of Go 1.6 and did fix the case
of a ^Z by itself, but not as part of a larger input:
C:\>c:\go1.6.3\bin\go run x.go
> ^Z
[0 "" EOF]
> hello^Zworld
[13 "hello\x1aworld\r\n" <nil>]
>
So the fix was incomplete.
Worse, the fix broke Unicode console input.
ReadFile does not handle Unicode console input correctly.
To handle Unicode correctly, programs must use ReadConsole.
Early versions of Go used ReadFile to read the console,
leading to incorrect Unicode handling, which was filed as #4760
and fixed in CL 7312053, which switched to ReadConsole
and was released as part of Go 1.1 and still worked as of Go 1.5:
C:\>c:\go1.5.4\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
>
But in Go 1.6:
C:\>c:\go1.6.3\bin\go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[0 "" EOF]
>
That is, changing back to ReadFile in Go 1.6 reintroduced #4760,
which has been refiled as #17097. (We have no automated test
for this because we don't know how to simulate console input
in a test: it appears that one must actually type at a keyboard
to use the real APIs. This CL at least adds a comment warning
not to reintroduce ReadFile again.)
CL 29493 attempted to fix#17097, but it was not a complete fix:
the hello world™ example above still fails, as does Shift-JIS input,
which was filed as #17939.
CL 29493 also broke ^Z handling, which was filed as #17427.
This CL attempts the never before successfully performed trick
of simultaneously fixing Unicode console input and ^Z handling.
It changes the console input to use ReadConsole again,
as in Go 1.5, which seemed to work for all known Unicode input.
Then it adds explicit handling of ^Z in the input stream.
(In the case where standard input is a redirected file, ^Z processing
should not happen, and it does not, because this code path is only
invoked when standard input is the console.)
With this CL:
C:\>go run x.go
> hello
[7 "hello\r\n" <nil>]
> hello world™
[16 "hello world™\r\n" <nil>]
> ^Z
[0 "" EOF]
> [2 "\r\n" <nil>]
> hello^Zworld
[5 "hello" <nil>]
> [0 "" EOF]
> [7 "world\r\n" <nil>]
This almost matches Unix:
$ go run /tmp/x.go
> hello
[6 "hello\n" <nil>]
> hello world™
[15 "hello world™\n" <nil>]
> ^D
[0 "" EOF]
> [1 "\n" <nil>]
> hello^Dworld
[5 "hello" <nil>]
> [6 "world\n" <nil>]
>
The difference is in the handling of hello^Dworld / hello^Zworld.
On Unix, hello^Dworld terminates the read of hello but does not
result in a zero-length read between reading hello and world.
This is dictated by the tty driver, not any special Go code.
On Windows, in this CL, hello^Zworld inserts a zero length read
result between hello and world, which is treated as an interior EOF.
This is implemented by the Go code in this CL, but it matches the
handling of ^Z on the console in other programs:
C:\>copy con x.txt
hello^Zworld
1 file(s) copied.
C:\>type x.txt
hello
C:\>
A natural question is how to test all this. As noted above, we don't
know how to write automated tests using the actual Windows console.
CL 29493 introduced the idea of substituting a different syscall.ReadFile
implementation for testing; this CL continues that idea but substituting
for syscall.ReadConsole instead. To avoid the regression of putting
ReadFile back, this CL adds a comment warning against that.
Fixes#17427.
Fixes#17939.
Change-Id: Ibaabd0ceb2d7af501d44ac66d53f64aba3944142
Reviewed-on: https://go-review.googlesource.com/33451
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The pprof code discards all heap allocations made by runtime
routines. This caused it to discard heap allocations made by functions
called by reflect.Call, as the calls are made via the functions
`runtime.call32`, `runtime.call64`, etc. Fix the profiler to retain
these heap allocations.
Fixes#18077.
Change-Id: I8962d552f1d0b70fc7e6f7b2dbae8d5bdefb0735
Reviewed-on: https://go-review.googlesource.com/33635
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Document that key in Header.Get(key) is case insensitive in
http.Header, mail.Header, textproto.Header.
Fixes#18019
Change-Id: Iba7932491e02e555190b6fce053088b580a853ef
Reviewed-on: https://go-review.googlesource.com/33530
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The element index needs to be placed in From3. Before this CL it
was impossible to write a VSTE instruction that could be
successfully parsed, so this won't affect existing assembly code.
Fixes#18075.
Change-Id: I5b71be4c6632b1d5a30820a529122f96fd1bc864
Reviewed-on: https://go-review.googlesource.com/33584
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bill O'Farrell <billotosyr@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The TestMain docs explain that flag.Parse() should be called if TestMain
itself depends on command-line flags.
The issue here is that the example implementation does not use any
flags, and thus the flag.Parse call is unnecessary. This leads to people
who use this example as a starting point for their own implementations
to forget that the call is not necessary in most cases.
Comment it out instead of removing the line to keep it as a reminder, as
suggested by Minux Ma.
Change-Id: I6ffc5413e7036366ae3cf0f069b7065e832a3b45
Reviewed-on: https://go-review.googlesource.com/33273
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When transitioning from C code to Go code we must respect the C
calling convention. On s390x this means that r6-r13, r15 and f8-f15
must be saved and restored by functions that use them.
On s390x we were saving the wrong set of floating point registers
(f0, f2, f4 and f6) rather than f8-f15 which means that Go code
could clobber registers that C code expects to be restored. This
CL modifies the crosscall functions on s390x to save/restore the
correct floating point registers.
Fixes#18035.
Change-Id: I5cc6f552c893a4e677669c8891521bf735492e97
Reviewed-on: https://go-review.googlesource.com/33571
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There is some code value too: types intending to implement
Source64 can write a conversion confirming that.
For #4254 and the Go 1.8 release notes.
Change-Id: I7fc350a84f3a963e4dab317ad228fa340dda5c66
Reviewed-on: https://go-review.googlesource.com/33456
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 32796 changes the SIGPIPE behaviour for c-archive and c-shared
programs. Add it to go1.8.txt.
Change-Id: I31200187033349c642965a4bb077bcc77d5329a3
Reviewed-on: https://go-review.googlesource.com/33397
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TestPendingConnsAfterErr showed a failure on slower systems.
Wait and check for the database to close all connections
before pronouncing failure.
A more careful method was attempted but the connection pool
behavior is too dependent on the scheduler behavior to be
predictable.
Fixes#15684
Change-Id: Iafdbc90ba51170c76a079db04c3d5452047433a4
Reviewed-on: https://go-review.googlesource.com/33418
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Applies the fix from CL 32920 to the new test TestSampledHeapAllocProfile
introduced in CL 33422. The test should be skipped rather than fail if
there is only one executable region of memory.
Updates #17852.
Change-Id: Id8c47b1f17ead14f02a58a024c9a04ebb8ec0429
Reviewed-on: https://go-review.googlesource.com/33453
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The expected default behavior (no explicit GOTRACEBACK setting)
is for the stack trace to start in user code, eliding unnecessary runtime
frames that led up to the actual trace printing code. The idea was that
the first line number printed was the one that crashed.
For #5832 we added code to show 'panic' frames so that if code panics
and then starts running defers and then we trace from there, the panic
frame can help explain why the code seems to have made a call not
present in the code. But that's only needed for panics between two different
call frames, not the panic at the very top of the stack trace.
Fix the fix to again elide the runtime code at the very top of the stack trace.
Simple panic:
package main
func main() {
var x []int
println(x[1])
}
Before this CL:
panic: runtime error: index out of range
goroutine 1 [running]:
panic(0x1056980, 0x1091bf0)
/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
main.main()
/tmp/x.go:5 +0x5
After this CL:
panic: runtime error: index out of range
goroutine 1 [running]:
main.main()
/tmp/x.go:5 +0x5
Panic inside defer triggered by panic:
package main
func main() {
var x []int
defer func() {
println(x[1])
}()
println(x[2])
}
Before this CL:
panic: runtime error: index out of range
panic: runtime error: index out of range
goroutine 1 [running]:
panic(0x1056aa0, 0x1091bf0)
/Users/rsc/go/src/runtime/panic.go:531 +0x1cf
main.main.func1(0x0, 0x0, 0x0)
/tmp/y.go:6 +0x62
panic(0x1056aa0, 0x1091bf0)
/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
main.main()
/tmp/y.go:8 +0x59
The middle panic is important: it explains why main.main ended up calling main.main.func1 on a line that looks like a call to println. The top panic is noise.
After this CL:
panic: runtime error: index out of range
panic: runtime error: index out of range
goroutine 1 [running]:
main.main.func1(0x0, 0x0, 0x0)
/tmp/y.go:6 +0x62
panic(0x1056ac0, 0x1091bf0)
/Users/rsc/go/src/runtime/panic.go:489 +0x2cf
main.main()
/tmp/y.go:8 +0x59
Fixes#17901.
Change-Id: Id6d7c76373f7a658a537a39ca32b7dc23e1e76aa
Reviewed-on: https://go-review.googlesource.com/33165
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When I added t.Parallel to some tests earlier, I overlooked some using
the global "Get" func, which uses DefaultTransport.
The DefaultTransport can have its CloseIdleConnections called by other
parallel tests. Use a private Transport instead.
Fixes#18006
Change-Id: Ia4faca5bac235cfa95dcf2703c25f3627112a5e9
Reviewed-on: https://go-review.googlesource.com/33432
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When we raise a signal that was delivered to C code, it's possible that
the kernel will not deliver it immediately. This is especially possible
on Darwin where we use send the signal to the entire process rather than
just the current thread. Sleep for a millisecond after sending the
signal to give it a chance to be delivered before we restore the Go
signal handler. In most real cases the program is going to crash at this
point, so sleeping is kind of irrelevant anyhow.
Fixes#14809.
Change-Id: Ib2c0d2c4e240977fb4535dc1dd2bdc50d430eb85
Reviewed-on: https://go-review.googlesource.com/33300
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When CC is set in the environment, the mkEnv function sets its version
of CC to the first word $CC and sets GOGCCFLAGS to the remainder. That
worked since Go 1 but was broken accidentally by
https://golang.org/cl/6409, which changed the code such that `go env`
calls mkEnv twice. The second call to mkEnv would clobber GOGCCFLAGS
based on the value of CC set by the first call. Go back to the old
handling by only calling mkEnv once.
Fixes#15457.
Change-Id: I000a1ebcc48684667e48f2b9b24605867b9e06cd
Reviewed-on: https://go-review.googlesource.com/33293
Reviewed-by: Russ Cox <rsc@golang.org>
Introduce R_WEAKADDROFF, a "weak" variation of the R_ADDROFF relocation
that will only reference the type described if it is in some other way
reachable.
Use this for the ptrToThis field in reflect type information where it
is safe to do so (that is, types that don't need to be included for
interface satisfaction, and types that won't cause the compiler to
recursively generate an endless series of ptr-to-ptr-to-ptr-to...
types).
Also fix a small bug in reflect, where StructOf was not clearing the
ptrToThis field of new types.
Fixes#17931
Change-Id: I4d3b53cb9c916c97b3b16e367794eee142247281
Reviewed-on: https://go-review.googlesource.com/33427
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
After x.ProbablyPrime(n) passes the n Miller-Rabin rounds,
add a Baillie-PSW test before declaring x probably prime.
Although the provable error bounds are unchanged, the empirical
error bounds drop dramatically: there are no known inputs
for which Baillie-PSW gives the wrong answer. For example,
before this CL, big.NewInt(443*1327).ProbablyPrime(1) == true.
Now it is (correctly) false.
The new Baillie-PSW test is two pieces: an added Miller-Rabin
round with base 2, and a so-called extra strong Lucas test.
(See the references listed in prime.go for more details.)
The Lucas test takes about 3.5x as long as the Miller-Rabin round,
which is close to theoretical expectations.
name time/op
ProbablyPrime/Lucas 2.91ms ± 2%
ProbablyPrime/MillerRabinBase2 850µs ± 1%
ProbablyPrime/n=0 3.75ms ± 3%
The speed of prime testing for a prime input does get slower:
name old time/op new time/op delta
ProbablyPrime/n=1 849µs ± 1% 4521µs ± 1% +432.31% (p=0.000 n=10+9)
ProbablyPrime/n=5 4.31ms ± 3% 7.87ms ± 1% +82.70% (p=0.000 n=10+10)
ProbablyPrime/n=10 8.52ms ± 3% 12.28ms ± 1% +44.11% (p=0.000 n=10+10)
ProbablyPrime/n=20 16.9ms ± 2% 21.4ms ± 2% +26.35% (p=0.000 n=9+10)
However, because the Baillie-PSW test is only added when the old
ProbablyPrime(n) would return true, testing composites runs at
the same speed as before, except in the case where the result
would have been incorrect and is now correct.
In particular, the most important use of this code is for
generating random primes in crypto/rand. That use spends
essentially all its time testing composites, so it is not
slowed down by the new Baillie-PSW check:
name old time/op new time/op delta
Prime 104ms ±22% 111ms ±16% ~ (p=0.165 n=10+10)
Thanks to Serhat Şevki Dinçer for CL 20170, which this CL builds on.
Fixes#13229.
Change-Id: Id26dde9b012c7637c85f2e96355d029b6382812a
Reviewed-on: https://go-review.googlesource.com/30770
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The gccgo compiler does not have the standard packages available, so it
can not check for violations of internal references.
Also, the gccgo compiler can not read runtime/internal/sys/zversion.go;
in fact, the file does not even exist for gccgo.
Change-Id: Ibadf16b371621ad1b87b6e858c5eb233913e179d
Reviewed-on: https://go-review.googlesource.com/33295
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We recently added these large zip64 tests. They're slow-ish already,
but fast enough in non-race mode with t.Parallel. But in race mode,
the concurrency makes them much slower than the normal
non-race-to-race multiplier.
They're taking so long now that it's causing test failures when it
sometimes is over the test timeout threshold.
Change-Id: I02f4ceaa9d6cab826708eb3860f47a57b05bdfee
Reviewed-on: https://go-review.googlesource.com/33423
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
count profiles with debug=1 retain their previous format.
Also add a test check for the proto profiles since all runtime/pprof
tests only look at the debug=1 profiles.
Change-Id: Ibe805585b597e5d3570807115940a1dc4535c03f
Reviewed-on: https://go-review.googlesource.com/33148
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If the scheduler has no user work and there's no GC work visible, it
puts the P to sleep (or blocks on the network). However, if we later
enqueue more GC work, there's currently nothing that specifically
wakes up the scheduler to let it start an idle GC worker. As a result,
we can underutilize the CPU during GC if Ps have been put to sleep.
Fix this by making GC wake idle Ps when work buffers are put on the
full list. We already have a hook to do this, since we use this to
preempt a random P if we need more dedicated workers. We expand this
hook to instead wake an idle P if there is one. The logic we use for
this is identical to the logic used to wake an idle P when we ready a
goroutine.
To make this really sound, we also fix the scheduler to re-check the
idle GC worker condition after releasing its P. This closes a race
where 1) the scheduler checks for idle work and finds none, 2) new
work is enqueued but there are no idle Ps so none are woken, and 3)
the scheduler releases its P.
There is one subtlety here. Currently we call enlistWorker directly
from putfull, but the gcWork is in an inconsistent state in the places
that call putfull. This isn't a problem right now because nothing that
enlistWorker does touches the gcWork, but with the added call to
wakep, it's possible to get a recursive call into the gcWork
(specifically, while write barriers are disallowed, this can do an
allocation, which can dispose a gcWork, which can put a workbuf). To
handle this, we lift the enlistWorker calls up a layer and delay them
until the gcWork is in a consistent state.
Fixes#14179.
Change-Id: Ia2467a52e54c9688c3c1752e1fc00f5b37bbfeeb
Reviewed-on: https://go-review.googlesource.com/32434
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Idle GC workers trigger whenever there's a GC running and the
scheduler doesn't find any other work. However, they currently run for
a full scheduler quantum (~10ms) once started.
This is really bad for event-driven applications, where work may come
in on the network hundreds of times during that window. In the
go-gcbench rpc benchmark, this is bad enough to often cause effective
STWs where all Ps are in the idle worker. When this happens, we don't
even poll the network any more (except for the background 10ms poll in
sysmon), so we don't even know there's more work to do.
Fix this by making idle workers check with the scheduler roughly every
100 µs to see if there's any higher-priority work the P should be
doing. This check includes polling the network for incoming work.
Fixes#16528.
Change-Id: I6f62ebf6d36a92368da9891bafbbfd609b9bd003
Reviewed-on: https://go-review.googlesource.com/32433
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Use an explicit ./ to make sure we link against the libgo.so we just
built, not some other libgo.so that the compiler or linker may decide to
seek out.
Fixes#17986.
Change-Id: Id23f6c95aa2b52f4f42c1b6dac45482c22b4290d
Reviewed-on: https://go-review.googlesource.com/33413
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This matches what we already do for switch statements and makes
this large section more visibly organized. No other changes besides
introducing the titles.
Fixes#4486.
Change-Id: I73f274e4fdd27c6cfeaed79090b4553e57a9c479
Reviewed-on: https://go-review.googlesource.com/33410
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, trace processing interleaves state/statistics updates and
emitting trace viewer objects. As a result, if events are being
filtered, either by time or by goroutines, we'll miss those
state/statistics updates. At best, this leads to bad statistics;
however, since we're now strictly checking G state transitions, it
usually leads to a failure to process the trace if there is any
filtering.
Fix this by separating state updates from emitting trace object. State
updates are done before filtering, so we always have correct state
information and statistics. Trace objects are only emitted if we pass
the filter. To determine when we need to emit trace counters, rather
than duplicating the knowledge of which events might modify
statistics, we keep track of the previously emitted counters and emit
a trace counter object whenever these have changed.
Fixes#17719.
Change-Id: Ic66e3ddaef60d1acaaf2ff4c62baa5352799cf99
Reviewed-on: https://go-review.googlesource.com/32810
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
- organize examples better
- add an example illustrating behavior if element type is a named pointer type
- both compilers and go/types (per https://go-review.googlesource.com/33358)
follow this now
See the issue for detailed discussion.
Fixes#17954.
Change-Id: I8d90507ff2347d9493813f75b73233819880d2b4
Reviewed-on: https://go-review.googlesource.com/33361
Reviewed-by: Rob Pike <r@golang.org>
The existing implementation of text/template handles the option
"missingkey=error" in an inconsitent manner: If the provided data is
a nil-interface, no error is returned (despite the fact that no key
can be found in it).
This patch makes text/template return an error if "missingkey=error"
is set and the provided data is a not a valid reflect.Value.
Fixes#15356
Change-Id: Ia0a83da48652ecfaf31f18bdbd78cb21dbca1164
Reviewed-on: https://go-review.googlesource.com/31638
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Before this CL, Go programs in c-archive or c-shared buildmodes
would not handle SIGPIPE. That leads to surprising behaviour where
writes on a closed pipe or socket would raise SIGPIPE and terminate
the program. This CL changes the Go runtime to handle
SIGPIPE regardless of buildmode. In addition, SIGPIPE from non-Go
code is forwarded.
Fixes#17393
Updates #16760
Change-Id: I155e82020a03a5cdc627a147c27da395662c3fe8
Reviewed-on: https://go-review.googlesource.com/32796
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When the CT extension is enabled but no SCTs are present, the existing
code calls "continue" which causes resizing the data byte slice to be
skipped. In fact, such extensions should be rejected.
Fixes#17958
Change-Id: Iad12da10d1ea72d04ae2e1012c28bb2636f06bcd
Reviewed-on: https://go-review.googlesource.com/33265
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently there are no diagnostics for mark root check during marking.
Fix this by printing out the same diagnostics we print during mark
termination.
Also, drop the allglock before throwing. Holding that across a throw
causes a self-deadlock with tracebackothers.
For #16083.
Change-Id: Ib605f3ae0c17e70704b31d8378274cfaa2307dc2
Reviewed-on: https://go-review.googlesource.com/33339
Reviewed-by: Rick Hudson <rlh@golang.org>
The top-level qualifiers are unimportant for our purposes. If a C
function is defined as `const int f(const int i)`, the `const`s are
meaningless to C, and we want to avoid using them in the struct we
create where the `const` has a completely different meaning.
This unwinds https://golang.org/cl/33097 with regard to top-level
qualifiers.
Change-Id: I3d66b0eb43b6d9a586d9cdedfae5a2306b46d96c
Reviewed-on: https://go-review.googlesource.com/33325
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Previously driver.Stmt could could be closed multiple times in
edge cases that drivers may not test for initially. Make their
job easier by ensuring the driver is only closed a single time.
Fixes#16019
Change-Id: I1e4777ef70697a849602e6ef9da73054a8feb4cd
Reviewed-on: https://go-review.googlesource.com/33352
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CL 33239 changed the polling loops from using sched_yield to a sleep
for 1/1000 of a second. The loop counters were not updated, so failing
tests now take 100 seconds to complete. Lower the loop counts to 5
seconds instead.
Change-Id: I7c9a343dacc8188603ecf7e58bd00b535cfc87f5
Reviewed-on: https://go-review.googlesource.com/33280
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TestReadStdin always fill up buffer provided by ReadFile caller full.
But we do not know if real ReadFile does the same. Add tests where
buffer is only filled with limited data.
Change-Id: I0fc776325c2b1fe60511126c439f4b0560e9d653
Reviewed-on: https://go-review.googlesource.com/33030
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
CIDRMask just returns a mask which corresponds to an address
prefix in CIDR nonation. A subnet for an IPv6 mask sounds a bit
confusing.
Change-Id: Ic7859ce992bc2de4043d3b25caf9a1051d118b0e
Reviewed-on: https://go-review.googlesource.com/33262
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If a program has had its text section split into multiple
sections then the ftab that is built is based on addresses
prior to splitting. That means all the function addresses
are there and correct because of relocation but the
but the computed idx won't always match up quite right and
in some cases go beyond the end of the table, causing a panic.
To resolve this, determine if the idx is too large and if it is,
set it to the last index in ftab. Then search backward to find the
matching function address.
Fixes#17854
Change-Id: I6940e76a5238727b0a9ac23dc80000996db2579a
Reviewed-on: https://go-review.googlesource.com/32972
Reviewed-by: David Chase <drchase@google.com>
It's possible for the pkgPath of a field to be different than that of
the struct type as a whole. In that case, store the field's pkgPath in
the name field. Use the field's pkgPath when setting PkgPath and when
checking for type identity.
Fixes#17952.
Change-Id: Iebaf92f0054b11427c8f6e4158c3bebcfff06f45
Reviewed-on: https://go-review.googlesource.com/33333
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Failing to create the output file would give confusing errors such as:
cover: invalid argument
Also do out.Close() even if Execute() errored.
Fixes#17951.
Change-Id: I897e1d31f7996871c54fde7cb09614cafbf6c3fc
Reviewed-on: https://go-review.googlesource.com/33278
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
The previous documentation purported to convert underlying strings to
[]byte, which it did not do. This adds support for underlying bool,
string, and []byte, which convert directly to their underlying type.
Fixes#15174.
Change-Id: I7fc4e2520577f097a48f39c9ff6c8160fdfb7be4
Reviewed-on: https://go-review.googlesource.com/27812
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
I had trouble translating the documentation language into a subnet
- e.g. whether /31 was CIDRMask(1, 31) or CIDRMask(1, 32) or
CIDRMask(31, 32) so I thought I'd add a short example showing how to
create the right masks.
Change-Id: Ia6a6de08c5c30b6d2249b3194cced2d3c383e317
Reviewed-on: https://go-review.googlesource.com/32677
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Zero out the sigaction structs, in case the sa_restorer field is set.
Clear the SA_RESTORER flag; it is part of the kernel interface, not the
libc interface.
Fixes#17947.
Change-Id: I610348ce3c196d3761cf2170f06c24ecc3507cf7
Reviewed-on: https://go-review.googlesource.com/33331
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Autotmp filtering was too aggressive and excluded types
necessary to make debuggers work properly. Restore the
"late filter" in dwarf.go based on names to exclude autotmps,
and remove the "early filter" in pgen.go based on how the
name was introduced. However, the updated naming scheme
with a dot prefix is retained to prevent accidental clashes
with legal Go identifier names.
Includes test (grouped with runtime gdb tests),
verified to fail without the fix.
Updates #17644.
Fixes#17830.
Change-Id: I7ec3f7230083889660236e5f6bc77ba5fe434e93
Reviewed-on: https://go-review.googlesource.com/33233
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This change makes use of synchronization primitive instead of
context-based canceling not to depend on defer execution scheduling.
Fixes#17927.
Change-Id: I5ca9287a48bb5cdda6845a7f12757f95175c5db8
Reviewed-on: https://go-review.googlesource.com/33257
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To generate the correct section offset the shared code path for
R_CALL, R_PCREL, and R_GOTPCREL on darwin when externally linking
walks up the symbol heirarchy adding the differences. This is fine,
except in the case where we are generating a GOT lookup, because
the topmost symbol is left in r.Xsym instead of the symbol we are
looking up. So all funcsym GOT lookups were looking up the outer
"go.func.*" symbol.
Fix this by separating out the R_GOTPCREL code path.
For #17828 (and may fix it).
Change-Id: I2c9f4d135e77c17270aa064d8c876dc6d485d659
Reviewed-on: https://go-review.googlesource.com/33211
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test requires tons of memory and results various failures, mainly
runtime errors and process termination by SIGKILL, caused by resource
exhaustion when the node under test doesn't have much resources.
This change makes use of -tcpbig flag to enable the test.
Change-Id: Id53fa5d88543e2e60ca9bb4f55a1914ccca844e1
Reviewed-on: https://go-review.googlesource.com/33254
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This ensures that runtime's signal handlers pass through the TSAN and
MSAN libc interceptors and subsequent calls to the intercepted
sigaction function from C will correctly see them.
Fixes#17753.
Change-Id: I9798bb50291a4b8fa20caa39c02a4465ec40bb8d
Reviewed-on: https://go-review.googlesource.com/33142
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Add an explicit WriteString method to closeOnce that acquires the
writers lock. This overrides the one promoted from the
embedded *os.File field. The promoted one naturally does not acquire
the lock, and can therefore race with the Close method.
Fixes#17647.
Change-Id: I3460f2a0d503449481cfb2fd4628b4855ab0ecdf
Reviewed-on: https://go-review.googlesource.com/33298
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If a C union type (or a C++ class type) can contain a pointer field,
then run the cgo checks on pointers to that type. This will test the
pointer as though it were an unsafe.Pointer, and will crash if it points
to Go memory that contains a pointer.
Fixes#15942.
Change-Id: Ic2d07ed9648d4b27078ae7683e26196bcbc59fc9
Reviewed-on: https://go-review.googlesource.com/33237
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In plugins and every program that opens a plugin, include a hash of
every imported package.
There are two versions of each hash: one local and one exported.
As the program starts and plugins are loaded, the first exported
symbol for each package becomes the canonical version.
Any subsequent plugin's local package hash symbol has to match the
canonical version.
Fixes#17832
Change-Id: I4e62c8e1729d322e14b1673bada40fa7a74ea8bc
Reviewed-on: https://go-review.googlesource.com/33161
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apparently when GOMAXPROCS == 1 a simple sched_yield in a tight loop is
not necessarily sufficient to permit a signal handler to run. Instead,
sleep for 1/1000 of a second.
Fixes#16649.
Change-Id: I83910144228556e742b7a92a441732ef61aa49d9
Reviewed-on: https://go-review.googlesource.com/33239
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change redoes the fix for #16101 (CL 31092) in a different way by
making t.Clone return the template associated with the t.Name() while
allowing for the case that a template of the same name is define-d.
Fixes#17735.
Change-Id: I1e69672390a4c81aa611046a209008ae4a3bb723
Reviewed-on: https://go-review.googlesource.com/33210
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Instead of scanning the text to count newlines, which is n², keep track as we go
and store the line number in the token.
benchmark old ns/op new ns/op delta
BenchmarkParseLarge-4 1589721293 38783310 -97.56%
Fixes#17851
Change-Id: I231225c61e667535e2ce55cd2facea6d279cc59d
Reviewed-on: https://go-review.googlesource.com/33234
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Instead of scanning the text to count newlines, which is n², keep track as we go
and store the line number in the token.
benchmark old ns/op new ns/op delta
BenchmarkParseLarge-4 1589721293 38783310 -97.56%
Fixes#17851
Change-Id: Ieaf89a35e371b405ad92e38baa1e3fa98d18cfb4
Reviewed-on: https://go-review.googlesource.com/32923
Reviewed-by: Robert Griesemer <gri@golang.org>
These are functionality tests, not formatter tests.
I also tested manually that 'go test cmd/go'
without -short still passes.
Change-Id: Id146e1dc3b65e19ea531869725cd0b97f4801b8b
Reviewed-on: https://go-review.googlesource.com/33169
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, `os.Clearenv()` (by way of `syscall.Clearenv`) would simply
set all environment variables' values to `""` rather than actually
unsetting them causing subsequent `os.LookupEnv` calls to return that
they were still set.
Fixes#17902
Change-Id: I54081b4b98665e9a39f55ea7582c8d40bb8a2a22
Reviewed-on: https://go-review.googlesource.com/33168
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Deadlines have been implemented on Plan 9 in CL 31521.
Enable the following tests:
- TestServerTimeouts
- TestOnlyWriteTimeout
- TestTLSHandshakeTimeout
- TestIssue4191_InfiniteGetTimeout
- TestIssue4191_InfiniteGetToPutTimeout
Updates #7237.
Change-Id: If5e75cfaa9133dcf9ce6aac9fc2badafc1612b64
Reviewed-on: https://go-review.googlesource.com/33197
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mention that it specifically returns x / 2, and do the same for
EncodedLen.
Change-Id: Ie334f5abecbc487caf4965abbcd14442591bef2a
Change-Id: Idfa413faad487e534489428451bf736b009293d6
Reviewed-on: https://go-review.googlesource.com/33191
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a variant of sync/atomic's TestUnaligned64 to
runtime/internal/atomic.
Skips the test on arm for now where it's currently failing.
Updates #17786
Change-Id: If63f9c1243e9db7b243a95205b2d27f7d1dc1e6e
Reviewed-on: https://go-review.googlesource.com/33159
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change is an experimental implementation of asynchronous
cancelable I/O operations on Plan 9, which are required to
implement deadlines.
There are no asynchronous syscalls on Plan 9. I/O operations
are performed with blocking pread and pwrite syscalls.
Implementing deadlines in Go requires a way to interrupt
I/O operations.
It is possible to interrupt reads and writes on a TCP connection
by forcing the closure of the TCP connection. This approach
has been used successfully in CL 31390.
However, we can't implement deadlines with this method, since
we require to be able to reuse the connection after the timeout.
On Plan 9, I/O operations are interrupted when the process
receives a note. We can rely on this behavior to implement
a more generic approach.
When doing an I/O operation (read or write), we start the I/O in
its own process, then wait for the result asynchronously. The
process is able to handle the "hangup" note. When receiving the
"hangup" note, the currently running I/O operation is canceled
and the process returns.
This way, deadlines can be implemented by sending an "hangup"
note to the process running the blocking I/O operation, after
the expiration of a timer.
Fixes#11932.
Fixes#17498.
Change-Id: I414f72c7a9a4f9b8f9c09ed3b6c269f899d9b430
Reviewed-on: https://go-review.googlesource.com/31521
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
1e-9 has a 1 in the last place, causing some Duration calculations to
have unnecessary rounding errors. 1e9 does not, so use that instead.
Change-Id: I96334a2c47e7a014b532eb4b8a3ef9550e7ed057
Reviewed-on: https://go-review.googlesource.com/33116
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The tree is inconsistent about single l vs double l in those
words in documentation, test messages, and one error value text.
$ git grep -E '[Mm]arshall(|s|er|ers|ed|ing)' | wc -l
42
$ git grep -E '[Mm]arshal(|s|er|ers|ed|ing)' | wc -l
1694
Make it consistently a single l, per earlier decisions. This means
contributors won't be confused by misleading precedence, and it helps
consistency.
Change the spelling in one error value text in newRawAttributes of
crypto/x509 package to be consistent.
This change was generated with:
perl -i -npe 's,([Mm]arshal)l(|s|er|ers|ed|ing),$1$2,' $(git grep -l -E '[Mm]arshall' | grep -v AUTHORS | grep -v CONTRIBUTORS)
Updates #12431.
Follows https://golang.org/cl/14150.
Change-Id: I85d28a2d7692862ccb02d6a09f5d18538b6049a2
Reviewed-on: https://go-review.googlesource.com/33017
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
pkg-config 0.24 adds support for quoting and escaping whitespace;
distros like CentOS 6 are still shipping pkg-config 0.23. Skip the test
there since there's no way to get whitespace into the pkg-config output.
Fixes#17846.
Change-Id: Ie4ea17e9b709372a20178b539498929754bcd51f
Reviewed-on: https://go-review.googlesource.com/33027
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When a Go program crashes with GOTRACEBACK=crash, the OS creates a
core dump. Include the text-formatted output of some of the cause of
that crash in the core dump.
Output printed by the runtime before crashing is maintained in a
circular buffer to allow access to messages that may be printed
immediately before calling runtime.throw.
The stack traces printed by the runtime as it crashes are not stored.
The information required to recreate them should be included in the
core file.
Updates #16893
There are no tests covering the generation of core dumps; this change
has not added any.
This adds (reentrant) locking to runtime.gwrite, which may have an
undesired performance impact.
Change-Id: Ia2463be3c12429354d290bdec5f3c8d565d1a2c3
Reviewed-on: https://go-review.googlesource.com/32013
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Users can implement the smtp.Auth interface and return zero bytes in
the "toServer []byte" return value from the Auth.Start method. People
apparently do this to implement the SMTP "LOGIN" method.
But we were then sending "AUTH LOGIN \r\n" to the server, which some
servers apparently choke on. So, trim it when the toServer value is
empty.
Fixes#17794
Change-Id: I83662dba9e0f61b1c5000396c096cf7110f78361
Reviewed-on: https://go-review.googlesource.com/33143
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I don't have any way to test or reproduce this problem,
but the current code is clearly wrong for Windows.
Make it better.
As I said on #17165:
But the borrowing of M's and the profiling of M's by the CPU profiler
seem not synchronized enough. This code implements the CPU profiler
on Windows:
func profileloop1(param uintptr) uint32 {
stdcall2(_SetThreadPriority, currentThread, _THREAD_PRIORITY_HIGHEST)
for {
stdcall2(_WaitForSingleObject, profiletimer, _INFINITE)
first := (*m)(atomic.Loadp(unsafe.Pointer(&allm)))
for mp := first; mp != nil; mp = mp.alllink {
thread := atomic.Loaduintptr(&mp.thread)
// Do not profile threads blocked on Notes,
// this includes idle worker threads,
// idle timer thread, idle heap scavenger, etc.
if thread == 0 || mp.profilehz == 0 || mp.blocked {
continue
}
stdcall1(_SuspendThread, thread)
if mp.profilehz != 0 && !mp.blocked {
profilem(mp)
}
stdcall1(_ResumeThread, thread)
}
}
}
func profilem(mp *m) {
var r *context
rbuf := make([]byte, unsafe.Sizeof(*r)+15)
tls := &mp.tls[0]
gp := *((**g)(unsafe.Pointer(tls)))
// align Context to 16 bytes
r = (*context)(unsafe.Pointer((uintptr(unsafe.Pointer(&rbuf[15]))) &^ 15))
r.contextflags = _CONTEXT_CONTROL
stdcall2(_GetThreadContext, mp.thread, uintptr(unsafe.Pointer(r)))
sigprof(r.ip(), r.sp(), 0, gp, mp)
}
func sigprof(pc, sp, lr uintptr, gp *g, mp *m) {
if prof.hz == 0 {
return
}
// Profiling runs concurrently with GC, so it must not allocate.
mp.mallocing++
... lots of code ...
mp.mallocing--
}
A borrowed M may migrate between threads. Between the
atomic.Loaduintptr(&mp.thread) and the SuspendThread, mp may have
moved to a new thread, so that it's in active use. In particular
it might be calling malloc, as in the crash stack trace. If so, the
mp.mallocing++ in sigprof would provoke the crash.
Those lines are trying to guard against allocation during sigprof.
But on Windows, mp is the thread being traced, not the current
thread. Those lines should really be using getg().m.mallocing, which
is the same on Unix but not on Windows. With that change, it's
possible the race on the actual thread is not a problem: the traceback
would get confused and eventually return an error, but that's fine.
The code expects that possibility.
Fixes#17165.
Change-Id: If6619731910d65ca4b1a6e7de761fa2518ef339e
Reviewed-on: https://go-review.googlesource.com/33132
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Note, most math functions are structured to use stubs, so that they can
be accelerated with assembly on any platform.
Sinh, cosh, and tanh were not structued with stubs, so this CL does
that. This set of routines was chosen as likely to produce good speedups
with assembly on any platform.
Technique used was minimax polynomial approximation using tables of
polynomial coefficients, with argument range reduction.
A table of scaling factors was also used for cosh and log10.
before after speedup
BenchmarkCos 22.1 ns/op 6.79 ns/op 3.25x
BenchmarkCosh 125 ns/op 11.7 ns/op 10.68x
BenchmarkLog10 48.4 ns/op 12.5 ns/op 3.87x
BenchmarkSin 22.2 ns/op 6.55 ns/op 3.39x
BenchmarkSinh 125 ns/op 14.2 ns/op 8.80x
BenchmarkTanh 65.0 ns/op 15.1 ns/op 4.30x
Accuracy was tested against a high precision
reference function to determine maximum error.
Approximately 4,000,000 points were tested for each function,
producing the following result.
Note: ulperr is error in "units in the last place"
max
ulperr
sin 1.43 (returns NaN beyond +-2^50)
cos 1.79 (returns NaN beyond +-2^50)
cosh 1.05
sinh 3.02
tanh 3.69
log10 1.75
Also includes a set of tests to test non-vector functions even
when SIMD is enabled
Change-Id: Icb45f14d00864ee19ed973d209c3af21e4df4edc
Reviewed-on: https://go-review.googlesource.com/32352
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Munday <munday@ca.ibm.com>
If the Server's Shutdown (or SetKeepAlivesEnabled) method was called
while a connection was in a Handler, but after the headers had been
written, the connection was not later closed.
Fixes#9478
Updates #17754 (reverts that workaround)
Change-Id: I65324ab8217373fbb38e12e2b8bffd0a91806072
Reviewed-on: https://go-review.googlesource.com/33141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 31462 made it possible to operate directly on reflect.Values
instead of always forcing a round trip to interface{} and back.
The round trip was losing addressability, which hurt users.
The round trip was also losing "interface-ness", which helped users.
That is, using reflect.ValueOf(v.Interface()) instead of v was doing
an implicit indirect any time v was itself an interface{} value: the result
was the reflect.Value for the underlying concrete value contained in the
interface, not the interface itself.
CL 31462 eliminated some "unnecessary" reflect.Value round trips
in order to preserve addressability, but in doing so it lost this implicit
indirection. This CL adds the indirection back.
It may help to compare the changes in this CL against funcs.go from CL 31462:
https://go-review.googlesource.com/#/c/31462/4/src/text/template/funcs.go
Everywhere CL 31462 changed 'v := reflect.ValueOf(x)' to 'v := x',
this CL changes 'v := x' to 'v := indirectInterface(x)'.
Fixes#17714.
Change-Id: I67cec4eb41fed1d56e1c19f12b0abbd0e59d35a2
Reviewed-on: https://go-review.googlesource.com/33139
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TestInterruptWithPanic_h2 was added yesterday in
https://golang.org/cl/33099 and https://golang.org/cl/33103
Deflake it. The http2 server sends an error before logging.
Rather than reorder the http2 code to log before writing the RSTStream
frame, just loop for a bit waiting for the condition we're
expecting.
This goes from 2 in 500 flakes for me to unreproducible.
Change-Id: I062866a5977f50c820965aaf83882ddd7bf98f91
Reviewed-on: https://go-review.googlesource.com/33140
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The restrictions were already being applied to the IP addresses
received from the host resolver. Apply the same restrictions to
literal IP addresses not passed to the host resolver.
For example, ResolveTCPAddr("tcp4", "[2001:db8::1]:http") used
to succeed and now does not (that's not an IPv4 address).
Perhaps a bit surprisingly,
ResolveTCPAddr("tcp4", "[::ffff:127.0.0.1]:http") succeeds,
behaving identically to ResolveTCPAddr("tcp4", "127.0.0.1:http"), and
ResolveTCPAddr("tcp6", "[::ffff:127.0.0.1]:http") fails,
behaving identically to ResolveTCPAddr("tcp6", "127.0.0.1:http").
Even so, it seems right to match (by reusing) the existing filtering
as applied to addresses resolved by the host C library.
If anyone can make a strong argument for changing the filtering
of IPv4-inside-IPv6 addresses, the fix can be applied to all
the code paths in a separate CL.
Fixes#14037.
Change-Id: I690dfdcbe93d730e11e00ea387fa7484cd524341
Reviewed-on: https://go-review.googlesource.com/32100
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
All the existing CPU profiler tests already parse the profile.
That should be sufficient indication that profiles can be parsed.
Fixes#17853.
Change-Id: Ie8a190e2ae4eef125c8eb0d4e8b7adac420abbdb
Reviewed-on: https://go-review.googlesource.com/33136
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
rsc's change golang.org/cl/32455 added a mechanism
that allows pprof to depend on gzip without introducing
an import cycle. This obsoletes the need for the gzip0
package, which was created solely to remove the need
for that dependency.
Change-Id: Ifa3b98faac9b251f909b84b4da54742046c4e3ad
Reviewed-on: https://go-review.googlesource.com/33137
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix spelling of "original" and "occurred" in new gofmt docs. The same
misspelling of "occurred" was also present in crypto/tls, I fixed it there as
well.
Change-Id: I67b4f1c09bd1a2eb1844207d5514f08a9f525ff9
Reviewed-on: https://go-review.googlesource.com/33138
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cmd/vet/all still doesn't run for mips/mipsle,
because the rest of the toolchain doesn't yet
fully support it.
Change-Id: I1a86b0edddbdcd5f43e752208508d99da7aabbb3
Reviewed-on: https://go-review.googlesource.com/33134
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Some commands generate binary outputs which are not human readable.
In interactive mode, there are no use-cases for such outputs.
Instead, the new code writes it to the temporary file on the $CWD and
shows the file name. So the user can use any program to display the
file outside interactive shell.
Fixes#17465
Change-Id: I5c479db26017607f7a28eafbff2385533e5c584e
Reviewed-on: https://go-review.googlesource.com/31123
Reviewed-by: Russ Cox <rsc@golang.org>
It will just cause confusion later as the go tool will say
"warning: GOPATH set to GOROOT (%s) has no effect".
Better to just leave GOPATH unset and get that warning instead.
Change-Id: I78ff9e87fdf4bb0460f4f6d6ee76e1becaa3e7b0
Reviewed-on: https://go-review.googlesource.com/33105
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
On some systems the external linker defaults to PIE. On some systems
DT_TEXTREL does not work correctly. When both are true we have a bad
situation: any Go program built with the default buildmode (exe) that
uses external linking will fail to run. Fix this by passing -no-pie to
the external linker, if the option is supported.
Fixes#17847.
Change-Id: I9b5ff97825d8b7f494f96d29c4c04f72b53dbf4e
Reviewed-on: https://go-review.googlesource.com/33106
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The cgo tool used to simply ignore C type qualifiers. To avoid problems
when a C function expected a qualifier that was not present, cgo emitted
a cast to void* around all pointer arguments. Unfortunately, that broke
code that contains both a function declaration and a macro, when the
macro required the argument to have the right type. To fix this problem,
don't ignore qualifiers. They are easy enough to handle for the limited
set of cases that matter for cgo, in which we don't care about array or
function types.
Fixes#17537.
Change-Id: Ie2988d21db6ee016a3e99b07f53cfb0f1243a020
Reviewed-on: https://go-review.googlesource.com/33097
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Whenever GOPATH is not defined in the environment, use $HOME/go
as its default value. For Windows systems use %USERPROFILE%/go
and $home/go for plan9.
The choice of these environment variables is based on what Docker
currently does. The os/user package is not used to avoid having
a cgo dependency.
Updates #17262. Documentation changes forthcoming.
Change-Id: I6368fbfbc5afda99d6e64c35c1980076fcf45344
Reviewed-on: https://go-review.googlesource.com/32019
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
@@ -4,40 +4,42 @@ Go is an open source programming language that makes it easy to build simple,
reliable, and efficient software.
For documentation about how to install and use Go,
visit https://golang.org/ or load doc/install-source.html
in your web browser.
*Gopher image by [Renee French][rf], licensed under [Creative Commons 3.0 Attributions license][cc3-by].*
Our canonical Git repository is located at https://go.googlesource.com/go.
There is a mirror of the repository at https://github.com/golang/go.
Unless otherwise noted, the Go source files are distributed under the
BSD-style license found in the LICENSE file.
### Download and Install
#### Binary Distributions
Official binary distributions are available at https://golang.org/dl/.
After downloading a binary release, visit https://golang.org/doc/install
or load doc/install.html in your web browser for installation
instructions.
#### Install From Source
If a binary distribution is not available for your combination of
operating system and architecture, visit
https://golang.org/doc/install/source or load doc/install-source.html
in your web browser for source installation instructions.
### Contributing
Go is the work of hundreds of contributors. We appreciate your help!
To contribute, please read the contribution guidelines:
https://golang.org/doc/contribute.html
##### Note that we do not accept pull requests and that we use the issue tracker for bug reports and proposals only. Please ask questions on https://forum.golangbridge.org or https://groups.google.com/forum/#!forum/golang-nuts.
Note that the Go project does not use GitHub pull requests, and that
we use the issue tracker for bug reports and proposals only. See
https://golang.org/wiki/Questions for a list of places to ask
questions about the Go language.
Unless otherwise noted, the Go source files are distributed
under the BSD-style license found in the LICENSE file.
--
## Binary Distribution Notes
If you have just untarred a binary Go distribution, you need to set
the environment variable $GOROOT to the full path of the go
directory (the one containing this file). You can omit the
variable if you unpack it into /usr/local/go, or if you rebuild
from sources by running all.bash (see doc/install-source.html).
You should also add the Go binary directory $GOROOT/bin
to your shell's path.
For example, if you extracted the tar file into $HOME/go, you might
put the following in your .profile:
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
See https://golang.org/doc/install or doc/install.html for more details.
That <code>structhchan<*testing.T></code> is the runtime-internal representation of a channel. It is currently empty, or gdb would have pretty-printed it's contents.
That <code>struct</code><code>hchan<*testing.T></code> is the
runtime-internal representation of a channel. It is currently empty,
@@ -561,12 +585,13 @@ The name of the host operating system and compilation architecture.
These default to the local system's operating system and
architecture.
</p>
</li>
<p>
Valid choices are the same as for <code>$GOOS</code> and
<code>$GOARCH</code>, listed above.
The specified values must be compatible with the local system.
For example, you should not set <code>$GOHOSTARCH</code> to
For example, you should not set <code>$GOHOSTARCH</code> to
<code>arm</code> on an x86 system.
</p>
@@ -579,6 +604,7 @@ directory to your <code>$PATH</code>, so you can use the tools.
If <code>$GOBIN</code> is set, the <ahref="/cmd/go">go command</a>
installs all commands there.
</p>
</li>
<li><code>$GO386</code> (for <code>386</code> only, default is auto-detected
if built on either <code>386</code> or <code>amd64</code>, <code>387</code> otherwise)
@@ -588,9 +614,10 @@ This controls the code generated by gc to use either the 387 floating-point unit
floating point computations.
</p>
<ul>
<li><code>GO386=387</code>: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).
<li><code>GO386=sse2</code>: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.
<li><code>GO386=387</code>: use x87 for floating point operations; should support all x86 chips (Pentium MMX or later).</li>
<li><code>GO386=sse2</code>: use SSE2 for floating point operations; has better performance than 387, but only available on Pentium 4/Opteron/Athlon 64 or later.</li>
</ul>
</li>
<li><code>$GOARM</code> (for <code>arm</code> only; default is auto-detected if building
on the target processor, 6 if not)
@@ -599,9 +626,9 @@ This sets the ARM floating point co-processor architecture version the run-time
should target. If you are compiling on the target system, its value will be auto-detected.
</p>
<ul>
<li><code>GOARM=5</code>: use software floating point; when CPU doesn't have VFP co-processor
<li><code>GOARM=6</code>: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)
<li><code>GOARM=7</code>: use VFPv3; usually Cortex-A cores
<li><code>GOARM=5</code>: use software floating point; when CPU doesn't have VFP co-processor</li>
<li><code>GOARM=6</code>: use VFPv1 only; default if cross compiling; usually ARM11 or better cores (VFPv2 or better is also supported)</li>
<li><code>GOARM=7</code>: use VFPv3; usually Cortex-A cores</li>
</ul>
<p>
If in doubt, leave this variable unset, and adjust it if required
@@ -610,6 +637,17 @@ The <a href="//golang.org/wiki/GoArm">GoARM</a> page
on the <ahref="//golang.org/wiki">Go community wiki</a>
contains further details regarding Go's ARM support.
</p>
</li>
<li><code>$GOMIPS</code> (for <code>mips</code> and <code>mipsle</code> only)
<p>
This sets whether to use floating point instructions.
</p>
<ul>
<li><code>GOMIPS=hardfloat</code>: use floating point instructions (the default)</li>
<li><code>GOMIPS=softfloat</code>: use soft floating point</li>
</ul>
</li>
</ul>
@@ -627,12 +665,12 @@ not <code>amd64</code>.
<p>
If you choose to override the defaults,
set these variables in your shell profile (<code>$HOME/.bashrc</code>,
<code>$HOME/.profile</code>, or equivalent). The settings might look
<code>$HOME/.profile</code>, or equivalent). The settings might look
distributions</a> are available for the FreeBSD (release 8-STABLE and above),
<ahref="/dl/"target="_blank">Official binary
distributions</a> are available for the FreeBSD (release 10-STABLE and above),
Linux, Mac OS X (10.8 and above), and Windows operating systems and
the 32-bit (<code>386</code>) and 64-bit (<code>amd64</code>) x86 processor
architectures.
@@ -33,7 +33,7 @@ system and architecture, try
<h2id="requirements">System requirements</h2>
<p>
Go binary distributions are available for these supported operating systems and architectures.
Go <ahref="/dl/">binary distributions</a> are available for these supported operating systems and architectures.
Please ensure your system meets these requirements before proceeding.
If your OS or architecture is not on the list, you may be able to
<ahref="/doc/install/source">install from source</a> or
@@ -47,10 +47,10 @@ If your OS or architecture is not on the list, you may be able to
<thalign="center">Notes</th>
</tr>
<tr><tdcolspan="3"><hr></td></tr>
<tr><td>FreeBSD 8-STABLE or later</td><td>amd64</td><td>Debian GNU/kFreeBSD not supported</td></tr>
<tr><td>Linux 2.6.23 or later with glibc</td><td>amd64, 386, arm</td><td>CentOS/RHEL 5.x not supported</td></tr>
<tr><td>MacOS X 10.8 or later</td><td>amd64</td><td>use the clang or gcc<sup>†</sup> that comes with Xcode<sup>‡</sup> for <code>cgo</code> support</td></tr>
<tr><td>Windows XP or later</td><td>amd64, 386</td><td>use MinGW gcc<sup>†</sup>. No need for cygwin or msys.</td></tr>
<tr><td>FreeBSD 10.3 or later</td><td>amd64, 386</td><td>Debian GNU/kFreeBSD not supported</td></tr>
<trvalign='top'><td>Linux 2.6.23 or later with glibc</td><td>amd64, 386, arm, arm64,<br>s390x, ppc64le</td><td>CentOS/RHEL 5.x not supported.<br>Install from source for other libc.</td></tr>
<tr><td>macOS 10.8 or later</td><td>amd64</td><td>use the clang or gcc<sup>†</sup> that comes with Xcode<sup>‡</sup> for <code>cgo</code> support</td></tr>
<tr><td>Windows XP SP2 or later</td><td>amd64, 386</td><td>use MinGW gcc<sup>†</sup>. No need for cygwin or msys.</td></tr>
</table>
<p>
@@ -77,7 +77,7 @@ first <a href="#uninstall">remove the existing version</a>.
<h3id="tarball">Linux, Mac OS X, and FreeBSD tarballs</h3>
<p>
<ahref="https://golang.org/dl/">Download the archive</a>
<ahref="/dl/">Download the archive</a>
and extract it into <code>/usr/local</code>, creating a Go tree in
<code>/usr/local/go</code>. For example:
</p>
@@ -117,12 +117,12 @@ to point to the directory in which it was installed.
</p>
<p>
For example, if you installed Go to your home directory you should add the
following commands to <code>$HOME/.profile</code>:
For example, if you installed Go to your home directory you should add
commands like the following to <code>$HOME/.profile</code>:
</p>
<pre>
export GOROOT=$HOME/go
export GOROOT=$HOME/go1.X
export PATH=$PATH:$GOROOT/bin
</pre>
@@ -138,7 +138,7 @@ location.
<h3id="osx">Mac OS X package installer</h3>
<p>
<ahref="https://golang.org/dl/">Download the package file</a>,
<ahref="/dl/">Download the package file</a>,
open it, and follow the prompts to install the Go tools.
The package installs the Go distribution to <code>/usr/local/go</code>.
</p>
@@ -167,7 +167,7 @@ MSI installer that configures your installation automatically.
<h4id="windows_msi">MSI installer</h4>
<p>
Open the <ahref="https://golang.org/dl/">MSI file</a>
Open the <ahref="/dl/">MSI file</a>
and follow the prompts to install the Go tools.
By default, the installer puts the Go distribution in <code>c:\Go</code>.
</p>
@@ -185,7 +185,7 @@ command prompts for the change to take effect.
<h4id="windows_zip">Zip archive</h4>
<p>
<ahref="https://golang.org/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
<ahref="/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
</p>
<p>
@@ -219,37 +219,15 @@ and building a simple program, as follows.
</p>
<p>
Create a directory to contain your <ahref="code.html#Workspaces">workspace</a>,
t.Logf("Failed %v of %v attempts.",failures,len(cmds))
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
