Skip to content

G
go
Switch branch/tag
  1. 03 Nov, 2016 34 commits
  3. 02 Nov, 2016 6 commits
    • Robert Griesemer's avatar
      go/types: set up correct type with NewAlias · 627f4d85
      Robert Griesemer authored 
      Change-Id: I4b035b3539c98e5b1442d1009d457cbc199b42ee
Reviewed-on: https://go-review.googlesource.com/32637Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      627f4d85
    • Michael Munday's avatar
      cmd/vet: add test case for ppc64{,le} · 5513f855
      Michael Munday authored 
      Adapted from the mips64 test case.

Fixes #17745.

Change-Id: I46f0900028adb936dcab2cdc701ea11d0a3cb95e
Reviewed-on: https://go-review.googlesource.com/32611
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
Reviewed-by: default avatarRob Pike <r@golang.org>
      5513f855
    • Keith Randall's avatar
      cmd/compile: compute faulting args before writing args to stack · cf28e5cc
      Keith Randall authored 
      when compiling f(a, b, c), we do something like:
  *(SP+0) = eval(a)
  *(SP+8) = eval(b)
  *(SP+16) = eval(c)
  call f

If one of those evaluations is later determined to unconditionally panic
(say eval(b) in this example), then the call is deadcode eliminated. But
any previous argument write (*(SP+0)=... here) is still around. Becuase
we only compute the size of the outarg area for calls which are still
around at the end of optimization, the space needed for *(SP+0)=v is not
accounted for and thus the outarg area may be too small.

The fix is to make sure that we evaluate any potentially panicing
operation before we write any of the args to the stack. It turns out
that fix is pretty easy, as we already have such a mechanism available
for function args. We just need to extend it to possibly panicing args
as well.

The resulting code (if b and c can panic, but a can't) is:
  tmpb = eval(b)
  *(SP+16) = eval(c)
  *(SP+0) = eval(a)
  *(SP+8) = tmpb
  call f

This change tickled a bug in how we find the arguments for intrinsic
calls, so that latent bug is fixed up as well.

Update #16760.

Change-Id: I0bf5edf370220f82bc036cf2085ecc24f356d166
Reviewed-on: https://go-review.googlesource.com/32551Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      cf28e5cc
    • Keith Randall's avatar
      cmd/compile: do more type conversion inline · 688995d1
      Keith Randall authored 
      The code to do the conversion is smaller than the
call to the runtime.
The 1-result asserts need to call panic if they fail, but that
code is out of line.

The only conversions left in the runtime are those which
might allocate and those which might need to generate an itab.

Given the following types:
  type E interface{}
  type I interface { foo() }
  type I2 iterface { foo(); bar() }
  type Big [10]int
  func (b Big) foo() { ... }

This CL inlines the following conversions:

was assertE2T
  var e E = ...
  b := i.(Big)
was assertE2T2
  var e E = ...
  b, ok := i.(Big)
was assertI2T
  var i I = ...
  b := i.(Big)
was assertI2T2
  var i I = ...
  b, ok := i.(Big)
was assertI2E
  var i I = ...
  e := i.(E)
was assertI2E2
  var i I = ...
  e, ok := i.(E)

These are the remaining runtime calls:

convT2E:
  var b Big = ...
  var e E = b
convT2I:
  var b Big = ...
  var i I = b
convI2I:
  var i2 I2 = ...
  var i I = i2
assertE2I:
  var e E = ...
  i := e.(I)
assertE2I2:
  var e E = ...
  i, ok := e.(I)
assertI2I:
  var i I = ...
  i2 := i.(I2)
assertI2I2:
  var i I = ...
  i2, ok := i.(I2)

Fixes #17405
Fixes #8422

Change-Id: Ida2367bf8ce3cd2c6bb599a1814f1d275afabe21
Reviewed-on: https://go-review.googlesource.com/32313
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: default avatarDavid Chase <drchase@google.com>
      688995d1
    • Keith Randall's avatar
      cmd/compile: On a runtime.KeepAlive call, keep whole variable alive · 761443ed
      Keith Randall authored 
      We generate an OpKeepAlive for the idata portion of the interface
for a runtime.KeepAlive call.  But given such an op, we need to keep
the entire containing variable alive, not just the range that was
passed to the OpKeepAlive operation.

Fixes #17710

Change-Id: I90de66ec8065e22fb09bcf9722999ddda289ae6e
Reviewed-on: https://go-review.googlesource.com/32477
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: default avatarJoe Tsai <thebrokentoaster@gmail.com>
      761443ed
    • Brad Fitzpatrick's avatar
      net/http: update bundled http2 · 09bb6434
      Brad Fitzpatrick authored 
      Update bundled x/net/http2 to x/net git rev 6c4ac8bd for:

   http2: fix Transport race sending RST_STREAM while reading DATA on cancels
   https://golang.org/cl/32571

   http2: remove h2-14 ALPN proto
   https://golang.org/cl/32576

Fixes #16974

Change-Id: I6ff8493a13d2641499fedf33e8005004735352ff
Reviewed-on: https://go-review.googlesource.com/32578
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      09bb6434
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7