Previously, we used OKEY nodes to represent keyed struct literal
elements. The field names were represented by an ONAME node, but this
is clumsy because it's the only remaining case where ONAME was used to
represent a bare identifier and not a variable.
This CL introduces a new OSTRUCTKEY node op for use in struct
literals. These ops instead store the field name in the node's own Sym
field. This is similar in spirit to golang.org/cl/20890.
Significant reduction in allocations for struct literal heavy code
like package unicode:
name old time/op new time/op delta
Template 345ms ± 6% 341ms ± 6% ~ (p=0.141 n=29+28)
Unicode 200ms ± 9% 184ms ± 7% -7.77% (p=0.000 n=29+30)
GoTypes 1.04s ± 3% 1.05s ± 3% ~ (p=0.096 n=30+30)
Compiler 4.47s ± 9% 4.49s ± 6% ~ (p=0.890 n=29+29)
name old user-ns/op new user-ns/op delta
Template 523M ±13% 516M ±17% ~ (p=0.400 n=29+30)
Unicode 334M ±27% 314M ±30% ~ (p=0.093 n=30+30)
GoTypes 1.53G ±10% 1.52G ±10% ~ (p=0.572 n=30+30)
Compiler 6.28G ± 7% 6.34G ±11% ~ (p=0.300 n=30+30)
name old alloc/op new alloc/op delta
Template 44.5MB ± 0% 44.4MB ± 0% -0.35% (p=0.000 n=27+30)
Unicode 39.2MB ± 0% 34.5MB ± 0% -11.79% (p=0.000 n=26+30)
GoTypes 125MB ± 0% 125MB ± 0% -0.12% (p=0.000 n=29+30)
Compiler 515MB ± 0% 515MB ± 0% -0.10% (p=0.000 n=29+30)
name old allocs/op new allocs/op delta
Template 426k ± 0% 424k ± 0% -0.39% (p=0.000 n=29+30)
Unicode 374k ± 0% 323k ± 0% -13.67% (p=0.000 n=29+30)
GoTypes 1.21M ± 0% 1.21M ± 0% -0.14% (p=0.000 n=29+29)
Compiler 4.40M ± 0% 4.39M ± 0% -0.13% (p=0.000 n=29+30)
Passes toolstash/buildall.
Change-Id: Iba4ee765dd1748f67e52fcade1cd75c9f6e13fa9
Reviewed-on: https://go-review.googlesource.com/30974
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
aindex is overkill when it's only ever used with known integer
constants, so just use typArray directly instead.
Change-Id: I43fc14e604172df859b3ad9d848d219bbe48e434
Reviewed-on: https://go-review.googlesource.com/30979
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL introduces first test for readConsole. And new test
discovered couple of problems with readConsole.
Console characters consist of multiple bytes each, but byte blocks
returned by syscall.ReadFile have no character boundaries. Some
multi-byte characters might start at the end of one block, and end
at the start of next block. readConsole feeds these blocks to
syscall.MultiByteToWideChar to convert them into utf16, but if some
multi-byte characters have no ending or starting bytes, the
syscall.MultiByteToWideChar might get confused. Current version of
syscall.MultiByteToWideChar call will make
syscall.MultiByteToWideChar ignore all these not complete
multi-byte characters.
The CL solves this issue by changing processing from "randomly
sized block of bytes at a time" to "one multi-byte character at a
time". New readConsole code calls syscall.ReadFile to get 1 byte
first. Then it feeds this byte to syscall.MultiByteToWideChar.
The new syscall.MultiByteToWideChar call uses MB_ERR_INVALID_CHARS
flag to make syscall.MultiByteToWideChar return error if input is
not complete character. If syscall.MultiByteToWideChar returns
correspondent error, we read another byte and pass 2 byte buffer
into syscall.MultiByteToWideChar, and so on until success.
Old readConsole code would also sometimes return no data if user
buffer was smaller then uint16 size, which would confuse callers
that supply 1 byte buffer. This CL fixes that problem too.
Fixes#17097
Change-Id: I88136cdf6a7bf3aed5fbb9ad2c759b6c0304ce30
Reviewed-on: https://go-review.googlesource.com/29493
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
It is easy to make the mistake of duplicating json struct field
tags especially when copy/pasting. This commit causes go vet to
report the mistake. Only field tags in the same struct type are
considered, because that is the only case which is undoubtedly an
error.
Fixes#12791.
Change-Id: I4130e4c04b177694cc0daf8f1acaf0751d4f062b
Reviewed-on: https://go-review.googlesource.com/16704
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
There was an inconsistency between the (json encoding + documentation)
and the xml encoding implementation. Pointer to an empty value was
not being serialized (i.e simply ignored). Which had the effect of making
impossible to have a struct with a string field for which we wanted to
serialize the value ""
Fixes#5452
Change-Id: Id858701801158409be01e962d2cda843424bd22a
Reviewed-on: https://go-review.googlesource.com/15684
Reviewed-by: Russ Cox <rsc@golang.org>
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: David Chase <drchase@google.com>
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: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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: Rob Pike <r@golang.org>
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/30825
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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/30824
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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/30823
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change imports the curve25519 package from x/crypto at revision
594708b89f21ece706681be23d04a6513a22de6e.
Change-Id: I379eaa71492959e404259fc1273d0057573bc243
Reviewed-on: https://go-review.googlesource.com/30822
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
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: Brad Fitzpatrick <bradfitz@golang.org>
* 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#n7311fa9c7bf90/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/28471
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
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: Russ Cox <rsc@golang.org>
- 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: Keith Randall <khr@golang.org>
Update comments for duffzero and duffcopy
which referred to legacy locations:
+ cmd/?g/cgen.go
+ cmd/?g/ggen.go
Remnants of the old days when we had 5g, 6g etc.
Those locations have since moved to:
+ cmd/compile/internal/<arch>/cgen.go
+ cmd/compile/internal/<arch>/ggen.go
Change-Id: Ie2ea668559d52d42b747260ea69a6d5b3d70e859
Reviewed-on: https://go-review.googlesource.com/29073
Reviewed-by: Russ Cox <rsc@golang.org>
EvalSymlinks returns error if given path or its target path don't exist.
Add a test for future improvement.
Change-Id: Ic9a4aa5eaee0fe7ac523d54d8eb3132a11b380b3
Reviewed-on: https://go-review.googlesource.com/27330
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This change adds runtime/trace support to go tool compile.
Change-Id: I6c496b9b063796123f75eba6af511c53a57c0196
Reviewed-on: https://go-review.googlesource.com/25354
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Add checks for failure of CreateEvent, SetEvent or
WaitForSingleObject. Any failures are considered fatal and
will throw() after printing an informative message.
Updates #16646
Change-Id: I3bacf9001d2abfa8667cc3aff163ff2de1c99915
Reviewed-on: https://go-review.googlesource.com/26655
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This cosmetic change defines ld.FlagTextAddr using ld.HEADR in
the Plan 9 cases, like it is done for other operating systems.
Change-Id: Ic929c1c437f25661058682cf3e159f0b16cdc538
Reviewed-on: https://go-review.googlesource.com/30912
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Support for multiple text sections was added in CL 27790.
However, this change broke the build on plan9/amd64.
In relocsym, the R_ADDROFF relocation was changed to
use offsets relative to the start of the first text
section. However, Segtext.Vaddr is the address of
the text segment, while we expect to start from
the first section (text.runtime) of the text segment.
Fixes#17411.
Change-Id: I86bbcbda81cea735b0ecf156eab2e6e5d63acce3
Reviewed-on: https://go-review.googlesource.com/30911
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
All the implementations of NsecToTimespec and NsecToTimeval were the
same other than types. Write a single version that uses
GOARCH/GOOS-specific setTimespec and setTimeval functions to handle the
types.
The logic in NsecToTimespec and NsecToTimeval caused times before 1970
to have a negative usec/nsec. The Linux kernel requires that usec
contain a positive number; for consistency, we do this for both
NsecToTimespec and NsecToTimeval.
Change-Id: I525eaba2e7cdb00cb57fa00182dabf19fec298ae
Reviewed-on: https://go-review.googlesource.com/30826
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The new implementation parses the plan9 interface files
and builds Interface representations for the net package.
Updates #17218
Change-Id: I3199d18d9e96a17e922186c3abff1d7cd9cbec2e
Reviewed-on: https://go-review.googlesource.com/29963
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Support the tagging of binaries created with the internal linker
on Solaris as having a non-executable stack by writing a PT_SUNWSTACK
program header.
Fixes#16074
Change-Id: I3888f2153083385d04a52f341570f93e5738b276
Reviewed-on: https://go-review.googlesource.com/24142
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The error coming out of matchGoImport does not differentiate between
having no imports, and having some invalid imports.
This some extra context to the error message to help debug these issues.
Fixes#16467
Change-Id: I3e9a119ed73da1bed5e07365be0221ea6b7f19db
Reviewed-on: https://go-review.googlesource.com/25121
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If strict option is enabled, when decoding, instead of skip the padding
bits, it will do strict check to enforce they are set to zero.
Fixes#15656
Change-Id: I869fb725a39cc9dde44dbc4ff0046446e7abc642
Reviewed-on: https://go-review.googlesource.com/24964
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Update the description of the conditions under which highlighting might
be misleading.
Fixes#16754
Change-Id: I3078a09e0b9a76d12078352e15a3f26ba3f1bbee
Reviewed-on: https://go-review.googlesource.com/30818
Reviewed-by: David Chase <drchase@google.com>
