1. 03 Nov, 2016 34 commits
  2. 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: '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
    • 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: 's 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: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      09bb6434