- 02 Sep, 2016 12 commits
-
-
Brad Fitzpatrick authored
The http.Transport's retry can't retry requests with non-nil bodies. When cloning an incoming server request into an outgoing client request, nil out the Body field if the ContentLength is 0. (For server requests, Body is always non-nil, even for GET, HEAD, etc.) Also, don't use the deprecated CancelRequest and use Context instead. And don't set Proto, ProtoMajor, ProtoMinor. Those are ignored in client requests, which was probably a later documentation clarification. Fixes #16036 Updates #16696 (remove useless Proto lines) Change-Id: I70a869e9bd4bf240c5838e82fb5aa695a539b343 Reviewed-on: https://go-review.googlesource.com/28412 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Joe Tsai authored
The use of PAX headers can modify the overall file size, thus the formerly created regFileReader may be stale. The relevant PAX specification for this behavior is: <<< Any fields in the preceding optional extended header shall override the associated fields in this header block for this file. >>> Where "optional extended header" refers to the preceding PAX header. Where "this header block" refers to the subsequent USTAR header. Fixes #15573 Fixes #15564 Change-Id: I83b1c3f05a9ca2d3be38647425ad21a9fe450ee2 Reviewed-on: https://go-review.googlesource.com/28418Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Follow-up to https://go-review.googlesource.com/28394. Change-Id: Ic4147e9ae786a4de0a3454131fac03e940ae2e76 Reviewed-on: https://go-review.googlesource.com/28417Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Jaana Burcu Dogan authored
Change-Id: I242a8960583e333f372929aad4adb8efbe441cd4 Reviewed-on: https://go-review.googlesource.com/28413Reviewed-by:
-
Josh Bleecher Snyder authored
hbits.morePointers and hbits.isPointer both do a load and a shift. Do it only once. Benchmarks using compilebench (because it is the benchmark I have the most tooling around), on a quiet machine. name old time/op new time/op delta Template 291ms ±14% 290ms ±15% ~ (p=0.702 n=100+99) Unicode 143ms ± 9% 142ms ± 9% ~ (p=0.126 n=99+98) GoTypes 934ms ± 4% 933ms ± 4% ~ (p=0.937 n=100+100) Compiler 4.92s ± 2% 4.90s ± 1% -0.28% (p=0.003 n=98+98) name old user-ns/op new user-ns/op delta Template 360user-ms ± 5% 355user-ms ± 4% -1.37% (p=0.000 n=97+96) Unicode 178user-ms ± 6% 176user-ms ± 6% -1.24% (p=0.001 n=96+99) GoTypes 1.22user-s ± 5% 1.21user-s ± 5% -0.94% (p=0.000 n=100+100) Compiler 6.50user-s ± 2% 6.44user-s ± 3% -0.94% (p=0.000 n=96+98) On amd64, before: "".scanobject t=1 size=581 args=0x10 locals=0x78 After: "".scanobject t=1 size=540 args=0x10 locals=0x78 Change-Id: I420ac3704549d484a5d85e19fea82c85da389514 Reviewed-on: https://go-review.googlesource.com/22712 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dmitry Vyukov authored
We reset global buffer only if its pos != 0. We ought to do it always, but queue it only if pos != 0. This is a latent bug. Currently it does not fire because whenever we create a global buffer, we increment pos. Change-Id: I01e28ae88ce9a5412497c524391b8b7cb443ffd9 Reviewed-on: https://go-review.googlesource.com/25574 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Gleb Stepanov authored
Rename variable to bitScan according to TODO comment. Change-Id: I81dd8cc1ca28c0dc9308a654ad65cdf5b2fd2ce3 Reviewed-on: https://go-review.googlesource.com/25175 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
Currently this message says "invalid stack pointer", which could be interpreted as the value of SP being invalid. Change it to "invalid pointer found on stack" to emphasize that it's a pointer on the stack that's invalid. Updates #16948. Change-Id: I753624f8cc7e08cf13d3ea5d9c790cc4af9fa372 Reviewed-on: https://go-review.googlesource.com/28430 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
The maximum input plaintext for GCM is 64GiB - 64. Since the GCM interface is one-shot, it's very hard to hit this in Go (one would need a 64GiB buffer in memory), but we should still enforce this limit. Thanks to Quan Nguyen for pointing it out. Change-Id: Icced47bf8d4d5dfbefa165cf13e893205c9577b8 Reviewed-on: https://go-review.googlesource.com/28410 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Sina Siadat authored
RFC 2616, section 14.10 says: >>> HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option. <<< The same requirement was included in RFC 7230, section 6.1. Fixes #16875 Change-Id: I57ad4a4a17775537c8810d0edd7de1604317b5fa Reviewed-on: https://go-review.googlesource.com/27970Reviewed-by:
-
David Glasser authored
While it was previously explicitly documented that "the default Source" is safe for concurrent use, a careless reader can interpret that as meaning "the implementation of the Source interface created by functions in this package" rather than "the default shared Source used by top-level functions". Be explicit that the Source returned by NewSource is not safe for use by multiple goroutines. Fixes #3611. Change-Id: Iae4bc04c3887ad6e2491e36e38feda40324022c5 Reviewed-on: https://go-review.googlesource.com/25501Reviewed-by:
-
Josh Bleecher Snyder authored
Current banners are: ##### Building Go bootstrap tool. ##### Building Go toolchain using /Users/josh/go/1.4. ##### Building go_bootstrap for host, darwin/amd64. ##### Building packages and commands for darwin/amd64. ##### Testing packages. ##### GOMAXPROCS=2 runtime -cpu=1,2,4 ##### Testing without libgcc. ##### sync -cpu=10 ##### ../misc/cgo/stdio ##### ../misc/cgo/life ##### ../misc/cgo/fortran ##### ../misc/cgo/test ##### Testing race detector ##### ../misc/cgo/testso ##### ../misc/cgo/testsovar ##### misc/cgo/testcarchive ##### ../misc/cgo/testcshared ##### ../misc/cgo/errors ##### ../test/bench/go1 ##### ../test ##### API check One of these things is not like the others. Fix that. Change-Id: If0bd8ea9293d73b5d1b70d6bf676bd9192991505 Reviewed-on: https://go-review.googlesource.com/26759 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
- 01 Sep, 2016 11 commits
-
-
Matt Layher authored
Fixes #16565 Change-Id: I3edfd2576a7ca5270644a4e7f126854f821f2c9a Reviewed-on: https://go-review.googlesource.com/25385Reviewed-by:
-
Matt Layher authored
Per RFC 7230, Section 3.3.2: "A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content).". Fixes #16942 Change-Id: I8006c76c126304e13618966e6eafb08a3885d3cd Reviewed-on: https://go-review.googlesource.com/28351Reviewed-by:
-
Martin Möhrmann authored
make(T, n, m) returns a slice of type T with length n and capacity m where "The size arguments n and m must be of integer type or untyped." https://tip.golang.org/ref/spec#Making_slices_maps_and_channels The failure to reject typed non-integer size arguments in make during compile time was uncovered after https://golang.org/cl/27851 changed the generation of makeslice calls. Fixes #16940 Updates #16949 Change-Id: Ib1e3576f0e6ad199c9b16b7a50c2db81290c63b4 Reviewed-on: https://go-review.googlesource.com/28301Reviewed-by:
-
Josh Bleecher Snyder authored
Found by vet. Change-Id: I50420771678b1a3695348ce1a81f410479ed09a1 Reviewed-on: https://go-review.googlesource.com/28394 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Keith Randall authored
Fixes #15509 Change-Id: I44073533f02d38795f9ba9b255db4d1ee426d70e Reviewed-on: https://go-review.googlesource.com/28390 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Update #16141 Change-Id: I7d32c5cdc197d86491a67ea579fa16cb3d675b51 Reviewed-on: https://go-review.googlesource.com/28273 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Emmanuel Odeke authored
Change-Id: I63af8f0a19ec91f4a2001aa7a2eadcd2232a47df Reviewed-on: https://go-review.googlesource.com/28348Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Ilya Tocar authored
name old time/op new time/op delta IndexByte32-48 9.05ns ± 7% 9.59ns ±11% +5.93% (p=0.001 n=19+20) IndexByte4K-48 118ns ± 4% 122ns ± 8% +3.52% (p=0.002 n=19+19) IndexByte4M-48 172µs ±13% 188µs ±12% +9.49% (p=0.000 n=20+20) IndexByte64M-48 8.00ms ±14% 8.05ms ±23% ~ (p=0.799 n=20+20) IndexBytePortable32-48 41.7ns ±15% 42.5ns ±12% ~ (p=0.372 n=20+20) IndexBytePortable4K-48 3.08µs ±16% 3.26µs ±10% +5.77% (p=0.018 n=20+20) IndexBytePortable4M-48 3.12ms ±17% 3.20ms ±10% ~ (p=0.157 n=20+20) IndexBytePortable64M-48 54.0ms ±14% 55.3ms ±14% ~ (p=0.640 n=20+20) Index32-48 230ns ±12% 46ns ± 6% -79.87% (p=0.000 n=20+19) Index4K-48 43.2µs ± 9% 3.2µs ±12% -92.58% (p=0.000 n=19+20) Index4M-48 44.4ms ± 7% 3.3ms ±13% -92.59% (p=0.000 n=19+20) Index64M-48 714ms ±10% 56ms ± 8% -92.22% (p=0.000 n=19+19) IndexEasy32-48 52.7ns ±10% 31.0ns ±11% -41.21% (p=0.000 n=20+20) IndexEasy4K-48 139ns ± 5% 1598ns ± 6% +1046.37% (p=0.000 n=19+19) IndexEasy4M-48 179µs ± 8% 1674µs ±10% +834.31% (p=0.000 n=19+20) IndexEasy64M-48 8.56ms ±10% 27.82ms ±16% +225.14% (p=0.000 n=19+20) name old speed new speed delta IndexByte32-48 3.52GB/s ± 7% 3.35GB/s ±11% -4.99% (p=0.001 n=20+20) IndexByte4K-48 34.5GB/s ± 7% 33.2GB/s ±10% -3.67% (p=0.002 n=20+20) IndexByte4M-48 24.6GB/s ±14% 22.4GB/s ±14% -8.73% (p=0.000 n=20+20) IndexByte64M-48 8.42GB/s ±16% 8.42GB/s ±19% ~ (p=0.799 n=20+20) IndexBytePortable32-48 770MB/s ±13% 756MB/s ±11% ~ (p=0.383 n=20+20) IndexBytePortable4K-48 1.34GB/s ±14% 1.26GB/s ±10% -5.76% (p=0.018 n=20+20) IndexBytePortable4M-48 1.35GB/s ±15% 1.31GB/s ±11% ~ (p=0.157 n=20+20) IndexBytePortable64M-48 1.25GB/s ±16% 1.22GB/s ±13% ~ (p=0.640 n=20+20) Index32-48 138MB/s ± 8% 687MB/s ± 8% +398.57% (p=0.000 n=19+20) Index4K-48 94.9MB/s ± 9% 1280.5MB/s ±11% +1249.11% (p=0.000 n=19+20) Index4M-48 94.6MB/s ± 7% 1278.5MB/s ±12% +1250.99% (p=0.000 n=19+20) Index64M-48 94.2MB/s ±10% 1210.9MB/s ± 8% +1185.04% (p=0.000 n=19+19) IndexEasy32-48 608MB/s ±10% 1035MB/s ±10% +70.15% (p=0.000 n=20+20) IndexEasy4K-48 29.3GB/s ± 6% 2.6GB/s ± 6% -91.24% (p=0.000 n=19+19) IndexEasy4M-48 23.3GB/s ±10% 2.5GB/s ± 9% -89.23% (p=0.000 n=20+20) IndexEasy64M-48 7.86GB/s ±11% 2.42GB/s ±14% -69.18% (p=0.000 n=19+20) Change-Id: Ia191f0a6ca80e113397d9ed98d25f195768b65bc Reviewed-on: https://go-review.googlesource.com/22550 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Cherry Zhang authored
Intrinsified atomic op produces <value,memory>. Make sure this memory is considered in the store chain calculation. Fixes #16948. Change-Id: I029f164b123a7e830214297f8373f06ea0bf1e26 Reviewed-on: https://go-review.googlesource.com/28350 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
See the issue below for details. Fixes #16794. Change-Id: I7e338089fd80ddcb634fa80bfc658dee2772361c Reviewed-on: https://go-review.googlesource.com/27356Reviewed-by:
-
Brad Fitzpatrick authored
In Go 1.0, the Config struct consisted only of exported fields. In Go 1.1, it started to grow private, uncopyable fields (sync.Once, sync.Mutex, etc). Ever since, people have been writing their own private Config.Clone methods, or risking it and doing a language-level shallow copy and copying the unexported sync variables. Clean this up and export the Config.clone method as Config.Clone. This matches the convention of Template.Clone from text/template and html/template at least. Fixes #15771 Updates #16228 (needs update in x/net/http2 before fixed) Updates #16492 (not sure whether @agl wants to do more) Change-Id: I48c2825d4fef55a75d2f99640a7079c56fce39ca Reviewed-on: https://go-review.googlesource.com/28075 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 31 Aug, 2016 17 commits
-
-
Joe Tsai authored
The tar.Reader guarantees stickiness of errors. Ensuring this property means that the methods of Reader need to be consistent about whose responsibility it is to actually ensure that errors are sticky. In this CL, we make it only the responsibility of the exported methods (Next and Read) to store tr.err. All other methods just return the error as is. As part of this change, we also check the error value of mergePAX (and test that it properly detects invalid PAX files). Since the value of mergePAX was never used before, we change it such that it always returns ErrHeader instead of strconv.SyntaxError. This keeps it consistent with other usages of strconv in the same tar package. Change-Id: Ia1c31da71f1de4c175da89a385dec665d3edd167 Reviewed-on: https://go-review.googlesource.com/28215 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by:
-
Rob Pike authored
This truly is a common point of confusion that deserves explanation in the FAQ. Change-Id: Ie624e31a2042ca99626fe7570d9c8c075aae6a84 Reviewed-on: https://go-review.googlesource.com/28275Reviewed-by:
-
Joe Tsai authored
This reverts commit 3607c5f4. This was causing failures on amd64 machines without AVX. Fixes #16939 Change-Id: I70080fbb4e7ae791857334f2bffd847d08cb25fa Reviewed-on: https://go-review.googlesource.com/28274Reviewed-by:
-
Keith Randall authored
We used to reserve X15 to implement the 3-operand floating-point sub/div ops with the 2-operand sub/div that 386/amd64 gives us. Now that resultInArg0 is implemented, we no longer need to reserve X15 (X7 on 386). Fixes #15584 Change-Id: I978e6c0a35236e89641bfc027538cede66004e82 Reviewed-on: https://go-review.googlesource.com/28272 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Makes the AuxInt arg to Move/Zero print in a readable format. Change-Id: I12295959b00ff7c1638d35836cc6d64d112c11ca Reviewed-on: https://go-review.googlesource.com/28271 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
This allows for example AMD64 ssa to generate (SETNE x) instead of (XORLconst [1] SETE). make.bash trigger count on AMD64: 691 generic.rules:225 1 generic.rules:226 4 generic.rules:228 1 generic.rules:229 8 generic.rules:231 6 generic.rules:238 2 generic.rules:257 Change-Id: I5b9827b2df63c8532675079e5a6026aa47bfd8dc Reviewed-on: https://go-review.googlesource.com/28232 Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Instead of saving all pragmas and processing them after parsing is finished, process them immediately during scanning like the current lexer does. This is a bit unfortunate because it means we can't use syntax.ParseFile to concurrently parse files yet, but it fixes how we report syntax errors in the presence of //line pragmas. While here, add a bunch more gcCompat entries to syntax/parser.go to get "go build -toolexec='toolstash -cmp' std cmd" passing. There are still a few remaining cases only triggered building unit tests, but this seems like a nice checkpoint. Change-Id: Iaf3bbcf2849857a460496f31eea228e0c585ce13 Reviewed-on: https://go-review.googlesource.com/28226 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Edward Muller authored
Fixes #16933 Change-Id: I2054abd28bc555b018309934774fc4ecc44826b3 Reviewed-on: https://go-review.googlesource.com/28217Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
-
Kevin Burke authored
Change-Id: I47e3cfa8b49e3d0b55c91387df31488b37038a8f Reviewed-on: https://go-review.googlesource.com/28225Reviewed-by:
-
Denis Nagorny authored
Use AVX if available on 4th generation of Intel(TM) Core(TM) processors. (collected on E5 2609v3 @1.9GHz) name old speed new speed delta Memmove/1-6 158MB/s ± 0% 172MB/s ± 0% +9.09% (p=0.000 n=16+16) Memmove/2-6 316MB/s ± 0% 345MB/s ± 0% +9.09% (p=0.000 n=18+16) Memmove/3-6 517MB/s ± 0% 517MB/s ± 0% ~ (p=0.445 n=16+16) Memmove/4-6 687MB/s ± 1% 690MB/s ± 0% +0.35% (p=0.000 n=20+17) Memmove/5-6 729MB/s ± 0% 729MB/s ± 0% +0.01% (p=0.000 n=16+18) Memmove/6-6 875MB/s ± 0% 875MB/s ± 0% +0.01% (p=0.000 n=18+18) Memmove/7-6 1.02GB/s ± 0% 1.02GB/s ± 1% ~ (p=0.139 n=19+20) Memmove/8-6 1.26GB/s ± 0% 1.26GB/s ± 0% +0.00% (p=0.000 n=18+18) Memmove/9-6 1.42GB/s ± 0% 1.42GB/s ± 0% +0.00% (p=0.000 n=17+18) Memmove/10-6 1.58GB/s ± 0% 1.58GB/s ± 0% +0.00% (p=0.000 n=19+19) Memmove/11-6 1.74GB/s ± 0% 1.74GB/s ± 0% +0.00% (p=0.001 n=18+17) Memmove/12-6 1.90GB/s ± 0% 1.90GB/s ± 0% +0.00% (p=0.000 n=19+19) Memmove/13-6 2.05GB/s ± 0% 2.05GB/s ± 0% +0.00% (p=0.000 n=18+19) Memmove/14-6 2.21GB/s ± 0% 2.21GB/s ± 0% +0.00% (p=0.000 n=16+20) Memmove/15-6 2.37GB/s ± 0% 2.37GB/s ± 0% +0.00% (p=0.004 n=19+20) Memmove/16-6 2.53GB/s ± 0% 2.53GB/s ± 0% +0.00% (p=0.000 n=16+16) Memmove/32-6 4.67GB/s ± 0% 4.67GB/s ± 0% +0.00% (p=0.000 n=17+17) Memmove/64-6 8.67GB/s ± 0% 8.64GB/s ± 0% -0.33% (p=0.000 n=18+17) Memmove/128-6 12.6GB/s ± 0% 11.6GB/s ± 0% -8.05% (p=0.000 n=16+19) Memmove/256-6 16.3GB/s ± 0% 16.6GB/s ± 0% +1.66% (p=0.000 n=20+18) Memmove/512-6 21.5GB/s ± 0% 24.4GB/s ± 0% +13.35% (p=0.000 n=18+17) Memmove/1024-6 24.7GB/s ± 0% 33.7GB/s ± 0% +36.12% (p=0.000 n=18+18) Memmove/2048-6 27.3GB/s ± 0% 43.3GB/s ± 0% +58.77% (p=0.000 n=19+17) Memmove/4096-6 37.5GB/s ± 0% 50.5GB/s ± 0% +34.56% (p=0.000 n=19+19) MemmoveUnalignedDst/1-6 135MB/s ± 0% 146MB/s ± 0% +7.69% (p=0.000 n=16+14) MemmoveUnalignedDst/2-6 271MB/s ± 0% 292MB/s ± 0% +7.69% (p=0.000 n=18+18) MemmoveUnalignedDst/3-6 438MB/s ± 0% 438MB/s ± 0% ~ (p=0.352 n=16+19) MemmoveUnalignedDst/4-6 584MB/s ± 0% 584MB/s ± 0% ~ (p=0.876 n=17+17) MemmoveUnalignedDst/5-6 631MB/s ± 1% 632MB/s ± 0% +0.25% (p=0.000 n=20+17) MemmoveUnalignedDst/6-6 759MB/s ± 0% 759MB/s ± 0% +0.00% (p=0.000 n=19+16) MemmoveUnalignedDst/7-6 885MB/s ± 0% 883MB/s ± 1% ~ (p=0.647 n=18+20) MemmoveUnalignedDst/8-6 1.08GB/s ± 0% 1.08GB/s ± 0% +0.00% (p=0.035 n=19+18) MemmoveUnalignedDst/9-6 1.22GB/s ± 0% 1.22GB/s ± 0% ~ (p=0.251 n=18+17) MemmoveUnalignedDst/10-6 1.35GB/s ± 0% 1.35GB/s ± 0% ~ (p=0.327 n=17+18) MemmoveUnalignedDst/11-6 1.49GB/s ± 0% 1.49GB/s ± 0% ~ (p=0.531 n=18+19) MemmoveUnalignedDst/12-6 1.63GB/s ± 0% 1.63GB/s ± 0% ~ (p=0.886 n=19+18) MemmoveUnalignedDst/13-6 1.76GB/s ± 0% 1.76GB/s ± 1% -0.24% (p=0.006 n=18+20) MemmoveUnalignedDst/14-6 1.90GB/s ± 0% 1.90GB/s ± 0% ~ (p=0.818 n=20+19) MemmoveUnalignedDst/15-6 2.03GB/s ± 0% 2.03GB/s ± 0% ~ (p=0.294 n=17+16) MemmoveUnalignedDst/16-6 2.17GB/s ± 0% 2.17GB/s ± 0% ~ (p=0.602 n=16+18) MemmoveUnalignedDst/32-6 4.05GB/s ± 0% 4.05GB/s ± 0% +0.00% (p=0.010 n=18+17) MemmoveUnalignedDst/64-6 7.59GB/s ± 0% 7.59GB/s ± 0% +0.00% (p=0.022 n=18+16) MemmoveUnalignedDst/128-6 11.1GB/s ± 0% 11.4GB/s ± 0% +2.79% (p=0.000 n=18+17) MemmoveUnalignedDst/256-6 16.4GB/s ± 0% 16.7GB/s ± 0% +1.59% (p=0.000 n=20+17) MemmoveUnalignedDst/512-6 15.7GB/s ± 0% 21.3GB/s ± 0% +35.87% (p=0.000 n=18+20) MemmoveUnalignedDst/1024-6 16.0GB/s ±20% 31.5GB/s ± 0% +96.93% (p=0.000 n=20+14) MemmoveUnalignedDst/2048-6 19.6GB/s ± 0% 42.1GB/s ± 0% +115.16% (p=0.000 n=17+18) MemmoveUnalignedDst/4096-6 6.41GB/s ± 0% 33.18GB/s ± 0% +417.56% (p=0.000 n=17+18) MemmoveUnalignedSrc/1-6 171MB/s ± 0% 166MB/s ± 0% -3.33% (p=0.000 n=19+16) MemmoveUnalignedSrc/2-6 343MB/s ± 0% 342MB/s ± 1% -0.41% (p=0.000 n=17+20) MemmoveUnalignedSrc/3-6 508MB/s ± 0% 493MB/s ± 1% -2.90% (p=0.000 n=17+17) MemmoveUnalignedSrc/4-6 677MB/s ± 0% 660MB/s ± 2% -2.55% (p=0.000 n=17+20) MemmoveUnalignedSrc/5-6 790MB/s ± 0% 790MB/s ± 0% ~ (p=0.139 n=17+17) MemmoveUnalignedSrc/6-6 948MB/s ± 0% 946MB/s ± 1% ~ (p=0.330 n=17+19) MemmoveUnalignedSrc/7-6 1.11GB/s ± 0% 1.11GB/s ± 0% -0.05% (p=0.026 n=17+17) MemmoveUnalignedSrc/8-6 1.38GB/s ± 0% 1.38GB/s ± 0% ~ (p=0.091 n=18+16) MemmoveUnalignedSrc/9-6 1.42GB/s ± 0% 1.40GB/s ± 1% -1.04% (p=0.000 n=19+20) MemmoveUnalignedSrc/10-6 1.58GB/s ± 0% 1.56GB/s ± 1% -1.15% (p=0.000 n=18+19) MemmoveUnalignedSrc/11-6 1.73GB/s ± 0% 1.71GB/s ± 1% -1.30% (p=0.000 n=20+20) MemmoveUnalignedSrc/12-6 1.89GB/s ± 0% 1.87GB/s ± 1% -1.18% (p=0.000 n=17+20) MemmoveUnalignedSrc/13-6 2.05GB/s ± 0% 2.02GB/s ± 1% -1.18% (p=0.000 n=17+20) MemmoveUnalignedSrc/14-6 2.21GB/s ± 0% 2.18GB/s ± 1% -1.14% (p=0.000 n=17+20) MemmoveUnalignedSrc/15-6 2.36GB/s ± 0% 2.34GB/s ± 1% -1.04% (p=0.000 n=17+20) MemmoveUnalignedSrc/16-6 2.52GB/s ± 0% 2.49GB/s ± 1% -1.26% (p=0.000 n=19+20) MemmoveUnalignedSrc/32-6 4.82GB/s ± 0% 4.61GB/s ± 0% -4.40% (p=0.000 n=19+20) MemmoveUnalignedSrc/64-6 5.03GB/s ± 4% 7.97GB/s ± 0% +58.55% (p=0.000 n=20+16) MemmoveUnalignedSrc/128-6 11.1GB/s ± 0% 11.2GB/s ± 0% +0.52% (p=0.000 n=17+18) MemmoveUnalignedSrc/256-6 16.5GB/s ± 0% 16.4GB/s ± 0% -0.10% (p=0.000 n=20+18) MemmoveUnalignedSrc/512-6 21.0GB/s ± 0% 22.1GB/s ± 0% +5.48% (p=0.000 n=14+17) MemmoveUnalignedSrc/1024-6 24.9GB/s ± 0% 31.9GB/s ± 0% +28.20% (p=0.000 n=19+20) MemmoveUnalignedSrc/2048-6 23.3GB/s ± 0% 33.8GB/s ± 0% +45.22% (p=0.000 n=17+19) MemmoveUnalignedSrc/4096-6 37.3GB/s ± 0% 42.7GB/s ± 0% +14.30% (p=0.000 n=17+17) Change-Id: Iab488d93a293cdf573ab5cd89b95a818bbb5d531 Reviewed-on: https://go-review.googlesource.com/22515 Run-TryBot: Denis Nagorny <denis.nagorny@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
This partially reverts commit 4e24e1d9. Since in release 1.7 VPSHUFD support negative constant as an argument, removing it as part of 4e24e1d9 was wrong. Add it back. Change-Id: Id1a3e062fe8fb4cf538edb3f9970f0664f3f545f Reviewed-on: https://go-review.googlesource.com/27712 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
-
Radu Berinde authored
Major reorganization of the crc32 code: - The arch-specific files now implement a well-defined interface (documented in crc32.go). They no longer have the responsibility of initializing and falling back to a non-accelerated implementation; instead, that happens in the higher level code. - The non-accelerated algorithms are moved to a separate file with no dependencies on other code. - The "cutoff" optimization for slicing-by-8 is moved inside the algorithm itself (as opposed to every callsite). Tests are significantly improved: - direct tests for the non-accelerated algorithms. - "cross-check" tests for arch-specific implementations (all archs). - tests for misaligned buffers for both IEEE and Castagnoli. Fixes #16909. Change-Id: I9b6dd83b7a57cd615eae901c0a6d61c6b8091c74 Reviewed-on: https://go-review.googlesource.com/27935Reviewed-by:
-
Ilya Tocar authored
J0-4 71.9ns ± 1% 54.6ns ± 0% -24.08% (p=0.000 n=20+18) J1-4 71.6ns ± 0% 55.4ns ± 0% -22.60% (p=0.000 n=19+20) Jn-4 153ns ± 0% 118ns ± 1% -22.71% (p=0.000 n=20+20) Y0-4 70.8ns ± 0% 53.9ns ± 0% -23.87% (p=0.000 n=19+19) Y1-4 70.8ns ± 0% 54.1ns ± 0% -23.54% (p=0.000 n=20+20) Yn-4 149ns ± 0% 116ns ± 0% -22.15% (p=0.000 n=19+20) Fixes #16889 Change-Id: Ie88496407b42f6acb918ffae1226b1b4c0500cb9 Reviewed-on: https://go-review.googlesource.com/28086 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
cmd/go links mingwex and mingw32 libraries to every package it builds. This breaks when 2 different packages call same gcc standard library function pow. gcc linker appends pow implementation to the compiled package, and names that function "pow". But when these 2 compiled packages are linked together into the final executable, linker complains, because it finds two "pow" functions with the same name. This CL stops linking of mingwex and mingw32 during package build - that leaves pow function reference unresolved. pow reference gets resolved as final executable is built, by having both internal and external linker use mingwex and mingw32 libraries. Fixes #8756 Change-Id: I50ddc79529ea5463c67118d668488345ecf069bc Reviewed-on: https://go-review.googlesource.com/26670 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
TestGetfsstat is failing on OS X 10.8. Not sure why. Add more debug info. Change-Id: I7dabb70dd7aeffda7e8959103db9e4886b84741e Reviewed-on: https://go-review.googlesource.com/28220Reviewed-by:
-
Kevin Burke authored
The goal for these examples is to show how to mirror the functionality of the sha256sum Unix utility, a common checksumming tool, using the Go standard library. Add a newline at the end of the input, so users will get the same output if they type `echo 'hello world' | sha256sum`, since the builtin shell echo appends a newline by default. Also use hex output (instead of the shorter base64) since this is the default output encoding for shasum/sha256sum. Change-Id: I0036874b3cc5ba85432bfcb86f81b51c4e0238fd Reviewed-on: https://go-review.googlesource.com/24868Reviewed-by:
-
Dave Cheney authored
Change-Id: I01bfab595c50582c5adf958dcecbd58524dbc28f Reviewed-on: https://go-review.googlesource.com/28212 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
