- 17 Oct, 2016 8 commits
-
-
Klaus Post authored
The incorrect table was used for estimating output size. This can give suboptimal selection of entropy encoder in rare cases. Change-Id: I8b358200f2d1f9a3f9b79a44269d7be704e1d2d9 Reviewed-on: https://go-review.googlesource.com/31172Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Yasuhiro Matsumoto authored
Fixes #16736 Change-Id: I335d201e3f6738d838de3881087cb640fc7670e8 Reviewed-on: https://go-review.googlesource.com/30578 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
Daniel Theophanes authored
Modify the new Context methods to take a name-value driver struct. This will require more modifications to drivers to use, but will reduce the overall number of structures that need to be maintained over time. Fixes #12381 Change-Id: I30747533ce418a1be5991a0c8767a26e8451adbd Reviewed-on: https://go-review.googlesource.com/30166Reviewed-by:
-
Martin Möhrmann authored
In ReadRune store the size of the rune that was read into lastRead to avoid the need to call DecodeRuneLast in UnreadRune. fmt: name old time/op new time/op delta ScanInts-4 481µs ± 4% 458µs ± 3% -4.64% (p=0.000 n=20+20) Change-Id: I500848e663a975f426402a4b3d27a541e5cac06c Reviewed-on: https://go-review.googlesource.com/28817Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Updates #16456 Change-Id: Ifea651ea3ece2267a6f0c1638181d6ddd9248a9f Reviewed-on: https://go-review.googlesource.com/31181Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Flesh out nacl's fake network system to match how all the other platforms work: all other systems' SetReadDeadline and SetWriteDeadline affect currently-blocked read & write calls. This was documented in golang.org/cl/30164 because it was the status quo and existing packages relied on it. (notably the net/http package) And add a test. Change-Id: I074a1054dcabcedc97b173dad5e827f8babf7cfc Reviewed-on: https://go-review.googlesource.com/31178 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Caleb Spare authored
Template.escape makes the assumption that t.Lookup(t.Name()) is t (escapeTemplate looks up the associated template by name and sets escapeErr appropriately). This assumption did not hold for a Cloned template, because the template associated with t.Name() was a second copy of the original. Add a test for the assumption that t.Lookup(t.Name()) == t. One effect of this broken assumption was #16101: parallel Executes racily accessed the template namespace because each Execute call saw t.escapeErr == nil and re-escaped the template concurrently with read accesses occurring outside the namespace mutex. Add a test for this race. Related to #12996 and CL 16104. Fixes #16101 Change-Id: I59831d0847abbabb4ef9135f2912c6ce982f9837 Reviewed-on: https://go-review.googlesource.com/31092 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Alex Brainman authored
Fixes #17439 Change-Id: I7caa28519f38692f9ca306f0789cbb975fa1d7c4 Reviewed-on: https://go-review.googlesource.com/31112Reviewed-by:
-
- 16 Oct, 2016 6 commits
-
-
Rob Pike authored
Fixes #16423 Change-Id: I9635db295be4d356d427adadd309084e16c4582f Reviewed-on: https://go-review.googlesource.com/31255Reviewed-by:
-
Rob Pike authored
Exit code 3 is unprecedented and inconsistent with other failures here, such as having no tool directory. Fixes #17145 Change-Id: Ie7ed56494d4511a600214666ce3a726d63a8fd8e Reviewed-on: https://go-review.googlesource.com/31253Reviewed-by:
-
Brad Fitzpatrick authored
No need to skip it. It passes. Maybe it was fixed at some point. Change-Id: I9848924aefda44f9b3a574a8705fa549d657f28d Reviewed-on: https://go-review.googlesource.com/31177 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com>
-
Brad Fitzpatrick authored
Change-Id: Ibae0be046c6a6596d3a98b094ec5f089bb68be7a Reviewed-on: https://go-review.googlesource.com/31182Reviewed-by:
-
Hiroshi Ioka authored
Change-Id: I8a176ed9c7f59ebdfd39c1e2b88905f977179982 Reviewed-on: https://go-review.googlesource.com/31119Reviewed-by:
-
Alex Carol authored
Change-Id: Idca6115181960eed7a955027ee77a02decb4e7f2 Reviewed-on: https://go-review.googlesource.com/31179Reviewed-by:
-
- 15 Oct, 2016 8 commits
-
-
Austin Clements authored
The error check patterns in this test are more complex than necessary because f2 gets inlined into f1. This behavior isn't important to the test, so disable inlining of f2 and simplify the error check patterns. Change-Id: Ia8aee92a52f9217ad71b89b2931494047e8d2185 Reviewed-on: https://go-review.googlesource.com/31132 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Austin Clements authored
Currently we use go:nowritebarrier in many places in proc.go. go:notinheap and go:yeswritebarrierrec now let us use go:nowritebarrierrec (the recursive form of the go:nowritebarrier pragma) more liberally. Do so in proc.go Change-Id: Ia7fcbc12ce6c51cb24730bf835fb7634ad53462f Reviewed-on: https://go-review.googlesource.com/30942Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
This covers basically all sysAlloc'd, persistentalloc'd, and fixalloc'd types. Change-Id: I0487c887c2a0ade5e33d4c4c12d837e97468e66b Reviewed-on: https://go-review.googlesource.com/30941Reviewed-by:
-
Austin Clements authored
Currently mspan links to its previous mspan using a **mspan field that points to the previous span's next field. This simplifies some of the list manipulation code, but is going to make it very hard to convince the compiler that mspan list manipulations don't need write barriers. Fix this by using a more traditional ("boring") linked list that uses a simple *mspan pointer to the previous mspan. This complicates some of the list manipulation slightly, but it will let us eliminate all write barriers from the mspan list manipulation code by marking mspan go:notinheap. Change-Id: I0d0b212db5f20002435d2a0ed2efc8aa0364b905 Reviewed-on: https://go-review.googlesource.com/30940Reviewed-by: -
Austin Clements authored
This adds a //go:notinheap pragma for declarations of types that must not be heap allocated. We ensure these rules by disallowing new(T), make([]T), append([]T), or implicit allocation of T, by disallowing conversions to notinheap types, and by propagating notinheap to any struct or array that contains notinheap elements. The utility of this pragma is that we can eliminate write barriers for writes to pointers to go:notinheap types, since the write barrier is guaranteed to be a no-op. This will let us mark several scheduler and memory allocator structures as go:notinheap, which will let us disallow write barriers in the scheduler and memory allocator much more thoroughly and also eliminate some problematic hybrid write barriers. This also makes go:nowritebarrierrec and go:yeswritebarrierrec much more powerful. Currently we use go:nowritebarrier all over the place, but it's almost never what you actually want: when write barriers are illegal, they're typically illegal for a whole dynamic scope. Partly this is because go:nowritebarrier has been around longer, but it's also because go:nowritebarrierrec couldn't be used in situations that had no-op write barriers or where some nested scope did allow write barriers. go:notinheap eliminates many no-op write barriers and go:yeswritebarrierrec makes it possible to opt back in to write barriers, so these two changes will let us use go:nowritebarrierrec far more liberally. This updates #13386, which is about controlling pointers from non-GC'd memory to GC'd memory. That would require some additional pragma (or pragmas), but could build on this pragma. Change-Id: I6314f8f4181535dd166887c9ec239977b54940bd Reviewed-on: https://go-review.googlesource.com/30939Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Austin Clements authored
This pragma cancels the effect of go:nowritebarrierrec. This is useful in the scheduler because there are places where we enter a function without a valid P (and hence cannot have write barriers), but then obtain a P. This allows us to annotate the function with go:nowritebarrierrec and split out the part after we've obtained a P into a go:yeswritebarrierrec function. Change-Id: Ic8ce4b6d3c074a1ecd8280ad90eaf39f0ffbcc2a Reviewed-on: https://go-review.googlesource.com/30938Reviewed-by:
-
Ilya Tocar authored
This simplifies code and provides performance iprovments: Similar to https://go-review.googlesource.com/#/c/28577 CountHard1-48 1.74ms ±14% 0.17ms ±14% -90.16% (p=0.000 n=19+19) CountHard2-48 1.78ms ±15% 0.25ms ±13% -86.10% (p=0.000 n=19+20) CountHard3-48 1.78ms ±12% 0.80ms ±11% -55.19% (p=0.000 n=17+20) CountTorture-48 13.5µs ±14% 13.6µs ±11% ~ (p=0.625 n=18+19) CountTortureOverlapping-48 6.92ms ±13% 8.42ms ±11% +21.72% (p=0.000 n=19+17) Change-Id: Ief120aee918a66487c76be56e0796871c8502f89 Reviewed-on: https://go-review.googlesource.com/28586 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Theophanes authored
Many database systems allow returning multiple result sets in a single query. This can be useful when dealing with many intermediate results on the server and there is a need to return more then one arity of data to the client. Fixes #12382 Change-Id: I480a9ac6dadfc8743e0ba8b6d868ccf8442a9ca1 Reviewed-on: https://go-review.googlesource.com/30592Reviewed-by:
-
- 14 Oct, 2016 3 commits
-
-
Rob Pike authored
If a labeled statement is the target of a goto, we must treat it as the boundary of a new basic block, but only if it is not already the boundary of a basic block such as a labeled for loop. Fixes #16624 Now reports 100% coverage for the test in the issue. Change-Id: If118bb6ff53a96c738e169d92c03cb3ce97bad0e Reviewed-on: https://go-review.googlesource.com/30977Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Robert Griesemer authored
Fixes #17398. Change-Id: Iac7899031c1bfbadc4f84e5b374eaf1f01dff8c8 Reviewed-on: https://go-review.googlesource.com/31190Reviewed-by:
-
Alex Brainman authored
Fixes #15355 Change-Id: Idbab7a627c5de249bb62d519c5a47f3d2f6c82a7 Reviewed-on: https://go-review.googlesource.com/22796Reviewed-by:
-
- 13 Oct, 2016 15 commits
-
-
Brad Fitzpatrick authored
Make a zero-byte write to a hijacked connection not log anything, so handlers can test whether a connection is hacked by doing a Write(nil). Fixes #16456 Change-Id: Id56caf822c8592067bd8422672f0c1aec89e866c Reviewed-on: https://go-review.googlesource.com/30812Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Michael Munday authored
Adds a test to check that block cipher modes accept a zero-length input. Fixes #17435. Change-Id: Ie093c4cdff756b5c2dcb79342e167b3de5622389 Reviewed-on: https://go-review.googlesource.com/31070 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Filippo Valsorda authored
Closes #15815 Change-Id: I08154dbff416198cf7787e446b1e00e62c03a972 Reviewed-on: https://go-review.googlesource.com/30917Reviewed-by:
-
Austin Clements authored
This clarifies some of the titles so they're more "news" friendly and less implementation-oriented. Change-Id: Ied02aa1e6824b04db5d32ecdd58e972515b1f588 Reviewed-on: https://go-review.googlesource.com/29830Reviewed-by:
-
Alan Donovan authored
This change is a copy of CL 22788 in x/tools. It has no observable effect yet, but brings the two packages in synch. Change-Id: I266c77547cb46deb69b1a36e1674dfebc430e3a5 Reviewed-on: https://go-review.googlesource.com/22936Reviewed-by:
-
Alex Brainman authored
This CL also includes vendored copy of debug/pe, otherwise bootstrapping fails. Updates #15345 Change-Id: I3a8ac990e3cb12cb4d24ec11b618b68190397fd1 Reviewed-on: https://go-review.googlesource.com/22603Reviewed-by:
-
Russ Cox authored
No functional changes here. Just makes next CL easier to read. Change-Id: Icf7b2281b4da6cb59ff4edff05943b2ee288576a Reviewed-on: https://go-review.googlesource.com/30945 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Anthony Canino authored
"abc"[1] is not like 'b', in that -"abc"[1] is uint8 math, not ideal constant math. Delay the constantification until after ideal constant folding is over. Fixes #11370. Change-Id: Iba2fc00ca2455959e7bab8f4b8b4aac14b1f9858 Reviewed-on: https://go-review.googlesource.com/15740 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #15146. Change-Id: I229611b9cc995a1391681c492c4d742195c787ea Reviewed-on: https://go-review.googlesource.com/30943 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
When we need to generate a call to _cgoCheckPointer, we need to type assert the result back to the desired type. That is harder when the type is unsafe.Pointer, as the package can have values of unsafe.Pointer types without actually importing unsafe, by mixing C void* and :=. We used to handle this by generating a special function for each needed type, and defining that function in a separate file where we did import unsafe. Simplify the code by not generating those functions, but instead just import unsafe under the alias _cgo_unsafe. This is a simplification step toward a fix for issue #16591. Change-Id: I0edb3e04b6400ca068751709fe063397cf960a54 Reviewed-on: https://go-review.googlesource.com/30973 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
name old time/op new time/op delta Template 349ms ± 5% 339ms ± 7% -2.89% (p=0.000 n=27+29) Unicode 187ms ±11% 182ms ±11% -2.77% (p=0.039 n=29+29) GoTypes 1.05s ± 3% 1.04s ± 4% ~ (p=0.103 n=29+29) Compiler 4.57s ± 3% 4.55s ± 3% ~ (p=0.202 n=30+29) name old user-ns/op new user-ns/op delta Template 510M ±21% 521M ±18% ~ (p=0.281 n=30+29) Unicode 303M ±34% 300M ±28% ~ (p=0.592 n=30+30) GoTypes 1.52G ± 9% 1.50G ± 9% ~ (p=0.314 n=30+30) Compiler 6.50G ± 5% 6.44G ± 5% ~ (p=0.362 n=29+30) name old alloc/op new alloc/op delta Template 44.7MB ± 0% 44.0MB ± 0% -1.63% (p=0.000 n=28+28) Unicode 34.6MB ± 0% 34.5MB ± 0% -0.18% (p=0.000 n=30+29) GoTypes 125MB ± 0% 123MB ± 0% -1.14% (p=0.000 n=30+30) Compiler 515MB ± 0% 513MB ± 0% -0.52% (p=0.000 n=30+30) name old allocs/op new allocs/op delta Template 427k ± 0% 416k ± 0% -2.66% (p=0.000 n=30+30) Unicode 323k ± 0% 322k ± 0% -0.28% (p=0.000 n=30+30) GoTypes 1.21M ± 0% 1.18M ± 0% -1.84% (p=0.000 n=29+30) Compiler 4.40M ± 0% 4.36M ± 0% -0.95% (p=0.000 n=30+30) Passes toolstash -cmp. Change-Id: Ifee7d012b1cddadda01450e027eef8d4ecf5581f Reviewed-on: https://go-review.googlesource.com/30980 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Matthew Dempsky authored
Change-Id: I36cf3523e00b80e2d3a690f251edd5d6f665d156 Reviewed-on: https://go-review.googlesource.com/30975 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
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:
-
Matthew Dempsky authored
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:
-
Alex Brainman authored
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:
-
