- 07 Nov, 2017 3 commits
-
-
Than McIntosh authored
A couple of the CPU profiling testpoints make calls to helper functions (cpuHog1, for example) where the computed value is always thrown away by the caller without being used. A smart compiler back end (in this case LLVM) can detect this fact and delete the contents of the called function, which can cause tests to fail. Harden the test slighly by passing in a value read from a global and insuring that the caller stores the value back to a global; this prevents any optimizer mischief. Change-Id: Icbd6e3e32ff299c68a6397dc1404a52b21eaeaab Reviewed-on: https://go-review.googlesource.com/76230 Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Russ Cox authored
Fixes #21309. Change-Id: I8ff1b0f37e34a3a4e9f8448d66a64fe3863d081f Reviewed-on: https://go-review.googlesource.com/76250 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
The package source dir is recorded in the archives, so it must be recorded in the build action hash too. Fixes #22596. Change-Id: I1d3c2523181c302e9917e5fb79c26b00ea03077a Reviewed-on: https://go-review.googlesource.com/76025 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
- 06 Nov, 2017 26 commits
-
-
griesemer authored
Be more pessimistic when parsing if/switch/for headers for better error messages when things go wrong. Fixes #22581. Change-Id: Ibb99925291ff53f35021bc0a59a4c9a7f695a194 Reviewed-on: https://go-review.googlesource.com/76290 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Carlos Eduardo Seo authored
This change adds a better implementation of IndexByte in asm that uses the vector registers/instructions on ppc64x. benchmark old ns/op new ns/op delta BenchmarkIndexByte/10-8 9.70 9.37 -3.40% BenchmarkIndexByte/32-8 10.9 10.9 +0.00% BenchmarkIndexByte/4K-8 254 92.8 -63.46% BenchmarkIndexByte/4M-8 249246 118435 -52.48% BenchmarkIndexByte/64M-8 10737987 7383096 -31.24% benchmark old MB/s new MB/s speedup BenchmarkIndexByte/10-8 1030.63 1067.24 1.04x BenchmarkIndexByte/32-8 2922.69 2928.53 1.00x BenchmarkIndexByte/4K-8 16065.95 44156.45 2.75x BenchmarkIndexByte/4M-8 16827.96 35414.21 2.10x BenchmarkIndexByte/64M-8 6249.67 9089.53 1.45x Change-Id: I81dbdd620f7bb4e395ce4d1f2a14e8e91e39f9a1 Reviewed-on: https://go-review.googlesource.com/71710 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
-
Joe Tsai authored
The NonUTF8 field provides users with a way to explictly tell the ZIP writer to avoid setting the UTF-8 flag. This is necessary because many readers: 1) (Still) do not support UTF-8 2) And use the local system encoding instead Thus, even though character encodings other than CP-437 and UTF-8 are not officially supported by the ZIP specification, pragmatically the world has permitted use of them. When a non-standard encoding is used, it is the user's responsibility to ensure that the target system is expecting the encoding used (e.g., producing a ZIP file you know is used on a Chinese version of Windows). We adjust the detectUTF8 function to account for Shift-JIS and EUC-KR not being identical to ASCII for two characters. We don't need an API for users to explicitly specify that they are encoding with UTF-8 since all single byte characters are compatible with all other common encodings (Windows-1256, Windows-1252, Windows-1251, Windows-1250, IEC-8859, EUC-KR, KOI8-R, Latin-1, Shift-JIS, GB-2312, GBK) except for the non-printable characters and the backslash character (all of which are invalid characters in a path name anyways). Fixes #10741 Change-Id: I9004542d1d522c9137973f1b6e2b623fa54dfd66 Reviewed-on: https://go-review.googlesource.com/75592 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Emmanuel Odeke authored
Updates #21317 @mdempsky fixed issue #21317 with CL 66810, so lock a test in to ensure we don't regress. The test is manual for now before test/run.go has support for matching column numbers so do it old school and match expected output after an exec. Change-Id: I6c2a66ddf04248f79d17ed7033a3280d50e41562 Reviewed-on: https://go-review.googlesource.com/76150 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Currently, assigning a []T where T is a go:notinheap type generates an unnecessary write barrier for storing the slice pointer. This fixes this by teaching HasHeapPointer that this type does not have a heap pointer, and tweaking the lowering of slice assignments so the pointer store retains the correct type rather than simply lowering it to a *uint8 store. Change-Id: I8bf7c66e64a7fefdd14f2bd0de8a5a3596340bab Reviewed-on: https://go-review.googlesource.com/76027 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
Fixes #22599. Change-Id: I2d59a8fae457881f681184fc6ed1f2aa597699b3 Reviewed-on: https://go-review.googlesource.com/76026 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
The cache will take care of keeping go test -tags lldb fast. Installing runtime/cgo this way just makes all the checkNotStale tests think runtime/cgo is out of date. Should fix ios builders. Fixes #22509. Change-Id: If092cc4feb189eb848b6a22f6d22b89b70df219c Reviewed-on: https://go-review.googlesource.com/76020 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
The change in cmd/dist ignores debug output, instead of assuming any output is from the template. The change in cmd/go makes the debug output show the package name on every line, so that interlaced prints can be deinterlaced. Change-Id: Ic3d59ee0256271067cb9be2fde643a0e19405375 Reviewed-on: https://go-review.googlesource.com/76019 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
Even though cmd/dist has historically distinguished "CC for gohostos/gohostarch" from "CC for target goos/goarch", it has not recorded that distinction for later use by cmd/cgo and cmd/go. Now that content-based staleness includes the CC setting in the decision about when to rebuild packages, the go command needs to know the details of which CC to use when. Otherwise lots of things look out of date and (worse) may be rebuilt with the wrong CC. A related issue is that users may want to be able to build a toolchain capable of cross-compiling for two different non-host targets, and to date we've required that CC_FOR_TARGET apply to both. This CL introduces CC_FOR_${GOOS}_${GOARCH}, so that you can (for example) set CC_FOR_linux_arm and CC_FOR_linux_arm64 separately on a linux/ppc64 host and be able to cross-compile to either arm or arm64 with the right toolchain. Fixes #8161. Half of a fix for #22509. Change-Id: I7a43769f39d859f659d31bc96980918ba102fb83 Reviewed-on: https://go-review.googlesource.com/76018 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
There are multiple valid reasons a tool might print to stderr. As long as we get the expected output on stdout, that's fine. Fixes #22588. Change-Id: I9c5d32da08288cb26dd575530a8257cd5f375367 Reviewed-on: https://go-review.googlesource.com/76017 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
Clearly -a means don't use the cache. An oversight that it did. Fixes #22586. Change-Id: I250b351439bd3fb5f8d6efc235b614f0a75ca64c Reviewed-on: https://go-review.googlesource.com/76016 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
This was a hack to make a new make.bash avoid reusing installed packages. The new content-based staleness is precise enough not to need this hack; now it's just causing unnecessary rebuilds: if a package doesn't import "runtime", for example, it doesn't need to be recompiled when runtime changes. (It does need to be relinked, and we still arrange that.) Change-Id: I4ddf6e16d754cf21b16e9db1ed52bddbf82e96c6 Reviewed-on: https://go-review.googlesource.com/76015 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Cherry Zhang authored
I thought SSA check was enabled for those tests, but in fact it was not. Enable it. So we have SSA check on for at least some tests on all architectures. Updates #22499. Change-Id: I51fcdda3af7faab5aeb33bf46c6db309285ce42c Reviewed-on: https://go-review.googlesource.com/76024Reviewed-by: Keith Randall <khr@golang.org>
-
Joe Tsai authored
The ModifiedTime and ModifiedDate fields are not expressive enough for many of the time extensions that have since been added to ZIP, nor are they easy to access since they in a legacy MS-DOS format, and must be set and retrieved via the SetModTime and ModTime methods. Instead, we add new field Modified of time.Time type that contains all of the previous information and more. Support for extended timestamps have been attempted before, but the change was reverted because it provided no ability for the user to specify the timezone of the legacy MS-DOS fields. Technically the old API did not either, but users were manually offsetting the timestamp to achieve the same effect. The Writer now writes the legacy timestamps according to the timezone of the FileHeader.Modified field. When the Modified field is set via the SetModTime method, it is in UTC, which preserves the old behavior. The Reader attempts to determine the timezone if both the legacy and extended timestamps are present since it can compute the delta between the two values. Since Modified is a superset of the information in ModifiedTime and ModifiedDate, we mark ModifiedTime, ModifiedDate, ModTime, and SetModTime as deprecated. Fixes #18359 Change-Id: I29c6bc0a62908095d02740df3e6902f50d3152f1 Reviewed-on: https://go-review.googlesource.com/74970 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Caleb Spare authored
This is like a write-only subset of bytes.Buffer with an allocation-free String method. Fixes #18990. Change-Id: Icdf7240f4309a52924dc3af04a39ecd737a210f4 Reviewed-on: https://go-review.googlesource.com/74931 Run-TryBot: Caleb Spare <cespare@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Radek Sohlich authored
The simple example would contribute to better understanding what function does. Change-Id: I36a2952df8b0e1762ec0cd908a867c457f39366e Reviewed-on: https://go-review.googlesource.com/75970Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tim Wright authored
The existing NaCl filesystem Link system call erroneously allowed a caller to call Link on an existing target which violates the POSIX standard and effectively corrupted the internal filesystem representation. Fixes #22383 Change-Id: I77b16c37af9bf00a1799fa84277f066180edac47 Reviewed-on: https://go-review.googlesource.com/76110Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Filippo Valsorda authored
Change-Id: I22a67733aa2d07298e124077654c9b1473802100 Reviewed-on: https://go-review.googlesource.com/76012Reviewed-by: Aliaksandr Valialkin <valyala@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
If the only thing changing in the binary is the embedded main.a action ID, go install was declining to install the binary, but go list could see that the binary needed reinstalling (was stale). Fixes #22531. Change-Id: I4a53b0ebd4c34aad907bab7da571fada545f3c6f Reviewed-on: https://go-review.googlesource.com/76014 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
I do not remember why we require deps.go to have a hard-coded copy of the dependency information for cmd/go, when we can read it from the source files instead. The answer probably involves cmd/dist once being a C program. In any event, stop doing that, which will eliminate the builder-only failures in the builder-only deps test. Change-Id: I0abd384c47401940ca08427b5be544812edcbe7f Reviewed-on: https://go-review.googlesource.com/76021 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
I typed 'go list -josn' without realizing I'd mistyped json, and I was confused for quite a while as to why I was staring at the 'go help json' text: the actual problem (a missing flag) scrolls far off the screen. If people want the full text, they can easily ask for it, but don't drown the important bit - unrecognized flag or other improper usage - with pages of supporting commentary. The help text does not help people who just need to be told about a typo. Change-Id: I179c431baa831e330f3ee495ce0a5369319962d5 Reviewed-on: https://go-review.googlesource.com/76013 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Emmanuel Odeke authored
Updates #22389 @mdempsky's CL 70850 fixed the unnecessary compile stack trace printing during ICE diagnostics. This CL adds a test to lock in this behavior. Change-Id: I9ce49923c80b78cb8c0bb5dc4af3c860a43d63ba Reviewed-on: https://go-review.googlesource.com/74630 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Michael Munday authored
Adds support for the cipher message with authentication (KMA) instruction added in message-security-assist extension 8. This instruction encapsulates most of the operations required for AES-GCM and is faster than executing the operations independently. name old speed new speed delta AESGCMSeal1K 1.96GB/s ± 0% 6.79GB/s ± 0% +246.47% (p=0.000 n=8+10) AESGCMOpen1K 1.85GB/s ± 0% 5.76GB/s ± 0% +211.18% (p=0.000 n=10+10) AESGCMSign8K 12.0GB/s ± 0% 14.5GB/s ± 0% +20.43% (p=0.000 n=10+8) AESGCMSeal8K 3.75GB/s ± 0% 14.16GB/s ± 0% +277.57% (p=0.000 n=9+10) AESGCMOpen8K 3.70GB/s ± 0% 13.57GB/s ± 0% +266.50% (p=0.000 n=10+9) Change-Id: I57c46573fc5a0bd63c32ce5cba6e37cab85e3de6 Reviewed-on: https://go-review.googlesource.com/73550 Run-TryBot: Michael Munday <mike.munday@ibm.com> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Volodymyr Paprotski <paprots@gmail.com> Reviewed-by: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
On Plan 9, some file servers, like ramfs, handle the read offset when reading directories. However, the offset isn't valid anymore after directory entries have been removed between successive calls to read. This issue happens when os.RemoveAll is called on a directory that doesn't fit on a single 9P response message. In this case, the first part of the directory is read, then directory entries are removed and the second read will be incomplete because the read offset won't be valid anymore. Consequently, the content of the directory will only be partially removed. We change RemoveAll to call fd.Seek(0, 0) before calling fd.Readdirnames, so the read offset will always be reset after removing the directory entries. After adding TestRemoveAllLarge, we noticed the same issue appears on NaCl and the same fix applies as well. Fixes #22572. Change-Id: Ifc76ea7ccaf0168c34dc8ec0f400dc04db1baf8f Reviewed-on: https://go-review.googlesource.com/75974 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Anmol Sethi authored
If the current time is equal to the NextUpdate time, then the CRL should be considered expired. Fixes #22568. Change-Id: I55bcc95c881097e826d43eb816a43b9b377b0265 Reviewed-on: https://go-review.googlesource.com/71972Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Filippo Valsorda <hi@filippo.io> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Paul Querna authored
Fixes #21105 Change-Id: Ia2dea9b82a356795f581ce75616198b46e97abb6 Reviewed-on: https://go-review.googlesource.com/75253 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
- 05 Nov, 2017 5 commits
-
-
Keith Randall authored
Use internal/testenv package to get the right go binary. Otherwise, I think we're just grabbing an old one from the environment. Fixes #22560. Change-Id: Id5b743b24717e15ec8ffbcfae4dc3e5f6a87b9a9 Reviewed-on: https://go-review.googlesource.com/76090 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: David Chase <drchase@google.com>
-
Daniel Martí authored
Otherwise, one can't run "go fmt" on a directory containing Go files if none of them are buildable (e.g. because of build tags). This is counter-intuitive, as fmt will format all Go files anyway. If we encounter such a load error, ignore it and carry on. All other load errors, such as when a package can't be found, should still be shown to the user. Add a test for the two kinds of load errors. Use fmt -n so that any changes to the formatting of the files in testdata don't actually get applied. The load errors still occur with -n, so the test does its job. Fixes #22183. Change-Id: I99d0c0cdd29015b6a3f5286a9bbff50757c78e0d Reviewed-on: https://go-review.googlesource.com/75930 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
David Chase authored
A statement like foo = bar + qux might compile to AX := AX + BX resulting in a regkill for AX before this instruction. The buggy behavior is to kill AX "at" this instruction, before it has executed. (Code generation of no-instruction values like RegKills applies their effects at the next actual instruction emitted). However, bar is still associated with AX until after the instruction executes, so the effect of the regkill must occur at the boundary between this instruction and the next. Similarly, the new value bound to AX is not visible until this instruction executes (and in the case of values that require multiple instructions in code generation, until all of them have executed). The ranges are adjusted so that a value's start occurs at the next following instruction after its evaluation, and the end occurs after (execution of) the first instruction following the end of the lifetime as a value. (Notice the asymmetry; the entire value must be finished before it is visible, but execution of a single instruction invalidates. However, the value *is* visible before that next instruction executes). The test was adjusted to make it insensitive to the result numbering for variables printed by gdb, since that is not relevant to the test and makes the differences introduced by small changes larger than necessary/useful. The test was also improved to present variable probes more intuitively, and also to allow explicit indication of "this variable was optimized out" Change-Id: I39453eead8399e6bb05ebd957289b112d1100c0e Reviewed-on: https://go-review.googlesource.com/74090 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
David Chase authored
For structs, slices, strings, interfaces, etc, propagation of names to their components (e.g., complex.real, complex.imag) is fragile (depends on phase ordering) and not done right for the "dec" pass. The dec pass is subsumed into decomposeBuiltin, and then names are pushed into the args of all OpFooMake opcodes. compile/ssa/debug_test.go was fixed to pay attention to variable values, and the reference files include checks for the fixes in this CL (which make debugging better). Change-Id: Ic2591ebb1698d78d07292b92c53667e6c37fa0cd Reviewed-on: https://go-review.googlesource.com/73210 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Hugues Bruant authored
When inlining a closure with captured variables, walk up the param chain to find the one that is defined inside the scope into which the function is being inlined, and map occurrences of the captures to temporary inlvars, similarly to what is done for function parameters. No noticeable impact on compilation speed and binary size. Minor improvements to go1 benchmarks on darwin/amd64 name old time/op new time/op delta BinaryTree17-4 2.59s ± 3% 2.58s ± 1% ~ (p=0.470 n=19+19) Fannkuch11-4 3.15s ± 2% 3.15s ± 1% ~ (p=0.647 n=20+19) FmtFprintfEmpty-4 43.7ns ± 3% 43.4ns ± 4% ~ (p=0.178 n=18+20) FmtFprintfString-4 74.0ns ± 2% 77.1ns ± 7% +4.13% (p=0.000 n=20+20) FmtFprintfInt-4 77.2ns ± 3% 79.2ns ± 6% +2.53% (p=0.000 n=20+20) FmtFprintfIntInt-4 112ns ± 4% 112ns ± 2% ~ (p=0.672 n=20+19) FmtFprintfPrefixedInt-4 136ns ± 1% 135ns ± 2% ~ (p=0.827 n=16+20) FmtFprintfFloat-4 232ns ± 2% 233ns ± 1% ~ (p=0.194 n=20+20) FmtManyArgs-4 490ns ± 2% 484ns ± 2% -1.28% (p=0.001 n=20+20) GobDecode-4 6.68ms ± 2% 6.72ms ± 2% ~ (p=0.113 n=20+19) GobEncode-4 5.62ms ± 2% 5.71ms ± 2% +1.64% (p=0.000 n=20+19) Gzip-4 235ms ± 3% 236ms ± 2% ~ (p=0.607 n=20+19) Gunzip-4 37.1ms ± 2% 36.8ms ± 3% ~ (p=0.060 n=20+20) HTTPClientServer-4 61.9µs ± 2% 62.7µs ± 4% +1.24% (p=0.007 n=18+19) JSONEncode-4 12.5ms ± 2% 12.4ms ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 51.6ms ± 3% 51.0ms ± 3% -1.19% (p=0.008 n=20+19) Mandelbrot200-4 4.12ms ± 6% 4.06ms ± 5% ~ (p=0.063 n=20+20) GoParse-4 3.12ms ± 5% 3.10ms ± 2% ~ (p=0.402 n=19+19) RegexpMatchEasy0_32-4 80.7ns ± 2% 75.1ns ± 9% -6.94% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 197ns ± 2% 186ns ± 2% -5.43% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 77.5ns ± 4% 71.9ns ± 7% -7.25% (p=0.000 n=20+18) RegexpMatchEasy1_1K-4 341ns ± 3% 341ns ± 3% ~ (p=0.732 n=20+20) RegexpMatchMedium_32-4 113ns ± 2% 112ns ± 3% ~ (p=0.102 n=20+20) RegexpMatchMedium_1K-4 36.6µs ± 2% 35.8µs ± 2% -2.26% (p=0.000 n=18+20) RegexpMatchHard_32-4 1.75µs ± 3% 1.74µs ± 2% ~ (p=0.473 n=20+19) RegexpMatchHard_1K-4 52.6µs ± 2% 52.0µs ± 3% -1.15% (p=0.005 n=20+20) Revcomp-4 381ms ± 4% 377ms ± 2% ~ (p=0.067 n=20+18) Template-4 57.3ms ± 2% 57.7ms ± 2% ~ (p=0.108 n=20+20) TimeParse-4 291ns ± 3% 292ns ± 2% ~ (p=0.585 n=20+20) TimeFormat-4 314ns ± 3% 315ns ± 1% ~ (p=0.681 n=20+20) [Geo mean] 47.4µs 47.1µs -0.73% name old speed new speed delta GobDecode-4 115MB/s ± 2% 114MB/s ± 2% ~ (p=0.115 n=20+19) GobEncode-4 137MB/s ± 2% 134MB/s ± 2% -1.63% (p=0.000 n=20+19) Gzip-4 82.5MB/s ± 3% 82.4MB/s ± 2% ~ (p=0.612 n=20+19) Gunzip-4 523MB/s ± 2% 528MB/s ± 3% ~ (p=0.060 n=20+20) JSONEncode-4 155MB/s ± 2% 156MB/s ± 3% ~ (p=0.192 n=20+20) JSONDecode-4 37.6MB/s ± 3% 38.1MB/s ± 3% +1.21% (p=0.007 n=20+19) GoParse-4 18.6MB/s ± 4% 18.7MB/s ± 2% ~ (p=0.405 n=19+19) RegexpMatchEasy0_32-4 396MB/s ± 2% 426MB/s ± 8% +7.56% (p=0.000 n=17+20) RegexpMatchEasy0_1K-4 5.18GB/s ± 2% 5.48GB/s ± 2% +5.79% (p=0.000 n=20+20) RegexpMatchEasy1_32-4 413MB/s ± 4% 444MB/s ± 6% +7.46% (p=0.000 n=20+19) RegexpMatchEasy1_1K-4 3.00GB/s ± 3% 3.00GB/s ± 3% ~ (p=0.678 n=20+20) RegexpMatchMedium_32-4 8.82MB/s ± 2% 8.90MB/s ± 3% +0.99% (p=0.044 n=20+20) RegexpMatchMedium_1K-4 28.0MB/s ± 2% 28.6MB/s ± 2% +2.32% (p=0.000 n=18+20) RegexpMatchHard_32-4 18.3MB/s ± 3% 18.4MB/s ± 2% ~ (p=0.482 n=20+19) RegexpMatchHard_1K-4 19.5MB/s ± 2% 19.7MB/s ± 3% +1.18% (p=0.004 n=20+20) Revcomp-4 668MB/s ± 4% 674MB/s ± 2% ~ (p=0.066 n=20+18) Template-4 33.8MB/s ± 2% 33.6MB/s ± 2% ~ (p=0.104 n=20+20) [Geo mean] 124MB/s 126MB/s +1.54% Updates #15561 Updates #18270 Change-Id: I980086efe28b36aa27f81577065e2a729ff03d4e Reviewed-on: https://go-review.googlesource.com/72490Reviewed-by: Hugues Bruant <hugues.bruant@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 04 Nov, 2017 6 commits
-
-
Keith Randall authored
This test was taking too long on ppc64x. There were a few reasons. The first is that the page size on ppc64x is 64k instead of 4k. That's 16x more work. The second is that the generic Index is pretty bad in this case. It first calls IndexByte which does a bunch of setup work only to find the byte we're looking for at index 0. Then it calls Equal which has to look at the whole string to find a difference on the last byte. To fix, just limit our attention to near the end of the page. Change-Id: I6b8bcbb94652a2da853862acc23803def0c49303 Reviewed-on: https://go-review.googlesource.com/76050 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Alberto Donizetti authored
This change adds code generation tests for multiplication by ±2ⁿ for arm and arm64, in preparation for a future CL which will remove the relevant architecture-specific SSA rules (the reduction is already performed by rules in generic.rules added in CL 36323). Change-Id: Iebdd5c3bb2fc632c85888569ff0c49f78569a862 Reviewed-on: https://go-review.googlesource.com/75752Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Alex Brainman authored
This makes the output they print refer to the code that called them. For example, instead of === RUN TestWindowsStackMemoryCgo --- SKIP: TestWindowsStackMemoryCgo (0.00s) testenv.go:213: skipping known flaky test ... PASS we see === RUN TestWindowsStackMemoryCgo --- SKIP: TestWindowsStackMemoryCgo (0.00s) crash_cgo_test.go:471: skipping known flaky test ... PASS Change-Id: I5f4c77c3aeab5c0e43c6dde2f15db70a6df24603 Reviewed-on: https://go-review.googlesource.com/76031Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Leigh McCulloch authored
The go repository contains a mix of github.com/golang/go/issues/xxxxx and golang.org/issues/xxxxx URLs for references to issues in the issue tracker. We should use one for consistency, and golang.org is preferred in case the project moves the issue tracker in the future. This reasoning is taken from a comment Sam Whited left on a CL I recently opened: https://go-review.googlesource.com/c/go/+/73890. In that CL I referenced an issue using its github.com URL, because other tests in the file I was changing contained references to issues using their github.com URL. Sam Whited left a comment on the CL stating I should change it to the golang.org URL. If new code is intended to reference issues via golang.org and not github.com, existing code should be updated so that precedence exists for contributors who are looking at the existing code as a guide for the code they should write. Change-Id: I3b9053fe38a1c56fc101a8b7fd7b8f310ba29724 Reviewed-on: https://go-review.googlesource.com/75673Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Tim Cooper authored
Example usage of functionality implemented in CL 66710. Change-Id: I87d6e4d2fb7a60e4ba1e6ef02715480eb7e8f8bd Reviewed-on: https://go-review.googlesource.com/76011 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alex Brainman authored
Updates #22575 Change-Id: I1f848768934b7024d2ef01db13b9003e9ca608a0 Reviewed-on: https://go-review.googlesource.com/76030Reviewed-by: Russ Cox <rsc@golang.org>
-