Skip to content

G
golang
Switch branch/tag
  1. 13 Oct, 2016 23 commits
  3. 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