]> Cypherpunks repositories - gostls13.git/log
gostls13.git
7 years agodatabase/sql: prevent race in driver by locking dc in Next
Daniel Theophanes [Sat, 23 Sep 2017 22:30:46 +0000 (15:30 -0700)]
database/sql: prevent race in driver by locking dc in Next

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>
7 years agocmd/link: zero symtab fields correctly
David Crawshaw [Fri, 13 Oct 2017 16:41:09 +0000 (12:41 -0400)]
cmd/link: zero symtab fields correctly

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>
7 years agonet: fix data race in TestClosingListener
Daniel Martí [Thu, 12 Oct 2017 10:57:36 +0000 (11:57 +0100)]
net: fix data race in TestClosingListener

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>
7 years agocmd/compile: simplify slice/array range loops for some element sizes
Martin Möhrmann [Sun, 18 Dec 2016 19:13:58 +0000 (20:13 +0100)]
cmd/compile: simplify slice/array range loops for some element sizes

In range loops over slices and arrays besides a variable to track the
index an extra variable containing the address of the current element
is used. To compute a pointer to the next element the elements size is
added to the address.

On 386 and amd64 an element of size 1, 2, 4 or 8 bytes can by copied
from an array using a MOV instruction with suitable addressing mode
that uses the start address of the array, the index of the element and
element size as scaling factor. Thereby, for arrays and slices with
suitable element size we can avoid keeping and incrementing an extra
variable to compute the next elements address.

Shrinks cmd/go by 4 kilobytes.

AMD64:
name                   old time/op    new time/op    delta
BinaryTree17              2.66s ± 7%     2.54s ± 0%  -4.53%  (p=0.000 n=10+8)
Fannkuch11                3.02s ± 1%     3.02s ± 1%    ~     (p=0.579 n=10+10)
FmtFprintfEmpty          45.6ns ± 1%    42.2ns ± 1%  -7.46%  (p=0.000 n=10+10)
FmtFprintfString         69.8ns ± 1%    70.4ns ± 1%  +0.84%  (p=0.041 n=10+10)
FmtFprintfInt            80.1ns ± 1%    79.0ns ± 1%  -1.35%  (p=0.000 n=10+10)
FmtFprintfIntInt          127ns ± 1%     125ns ± 1%  -1.00%  (p=0.007 n=10+9)
FmtFprintfPrefixedInt     158ns ± 2%     152ns ± 1%  -4.11%  (p=0.000 n=10+10)
FmtFprintfFloat           218ns ± 1%     214ns ± 1%  -1.61%  (p=0.000 n=10+10)
FmtManyArgs               508ns ± 1%     504ns ± 1%  -0.93%  (p=0.001 n=9+10)
GobDecode                6.76ms ± 1%    6.78ms ± 1%    ~     (p=0.353 n=10+10)
GobEncode                5.84ms ± 1%    5.77ms ± 1%  -1.31%  (p=0.000 n=10+9)
Gzip                      223ms ± 1%     218ms ± 1%  -2.39%  (p=0.000 n=10+10)
Gunzip                   40.3ms ± 1%    40.4ms ± 3%    ~     (p=0.796 n=10+10)
HTTPClientServer         73.5µs ± 0%    73.3µs ± 0%  -0.28%  (p=0.000 n=10+9)
JSONEncode               12.7ms ± 1%    12.6ms ± 8%    ~     (p=0.173 n=8+10)
JSONDecode               57.5ms ± 1%    56.1ms ± 2%  -2.40%  (p=0.000 n=10+10)
Mandelbrot200            3.80ms ± 1%    3.86ms ± 6%    ~     (p=0.579 n=10+10)
GoParse                  3.25ms ± 1%    3.23ms ± 1%    ~     (p=0.052 n=10+10)
RegexpMatchEasy0_32      74.4ns ± 1%    76.9ns ± 1%  +3.39%  (p=0.000 n=10+10)
RegexpMatchEasy0_1K       243ns ± 2%     248ns ± 1%  +1.86%  (p=0.000 n=10+8)
RegexpMatchEasy1_32      71.0ns ± 2%    72.8ns ± 1%  +2.55%  (p=0.000 n=10+10)
RegexpMatchEasy1_1K       370ns ± 1%     383ns ± 0%  +3.39%  (p=0.000 n=10+9)
RegexpMatchMedium_32      107ns ± 0%     113ns ± 1%  +5.33%  (p=0.000 n=6+10)
RegexpMatchMedium_1K     35.0µs ± 1%    36.0µs ± 1%  +3.13%  (p=0.000 n=10+10)
RegexpMatchHard_32       1.65µs ± 1%    1.69µs ± 1%  +2.23%  (p=0.000 n=10+9)
RegexpMatchHard_1K       49.8µs ± 1%    50.6µs ± 1%  +1.59%  (p=0.000 n=10+10)
Revcomp                   398ms ± 1%     396ms ± 1%  -0.51%  (p=0.043 n=10+10)
Template                 63.4ms ± 1%    60.8ms ± 0%  -4.11%  (p=0.000 n=10+9)
TimeParse                 318ns ± 1%     322ns ± 1%  +1.10%  (p=0.005 n=10+10)
TimeFormat                323ns ± 1%     336ns ± 1%  +4.15%  (p=0.000 n=10+10)

Updates: #15809.

Change-Id: I55915aaf6d26768e12247f8a8edf14e7630726d1
Reviewed-on: https://go-review.googlesource.com/38061
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
7 years agoruntime: use vDSO on linux/386 to improve time.Now performance
Frank Somers [Tue, 10 Oct 2017 21:50:01 +0000 (22:50 +0100)]
runtime: use vDSO on linux/386 to improve time.Now performance

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>
7 years agosyscall: correct type for timeout argument to Select on linux/{arm64,mips64x}
Tobias Klauser [Fri, 13 Oct 2017 11:51:23 +0000 (13:51 +0200)]
syscall: correct type for timeout argument to Select on linux/{arm64,mips64x}

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>
7 years agocmd/asm: refine Go assembly for ARM64
Wei Xiao [Tue, 25 Apr 2017 10:29:54 +0000 (18:29 +0800)]
cmd/asm: refine Go assembly for ARM64

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>
7 years agoimage/gif: try harder to use global color table
Jed Denlea [Wed, 4 Oct 2017 22:36:07 +0000 (15:36 -0700)]
image/gif: try harder to use global color table

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>
7 years agocmd/compile: attempt to deflake debug_test.go
David Chase [Wed, 11 Oct 2017 14:28:20 +0000 (10:28 -0400)]
cmd/compile: attempt to deflake debug_test.go

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>
7 years agoreflect: allow Copy to a byte array or byte slice from a string
Tim Cooper [Thu, 12 Oct 2017 20:42:18 +0000 (17:42 -0300)]
reflect: allow Copy to a byte array or byte slice from a string

This somewhat mirrors the special case behavior of the copy built-in.

Fixes #22215

Change-Id: Ic353003ad3de659d3a6b4e9d97295b42510f3bf7
Reviewed-on: https://go-review.googlesource.com/70431
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agoruntime: factor amd64 specifics from vdso_linux.go
Frank Somers [Tue, 10 Oct 2017 21:27:01 +0000 (22:27 +0100)]
runtime: factor amd64 specifics from vdso_linux.go

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>
7 years agocmd/link, runtime: put hasmain bit in moduledata
David Crawshaw [Mon, 9 Oct 2017 20:04:44 +0000 (16:04 -0400)]
cmd/link, runtime: put hasmain bit in moduledata

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>
7 years agocmd/link: split PE loader into its own package
David Crawshaw [Thu, 12 Oct 2017 17:38:45 +0000 (13:38 -0400)]
cmd/link: split PE loader into its own package

For #22095

Change-Id: I8f48fce571b69a7e8edf2ad7733ffdfd38676e63
Reviewed-on: https://go-review.googlesource.com/70310
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agocmd/compile: add two error position tests for the typechecker
Tobias Klauser [Thu, 12 Oct 2017 11:49:49 +0000 (13:49 +0200)]
cmd/compile: add two error position tests for the typechecker

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>

7 years agocmd/compile: intrinsify runtime/internal/sys.Ctz{32,64} on ppc64
Matthew Dempsky [Thu, 12 Oct 2017 18:45:35 +0000 (11:45 -0700)]
cmd/compile: intrinsify runtime/internal/sys.Ctz{32,64} on ppc64

These functions are identical to math/bits.TrailingZeros{32,64}, which
are already intrinsified on ppc64.

Change-Id: If7ee57e7afe53154874f4b66bacdb6237806128a
Reviewed-on: https://go-review.googlesource.com/70350
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
7 years agotest: add test case that gccgo miscompiled
Ian Lance Taylor [Thu, 12 Oct 2017 17:25:25 +0000 (10:25 -0700)]
test: add test case that gccgo miscompiled

Error was

main.go:7:11: error: import error at 162: expected ‘<type ’

Change-Id: Iacfe4bfa003d7708a21ebc89ad1ab2d4a3b041a8
Reviewed-on: https://go-review.googlesource.com/70290
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
7 years agocmd/link: generate PC ranges for compilation unit DIEs
Austin Clements [Tue, 10 Oct 2017 20:19:49 +0000 (16:19 -0400)]
cmd/link: generate PC ranges for compilation unit DIEs

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>
7 years agocmd/link: one DWARF compilation unit per package
Austin Clements [Mon, 9 Oct 2017 20:19:56 +0000 (16:19 -0400)]
cmd/link: one DWARF compilation unit per package

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>

7 years agocmd/link: remove silly sym.R[:0] truncation
Austin Clements [Wed, 11 Oct 2017 19:57:58 +0000 (15:57 -0400)]
cmd/link: remove silly sym.R[:0] truncation

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>

7 years agocmd/link: eliminate .debug_aranges
Austin Clements [Wed, 11 Oct 2017 15:05:58 +0000 (11:05 -0400)]
cmd/link: eliminate .debug_aranges

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>
7 years agocmd/link: suppress unnecessary DWARF relocs that confuse dsymutil
Heschi Kreinick [Wed, 4 Oct 2017 22:30:38 +0000 (18:30 -0400)]
cmd/link: suppress unnecessary DWARF relocs that confuse dsymutil

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>
7 years agoruntime: don't restore the alternate signal stack on ios
Elias Naur [Thu, 12 Oct 2017 16:41:06 +0000 (18:41 +0200)]
runtime: don't restore the alternate signal stack on ios

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>
7 years agocmd/go: delete p.Internal.Target in favor of p.Target
Russ Cox [Thu, 12 Oct 2017 01:34:02 +0000 (21:34 -0400)]
cmd/go: delete p.Internal.Target in favor of p.Target

The two are not meaningfully different, and it is confusing to have two.

Change-Id: Ie6a355ea4d79fb4bb79bf5124071a866038b19ba
Reviewed-on: https://go-review.googlesource.com/70211
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
7 years agointernal/poll: only call SetFileCompletionNotificationModes for sockets
Alex Brainman [Wed, 11 Oct 2017 07:23:30 +0000 (18:23 +1100)]
internal/poll: only call SetFileCompletionNotificationModes for sockets

CL 36799 made SetFileCompletionNotificationModes to be called for
file handles. I don't think it is correct. Revert that change.

Fixes #22024
Fixes #22207

Change-Id: I26260e8a727131cffbf60958d79eca2457495554
Reviewed-on: https://go-review.googlesource.com/69871
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agointernal/poll: do not call SetFileCompletionNotificationModes if it is broken
Alex Brainman [Wed, 11 Oct 2017 07:15:25 +0000 (18:15 +1100)]
internal/poll: do not call SetFileCompletionNotificationModes if it is broken

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>
7 years agoimage/gif: make Decode only keep the first frame in memory
Artyom Pervukhin [Wed, 11 Oct 2017 08:19:44 +0000 (11:19 +0300)]
image/gif: make Decode only keep the first frame in memory

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>
7 years agoruntime: fix dragonfly/amd64
Austin Clements [Thu, 12 Oct 2017 01:51:30 +0000 (21:51 -0400)]
runtime: fix dragonfly/amd64

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>
7 years agodoc: recommend building Go 1.4 with CGO_ENABLED=0
Ian Lance Taylor [Fri, 8 Sep 2017 21:38:10 +0000 (14:38 -0700)]
doc: recommend building Go 1.4 with CGO_ENABLED=0

Fixes #21054

Change-Id: I016486dc62c04a80727f8da7d1dcec52f2c7f344
Reviewed-on: https://go-review.googlesource.com/62291
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
7 years agoruntime: fix crash on Plan 9
David du Colombier [Wed, 11 Oct 2017 23:39:46 +0000 (01:39 +0200)]
runtime: fix crash on Plan 9

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>
7 years agocmd/compile: record InlCost in export data
Matthew Dempsky [Wed, 11 Oct 2017 22:25:13 +0000 (15:25 -0700)]
cmd/compile: record InlCost in export data

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>
7 years agocmd/compile: deduplicate a few lines in swt.go
Daniel Martí [Wed, 27 Sep 2017 10:30:10 +0000 (11:30 +0100)]
cmd/compile: deduplicate a few lines in swt.go

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>
7 years agocmd/compile: inline calls to local closures
Hugues Bruant [Mon, 18 Sep 2017 21:54:10 +0000 (14:54 -0700)]
cmd/compile: inline calls to local closures

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>
7 years agoruntime: don't try to free OS-created signal stacks
Austin Clements [Wed, 11 Oct 2017 21:04:26 +0000 (17:04 -0400)]
runtime: don't try to free OS-created signal stacks

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>

7 years agoencoding/json: use Deprecated markers
Joe Tsai [Wed, 11 Oct 2017 21:41:25 +0000 (14:41 -0700)]
encoding/json: use Deprecated markers

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>

7 years agocmd/compile: add line numbers to values & blocks in ssa.html
David Chase [Tue, 10 Oct 2017 18:44:15 +0000 (14:44 -0400)]
cmd/compile: add line numbers to values & blocks in ssa.html

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>
7 years agoruntime: unify amd64 -buildmode=c-archive/c-shared entry point code
Ian Lance Taylor [Tue, 10 Oct 2017 22:11:05 +0000 (15:11 -0700)]
runtime: unify amd64 -buildmode=c-archive/c-shared entry point code

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>
7 years agomisc/cgo/testcarchive: use -no-pie where needed
Lynn Boger [Wed, 11 Oct 2017 20:02:59 +0000 (16:02 -0400)]
misc/cgo/testcarchive: use -no-pie where needed

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>
7 years agocmd/link: move ELF reader to its own package
David Crawshaw [Fri, 6 Oct 2017 20:01:02 +0000 (16:01 -0400)]
cmd/link: move ELF reader to its own package

Along the way, switch to using relocation constants from debug/elf.

For #22095

Change-Id: I1a64353619f95dde5aa39060c4b9d001af7dc1e4
Reviewed-on: https://go-review.googlesource.com/69013
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agotest: skip issue22200b.go on mipsle
Cherry Zhang [Wed, 11 Oct 2017 20:05:10 +0000 (16:05 -0400)]
test: skip issue22200b.go on mipsle

It should be skipped on 32-bit architectures.

Change-Id: If7a64b9e90e47c3e8734dd62729bfd2944ae926c
Reviewed-on: https://go-review.googlesource.com/70071
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

7 years agocmd/dist: refresh deps.go after recent package io changes
Russ Cox [Wed, 11 Oct 2017 20:30:45 +0000 (16:30 -0400)]
cmd/dist: refresh deps.go after recent package io changes

Change-Id: Iaa960c85011289e047c64b53cf610838eb50332d
Reviewed-on: https://go-review.googlesource.com/70073
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
7 years agoruntime: unify amd64 -buildmode=exe entry point code
Ian Lance Taylor [Mon, 9 Oct 2017 18:31:20 +0000 (11:31 -0700)]
runtime: unify amd64 -buildmode=exe entry point code

All of the amd64 entry point code is the same except for Plan 9.
Unify it all into asm_amd64.s.

Change-Id: Id47ce3a7bb2bb0fd48f326a2d88ed18b17dee456
Reviewed-on: https://go-review.googlesource.com/69292
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agocmd/link: fix some unintentional symbol creation
Austin Clements [Tue, 10 Oct 2017 15:58:31 +0000 (11:58 -0400)]
cmd/link: fix some unintentional symbol creation

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>
7 years agoio: simplify pipe implementation
Joe Tsai [Fri, 22 Sep 2017 00:43:00 +0000 (17:43 -0700)]
io: simplify pipe implementation

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>
7 years agonet: implement deadline functionality on Pipe
Joe Tsai [Fri, 24 Feb 2017 01:13:09 +0000 (17:13 -0800)]
net: implement deadline functionality on Pipe

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>
7 years agocmd/internal/buildid: add missing f.Close in ReadFile
Russ Cox [Wed, 11 Oct 2017 19:14:53 +0000 (15:14 -0400)]
cmd/internal/buildid: add missing f.Close in ReadFile

On Windows, not closing f keeps us from being able to remove it.

Change-Id: Id4cb709b6ce0b30485b87364a9f0e6e71d2782bd
Reviewed-on: https://go-review.googlesource.com/70070
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agocmd/dist: reenable TestDeps
Russ Cox [Wed, 11 Oct 2017 18:17:57 +0000 (14:17 -0400)]
cmd/dist: reenable TestDeps

It looks like I forgot to reenable this test when I fixed #21522.
Update deps.go and reenable.

Change-Id: I68a45df09b418f48d93d2e7ab1d274e056c192e6
Reviewed-on: https://go-review.googlesource.com/70050
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
7 years agocmd/go: record both build ID and content ID in archives and binaries
Russ Cox [Fri, 6 Oct 2017 19:48:51 +0000 (15:48 -0400)]
cmd/go: record both build ID and content ID in archives and binaries

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>
7 years agocmd/compile: fix some plive comments
Austin Clements [Mon, 2 Oct 2017 21:29:10 +0000 (17:29 -0400)]
cmd/compile: fix some plive comments

The liveness analysis no longer directly emits PCDATA. Fix stale
comments that say so.

Change-Id: Id26b112ddf4c13a12ebf766f64bf57c68fbfe3ef
Reviewed-on: https://go-review.googlesource.com/67691
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7 years agocmd/compile: abort earlier if stack frame too large
Keith Randall [Wed, 11 Oct 2017 00:43:41 +0000 (17:43 -0700)]
cmd/compile: abort earlier if stack frame too large

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>
7 years agocmd/compile: fold constant comparisions into SETxxmem ops.
Keith Randall [Wed, 11 Oct 2017 16:28:47 +0000 (09:28 -0700)]
cmd/compile: fold constant comparisions into SETxxmem ops.

Fixes #22198

Change-Id: I5cb91c73069af8b16a2580d28756efd58c84b690
Reviewed-on: https://go-review.googlesource.com/69990
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7 years agocmd/buildid: add new tool factoring out code needed by go command
Russ Cox [Fri, 6 Oct 2017 18:03:55 +0000 (14:03 -0400)]
cmd/buildid: add new tool factoring out code needed by go command

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>
7 years agocmd/compile: split TestNexting into subtests
Austin Clements [Wed, 11 Oct 2017 14:34:35 +0000 (10:34 -0400)]
cmd/compile: split TestNexting into subtests

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>
7 years agoruntime: make (Un)LockOSThread doc more prescriptive
Austin Clements [Wed, 2 Aug 2017 19:54:05 +0000 (15:54 -0400)]
runtime: make (Un)LockOSThread doc more prescriptive

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>
7 years agoruntime: terminate locked OS thread if its goroutine exits
Austin Clements [Fri, 16 Jun 2017 20:21:12 +0000 (16:21 -0400)]
runtime: terminate locked OS thread if its goroutine exits

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>
7 years agoruntime: make it possible to exit Go-created threads
Austin Clements [Fri, 16 Jun 2017 19:54:21 +0000 (15:54 -0400)]
runtime: make it possible to exit Go-created threads

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>
7 years agocmd/go: make cmd/* default to go tool installation
Russ Cox [Fri, 6 Oct 2017 18:12:56 +0000 (14:12 -0400)]
cmd/go: make cmd/* default to go tool installation

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>
7 years agoruntime: replace sched.mcount int32 with sched.mnext int64
Austin Clements [Fri, 6 Oct 2017 01:28:01 +0000 (21:28 -0400)]
runtime: replace sched.mcount int32 with sched.mnext int64

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>
7 years agocmd/go: hoist C++, Objective-C, and Fortran checks earlier
Russ Cox [Thu, 5 Oct 2017 23:30:51 +0000 (19:30 -0400)]
cmd/go: hoist C++, Objective-C, and Fortran checks earlier

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>
7 years agoruntime: mark mstart as nowritebarrierrec
Austin Clements [Thu, 15 Jun 2017 19:02:32 +0000 (15:02 -0400)]
runtime: mark mstart as nowritebarrierrec

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>
7 years agocmd/go: replace a.Package.Internal.Pkgfile with a.built
Russ Cox [Thu, 5 Oct 2017 20:57:25 +0000 (16:57 -0400)]
cmd/go: replace a.Package.Internal.Pkgfile with a.built

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>
7 years agoruntime: make m.nextwaitm an muintptr
Austin Clements [Thu, 15 Jun 2017 16:23:09 +0000 (12:23 -0400)]
runtime: make m.nextwaitm an muintptr

This field is really a *m (modulo its bottom bit). Change it from
uintptr to muintptr to document this fact.

Change-Id: I2d181a955ef1d2c1a268edf20091b440d85726c9
Reviewed-on: https://go-review.googlesource.com/46034
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>
7 years agocmd/go: clean up compile vs link vs shared library actions
Russ Cox [Tue, 10 Oct 2017 01:07:32 +0000 (21:07 -0400)]
cmd/go: clean up compile vs link vs shared library actions

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>
7 years agoruntime: don't start new threads from locked threads
Austin Clements [Thu, 15 Jun 2017 14:51:15 +0000 (10:51 -0400)]
runtime: don't start new threads from locked threads

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>
7 years agocmd/go: separate compile and link steps in action graph
Russ Cox [Mon, 9 Oct 2017 19:19:46 +0000 (15:19 -0400)]
cmd/go: separate compile and link steps in action graph

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>
7 years agodebug/elf: add relocation constants
David Crawshaw [Fri, 6 Oct 2017 19:59:44 +0000 (15:59 -0400)]
debug/elf: add relocation constants

Compiled from various tables found around the internet.

Some of these are used by cmd/link.

Change-Id: I258b25e694dbe91a61d675763f2c47ccc928fd70
Reviewed-on: https://go-review.googlesource.com/69012
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agocmd/go: correct directory used in checkNestedVCS test
Ian Lance Taylor [Tue, 10 Oct 2017 21:10:28 +0000 (14:10 -0700)]
cmd/go: correct directory used in checkNestedVCS test

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 #22157
Fixes #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>
7 years agocmd/compile: optimize ARM code with CMN/TST/TEQ
Ben Shi [Mon, 2 Oct 2017 03:09:28 +0000 (03:09 +0000)]
cmd/compile: optimize ARM code with CMN/TST/TEQ

CMN/TST/TEQ were supported since ARMv4, which can be used to
simplify comparisons.

This patch implements the optimization and here are the benchmark
results.

1. A special test case got 18.21% improvement.
name                     old time/op    new time/op    delta
TSTTEQ-4                    806µs ± 1%     659µs ± 0%  -18.21%  (p=0.000 n=20+18)
(https://github.com/benshi001/ugo1/blob/master/tstteq_test.go)

2. There is no regression in the compilecmp benchmark.
name        old time/op       new time/op       delta
Template          2.31s ± 1%        2.30s ± 1%    ~     (p=0.661 n=10+9)
Unicode           1.32s ± 3%        1.32s ± 5%    ~     (p=0.280 n=10+10)
GoTypes           7.69s ± 1%        7.65s ± 0%  -0.52%  (p=0.027 n=10+8)
Compiler          36.5s ± 1%        36.4s ± 1%    ~     (p=0.546 n=9+9)
SSA               85.1s ± 2%        84.9s ± 1%    ~     (p=0.529 n=10+10)
Flate             1.43s ± 2%        1.43s ± 2%    ~     (p=0.661 n=10+9)
GoParser          1.81s ± 2%        1.81s ± 1%    ~     (p=0.796 n=10+10)
Reflect           5.10s ± 2%        5.09s ± 1%    ~     (p=0.853 n=10+10)
Tar               2.47s ± 1%        2.48s ± 1%    ~     (p=0.123 n=10+10)
XML               2.59s ± 1%        2.58s ± 1%    ~     (p=0.853 n=10+10)
[Geo mean]        4.78s             4.77s       -0.17%

name        old user-time/op  new user-time/op  delta
Template          2.72s ± 3%        2.73s ± 2%    ~     (p=0.928 n=10+10)
Unicode           1.58s ± 4%        1.60s ± 1%    ~     (p=0.087 n=10+9)
GoTypes           9.41s ± 2%        9.36s ± 1%    ~     (p=0.060 n=10+10)
Compiler          44.4s ± 2%        44.2s ± 2%    ~     (p=0.289 n=10+10)
SSA                110s ± 2%         110s ± 1%    ~     (p=0.739 n=10+10)
Flate             1.67s ± 2%        1.63s ± 3%    ~     (p=0.063 n=10+10)
GoParser          2.12s ± 1%        2.12s ± 2%    ~     (p=0.840 n=10+10)
Reflect           5.94s ± 1%        5.98s ± 1%    ~     (p=0.063 n=9+10)
Tar               3.01s ± 2%        3.02s ± 2%    ~     (p=0.584 n=10+10)
XML               3.04s ± 3%        3.02s ± 2%    ~     (p=0.696 n=10+10)
[Geo mean]        5.73s             5.72s       -0.20%

name        old text-bytes    new text-bytes    delta
HelloSize         579kB ± 0%        579kB ± 0%    ~     (all equal)

name        old data-bytes    new data-bytes    delta
HelloSize        5.46kB ± 0%       5.46kB ± 0%    ~     (all equal)

name        old bss-bytes     new bss-bytes     delta
HelloSize        72.8kB ± 0%       72.8kB ± 0%    ~     (all equal)

name        old exe-bytes     new exe-bytes     delta
HelloSize        1.03MB ± 0%       1.03MB ± 0%    ~     (all equal)

3. There is little change in the go1 benchmark (excluding the noise).
name                     old time/op    new time/op     delta
BinaryTree17-4              40.3s ± 1%      40.6s ± 1%  +0.80%  (p=0.000 n=30+30)
Fannkuch11-4                24.2s ± 1%      24.1s ± 0%    ~     (p=0.093 n=30+30)
FmtFprintfEmpty-4           834ns ± 0%      826ns ± 0%  -0.93%  (p=0.000 n=29+24)
FmtFprintfString-4         1.39µs ± 1%     1.36µs ± 0%  -2.02%  (p=0.000 n=30+30)
FmtFprintfInt-4            1.43µs ± 1%     1.44µs ± 1%    ~     (p=0.155 n=30+29)
FmtFprintfIntInt-4         2.09µs ± 0%     2.11µs ± 0%  +1.16%  (p=0.000 n=28+30)
FmtFprintfPrefixedInt-4    2.33µs ± 1%     2.36µs ± 0%  +1.25%  (p=0.000 n=30+30)
FmtFprintfFloat-4          4.27µs ± 1%     4.32µs ± 1%  +1.27%  (p=0.000 n=30+30)
FmtManyArgs-4              8.18µs ± 0%     8.14µs ± 0%  -0.46%  (p=0.000 n=25+27)
GobDecode-4                 101ms ± 1%      101ms ± 1%    ~     (p=0.182 n=29+29)
GobEncode-4                89.6ms ± 1%     87.8ms ± 2%  -2.02%  (p=0.000 n=30+29)
Gzip-4                      4.07s ± 1%      4.08s ± 1%    ~     (p=0.173 n=30+27)
Gunzip-4                    602ms ± 1%      600ms ± 1%  -0.29%  (p=0.000 n=29+28)
HTTPClientServer-4          679µs ± 4%      683µs ± 3%    ~     (p=0.197 n=30+30)
JSONEncode-4                241ms ± 1%      239ms ± 1%  -0.84%  (p=0.000 n=30+30)
JSONDecode-4                903ms ± 1%      882ms ± 1%  -2.33%  (p=0.000 n=30+30)
Mandelbrot200-4            41.8ms ± 0%     41.8ms ± 0%    ~     (p=0.719 n=30+30)
GoParse-4                  45.5ms ± 1%     45.8ms ± 1%  +0.52%  (p=0.000 n=30+30)
RegexpMatchEasy0_32-4      1.27µs ± 1%     1.27µs ± 0%  -0.60%  (p=0.000 n=30+30)
RegexpMatchEasy0_1K-4      7.77µs ± 6%     7.69µs ± 4%  -0.96%  (p=0.040 n=30+30)
RegexpMatchEasy1_32-4      1.29µs ± 1%     1.28µs ± 1%  -0.54%  (p=0.000 n=30+30)
RegexpMatchEasy1_1K-4      10.3µs ± 6%     10.2µs ± 3%    ~     (p=0.453 n=30+27)
RegexpMatchMedium_32-4     1.98µs ± 1%     2.00µs ± 1%  +0.85%  (p=0.000 n=30+29)
RegexpMatchMedium_1K-4      503µs ± 0%      503µs ± 1%    ~     (p=0.752 n=30+30)
RegexpMatchHard_32-4       27.1µs ± 1%     26.5µs ± 0%  -1.96%  (p=0.000 n=30+24)
RegexpMatchHard_1K-4        809µs ± 1%      799µs ± 1%  -1.29%  (p=0.000 n=29+30)
Revcomp-4                  67.3ms ± 2%     67.2ms ± 1%    ~     (p=0.265 n=29+29)
Template-4                  1.08s ± 1%      1.07s ± 0%  -1.39%  (p=0.000 n=30+22)
TimeParse-4                6.93µs ± 1%     6.96µs ± 1%  +0.40%  (p=0.005 n=30+30)
TimeFormat-4               13.3µs ± 0%     13.3µs ± 1%    ~     (p=0.734 n=30+30)
[Geo mean]                  709µs           707µs       -0.32%

name                     old speed      new speed       delta
GobDecode-4              7.59MB/s ± 1%   7.57MB/s ± 1%    ~     (p=0.145 n=29+29)
GobEncode-4              8.56MB/s ± 1%   8.74MB/s ± 1%  +2.07%  (p=0.000 n=30+29)
Gzip-4                   4.76MB/s ± 1%   4.75MB/s ± 1%  -0.25%  (p=0.037 n=30+30)
Gunzip-4                 32.2MB/s ± 1%   32.3MB/s ± 1%  +0.29%  (p=0.000 n=29+28)
JSONEncode-4             8.04MB/s ± 1%   8.11MB/s ± 1%  +0.85%  (p=0.000 n=30+30)
JSONDecode-4             2.15MB/s ± 1%   2.20MB/s ± 1%  +2.29%  (p=0.000 n=30+30)
GoParse-4                1.27MB/s ± 1%   1.26MB/s ± 1%  -0.73%  (p=0.000 n=30+30)
RegexpMatchEasy0_32-4    25.1MB/s ± 1%   25.3MB/s ± 0%  +0.61%  (p=0.000 n=30+30)
RegexpMatchEasy0_1K-4     131MB/s ± 6%    133MB/s ± 4%  +1.35%  (p=0.009 n=28+30)
RegexpMatchEasy1_32-4    24.9MB/s ± 1%   25.0MB/s ± 1%  +0.54%  (p=0.000 n=30+30)
RegexpMatchEasy1_1K-4    99.2MB/s ± 6%  100.2MB/s ± 3%    ~     (p=0.448 n=30+27)
RegexpMatchMedium_32-4    503kB/s ± 1%    500kB/s ± 0%  -0.66%  (p=0.002 n=30+24)
RegexpMatchMedium_1K-4   2.04MB/s ± 0%   2.04MB/s ± 1%    ~     (p=0.358 n=30+30)
RegexpMatchHard_32-4     1.18MB/s ± 1%   1.20MB/s ± 1%  +1.75%  (p=0.000 n=30+30)
RegexpMatchHard_1K-4     1.26MB/s ± 1%   1.28MB/s ± 1%  +1.42%  (p=0.000 n=30+30)
Revcomp-4                37.8MB/s ± 2%   37.8MB/s ± 1%    ~     (p=0.266 n=29+29)
Template-4               1.80MB/s ± 1%   1.82MB/s ± 1%  +1.46%  (p=0.000 n=30+30)
[Geo mean]               6.91MB/s        6.96MB/s       +0.70%

fixes #21583

Change-Id: I24065a80588ccae7de3ad732a3cfb0026cf7e214
Reviewed-on: https://go-review.googlesource.com/67490
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agoruntime: move vdso_linux_amd64.go to vdso_linux.go
Frank Somers [Tue, 10 Oct 2017 20:15:56 +0000 (21:15 +0100)]
runtime: move vdso_linux_amd64.go to vdso_linux.go

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>
7 years agocmd/compile: eliminate some lineno uses
Daniel Martí [Tue, 10 Oct 2017 22:04:48 +0000 (23:04 +0100)]
cmd/compile: eliminate some lineno uses

Focused on ranges, selects and switches for this one.

While at it, simplify some vars in typecheckselect.

Updates #19683.

Change-Id: Ib6aabe0f6826cb1930483aeb4bb2de1ff8052d9e
Reviewed-on: https://go-review.googlesource.com/69690
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agocmd/compile: fix OTYPESW Op comment
Alberto Donizetti [Sun, 8 Oct 2017 12:12:40 +0000 (14:12 +0200)]
cmd/compile: fix OTYPESW Op comment

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>
7 years agocmd/compile: disable TestNexting in short mode
Ian Lance Taylor [Wed, 11 Oct 2017 00:19:56 +0000 (17:19 -0700)]
cmd/compile: disable TestNexting in short mode

Updates #22206

Change-Id: If75feddc01f8f86f294929fa7081c70eb15e581d
Reviewed-on: https://go-review.googlesource.com/69790
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
7 years agocmd/compile/internal/syntax: consider function nesting for error recovery
griesemer [Tue, 10 Oct 2017 23:56:56 +0000 (16:56 -0700)]
cmd/compile/internal/syntax: consider function nesting for error recovery

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>

7 years agocmd/compile/internal/syntax: factor out parsing of func bodies (cleanup)
griesemer [Tue, 10 Oct 2017 23:12:52 +0000 (16:12 -0700)]
cmd/compile/internal/syntax: factor out parsing of func bodies (cleanup)

Change-Id: If6481a5401940a923fc9a104981dfb90eed0d1ac
Reviewed-on: https://go-review.googlesource.com/69750
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agocmd/compile/internal/syntax: remove some outdated comments (cleanup)
griesemer [Tue, 10 Oct 2017 22:53:51 +0000 (15:53 -0700)]
cmd/compile/internal/syntax: remove some outdated comments (cleanup)

Change-Id: If242bb99d501420827b764c908580f2363e01ac4
Reviewed-on: https://go-review.googlesource.com/69730
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7 years agocmd/asm, cmd/internal/obj/ppc64: Fix Data Cache instructions for ppc64x
Carlos Eduardo Seo [Thu, 5 Oct 2017 21:30:13 +0000 (17:30 -0400)]
cmd/asm, cmd/internal/obj/ppc64: Fix Data Cache instructions for ppc64x

This change fixes the implementation of Data Cache instructions for
ppc64x, allowing non-zero hint field values.

Change-Id: I454aac9293d069a4817ee574d5809fa1799b3216
Reviewed-on: https://go-review.googlesource.com/68670
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
7 years agoarchive/tar: ignore ChangeTime and AccessTime unless Format is specified
Joe Tsai [Mon, 9 Oct 2017 18:45:43 +0000 (11:45 -0700)]
archive/tar: ignore ChangeTime and AccessTime unless Format is specified

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>

7 years agoarchive/tar: improve handling of directory paths
Joe Tsai [Fri, 6 Oct 2017 08:40:58 +0000 (01:40 -0700)]
archive/tar: improve handling of directory paths

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>

7 years agocmd/compile: intrinsify atomics on MIPS64
Cherry Zhang [Thu, 5 Oct 2017 14:11:38 +0000 (10:11 -0400)]
cmd/compile: intrinsify atomics on MIPS64

Change-Id: Ica65b7a52af9558a05d0a0e1dff0f9ec838f4117
Reviewed-on: https://go-review.googlesource.com/68830
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
7 years agocmd/compile: simplify mkinlcall1
Matthew Dempsky [Mon, 9 Oct 2017 18:06:52 +0000 (11:06 -0700)]
cmd/compile: simplify mkinlcall1

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>
7 years agocmd/compile: remove outdated TODO about inlining
Matthew Dempsky [Tue, 10 Oct 2017 16:35:11 +0000 (09:35 -0700)]
cmd/compile: remove outdated TODO about inlining

We've supported inlining methods called as functions for a while now.

Change-Id: I53fba426e45f91d65a38f00456c2ae1527372b50
Reviewed-on: https://go-review.googlesource.com/69530
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
7 years agotesting: add PAUSE, CONT output lines to explain Parallel execution
Russ Cox [Tue, 18 Jul 2017 01:06:05 +0000 (21:06 -0400)]
testing: add PAUSE, CONT output lines to explain Parallel execution

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>
7 years agocmd/compile: make bad Ctypes be only 0
Daniel Martí [Tue, 10 Oct 2017 16:36:03 +0000 (17:36 +0100)]
cmd/compile: make bad Ctypes be only 0

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>

7 years agocmd/compile: clean up ADDconst on PPC64
Cherry Zhang [Tue, 10 Oct 2017 14:26:35 +0000 (10:26 -0400)]
cmd/compile: clean up ADDconst on PPC64

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>
7 years agocrypto/x509: reject intermediates with unknown critical extensions.
Adam Langley [Fri, 6 Oct 2017 19:46:22 +0000 (12:46 -0700)]
crypto/x509: reject intermediates with unknown critical extensions.

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>
7 years agocmd/compile: intrinsify runtime.getcallersp
Cherry Zhang [Mon, 9 Oct 2017 19:33:29 +0000 (15:33 -0400)]
cmd/compile: intrinsify runtime.getcallersp

Add a compiler intrinsic for getcallersp. So we are able to get
rid of the argument (not done in this CL).

Change-Id: Ic38fda1c694f918328659ab44654198fb116668d
Reviewed-on: https://go-review.googlesource.com/69350
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
7 years agoruntime: fix cgo export of panicmem on ios
Elias Naur [Sun, 8 Oct 2017 13:23:10 +0000 (15:23 +0200)]
runtime: fix cgo export of panicmem on ios

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>
7 years agocmd/dist, cmd/link, cmd/go: make c-shared work on windows
Alex Brainman [Thu, 5 Oct 2017 06:36:13 +0000 (17:36 +1100)]
cmd/dist, cmd/link, cmd/go: make c-shared work on windows

Thanks to Christopher Nelson for spearheading the effort.

Fixes #11058

Change-Id: Icafabac8dc697626ff1bd943cc577b0b1cc6b349
Reviewed-on: https://go-review.googlesource.com/69091
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agocmd/go: add undocumented -debug-actiongraph flag to dump action graph
Russ Cox [Mon, 9 Oct 2017 18:37:11 +0000 (14:37 -0400)]
cmd/go: add undocumented -debug-actiongraph flag to dump action graph

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>

7 years agocmd/link: various cleanups using tools
Daniel Martí [Mon, 9 Oct 2017 09:11:00 +0000 (10:11 +0100)]
cmd/link: various cleanups using tools

* remove unnecessary explicit types
* remove dead assignments
* remove unused fields
* unindent code using early continues
* remove some unnecessary type conversions
* remove some unused func parameters

Change-Id: I202c67e92940beacbd80fc2dc179f9556dc5d9e5
Reviewed-on: https://go-review.googlesource.com/69118
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
7 years agocmd/compile: add ideal int constants to dwarf
Keith Randall [Mon, 9 Oct 2017 17:08:54 +0000 (10:08 -0700)]
cmd/compile: add ideal int constants to dwarf

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>
7 years agocmd/compile: skip ssa/debug_test.go when gdb missing etc.
David Chase [Mon, 9 Oct 2017 20:41:25 +0000 (16:41 -0400)]
cmd/compile: skip ssa/debug_test.go when gdb missing etc.

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>
7 years agoruntime: remove a few unused params and results
Daniel Martí [Mon, 9 Oct 2017 09:54:22 +0000 (10:54 +0100)]
runtime: remove a few unused params and results

These have never had a use - not even going back to when they were added
in C.

Change-Id: I143b6902b3bacb1fa83c56c9070a8adb9f61a844
Reviewed-on: https://go-review.googlesource.com/69119
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>

7 years agoencoding/asn1: don't encode strings with '*' as PrintableString.
Adam Langley [Fri, 6 Oct 2017 17:48:01 +0000 (10:48 -0700)]
encoding/asn1: don't encode strings with '*' as PrintableString.

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>
7 years agogo/doc: fix constant type propagation
griesemer [Fri, 6 Oct 2017 00:03:53 +0000 (17:03 -0700)]
go/doc: fix constant type propagation

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>
7 years agocmd/compile/internal/syntax: remove unused code
griesemer [Fri, 6 Oct 2017 23:44:12 +0000 (16:44 -0700)]
cmd/compile/internal/syntax: remove unused code

Change-Id: I9c75dee7e4498cc11c08cad1ae34ff2af75f1469
Reviewed-on: https://go-review.googlesource.com/69071
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
7 years agoruntime: remove the 'go:nosplit' directive from documentation
Gabriel Aszalos [Mon, 9 Oct 2017 15:31:06 +0000 (17:31 +0200)]
runtime: remove the 'go:nosplit' directive from documentation

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>
7 years agoencoding/base64: optimize DecodeString
Josselin Costanzi [Wed, 22 Mar 2017 20:19:15 +0000 (21:19 +0100)]
encoding/base64: optimize DecodeString

Optimize base64 decoding speed by adding 32-bits and 64-bits specialized
methods that don't perform any error checking and fall back to the more
complex decodeQuantum method when a non-base64 character is present.

On a 64-bits cpu:

name                 old time/op    new time/op     delta
DecodeString/2-4       70.0ns ± 6%     69.2ns ± 0%     ~     (p=0.169 n=5+8)
DecodeString/4-4       91.3ns ± 2%     80.4ns ± 0%  -11.89%  (p=0.001 n=5+10)
DecodeString/8-4        126ns ± 5%      106ns ± 0%  -16.14%  (p=0.000 n=5+7)
DecodeString/64-4       652ns ±21%      361ns ± 0%  -44.57%  (p=0.000 n=5+7)
DecodeString/8192-4    61.0µs ±13%     31.5µs ± 1%  -48.38%  (p=0.001 n=5+9)

name                 old speed      new speed       delta
DecodeString/2-4     57.2MB/s ± 6%   57.7MB/s ± 2%     ~     (p=0.419 n=5+9)
DecodeString/4-4     87.7MB/s ± 2%   99.5MB/s ± 0%  +13.45%  (p=0.001 n=5+10)
DecodeString/8-4     94.8MB/s ± 5%  112.6MB/s ± 1%  +18.82%  (p=0.001 n=5+9)
DecodeString/64-4     136MB/s ±19%    243MB/s ± 0%  +78.17%  (p=0.003 n=5+7)
DecodeString/8192-4   180MB/s ±11%    347MB/s ± 1%  +92.94%  (p=0.001 n=5+9)

Improves #19636

Change-Id: Ic10a454851093a7e1d46ca0c140deed73535d990
Reviewed-on: https://go-review.googlesource.com/38632
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agocmd/vet: skip self-assigns with side effects
Daniel Martí [Sun, 8 Oct 2017 17:29:45 +0000 (18:29 +0100)]
cmd/vet: skip self-assigns with side effects

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>
7 years agomisc/cgo/testcarchive: skip flaky SIGPROF test on darwin
Elias Naur [Sun, 8 Oct 2017 14:53:18 +0000 (16:53 +0200)]
misc/cgo/testcarchive: skip flaky SIGPROF test on darwin

Updates #19320.

Change-Id: Id38df033e3f0873986e668c8ff3855b6e08407a9
Reviewed-on: https://go-review.googlesource.com/69114
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
7 years agomisc/cgo/testcshared: don't overwrite cc in parallel runs
Ian Lance Taylor [Mon, 9 Oct 2017 05:00:34 +0000 (22:00 -0700)]
misc/cgo/testcshared: don't overwrite cc in parallel runs

Fixes #22176

Change-Id: If47ec9a25da6b480868d8eeccc518dc97d48bda7
Reviewed-on: https://go-review.googlesource.com/69230
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>