Skip to content

G
golang
Switch branch/tag
  1. 03 Nov, 2016 36 commits
  3. 02 Nov, 2016 4 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: 's 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: 's avatarDavid Chase <drchase@google.com>
Reviewed-by: 's 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: 's 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: 's avatarDavid Chase <drchase@google.com>
      688995d1