1. 13 Oct, 2016 23 commits
  2. 12 Oct, 2016 17 commits
    • Russ Cox's avatar
      syscall: update darwin/amd64 for timespec change · 90a75085
      Russ Cox authored
      Change-Id: I74f47f519dfee10cd079ad9a4e09e36e8d74c6dc
      Reviewed-on: https://go-review.googlesource.com/30937
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      90a75085
    • Joe Tsai's avatar
      archive/tar: reduce allocations in formatOctal · 14e545b6
      Joe Tsai authored
      Change-Id: I9ddb7d2a97d28aba7a107b65f278993daf7807fa
      Reviewed-on: https://go-review.googlesource.com/30960Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      14e545b6
    • Lynn Boger's avatar
      cmd/asm: recognize CR1-CR7 on ppc64x branch instructions · 6da8bdd2
      Lynn Boger authored
      Some of the branch instructions (BEQ, BNE, BLT, etc.) accept
      all the valid CR values as operands, but the CR register value is
      not parsed and not put into the instruction, so that CR0 is always
      used regardless of what was specified on the instruction.  For example
      BEQ CR2,label becomes beq cr0,label.
      
      This adds the change to the PPC64 assembler to recognize the CR value
      and set the approppriate field in the instruction so the correct
      CR is used.  This also adds some general comments on the branch
      instruction BC and its operand values.
      
      Fixes #17408
      
      Change-Id: I8e956372a42846a4c09a7259e9172eaa29118e71
      Reviewed-on: https://go-review.googlesource.com/30930
      Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      6da8bdd2
    • Keith Randall's avatar
      cmd/compile,runtime: redo how map assignments work · 442de98c
      Keith Randall authored
      To compile:
        m[k] = v
      instead of:
        mapassign(maptype, m, &k, &v), do
      do:
        *mapassign(maptype, m, &k) = v
      
      mapassign returns a pointer to the value slot in the map.  It is just
      like mapaccess except that it will allocate a new slot if k is not
      already present in the map.
      
      This makes map accesses faster but potentially larger (codewise).
      
      It is faster because the write into the map is done when the compiler
      knows the concrete type, so it can be done with a few store
      instructions instead of calling typedmemmove.  We also potentially
      avoid stack temporaries to hold v.
      
      The code can be larger when the map has pointers in its value type,
      since there is a write barrier call in addition to the mapassign call.
      That makes the code at the callsite a bit bigger (go binary is 0.3%
      bigger).
      
      This CL is in preparation for doing operations like m[k] += v with
      only a single runtime call.  That will roughly double the speed of
      such operations.
      
      Update #17133
      Update #5147
      
      Change-Id: Ia435f032090a2ed905dac9234e693972fe8c2dc5
      Reviewed-on: https://go-review.googlesource.com/30815
      Run-TryBot: Keith Randall <khr@golang.org>
      Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      442de98c
    • Russ Cox's avatar
      unicode: change SimpleFold to handle invalid runes · 55ef67f2
      Russ Cox authored
      Functions like ToLower and ToUpper return the invalid rune back,
      so we might as well do the same here.
      
      I changed my mind about panicking when I tried to document the behavior.
      
      Fixes #16690 (again).
      
      Change-Id: If1c68bfcd66daea160fd19948e7672b0e1add106
      Reviewed-on: https://go-review.googlesource.com/30935
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarRob Pike <r@golang.org>
      55ef67f2
    • David Crawshaw's avatar
      cmd/link: force external linking for plugins · 413afcaf
      David Crawshaw authored
      Fixes #17415
      
      Change-Id: I6f896d549092e5e0dba72351e5385992b4cbe90f
      Reviewed-on: https://go-review.googlesource.com/30933
      Run-TryBot: David Crawshaw <crawshaw@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      413afcaf
    • Adam Langley's avatar
      crypto/tls: enable X25519 by default. · 9e98e7e6
      Adam Langley authored
      Since this changes the offered curves in the ClientHello, all the test
      data needs to be updated too.
      
      Change-Id: I227934711104349c0f0eab11d854e5a2adcbc363
      Reviewed-on: https://go-review.googlesource.com/30825Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      9e98e7e6
    • Adam Langley's avatar
      crypto/tls: support X25519. · 8a11cb31
      Adam Langley authored
      X25519 (RFC 7748) is now commonly used for key agreement in TLS
      connections, as specified in
      https://tools.ietf.org/html/draft-ietf-tls-curve25519-01.
      
      This change adds support for that in crypto/tls, but does not enabled it
      by default so that there's less test noise. A future change will enable
      it by default and will update all the test data at the same time.
      
      Change-Id: I91802ecd776d73aae5c65bcb653d12e23c413ed4
      Reviewed-on: https://go-review.googlesource.com/30824Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8a11cb31
    • Adam Langley's avatar
      crypto/tls: fix printing of OpenSSL output when updating a test fails. · 8c74139c
      Adam Langley authored
      When updating the test data against OpenSSL, the handshake can fail and
      the stdout/stderr output of OpenSSL is very useful in finding out why.
      
      However, printing that output has been broken for some time because its
      no longer sent to a byte.Buffer. This change fixes that.
      
      Change-Id: I6f846c7dc80f1ccee9fa1be36f0b579b3754e05f
      Reviewed-on: https://go-review.googlesource.com/30823Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      8c74139c
    • Adam Langley's avatar
      vendor/golang_org/x/crypto/curve25519: new package · e875fe42
      Adam Langley authored
      This change imports the curve25519 package from x/crypto at revision
      594708b89f21ece706681be23d04a6513a22de6e.
      
      Change-Id: I379eaa71492959e404259fc1273d0057573bc243
      Reviewed-on: https://go-review.googlesource.com/30822Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      e875fe42
    • Adam Langley's avatar
      crypto/tls: switch to OpenSSL 1.1.0 for test data. · 9d88292c
      Adam Langley authored
      We will need OpenSSL 1.1.0 in order to test some of the features
      expected for Go 1.8. However, 1.1.0 also disables (by default) some
      things that we still want to test, such as RC4, 3DES and SSLv3. Thus
      developers wanting to update the crypto/tls test data will need to build
      OpenSSL from source.
      
      This change updates the test data with transcripts generated by 1.1.0
      (in order to reduce future diffs) and also causes a banner to be printed
      if 1.1.0 is not used when updating.
      
      (The test for an ALPN mismatch is removed because OpenSSL now terminates
      the connection with a fatal alert if no known ALPN protocols are
      offered. There's no point testing against this because it's an OpenSSL
      behaviour.)
      
      Change-Id: I957516975e0b8c7def84184f65c81d0b68f1c551
      Reviewed-on: https://go-review.googlesource.com/30821
      Run-TryBot: Adam Langley <agl@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      9d88292c
    • Joe Tsai's avatar
      archive/tar: fix and cleanup readOldGNUSparseMap · 0e36456b
      Joe Tsai authored
      * Assert that the format is GNU.
      Both GNU and STAR have some form of sparse file support with
      incompatible header structures. Worse yet, both formats use the
      'S' type flag to indicate the presence of a sparse file.
      As such, we should check the format (based on magic numbers)
      and fail early.
      
      * Move realsize parsing logic into readOldGNUSparseMap.
      This is related to the sparse parsing logic and belongs here.
      
      * Fix the termination condition for parsing sparse fields.
      The termination condition for reading the sparse fields
      is to simply check if the first byte of the offset field is NULL.
      This does not seem to be documented in the GNU manual, but this is
      the check done by the both the GNU and BSD implementations:
      	http://git.savannah.gnu.org/cgit/tar.git/tree/src/sparse.c?id=9a33077a7b7ad7d32815a21dee54eba63b38a81c#n731
      	https://github.com/libarchive/libarchive/blob/1fa9c7bf90f0862036a99896b0501c381584451a/libarchive/archive_read_support_format_tar.c#L2207
      
      * Fix the parsing of sparse fields to use parseNumeric.
      This is what GNU and BSD do. The previous two links show that
      GNU and BSD both handle base-256 and base-8.
      
      * Detect truncated streams.
      The call to io.ReadFull does not check if the error is io.EOF.
      Getting io.EOF in this method is never okay and should always be
      converted to io.ErrUnexpectedEOF.
      
      * Simplify the function.
      The logic is essentially a do-while loop so we can remove
      some redundant code.
      
      Change-Id: Ib2f601b1a283eaec1e41b1d3396d649c80749c4e
      Reviewed-on: https://go-review.googlesource.com/28471Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Russ Cox <rsc@golang.org>
      0e36456b
    • Joe Tsai's avatar
      archive/tar: handle integer overflow on 32bit machines · 14204662
      Joe Tsai authored
      Most calls to strconv.ParseInt(x, 10, 0) should really be
      calls to strconv.ParseInt(x, 10, 64) in order to ensure that they
      do not overflow on 32b architectures.
      
      Furthermore, we should document a bug where Uid and Gid may
      overflow on 32b machines since the type is declared as int.
      
      Change-Id: I99c0670b3c2922e4a9806822d9ad37e1a364b2b8
      Reviewed-on: https://go-review.googlesource.com/28472
      Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      14204662
    • Hiroshi Ioka's avatar
      unicode: panic if given rune is negative in SimpleFold · 94f49fd4
      Hiroshi Ioka authored
      Fixes #16690
      
      Change-Id: I6db588c4b0f23c5ec6bc9b85a488b60fab3f2f13
      Reviewed-on: https://go-review.googlesource.com/30892Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      94f49fd4
    • Momchil Velikov's avatar
      cmd/compile: trim more blocks · be302e6d
      Momchil Velikov authored
       - trim blocks with multiple predecessors
       - trim blocks, which contain only phi-functions
       - trim blocks, which can be merged into the successor block
      
      As an example, compiling the following source:
      
      ---8<------
      package p
      
      type Node struct {
              Key         int
              Left, Right *Node
      }
      
      func Search(r *Node, k int) *Node {
              for r != nil {
                      switch {
                      case k == r.Key:
                              return r
                      case k < r.Key:
                              r = r.Left
                      default:
                              r = r.Right
                      }
              }
              return nil
      }
      ---8<------
      
      with `GOSSAFUNC=Search" go tool compile t.go`, results in the following
      code:
      
      ---8<------
      genssa
      
            00000 (t.go:8)	TEXT	"".Search(SB), $0
            00001 (t.go:8)	FUNCDATA	$0, "".gcargs·0(SB)
            00002 (t.go:8)	FUNCDATA	$1, "".gclocals·1(SB)
            00003 (t.go:8)	TYPE	"".r(FP)type.*"".Node, $8
            00004 (t.go:8)	TYPE	"".k+8(FP)type.int, $8
            00005 (t.go:8)	TYPE	"".~r2+16(FP)type.*"".Node, $8
      v40   00006 (t.go:9)	MOVQ	"".k+8(FP), AX
      v34   00007 (t.go:9)	MOVQ	"".r(FP), CX
      v33   00008 (t.go:9)	TESTQ	CX, CX
      b2    00009 (t.go:9)	JEQ	$0, 22
      v16   00010 (t.go:11)	MOVQ	(CX), DX
      v21   00011 (t.go:11)	CMPQ	DX, AX
      b9    00012 (t.go:11)	JEQ	$0, 19
      v64   00013 (t.go:13)	CMPQ	AX, DX
      b13   00014 (t.go:13)	JGE	17
      v36   00015 (t.go:14)	MOVQ	8(CX), CX
      b4    00016 (t.go:9)	JMP	8                  <---+
      v42   00017 (t.go:16)	MOVQ	16(CX), CX             |
      b21   00018 (t.go:10)	JMP	16                 ----+
      v28   00019 (t.go:12)	VARDEF	"".~r2+16(FP)
      v29   00020 (t.go:12)	MOVQ	CX, "".~r2+16(FP)
      b10   00021 (t.go:12)	RET
      v44   00022 (t.go:19)	VARDEF	"".~r2+16(FP)
      v45   00023 (t.go:19)	MOVQ	$0, "".~r2+16(FP)
      b5    00024 (t.go:19)	RET
      00025 (<unknown line number>)	END
      ---8<------
      
      Note the jump at 18 jumps to another jump at 16.
      
      Looking at the function after trimming:
      
      --8<------
      after trim [199 ns]
      
      b1:
      v1 = InitMem <mem>
      v2 = SP <uintptr> : SP
      v67 = Arg <*Node> {r} : r[*Node]
      v59 = Arg <int> {k} : k[int]
      v40 = LoadReg <int> v59 : AX
      v34 = LoadReg <*Node> v67 : CX
      Plain → b2
      
      b2: ← b1 b4
      v8 = Phi <*Node> v34 v68 : CX
      v33 = TESTQ <flags> v8 v8
      NE v33 → b9 b5 (likely)
      
      b9: ← b2
      v16 = MOVQload <int> v8 v1 : DX
      v21 = CMPQ <flags> v16 v40
      EQ v21 → b10 b13 (unlikely)
      
      b13: ← b9
      v64 = CMPQ <flags> v40 v16
      LT v64 → b19 b21
      
      b19: ← b13
      v36 = MOVQload <*Node> [8] v8 v1 : CX
      Plain → b4
      
      b4: ← b21 b19                       <
      v68 = Phi <*Node> v42 v36 : CX      <- no actual code
      Plain → b2                          <
      
      b21: ← b13
      v42 = MOVQload <*Node> [16] v8 v1 : CX
      Plain → b4
      
      b10: ← b9
      v28 = VarDef <mem> {~r2} v1
      v29 = MOVQstore <mem> {~r2} v2 v8 v28
      v30 = Copy <mem> v29
      Ret v30
      
      b5: ← b2
      v44 = VarDef <mem> {~r2} v1
      v45 = MOVQstoreconst <mem> {~r2} [val=0,off=0] v2 v44
      v47 = Copy <mem> v45
      Ret v47
      
      --8<------
      
      The jump at 16 corresponds to the edge b21 -> b4. The block b4 contains
      only phi-ops, i.e. no actual code besides the jump to b2. However b4 is
      not trimmed, because it a) has more than one predecessor, and b) it is
      not empty.
      
      This change enhances trim.go to remove more blocks, subject to the
      following criteria:
      
       - block has predecessors (i.e. not the start block)
      
       - block is BlockPlain
      
       - block does not loop back to itself
      
       - block is the single predecessor of its successor; the instructions of
         the block are merged into the successor
      
       - block does no emit actual code, besides a possible unconditional
         jump.
           Currently only OpPhi are considered to not be actual code,
         perhaps OpKeepAlive/others should be considered too?
      
      As an example, after the change, the block b4 is trimmed and the jump at
      18 jumps directly to 8.
      
      Revision 1: Adjust phi-ops arguments after merge
      
      Ensure the number of phi-ops arguments matches the new number of
      predecessors in the merged block.
      When moving values, make them refer to the merged block.
      
      Revision 2:
       - Make clear the intent that we do not want to trim the entry block
       - Double check that we are merging a phi operation
       - Minor code style fix
       - Fix a potentially dangerous situation when a blocks refers to the
         inline value space in another block
      
      Change-Id: I0ab91779f931f404d11008f5c45606d985d7fbaa
      Reviewed-on: https://go-review.googlesource.com/28812
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      be302e6d
    • Kevin Burke's avatar
      syscall: document that Exec wraps execve(2) · 8d1d9292
      Kevin Burke authored
      Change-Id: I611511434f37c75f77c22f61f469108243bc0101
      Reviewed-on: https://go-review.googlesource.com/29121Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      8d1d9292
    • Cyrill Schumacher's avatar
      net/http: optimize internal cookie functions · 68998433
      Cyrill Schumacher authored
      - precalculate *Cookie slice in read cookie functions
      - readSetCookies: pre-allocs depending on the count of Set-Cookies
      - rename success variable to ok; avoid else
      - refactor Cookie.String to use less allocations
      - remove fmt package and replace with writes to a bytes.Buffer
      - add BenchmarkReadSetCookies and BenchmarkReadCookies
      
      name              old time/op    new time/op    delta
      CookieString-8      1.42µs ± 2%    0.78µs ± 1%  -45.36%        (p=0.000 n=10+10)
      ReadSetCookies-8    3.46µs ± 1%    3.42µs ± 2%   -1.39%        (p=0.001 n=10+10)
      ReadCookies-8       5.12µs ± 1%    5.15µs ± 2%     ~           (p=0.393 n=10+10)
      
      name              old alloc/op   new alloc/op   delta
      CookieString-8        520B ± 0%      384B ± 0%  -26.15%        (p=0.000 n=10+10)
      ReadSetCookies-8      968B ± 0%      960B ± 0%   -0.83%        (p=0.000 n=10+10)
      ReadCookies-8       2.01kB ± 0%    2.01kB ± 0%     ~     (all samples are equal)
      
      name              old allocs/op  new allocs/op  delta
      CookieString-8        10.0 ± 0%       3.0 ± 0%  -70.00%        (p=0.000 n=10+10)
      ReadSetCookies-8      18.0 ± 0%      17.0 ± 0%   -5.56%        (p=0.000 n=10+10)
      ReadCookies-8         16.0 ± 0%      16.0 ± 0%     ~     (all samples are equal)
      
      Change-Id: I870670987f10f3e52f9c657cfb8e6eaaa97a6162
      Reviewed-on: https://go-review.googlesource.com/27850
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      68998433