Aside from removing the superfluous comment near syms, this diff is
entirely mechanically generated via Emacs's query-replace-regexp to
replace "^\tstruct {\n[^}]*}" with "\t".
Change-Id: Ide7e4b5995f6a121b3f57415e033933ac5c7431a
Reviewed-on: https://go-review.googlesource.com/8427
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
These registers are not available for programs to use. Prior to this
change, the compiler would crash attempting to use ZR as a general
purpose register. Other programs would compile but on execution would
overwrite the G register and cause havoc.
Fixes linux/arm64 build.
Fixes#10304Fixes#10320
Change-Id: I5cf51d3b77cfe3db7dd6377324950cafb02f8d8b
Reviewed-on: https://go-review.googlesource.com/8456
Reviewed-by: Minux Ma <minux@golang.org>
The original implementation used 16 int "words" but only 29 bits per word
for a total of 16*29 = 464 bits, with a space consumption of 16*64 = 1024
bits on a 64 bit machine. Switching to 512 bits increases precision while
still using (in the worst case) half the amount of memory per mp value on
a 64 bit machine.
Also: Decreased permitted number of least-significant mantissa bits which
may be incorrect when considering if a precise floating-point constant is
an integer from 29 to 16 bits.
Change-Id: Iee9287056f0e9aa4f06ceac0724ff4674f710c53
Reviewed-on: https://go-review.googlesource.com/8429
Reviewed-by: Russ Cox <rsc@golang.org>
I first prototyped this change in Sept 2011, and I discarded it
because it made no difference in the obvious benchmark loop.
It still makes no difference in the obvious benchmark loop,
but in a less obvious one, doing some extra computation
around the calls to Sqrt, not making the call does have a
significant effect.
benchmark old ns/op new ns/op delta
BenchmarkSqrt 4.56 4.57 +0.22%
BenchmarkSqrtIndirect 4.56 4.56 +0.00%
BenchmarkSqrtGo 69.4 69.4 +0.00%
BenchmarkSqrtPrime 4417 3647 -17.43%
This is a warmup for using hardware expansions for some
calls to 1-line assembly routines in the runtime (for example getg).
Change-Id: Ie66be23f8c09d0f7dc4ddd7ca8a93cfce28f55a4
Reviewed-on: https://go-review.googlesource.com/8356
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No test cases yet, but I found this while double checking the
proginfo table.
Change-Id: Ib59675c117c676c1298bcab8765ca6a8fd234de8
Reviewed-on: https://go-review.googlesource.com/8431
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
I guess we need more builders.
Change-Id: I309e3df7608b9eef9339196fdc50dedf5f9422e4
Reviewed-on: https://go-review.googlesource.com/8434
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
This change makes use of the socktest package instead of the non-thread
safe variable syscall.SocketDisableIPv6 for simulating unreachable
external networks.
Also adds -ipv4 flag, -ipv6 flag already exists, as a control knob for
testing on each of IPv4-only, IPv6-only and dual IP stack kernels.
Fixes#7687.
Change-Id: I82002007fd526e8cf4de207f935e721df049a22f
Reviewed-on: https://go-review.googlesource.com/8390
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is Part 2 of the change, see Part 1 here: in https://go-review.googlesource.com/#/c/7692/
Suggested by iant@, we use the library initialization entry point to:
- create a new OS thread and run the "regular" runtime init stack on
that thread
- return immediately from the main (i.e., loader) thread
- at the first CGO invocation, we wait for the runtime initialization
to complete.
The above mechanism is implemented only on linux_amd64. Next step is to
support it on linux_arm. Other platforms don't yet support shared library
compiling/linking, but we intend to use the same strategy there as well.
Change-Id: Ib2c81b1b83bee837134084b75a3beecfb8de6bf4
Reviewed-on: https://go-review.googlesource.com/8094
Run-TryBot: Srdjan Petrovic <spetrovic@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change makes TestDialTimeoutFDLeak work on almost all the supported
platforms.
Updates #4384.
Change-Id: I3608f438003003f9b7cfa17c9e5fe7077700fd60
Reviewed-on: https://go-review.googlesource.com/8392
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A CSR containing challengePassword or unstructuredName Attributes
(included in default OpenSSL prompts) would break ASN.1 parsing.
This updates the parsing structures to allow but then ignore these
fields.
See this CFSSL issue: https://github.com/cloudflare/cfssl/issues/115
Change-Id: I26a3bf1794589d27e6e763da88ae32276f0170c7
Reviewed-on: https://go-review.googlesource.com/8160
Reviewed-by: Adam Langley <agl@golang.org>
It's a single, package-wide init function specified for the net package.
Change-Id: Id5894d65e1a92297cc16803cc5e4d4eef0b4b099
Reviewed-on: https://go-review.googlesource.com/8391
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This tracks both total CPU time used by GC and the total time
available to all Ps since the beginning of the program and uses this
to derive a cumulative CPU usage percent for the gctrace line.
Change-Id: Ica85372b8dd45f7621909b325d5ac713a9b0d015
Reviewed-on: https://go-review.googlesource.com/8350
Reviewed-by: Russ Cox <rsc@golang.org>
GODEBUG=gctrace=1 turns on a per-GC cycle trace line. The current line
is left over from the STW garbage collector and includes a lot of
information that is no longer meaningful for the concurrent GC and
doesn't include a lot of information that is important.
Replace this line with a new line designed for the new garbage
collector.
This new line is focused more on helping the user understand the
impact of the garbage collector on their program and less on telling
us, the runtime developers, everything that's happening inside
GC. It's designed to fit in 80 columns and intentionally omit some
potentially useful things that were in the old line. We might want a
"verbose" mode that adds information for us.
We'll be able to further simplify the line once we eliminate the STW
around enabling the write barrier. Then we'll have just one STW phase,
one concurrent phase, and one more STW phase, so we'll be able to
reduce the number of times from five to three.
Change-Id: Icc30939fe4576fb4491b4eac811649395727aa2a
Reviewed-on: https://go-review.googlesource.com/8208
Reviewed-by: Russ Cox <rsc@golang.org>
This change replaces all direct ECDSA/RSA sign and decrypt operations
with calls through the crypto.Signer and crypto.Decrypter interfaces.
This is a follow-up to https://go-review.googlesource.com/#/c/3900/
which added crypto.Decrypter and implemented it for RSA.
Change-Id: Ie0f3928448b285f329efcd3a93ca3fd5e3b3e42d
Reviewed-on: https://go-review.googlesource.com/7804
Reviewed-by: Adam Langley <agl@golang.org>
All multi-precision arithmetic is now based on math/big.
- passes all.bash
- added test cases for fixed bugs
Fixes#7740.
Fixes#6866.
Change-Id: I67268b91766970ced3b928260053ccdce8753d58
Reviewed-on: https://go-review.googlesource.com/7912
Reviewed-by: Russ Cox <rsc@golang.org>
This restores go.errors from before 3af0d79 along with a fixed up
version of the bisonerrors AWK script, translated to Go.
However, this means Yyerror needs access to the yacc parser's state,
which is currently private. To workaround that, add a "state"
accessor method like the Lookahead method added in c7fa3c6.
Update issue #9968.
Change-Id: Ib868789e92fdb7d135442120a392457923e50121
Reviewed-on: https://go-review.googlesource.com/7270
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is vendored copy of the pure-Go version of math/big.
To update, run vendor.bash in place.
This will permit the use of the new big.Float functionality in
gc (which is not available in 1.4, the version used for bootstrapping).
Change-Id: I4dcdea875d54710005ca3fdea2e0e30422b1b46d
Reviewed-on: https://go-review.googlesource.com/7857
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Yacc generates a bunch of global variables of the form
var yyFoo = []int{...}
where yyFoo is never subsequently modified to point to a different
slice. Since these variables are implicitly compiled as
var yyFoo = ([...]int{...})[:]
anyway, by simply converting them all to
var yyFoo = [...]int{...}
we save sizeof(sliceStruct) bytes of data memory for each variable and
also make len(yyFoo) into compile-time constant expressions, which
shaves some bytes off text size:
$ size 6g.before 6g.after
text data bss dec hex filename
4598019 605968 342700 5546687 54a2bf 6g.before
4597810 605552 342700 5546062 54a04e 6g.after
Change-Id: I53c7aa6efdb2d52738013e9d337a59afbfcb2494
Reviewed-on: https://go-review.googlesource.com/7520
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
This change cleans up some of the uglyness introduced in 8fc73a39ef
by moving the gc.Use_sse into the gc.Arch struct and adjusting its
zero value to be more useful.
Change-Id: I26ff5d9ac57b3f25e936519e443de6583cdafa56
Reviewed-on: https://go-review.googlesource.com/7994
Reviewed-by: Russ Cox <rsc@golang.org>
On arm64, CMP $foo, R is encoded as from=$foo, reg=R, not as from=$foo,
to=R. The progtable entry for ACMP incorrectly described the latter
form. Because of this, the registerizer was not accounting the registers
used in CMP instructions and was incorrectly re-assigning those registers.
This was an old problem, but it only became apparent after b115c35
(cmd/internal/gc: move cgen, regalloc, et al to portable code). Previous
to this commit, the compiler used a slightly larger register set for the
temps than it used for register variables. Since it had plenty registers
dedicated to temps, the registers used in CMP instruction never clashed
with registers assigned to register variables.
Fixes#10253
Change-Id: Iedf4bd882bd59440dff310ac0f81e0f53d80d7ed
Reviewed-on: https://go-review.googlesource.com/8387
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Fixes#9053
Change-Id: I7b9af3647800671f065c366a6adf9278e64ebec9
Reviewed-on: https://go-review.googlesource.com/8400
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently hashmap is riddled with code that attempts to force a GC on
the next allocation if checkgc is set. This no longer works as
originally intended with the concurrent collector, and is apparently
no longer used anyway.
Remove checkgc.
Change-Id: Ia6c17c405fa8821dc2e6af28d506c1133ab1ca0c
Reviewed-on: https://go-review.googlesource.com/8355
Reviewed-by: Keith Randall <khr@golang.org>
This tries to clarify that Alloc and HeapAlloc are tied to how much
freeing has been done by the sweeper.
Change-Id: Id8320074bd75de791f39ec01bac99afe28052d02
Reviewed-on: https://go-review.googlesource.com/8354
Reviewed-by: Rick Hudson <rlh@golang.org>
Also updates the comments on test flags.
Change-Id: I8dbd90270e08728ab309ab88a3030e0f8e547175
Reviewed-on: https://go-review.googlesource.com/8394
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This makes it easier to experiment with alternative implementations.
While we're here, update the comments.
No functional changes. Passes toolstash -cmp.
Change-Id: I428535754908f0fdd7cc36c214ddb6e1e60f376e
Reviewed-on: https://go-review.googlesource.com/8310
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change makes TestDialTimeout work on almost all the supported
platforms.
Updates #3016.
Updates #3307.
Updates #3867.
Updates #5380.
Updates #5349.
Change-Id: Iacf0ebea23cdd8f6c0333d70c667a5a5f5eb0ed2
Reviewed-on: https://go-review.googlesource.com/8220
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It functions exactly the same, but this is the more common
style for these kinds of multi-key comparison functions,
and is more regular.
Change-Id: I46630948f893bcc96c05eb3d36eb82e1d97a6fa0
Reviewed-on: https://go-review.googlesource.com/8358
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a follow-up to CL 7360.
It was generated with eg and gofmt -r.
The only manual changes are the unembedding in syntax.go
and backporting changes from y.go to go.y.
Passes toolstash -cmp.
Change-Id: I3d6d06ecb659809a4bc8592395d5b9a18967218e
Reviewed-on: https://go-review.googlesource.com/8053
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Nodes dominate gc's memory usage, but many fields are only used
for a subset of kinds of nodes. This change pulls out fields
used only for func-like Nodes. This reduces the size of the
Node struct on a 64-bit machine from 504 bytes to 416 bytes (-17%).
Compiling the runtime, 1.5% of nodes have a non-nil Func.
In html/template, 2.7% of nodes have a non-nil Func.
This change introduces an extra alloc and associated GC overhead
when Func is non-nil. However, when Func is nil, as it almost
always is, it spares the garbage collector scanning some Node fields.
Empirically, this change appears to be roughly neutral with regard to GC.
To keep the diff readable, this CL uses an embedded Func field.
A subsequent CL will unembed the field.
Passes toolstash -cmp.
Change-Id: Ide86aa954b097fb8e6154f0811d3691497477004
Reviewed-on: https://go-review.googlesource.com/7360
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change stabilizes the result of Sort when the error list contains
multiple items for same position. To stabilize the result, newly also
the Msg field is considered.
The motivation is to avoid diffs of sorted scanner.ErrorList output
in repository tracked logs like:
-testdata/foo.go:19:44: "bar"
testdata/foo.go:19:44: "qux"
+testdata/foo.go:19:44: "bar"
The change was approved at [0] before submitting.
As a side effect, one file in go/parser/testdata must be updated as
well. For this file the parser produces two different errors:
testdata/issue3106.src:22:5: expected ';', found 'if'
testdata/issue3106.src:22:5: expected operand, found 'if'
Before comparing the actual and expected errors, the former are
filtered to keep only one error per source line[1]. With the new
(*ErrorList).Less the outcome is the other error than before which is
kept after the call to RemoveMultiplies.
[0]: https://groups.google.com/d/msg/golang-nuts/5ChC0XiIwlU/rol_yb2gTj4J
[1]:
9d0239771a/src/go/parser/error_test.go (L160)
Change-Id: Ib72c98a891cdeef34705c22dfbeb0408dcdfddf8
Reviewed-on: https://go-review.googlesource.com/8340
Reviewed-by: Robert Griesemer <gri@golang.org>
cmd/gofmt and go/format had 3 functions (parse, format and isSpace)
that had to be kept in-sync.
This CL extracts these 3 functions and refactors them into a new
internal/format package.
This CL is just code reorganization with no behavior nor semantic
change.
Change-Id: I593f24e9d3cadbbd9559a67e3b1d2ff190b4fd90
Reviewed-on: https://go-review.googlesource.com/6760
Reviewed-by: Robert Griesemer <gri@golang.org>
The c2go translation left a lot of case expressions on separate lines.
Merge expressions onto single lines subject to these constraints:
* Max 4 clauses, all literals or names
* Don't move expressions with comments
The change was created by running http://play.golang.org/p/yHajs72h-g:
$ mergecase cmd/internal/{ld,gc,obj}/*.go cmd/internal/obj/*/*.go
Passes toolstash -cmp.
Change-Id: Iba41b390d302e5486e5dc6ba7599a92270676556
Reviewed-on: https://go-review.googlesource.com/7593
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
This makes it cheaper to copy string literals.
This happens just about anywhere that they are used.
Example:
func f() string {
return "f"
}
Using 6g, compiler output before:
"".f t=1 size=32 value=0 args=0x10 locals=0x0
0x0000 00000 (p.go:3) TEXT "".f+0(SB),4,$0-16
0x0000 00000 (p.go:3) FUNCDATA $0,gclocals·d64e51a4c4bfeaa840e480961ec6b0b3+0(SB)
0x0000 00000 (p.go:3) FUNCDATA $1,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
0x0000 00000 (p.go:4) LEAQ go.string."f"+0(SB),BX
0x0007 00007 (p.go:4) MOVQ (BX),BP
0x000a 00010 (p.go:4) MOVQ BP,"".~r0+8(FP)
0x000f 00015 (p.go:4) MOVQ 8(BX),BP
0x0013 00019 (p.go:4) MOVQ BP,"".~r0+16(FP)
0x0018 00024 (p.go:4) RET ,
After:
"".f t=1 size=32 value=0 args=0x10 locals=0x0
0x0000 00000 (p.go:3) TEXT "".f+0(SB),4,$0-16
0x0000 00000 (p.go:3) FUNCDATA $0,gclocals·d64e51a4c4bfeaa840e480961ec6b0b3+0(SB)
0x0000 00000 (p.go:3) FUNCDATA $1,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
0x0000 00000 (p.go:4) MOVQ $go.string."f"+16(SB),BX
0x0007 00007 (p.go:4) MOVQ BX,"".~r0+8(FP)
0x000c 00012 (p.go:4) MOVQ $1,"".~r0+16(FP)
0x0015 00021 (p.go:4) RET ,
The leading MOVQ here will be converted into a LEAQ by the linker,
but there is still a net reduction of two MOVQs.
Before:
TEXT main.f(SB)
p.go:4 0x2000 488d1d49500500 LEAQ 0x55049(IP), BX
p.go:4 0x2007 488b2b MOVQ 0(BX), BP
p.go:4 0x200a 48896c2408 MOVQ BP, 0x8(SP)
p.go:4 0x200f 488b6b08 MOVQ 0x8(BX), BP
p.go:4 0x2013 48896c2410 MOVQ BP, 0x10(SP)
p.go:4 0x2018 c3 RET
After:
TEXT main.f(SB)
p.go:4 0x2000 488d1dd94c0500 LEAQ 0x54cd9(IP), BX
p.go:4 0x2007 48895c2408 MOVQ BX, 0x8(SP)
p.go:4 0x200c 48c744241001000000 MOVQ $0x1, 0x10(SP)
p.go:4 0x2015 c3 RET
The performance improvement is small but widespread.
As a nice small example, net/url's sole benchmark using 6g:
benchmark old ns/op new ns/op delta
BenchmarkString 16372 16118 -1.55%
And with 8g:
benchmark old ns/op new ns/op delta
BenchmarkString 22034 21709 -1.47%
Change-Id: I4ce202ee7dbd4057be869e2faaaa638c28a1fff0
Reviewed-on: https://go-review.googlesource.com/2587
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
This change provides a convenient way to monitor database connection pool.
Change-Id: I4b3757855b43f3b254acf9312e2a16e2f87840d0
Reviewed-on: https://go-review.googlesource.com/7950
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL is an amagamation of several fixes Canonical have made on their
fork of the cmd/go tool (packaged as gccgo-go.deb on Ubuntu 14.04+).
Additionally this CL brings gccgoToolchain.ldi() up to date with the version
that will ship in gccgo-5.0. As gccgo is most likely to be used with its
own version of the go tool that it supples it makes good sense that the libgo
version should dictate the contents of gccgotoolchain.ld()
Please see https://codereview.appspot.com/222890043/ for more details on the
issues fixed.
Change-Id: Icf7deb43f8e80b424757f1673e6bca7a0aa2a1ac
Reviewed-on: https://go-review.googlesource.com/8250
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, scanner uses -1 to represent 2 different states:
1. I haven't yet scanned anything, call it "Beginning of File"
2. I've reached the end of the input, ie EOF
The result of this behavior is that calling Peek() when next()
has detected the end of the input and set s.ch to scanner.EOF,
is that Peek() things "oh, s.ch is < 0, which to me means that
I haven't scanned any next yet, let me try and clear the BOM
marker."
When this behavior is run on a typical IO, next() will issue
a Read and get (0, io.EOF) back for the second time without
blocking and Peek() will return scanner.EOF.
The bug comes into play when, inside a terminal, hitting Control-D.
This causes the terminal to return a EOF condition to the reader
but it does not actually close the fd.
So, combining these 2 situations, we arrive at the bug:
What is expected: hitting Control-D in a terminal will make Peek()
return scanner.EOF instantly.
What actually happens:
0. Code waiting in Next()
1. User hits Control-D
2. fd returns EOF condition
3. EOF bubbles it's way out to line 249 in scanner.go
4. next() returns scanner.EOF
5. Next() saves the scanner.EOF to s.ch and returns the previous value
6. Peek() runs, sees s.ch < 0, mistakenly thinks it hasn't run yet and
tries to read the BOM marker.
7. next() sees the buffer is empty and tries to fill it again, blocking
on line 249.
The fix is simple: use a different code to indicate that no data
has been scanned.
Change-Id: Iee8f4da5881682c4d4c36b93b9bf397ac5798179
Reviewed-on: https://go-review.googlesource.com/7913
Reviewed-by: Robert Griesemer <gri@golang.org>
The tests in the basic string section are now covering more code paths
for encoding a string into the hexadecimal representation of its bytes.
Changed the basic string and basic bytes tests so that they mirror each other.
Change-Id: Ib5dc7b33876769965f9aba2ac270040abc4b2451
Reviewed-on: https://go-review.googlesource.com/2611
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
