- 01 Sep, 2016 4 commits
-
-
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: Keith Randall <khr@golang.org>
-
Robert Griesemer authored
See the issue below for details. Fixes #16794. Change-Id: I7e338089fd80ddcb634fa80bfc658dee2772361c Reviewed-on: https://go-review.googlesource.com/27356Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
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: Andrew Gerrand <adg@golang.org>
-
- 31 Aug, 2016 21 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: Brad Fitzpatrick <bradfitz@golang.org>
-
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: Ian Lance Taylor <iant@golang.org>
-
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: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
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: David Chase <drchase@google.com>
-
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: Josh Bleecher Snyder <josharian@gmail.com>
-
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: Brad Fitzpatrick <bradfitz@golang.org>
-
Kevin Burke authored
Change-Id: I47e3cfa8b49e3d0b55c91387df31488b37038a8f Reviewed-on: https://go-review.googlesource.com/28225Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
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: Keith Randall <khr@golang.org>
-
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: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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: Keith Randall <khr@golang.org>
-
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: Keith Randall <khr@golang.org>
-
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: Ian Lance Taylor <iant@golang.org>
-
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: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
In the event of an unexpected error, we should always flush available decompressed data to the user. Fixes #16924 Change-Id: I0bc0824c3201f3149e84e6a26e3dbcba72a1aae5 Reviewed-on: https://go-review.googlesource.com/28216 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
Change-Id: I0a3726f841122643bd1680ef6bd450c2039f362b Reviewed-on: https://go-review.googlesource.com/28213Reviewed-by: Rob Pike <r@golang.org>
-
Brad Fitzpatrick authored
As @pmarks-net said in the bug, this is something of a prisoner's dilemma, but it does help people who occasionally report problems. This is temporary. IPv6 is happening regardless of our decision here, so we'll do this for now. Fixes #15324 Change-Id: I8cc29c6efa56222970996c71182fc9ee89d78539 Reviewed-on: https://go-review.googlesource.com/28077 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Bryan Alexander authored
Fix bug in UnknownAuthorityError.Error that would never allow Org Name to be inserted into error message if the Common Name was empty. Create tests for all three paths in UnknownAuthorityError.Error Change-Id: Id8afc444e897ef549df682d93a8563fd9de22a2b Reviewed-on: https://go-review.googlesource.com/27992 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 30 Aug, 2016 15 commits
-
-
Josh Bleecher Snyder authored
Change-Id: I37706ff0a3486827c5b072c95ad890ea87ede847 Reviewed-on: https://go-review.googlesource.com/28210 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
On ARM64, MIPS64, and PPC64, some floating point registers were reserved for constants 0, 1, 2, 0.5, etc. This CL removes them. On ARM64, they are never used. On MIPS64 and PPC64, the only use case is a multiplication-by-2 in the old backend of the compiler, which is replaced with an addition. Change-Id: I737cbf43283756e3408964fc88c567a938c57036 Reviewed-on: https://go-review.googlesource.com/28095 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
Recognize runtime.newobject and don't Zero or NilCheck it. Fixes #15914 (?) Updates #15390. TBD: add test Change-Id: Ia3bfa5c2ddbe2c27c92d9f68534a713b5ce95934 Reviewed-on: https://go-review.googlesource.com/27930 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Keith Randall authored
This change makes sure that tests are run with the correct version of the go tool. The correct version is the one that we invoked with "go test", not the one that is first in our path. Fixes #16577 Change-Id: If22c8f8c3ec9e7c35d094362873819f2fbb8559b Reviewed-on: https://go-review.googlesource.com/28089Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Use terms like "equal" and "identical types" to match the Go spec, rather than inventing a new explanation. See also discussion on golang.org/cl/27170. Updates #16348. Change-Id: I0fe0bd01c0d1da3c8937a579c2ba44cf1eb16b71 Reviewed-on: https://go-review.googlesource.com/28054Reviewed-by: Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Change-Id: I2d01f692ae30a166079976b86bf0b7a439f05d5c Reviewed-on: https://go-review.googlesource.com/28178 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Fixes C compiler warning: ./main.go:54:1: warning: control reaches end of non-void function [-Wreturn-type] Should help fix the linux builders that broke due to CL 23005. Change-Id: Ib0630798125e35a12f99d666b7ffe7b3196f0ecc Reviewed-on: https://go-review.googlesource.com/28176 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
It's only needed for a check that can be pushed up into bimport.go, where it makes more sense anyway. Change-Id: I6ef381ff4f29627b0f390ce27fef08902932bea6 Reviewed-on: https://go-review.googlesource.com/28177 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Change-Id: Icb1671187d70edd962e2bda2cc45771b17a8e770 Reviewed-on: https://go-review.googlesource.com/28175 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Change-Id: Idd3e677dec00eb36a2cf7baa34e772335e1f2bc8 Reviewed-on: https://go-review.googlesource.com/28173 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Consider a switch statement like: switch x { case 1: // ... case 2, 3, 4, 5, 6: // ... case 5: // ... } Prior to this CL, the generated code treated 2, 3, 4, 5, and 6 independently in a binary search. With this CL, the generated code checks whether 2 <= x && x <= 6. walkinrange then optimizes that range check into a single unsigned comparison. Experiments suggest that the best min range size is 2, using binary size as a proxy for optimization. Binary sizes before/after this CL: cmd/compile: 14209728 / 14165360 cmd/go: 9543100 / 9539004 Change-Id: If2f7fb97ca80468fa70351ef540866200c4c996c Reviewed-on: https://go-review.googlesource.com/26770 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
This is a follow-up to the discussion in CL 27853. During make.bash, trigger count: 24 rewrite generic.rules:57 22 rewrite generic.rules:69 10 rewrite generic.rules:54 10 rewrite generic.rules:58 10 rewrite generic.rules:67 7 rewrite generic.rules:66 4 rewrite generic.rules:59 3 rewrite generic.rules:50 3 rewrite generic.rules:51 3 rewrite generic.rules:52 1 rewrite generic.rules:64 Change-Id: Id96cb6a707a4a564831f763c2d4d0e180c94bbef Reviewed-on: https://go-review.googlesource.com/28088 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Martin Möhrmann <martisch@uos.de>
-
Matthew Dempsky authored
These were a hack abstraction for before FuncType existed. The result value from calling FuncType() could be saved, but this maintains the current idiom of consistently using t.FuncType().foo everywhere in case we choose to evolve the API further. Change-Id: I81f19aaeab6fb7caa2d4da8bf0bbbc358ab970d0 Reviewed-on: https://go-review.googlesource.com/28150 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Hiroshi Ioka authored
Current code assumes there are not ".." in the Clean(path). That's not true. Clean doesn't handle leading "..", so we need to stop normalization if we see "..". Fixes #16793 Change-Id: I0a7901bedac17f1210b134d593ebd9f5e8483775 Reviewed-on: https://go-review.googlesource.com/27410Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Change-Id: I6c48683b620b0f119d7f0ae4a88502773202756b Reviewed-on: https://go-review.googlesource.com/28170Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-