Skip to content

G
golang
Switch branch/tag
  1. 12 Oct, 2017 16 commits
  3. 11 Oct, 2017 24 commits
    • Matthew Dempsky's avatar
      cmd/compile: record InlCost in export data · a509cae9
      Matthew Dempsky authored 
      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: 's avatarRobert Griesemer <gri@golang.org>
      a509cae9
    • Daniel Martí's avatar
      cmd/compile: deduplicate a few lines in swt.go · 1fbeccb1
      Daniel Martí authored 
      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: 's avatarMatthew Dempsky <mdempsky@google.com>
      1fbeccb1
    • Hugues Bruant's avatar
      cmd/compile: inline calls to local closures · 4f70a2a6
      Hugues Bruant authored 
      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: 's avatarHugues Bruant <hugues.bruant@gmail.com>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      4f70a2a6
    • Austin Clements's avatar
      runtime: don't try to free OS-created signal stacks · 44d9e96d
      Austin Clements authored 
      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/70130Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      44d9e96d
    • Joe Tsai's avatar
      encoding/json: use Deprecated markers · a3e013b0
      Joe Tsai authored 
      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/70110Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      a3e013b0
    • David Chase's avatar
      cmd/compile: add line numbers to values & blocks in ssa.html · edcf2d0c
      David Chase authored 
      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: 's avatarCherry Zhang <cherryyz@google.com>
      edcf2d0c
    • Ian Lance Taylor's avatar
      runtime: unify amd64 -buildmode=c-archive/c-shared entry point code · 30cb30e5
      Ian Lance Taylor authored 
      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: 's avatarAustin Clements <austin@google.com>
      30cb30e5
    • Lynn Boger's avatar
      misc/cgo/testcarchive: use -no-pie where needed · c15c44ec
      Lynn Boger authored 
      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: 's avatarIan Lance Taylor <iant@golang.org>
      c15c44ec
    • David Crawshaw's avatar
      cmd/link: move ELF reader to its own package · ecfa7375
      David Crawshaw authored 
      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: 's avatarIan Lance Taylor <iant@golang.org>
      ecfa7375
    • Cherry Zhang's avatar
      test: skip issue22200b.go on mipsle · 70576947
      Cherry Zhang authored 
      It should be skipped on 32-bit architectures.

Change-Id: If7a64b9e90e47c3e8734dd62729bfd2944ae926c
Reviewed-on: https://go-review.googlesource.com/70071Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
      70576947
    • Russ Cox's avatar
      cmd/dist: refresh deps.go after recent package io changes · d19ced04
      Russ Cox authored 
      Change-Id: Iaa960c85011289e047c64b53cf610838eb50332d
Reviewed-on: https://go-review.googlesource.com/70073
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      d19ced04
    • Ian Lance Taylor's avatar
      runtime: unify amd64 -buildmode=exe entry point code · cf3f7712
      Ian Lance Taylor authored 
      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: 's avatarAustin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      cf3f7712
    • Austin Clements's avatar
      cmd/link: fix some unintentional symbol creation · e29efbcb
      Austin Clements authored 
      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: 's avatarHeschi Kreinick <heschi@google.com>
Reviewed-by: 's avatarThan McIntosh <thanm@google.com>
      e29efbcb
    • Joe Tsai's avatar
      io: simplify pipe implementation · 371eda45
      Joe Tsai authored 
      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: 's avatarBryan Mills <bcmills@google.com>
      371eda45
    • Joe Tsai's avatar
      net: implement deadline functionality on Pipe · e2dd8ca9
      Joe Tsai authored 
      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: 's avatarIan Lance Taylor <iant@golang.org>
      e2dd8ca9
    • Russ Cox's avatar
      cmd/internal/buildid: add missing f.Close in ReadFile · 7dcd3330
      Russ Cox authored 
      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: 's avatarDavid Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      7dcd3330
    • Russ Cox's avatar
      cmd/dist: reenable TestDeps · 31896332
      Russ Cox authored 
      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: 's avatarDavid Crawshaw <crawshaw@golang.org>
      31896332
    • Russ Cox's avatar
      cmd/go: record both build ID and content ID in archives and binaries · cdbc363c
      Russ Cox authored 
      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/69054Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      cdbc363c
    • Austin Clements's avatar
      cmd/compile: fix some plive comments · 85f93c88
      Austin Clements authored 
      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: 's avatarMatthew Dempsky <mdempsky@google.com>
      85f93c88
    • Keith Randall's avatar
      cmd/compile: abort earlier if stack frame too large · e130dcf0
      Keith Randall authored 
      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: 's avatarIan Lance Taylor <iant@golang.org>
      e130dcf0
    • Keith Randall's avatar
      cmd/compile: fold constant comparisions into SETxxmem ops. · 624630b8
      Keith Randall authored 
      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: 's avatarMatthew Dempsky <mdempsky@google.com>
      624630b8
    • Russ Cox's avatar
      cmd/buildid: add new tool factoring out code needed by go command · 9ad2319b
      Russ Cox authored 
      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/69053Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      9ad2319b
    • Austin Clements's avatar
      cmd/compile: split TestNexting into subtests · 0bede7f3
      Austin Clements authored 
      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: 's avatarHeschi Kreinick <heschi@google.com>
      0bede7f3
    • Austin Clements's avatar
      runtime: make (Un)LockOSThread doc more prescriptive · 0aef82aa
      Austin Clements authored 
      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: 's avatarKeith Randall <khr@golang.org>
      0aef82aa