- 12 Apr, 2015 5 commits
-
-
David Crawshaw authored
Just like darwin/arm. Change-Id: Iadc30b7307ae56fd4f8a681d49672bed7ca6966f Reviewed-on: https://go-review.googlesource.com/8810Reviewed-by:
Minux Ma <minux@golang.org>
-
David Crawshaw authored
Just like darwin/arm. Change-Id: Iabb6282f18548da43117ee60f7ad6e272502f09d Reviewed-on: https://go-review.googlesource.com/8825Reviewed-by:
-
David Crawshaw authored
Just like darwin/arm. Change-Id: Ib64a3e8ff11249a20b0208bd3b900db318c682b7 Reviewed-on: https://go-review.googlesource.com/8817Reviewed-by:
-
David Crawshaw authored
Similar to darwin/arm. This issue is quite worrying and I hope it can be addressed for Go 1.5. Change-Id: Ic095281d6a2e9a38a59973f58d464471db5a2edc Reviewed-on: https://go-review.googlesource.com/8811Reviewed-by:
-
David Crawshaw authored
Change-Id: Ia49ab729747acb07bf392d90aea9e752471e152e Reviewed-on: https://go-review.googlesource.com/8789Reviewed-by:
-
- 11 Apr, 2015 11 commits
-
-
Michael Hudson-Doyle authored
Change-Id: Id469165b1acd383837b1f4e1e6f961e10dfa5d61 Reviewed-on: https://go-review.googlesource.com/8332Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org>
-
Matthew Dempsky authored
While here, this changes DWAbbrev's attr field from a [30]DWAttrForm with zero-termination to a simple []DWAttrForm, and updates its users accordingly. Passes "go build -toolexec 'toolstash -cmp' -a std" on linux/amd64. Change-Id: I52b5f7a749bdb3e7588fc8ebdb8fee2cf8cab602 Reviewed-on: https://go-review.googlesource.com/8762 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Dmitry Vyukov authored
Change-Id: I440435927fc9f417d81ed4e8656a73787bf0968a Reviewed-on: https://go-review.googlesource.com/8801Reviewed-by:
-
Michael Hudson-Doyle authored
The symbols for the actual data in a constant string or bytes literal should be local. Change-Id: Idafcfba9a638eaa4e460e5103d96843960559b35 Reviewed-on: https://go-review.googlesource.com/8772Reviewed-by:
-
Michael Hudson-Doyle authored
When dynamically linking Go code, it is no longer safe to assume that strings that end up in method names are identical if they are equal. The performance impact seems to be noise: benchmark old ns/op new ns/op delta BenchmarkAssertI2E2 13.3 13.1 -1.50% BenchmarkAssertE2I 23.5 23.2 -1.28% BenchmarkAssertE2E2Blank 0.83 0.82 -1.20% BenchmarkConvT2ISmall 60.7 60.1 -0.99% BenchmarkAssertI2T 10.2 10.1 -0.98% BenchmarkAssertE2T 10.2 10.3 +0.98% BenchmarkConvT2ESmall 56.7 57.2 +0.88% BenchmarkConvT2ILarge 59.4 58.9 -0.84% BenchmarkConvI2E 13.0 12.9 -0.77% BenchmarkAssertI2E 13.4 13.3 -0.75% BenchmarkConvT2IUintptr 57.9 58.3 +0.69% BenchmarkConvT2ELarge 55.9 55.6 -0.54% BenchmarkAssertI2I 23.8 23.7 -0.42% BenchmarkConvT2EUintptr 55.4 55.5 +0.18% BenchmarkAssertE2E 6.12 6.11 -0.16% BenchmarkAssertE2E2 14.4 14.4 +0.00% BenchmarkAssertE2T2 10.0 10.0 +0.00% BenchmarkAssertE2T2Blank 0.83 0.83 +0.00% BenchmarkAssertE2TLarge 10.7 10.7 +0.00% BenchmarkAssertI2E2Blank 0.83 0.83 +0.00% BenchmarkConvI2I 23.4 23.4 +0.00% Change-Id: I0b3dfc314215a4d4e09eec6b42c1e3ebce33eb56 Reviewed-on: https://go-review.googlesource.com/8239Reviewed-by:
-
Michael Hudson-Doyle authored
This will fruitlessly rebuild stale packages that are in a shared library. Change-Id: I66a6e1adf7818558e7d1351ab215a5021b4a8a6b Reviewed-on: https://go-review.googlesource.com/8333Reviewed-by:
-
Shenghou Ma authored
Change-Id: Ibfb5a96995a954c8c1dc563c33bdddbdb4866425 Reviewed-on: https://go-review.googlesource.com/8765Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
This will make it possible to access the gcimporter (and gccgoimporter, eventually) from the forthcoming gc/importer package, without exposing compiler names in package names. This change was created by manually adjusting the gcimporter paths in go/types.bash and then running sh go/types.bash (i.e., by revendoring gcimporter). The only manual changes are in go/types.bash. Change-Id: Idc282439742288c09caa58b3a66d77aec0325faf Reviewed-on: https://go-review.googlesource.com/8764Reviewed-by:
Rob Pike <r@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org>
-
Rob Pike authored
Change-Id: Ieadbd2b1ad442ba3eb2ad5f552d96c93ba3e5a2e Reviewed-on: https://go-review.googlesource.com/8790Reviewed-by:
-
Rob Pike authored
Issue 9483 suggests several approaches to correlating logs from machines in different time zones. This approach is the simplest and really should be sufficient: provide a way to clamp the time stamps to UTC. Fixes #9483. Change-Id: If540b991d758c4d845a719779f8255ece7c452e7 Reviewed-on: https://go-review.googlesource.com/8761Reviewed-by:
-
Michael Hudson-Doyle authored
Jumping to an offset past a symbol isn't something that is really supported by dynamic linkers, so do it by hand. Change-Id: Ifff8834c6cdfa3d521ebd8479d2e93906df9b258 Reviewed-on: https://go-review.googlesource.com/8238Reviewed-by:
-
- 10 Apr, 2015 24 commits
-
-
Michael Hudson-Doyle authored
Skip the test when there is no .gosymtab section in the executable rather than crashing. Change-Id: Ieb3df07e307f50c33cdafab38f9b5d1ac0e55c04 Reviewed-on: https://go-review.googlesource.com/5110Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Ian Lance Taylor authored
Change-Id: I353ff7eb35b066a1a2693c087c9876adac8e3fd0 Reviewed-on: https://go-review.googlesource.com/8763Reviewed-by:
-
Shenghou Ma authored
Change-Id: I8d17e2b0fbc529ca7958c75222964a5e419aa3db Reviewed-on: https://go-review.googlesource.com/8717Reviewed-by:
-
Derek Buitenhuis authored
A similar fix was applied in 54568685 but another instance of 'pc' was missed. Also adds a test for the goroutine gdb command. It currently uses goroutine 2 for the test, since goroutine 1 has its stack pointer set to 0 for some reason. Change-Id: I53ca22be6952f03a862edbdebd9b5c292e0853ae Reviewed-on: https://go-review.googlesource.com/8729 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Rob Pike authored
Change-Id: I9e8a0dc152ef9403ff5ece0c161bda3a2f4448a8 Reviewed-on: https://go-review.googlesource.com/8760Reviewed-by:
-
Caleb Spare authored
This is a version of Time.Format that doesn't require allocation. This is an updated version of 0af302f5 submitted by @bradfitz which was later rolled back. Fixes #5192 Updates #5195 Change-Id: I4e6255bee1cf3914a6cc8d9d2a881cfeb273c08e Reviewed-on: https://go-review.googlesource.com/1760Reviewed-by:
-
Dmitry Vyukov authored
Now that getg is an intrinsic, more runtime functions gets inlined (in particular, LockOSThread). Runtime code gets race instrumented after inlining into other packages. This can lead to false positives, as race detector ignores all internal synchronization in runtime. Inling of LockOSThread lead to false race reports on m contents. See the issue for an example. Fixes #10380 Change-Id: Ic9b760b53c28c2350bc54a5d4677fcd1c1f86e5f Reviewed-on: https://go-review.googlesource.com/8690Reviewed-by:
-
Austin Clements authored
Currently, when allocation reaches the concurrent GC trigger size, we start the concurrent collector by ready'ing its G. This simply puts it on the end of the P's run queue, which means we may not actually start GC for some time as the current G continues to run and then the P drains other Gs already on its run queue. Since the mutator can continue to allocate, the heap can potentially be much larger than we intended by the time GC actually starts. Furthermore, how much larger is difficult to predict since it depends on the scheduler. Fix this by preempting the current G and switching directly to the concurrent GC G as soon as we reach the trigger heap size. On the garbage benchmark from the benchmarks subrepo with GOMAXPROCS=4, this reduces the time from triggering the GC to the beginning of sweep termination by 10 to 30 milliseconds, which reduces allocation after the trigger by up to 10MB (a large fraction of the 64MB live heap the benchmark tries to maintain). One other known source of delay before we "really" start GC is the sweep finalization performed before sweep termination. This has similar negative effects on heap size and predictability, but is an orthogonal problem. This change adds a TODO for this. Change-Id: I8bae98cb43685c1bf353ff55868e4647e3743c47 Reviewed-on: https://go-review.googlesource.com/8513Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
These were appropriate for STW GC, since it interrupted the allocating Goroutine, but don't apply to concurrent GC, which runs on its own Goroutine. Forced GC is still STW, but it makes sense to attribute the GC to the goroutine that called runtime.GC(). Change-Id: If12418ca66dc7e53b8b16025af4e03adb5d9577e Reviewed-on: https://go-review.googlesource.com/8715Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
-
Austin Clements authored
Currently, GC disables preemption between the traceGCStart and traceGCDone, so it never moves Ps. Consequently, the trace verifier attaches information about GC to its per-P state and will fail if GC starts on one P and ends on another. GC will soon be preemptible and may end on a different P than it began. Hence, this change lifts this per-P verifier state to global state. Change-Id: I82256e2baab1ff3c4453fec312079018423b4b51 Reviewed-on: https://go-review.googlesource.com/8714Reviewed-by:
-
Austin Clements authored
exitsyscallfast checks for freezetheworld, but does so only by checking if stopwait is positive. This can also happen during stoptheworld, which is harmless, but confusing. Shortly, it will be important that we get to the p.status cas even if stopwait is set. Hence, make this test more specific so it only triggers with freezetheworld and not other uses of stopwait. Change-Id: Ibb722cd8360c3ed5a9654482519e3ceb87a8274d Reviewed-on: https://go-review.googlesource.com/8205Reviewed-by:
-
Austin Clements authored
Currently, the only way to know the Go type of an attribute of some DWARF attribute class was to read the dwarf package code (or experiment). This makes it hard to go from the DWARF specification to writing code that uses the dwarf package. Fix this by adding a table to the documentation comment of the Field type that gives the correspondence between DWARF attribute classes and Go types. Change-Id: I57c678a551fa1eb46f8207085d5a53d44985e3e7 Reviewed-on: https://go-review.googlesource.com/7280Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Robert Griesemer authored
The existing code used ints for the (slow) decimal conversion and assumed that they were 32bit wide. This change uses uints and the appropriate width (32 or 64bit) depending on platform. The performance difference is in the noise for the usual (optimized) case which does not use the slow path conversion: benchmark old ns/op new ns/op delta BenchmarkFormatFloatDecimal 298 299 +0.34% BenchmarkFormatFloat 388 392 +1.03% BenchmarkFormatFloatExp 365 364 -0.27% BenchmarkFormatFloatNegExp 364 362 -0.55% BenchmarkFormatFloatBig 482 476 -1.24% BenchmarkAppendFloatDecimal 100 102 +2.00% BenchmarkAppendFloat 199 201 +1.01% BenchmarkAppendFloatExp 174 175 +0.57% BenchmarkAppendFloatNegExp 169 174 +2.96% BenchmarkAppendFloatBig 286 286 +0.00% BenchmarkAppendFloat32Integer 99.9 102 +2.10% BenchmarkAppendFloat32ExactFraction 161 164 +1.86% BenchmarkAppendFloat32Point 199 201 +1.01% BenchmarkAppendFloat32Exp 167 168 +0.60% BenchmarkAppendFloat32NegExp 163 169 +3.68% BenchmarkAppendFloat64Fixed1 137 134 -2.19% BenchmarkAppendFloat64Fixed2 144 146 +1.39% BenchmarkAppendFloat64Fixed3 138 140 +1.45% BenchmarkAppendFloat64Fixed4 144 145 +0.69% The performance difference is significant if the fast path conversion is explicitly turned off (ftoa.go:101): benchmark old ns/op new ns/op delta BenchmarkFormatFloatDecimal 459 427 -6.97% BenchmarkFormatFloat 1560 1180 -24.36% BenchmarkFormatFloatExp 5501 3128 -43.14% BenchmarkFormatFloatNegExp 24085 14360 -40.38% BenchmarkFormatFloatBig 1409 1081 -23.28% BenchmarkAppendFloatDecimal 248 226 -8.87% BenchmarkAppendFloat 1315 982 -25.32% BenchmarkAppendFloatExp 5274 2869 -45.60% BenchmarkAppendFloatNegExp 23905 14054 -41.21% BenchmarkAppendFloatBig 1194 860 -27.97% BenchmarkAppendFloat32Integer 167 175 +4.79% BenchmarkAppendFloat32ExactFraction 182 184 +1.10% BenchmarkAppendFloat32Point 556 564 +1.44% BenchmarkAppendFloat32Exp 1134 918 -19.05% BenchmarkAppendFloat32NegExp 2679 1801 -32.77% BenchmarkAppendFloat64Fixed1 274 238 -13.14% BenchmarkAppendFloat64Fixed2 494 368 -25.51% BenchmarkAppendFloat64Fixed3 1833 1008 -45.01% BenchmarkAppendFloat64Fixed4 6133 3596 -41.37% Change-Id: I829b8abcca882b1c10d8ae421d3249597c31f3c9 Reviewed-on: https://go-review.googlesource.com/3811Reviewed-by:
-
Dmitry Vyukov authored
Fix tracing of syscall exit after: https://go-review.googlesource.com/#/c/7504/ Change-Id: Idcde2aa826d2b9a05d0a90a80242b6bfa78846ab Reviewed-on: https://go-review.googlesource.com/8728Reviewed-by:
-
Dmitry Vyukov authored
Fixes #10378 This is clumsy, but currently cover tool fails as: $ go test -run=none -cover syscall syscall_linux_amd64.go:15: can only use //go:noescape with external func implementations FAIL syscall [build failed] This happens because cover tool mishandles //go: comments. r and gri said that fixing cover is infeasible due to go/ast limitations. So at least fix the offending code so that coverage works. This come up in context of coverage-guided fuzzing which works best with program-wide coverage. Change-Id: I142e5774c9f326ed38cb202693bd4edae93879ba Reviewed-on: https://go-review.googlesource.com/8723Reviewed-by:
-
Dmitry Vyukov authored
The flag updates error annotations in test files from actual compiler output. This is useful when doing compiler changes that add/remove/change lots of errors, or when adding lots of new tests. Also I noticed at least 2 cases where annotation were sub-optimal: 1. The annotation was "leaking param p" when the actual error is "leaking param p to result ~r1". 2. The annotation was "leaking param m" when the actual errors are "leaking param m" and "leaking param mv1". For now it works only for errorcheck mode. Also, apply the update to escape and liveness tests. Some files have gccgo-specific errors of the form "gc error|gccgo error", so it is risky to run update on all files. Gccgo-specific error does not necessary contain '|', it can be just truncated. Change-Id: Iaaae767f859dcb8321a8cb4970b2b70969e8a345 Reviewed-on: https://go-review.googlesource.com/5310 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
-
Paul Marks authored
Remove the "netaddr" type, which ambiguously represented either one address, or a list of addresses. Instead, use "addrList" wherever multiple addresses are supported. The "first" method returns the first address matching some condition (e.g. "is it IPv4?"), primarily to support legacy code that can't handle multiple addresses. The "partition" method splits an addrList into two categories, as defined by some strategy function. This is useful for implementing Happy Eyeballs, and similar two-channel algorithms. Finally, internetAddrList (formerly resolveInternetAddr) no longer mangles the ordering defined by getaddrinfo. In the future, this may be used by a sequential Dial implementation. Updates #8453, #8455. Change-Id: I7375f4c34481580ab40e31d33002a4073a0474f3 Reviewed-on: https://go-review.googlesource.com/8360Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com> Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dave Cheney authored
Update #9855 In preparation for introducing direct use of a zero register on platforms that support it, take the opportunity to clean up Componentgen a bit. Change-Id: I120ce1ffcca8c4f7603bfe76bfa1aedd27ebb4d2 Reviewed-on: https://go-review.googlesource.com/8691 Run-TryBot: Dave Cheney <dave@cheney.net> Reviewed-by:
-
Michael Hudson-Doyle authored
'themoduledata' doesn't really make sense now we support multiple moduledata objects. Change-Id: I8263045d8f62a42cb523502b37289b0fba054f62 Reviewed-on: https://go-review.googlesource.com/8521Reviewed-by:
-
Daniel Theophanes authored
If GOBIN is not empty the build moves the go executable to a new path. When this test runs it fails to find the go cmd in the GOROOT. Change-Id: I100def0fbcb9691b13776f795b1d1725e36d8102 Reviewed-on: https://go-review.googlesource.com/8735Reviewed-by:
-
Michael Hudson-Doyle authored
This changes all the places that consult themoduledata to consult a linked list of moduledata objects, as will be necessary for -linkshared to work. Obviously, as there is as yet no way of adding moduledata objects to this list, all this change achieves right now is wasting a few instructions here and there. Change-Id: I397af7f60d0849b76aaccedf72238fe664867051 Reviewed-on: https://go-review.googlesource.com/8231Reviewed-by:
-
Michael Hudson-Doyle authored
Modelled somewhat on the -race support. Change-Id: I137037addfc76341f7deb216776fdd18e9af9fe5 Reviewed-on: https://go-review.googlesource.com/8680Reviewed-by:
-
Michael Hudson-Doyle authored
Change-Id: I49862e177045369d6c94d6a58afbdace4f13cc96 Reviewed-on: https://go-review.googlesource.com/8237Reviewed-by:
-
Josh Bleecher Snyder authored
Broken by CL 8541. Change-Id: Ie2e89a22b91748e82f7bc4723660a24ed4135687 Reviewed-on: https://go-review.googlesource.com/8734Reviewed-by:
-
