- 30 Mar, 2017 15 commits
-
-
David du Colombier authored
TestDWARF has been added in CL 38855. This test is failing on Plan 9 because executables don't have a DWARF symbol table. Fixes #19793. Change-Id: I7fc547a7c877b58cc4ff6b4eb5b14852e8b4668b Reviewed-on: https://go-review.googlesource.com/38931 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
Even very large Types are not very big. The haspointer cache looks like premature optimization. Removing them has no detectable compiler performance impact, and it removes mutable shared state used by the backend. Updates #15756 Change-Id: I2d2cf03f470f5eef5bcd50ff693ef6a01d481700 Reviewed-on: https://go-review.googlesource.com/38912 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Egon Elbre authored
Flush file content to disk before diffing files, may cause unpredictable results on Windows. Convert from \r\n to \n when comparing diff result. Change-Id: Ibcd6154a2382dba1338ee5674333611aea16bb65 Reviewed-on: https://go-review.googlesource.com/36750Reviewed-by:
Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org>
-
Ben Shi authored
REV/REV16/REVSH were introduced in ARMv6, they offered more efficient byte reverse operatons. MMUL/MMULA/MMULS were introduced in ARMv6, they simplified a serial of mul->shift->add/sub operations into a single instruction. RBIT was introduced in ARMv7, it inversed a 32-bit word's bit order. MULS was introduced in ARMv7, it corresponded to MULA. MULBB/MULABB were introduced in ARMv5TE, they performed 16-bit multiplication (and accumulation). Change-Id: I6365b17b3c4eaf382a657c210bb0094b423b11b8 Reviewed-on: https://go-review.googlesource.com/35565 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
100% code movement. Change-Id: Idb51c61b7363229258a3b48045e901bea68c7a85 Reviewed-on: https://go-review.googlesource.com/38911 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I162e86e5f92c8b827a74ee860d16abadf83bc43e Reviewed-on: https://go-review.googlesource.com/38910 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Josh Bleecher Snyder authored
CL 38147 eliminated package gc globals in formatting routines. However, tconv still used the Type field Trecur to avoid infinite recursion when formatting recursive interfaces types such as (test/fixedbugs398.go): type i1 interface { F() interface { i1 } } type i2 interface { F() interface { i2 } } This CL changes the recursion prevention to use a parameter, and threads it through the formatting routines. Because this fundamentally limits the embedding depth of all types, it sets the depth limit to be much higher. In practice, it is unlikely to impact any code at all, one way or the other. The remaining uses of Type.Trecur are boolean in nature. A future CL will change Type.Trecur to be a boolean flag. The removal of a couple of mode.Sprintf calls makes this a very minor net performance improvement: name old alloc/op new alloc/op delta Template 40.0MB ± 0% 40.0MB ± 0% -0.13% (p=0.032 n=5+5) Unicode 30.0MB ± 0% 29.9MB ± 0% ~ (p=0.310 n=5+5) GoTypes 114MB ± 0% 113MB ± 0% -0.25% (p=0.008 n=5+5) SSA 856MB ± 0% 855MB ± 0% -0.04% (p=0.008 n=5+5) Flate 25.5MB ± 0% 25.4MB ± 0% -0.27% (p=0.008 n=5+5) GoParser 31.9MB ± 0% 31.9MB ± 0% ~ (p=0.222 n=5+5) Reflect 79.0MB ± 0% 78.6MB ± 0% -0.45% (p=0.008 n=5+5) Tar 26.8MB ± 0% 26.7MB ± 0% -0.25% (p=0.032 n=5+5) XML 42.4MB ± 0% 42.4MB ± 0% ~ (p=0.151 n=5+5) name old allocs/op new allocs/op delta Template 395k ± 0% 391k ± 0% -1.00% (p=0.008 n=5+5) Unicode 321k ± 1% 319k ± 0% -0.56% (p=0.008 n=5+5) GoTypes 1.16M ± 0% 1.14M ± 0% -1.61% (p=0.008 n=5+5) SSA 7.63M ± 0% 7.60M ± 0% -0.30% (p=0.008 n=5+5) Flate 239k ± 0% 234k ± 0% -1.94% (p=0.008 n=5+5) GoParser 320k ± 0% 317k ± 1% -0.86% (p=0.008 n=5+5) Reflect 1.00M ± 0% 0.98M ± 0% -2.17% (p=0.016 n=4+5) Tar 255k ± 1% 251k ± 0% -1.35% (p=0.008 n=5+5) XML 398k ± 0% 395k ± 0% -0.89% (p=0.008 n=5+5) Updates #15756 Change-Id: Id23e647d347aa841f9a69d51f7d2d7d27b259239 Reviewed-on: https://go-review.googlesource.com/38797 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Russ Cox authored
Right now, at least with Xcode 8.3, we invoke dsymutil and dutifully copy what it produces back into the binary, but it has actually dropped all the DWARF information that we wanted, because it didn't like the look of go.o. Make it like the look of go.o. DWARF is tested in other ways, but typically indirectly and not for cgo programs. Add a direct test, and one that exercises cgo. This detects missing dwarf information in cgo-using binaries on macOS, at least with Xcode 8.3, and possibly earlier versions as well. Fixes #19772. Change-Id: I0082e52c0bc8fc4e289770ec3dc02f39fd61e743 Reviewed-on: https://go-review.googlesource.com/38855 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Josh Bleecher Snyder authored
Place comments correctly. Simplify control flow. Reduce variable scope. Passes toolstash-check. Change-Id: Iea47ed3502c15491c2ca6db8149fe0949b8849aa Reviewed-on: https://go-review.googlesource.com/38914 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Now that we no longer generate dead code, it is possible to follow block predecessors into infinite loops with no variable definitions, causing an infinite loop during phi insertion. To fix that, check explicitly whether the predecessor is dead in lookupVarOutgoing, and if so, bail. The loop in lookupVarOutgoing is very hot code, so I am wary of adding anything to it. However, a long, CPU-only benchmarking run shows no performance impact at all. Fixes #19783 Change-Id: I8ef8d267e0b20a29b5cb0fecd7084f76c6f98e47 Reviewed-on: https://go-review.googlesource.com/38913Reviewed-by:
David Chase <drchase@google.com>
-
Josh Bleecher Snyder authored
We use an "autogenerated" position in several places. Rather than recreate it each time, make one early on and reuse it. This removes the creation of new positions during the backend, which was not concurrency-safe. Updates #15756 Change-Id: Ic116b2e60f0e99de1a2ea87fe763831b50b645f8 Reviewed-on: https://go-review.googlesource.com/38915 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Russ Cox authored
Without this, the load fails during kernel exec, which results in the mysterious and completely uninformative "Killed: 9" error. It appears that the stars (or at least the inputs) were properly aligned with earlier versions of Xcode so that this happened accidentally. Make it happen on purpose. Gregory Man bisected the breakage to this change in LLVM, which fits the theory nicely: https://github.com/llvm-mirror/llvm/commit/9a41e59c Fixes #19734. Change-Id: Ice67a09af2de29d3c0d5e3fcde6a769580897c95 Reviewed-on: https://go-review.googlesource.com/38854 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Might as well provide a way around the mach-o munging that doesn't require stripping all symbols. After all, -w does mean no DWARF. For #11887, #19734, and anyone else that needs to disable this code path without losing the symbol table. Change-Id: I254b7539f97fb9211fa90f446264b383e7f3980f Reviewed-on: https://go-review.googlesource.com/38853 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
This keeps the host linker from printing ld: warning: option -s is obsolete and being ignored Fixes #19775. Change-Id: I18dd4e4b3f59cbf35dad770fd65e6baea5a7347f Reviewed-on: https://go-review.googlesource.com/38851 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alex Brainman authored
Change-Id: I6b6a6dc57e48e02ff0d452755b8dcf5543b3caed Reviewed-on: https://go-review.googlesource.com/38759Reviewed-by:
-
- 29 Mar, 2017 23 commits
-
-
Elias Naur authored
The gold linker is used by default in the Android NDK, except on arm64: https://github.com/android-ndk/ndk/issues/148 The Go linker already forces the use of the gold linker on arm and arm64 (CL 22141) for other reasons. However, the test.bash script in testcshared doesn't, resulting in linker errors on android/arm64: warning: liblog.so, needed by ./libgo.so, not found (try using -rpath or -rpath-link) Add -fuse-ld=gold when running testcshared on Android. Fixes the android/arm64 builder. Change-Id: I35ca96f01f136bae72bec56d71b7ca3f344df1ed Reviewed-on: https://go-review.googlesource.com/38832 Run-TryBot: Elias Naur <elias.naur@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Caleb Spare authored
Change-Id: I31cfae1e98313b68e3bc8f49079491d2725a662b Reviewed-on: https://go-review.googlesource.com/38850Reviewed-by:
-
Ilya Tocar authored
After https://golang.org/cl/31490 we break false output dependency for CVTS.. in compiler generated code. I've looked through asm code, which uses CVTS.. and added XOR to the only case where it affected performance. Log-6 21.6ns ± 0% 19.9ns ± 0% -7.87% (p=0.000 n=10+10) Change-Id: I25d9b405e3041a3839b40f9f9a52e708034bb347 Reviewed-on: https://go-review.googlesource.com/38771 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Michael Munday authored
There is always 128 bytes available below the stackguard. Allow functions with medium-sized stack frames to use this, potentially allowing them to avoid growing the stack. This change makes all architectures use the same calculation as x86. Change-Id: I2afb1a7c686ae5a933e50903b31ea4106e4cd0a0 Reviewed-on: https://go-review.googlesource.com/38734Reviewed-by:
-
haya14busa authored
It reduces needless allocations on compiling onepass regex. Following CL 38750 name old time/op new time/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 5.75µs ± 1% 5.51µs ± 2% -4.25% (p=0.008 n=5+5) CompileOnepass/^abcd$-4 4.76µs ± 0% 4.52µs ± 1% -5.06% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a{0,})*?)$-4 5.56µs ± 0% 5.56µs ± 3% ~ (p=0.524 n=5+5) CompileOnepass/^(?:(?:a+)*)$-4 5.09µs ± 0% 5.15µs ± 5% ~ (p=0.690 n=5+5) CompileOnepass/^(?:(?:a|(?:aa)))$-4 6.53µs ± 0% 6.43µs ± 5% ~ (p=0.151 n=5+5) CompileOnepass/^(?:[^\s\S])$-4 4.05µs ± 1% 4.00µs ± 2% ~ (p=0.095 n=5+5) CompileOnepass/^(?:(?:(?:a*)+))$-4 5.47µs ± 0% 5.36µs ± 1% -1.91% (p=0.008 n=5+5) CompileOnepass/^[a-c]+$-4 4.13µs ± 1% 4.05µs ± 0% -2.07% (p=0.008 n=5+5) CompileOnepass/^[a-c]*$-4 4.59µs ± 2% 4.93µs ± 7% +7.30% (p=0.016 n=5+5) CompileOnepass/^(?:a*)$-4 4.67µs ± 1% 4.82µs ± 8% ~ (p=0.730 n=4+5) CompileOnepass/^(?:(?:aa)|a)$-4 6.43µs ± 1% 6.18µs ± 1% -3.91% (p=0.008 n=5+5) CompileOnepass/^...$-4 4.71µs ± 0% 4.31µs ± 1% -8.51% (p=0.008 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 6.37µs ± 0% 6.17µs ± 0% -3.23% (p=0.008 n=5+5) CompileOnepass/^a((b))c$-4 6.85µs ± 1% 6.50µs ± 1% -5.15% (p=0.008 n=5+5) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 6.99µs ± 1% 6.66µs ± 1% -4.81% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 6.15µs ± 1% 5.87µs ± 0% -4.57% (p=0.008 n=5+5) CompileOnepass/^a(?:(b)|(c))c$-4 8.62µs ± 1% 8.21µs ± 1% -4.77% (p=0.008 n=5+5) CompileOnepass/^a(?:b|c)$-4 5.76µs ±42% 4.42µs ± 1% -23.35% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c)$-4 7.17µs ± 6% 6.86µs ± 0% -4.39% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c+)$-4 8.08µs ± 2% 7.67µs ± 2% -4.97% (p=0.008 n=5+5) CompileOnepass/^a(?:bc)+$-4 5.53µs ± 3% 5.35µs ± 1% -3.34% (p=0.008 n=5+5) CompileOnepass/^a(?:[bcd])+$-4 5.08µs ± 1% 4.98µs ± 0% -2.02% (p=0.008 n=5+5) CompileOnepass/^a((?:[bcd])+)$-4 6.49µs ± 1% 6.29µs ± 1% -3.03% (p=0.008 n=5+5) CompileOnepass/^a(:?b|c)*d$-4 11.8µs ± 1% 11.4µs ± 3% -3.98% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 8.02µs ± 1% 7.54µs ± 1% -6.00% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 228µs ±18% 196µs ± 0% -14.02% (p=0.016 n=5+4) name old alloc/op new alloc/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 3.41kB ± 0% 3.38kB ± 0% -0.94% (p=0.008 n=5+5) CompileOnepass/^abcd$-4 2.75kB ± 0% 2.74kB ± 0% -0.29% (p=0.008 n=5+5) CompileOnepass/^(?:(?:a{0,})*?)$-4 3.34kB ± 0% 3.34kB ± 0% ~ (all equal) CompileOnepass/^(?:(?:a+)*)$-4 2.95kB ± 0% 2.95kB ± 0% ~ (all equal) CompileOnepass/^(?:(?:a|(?:aa)))$-4 3.75kB ± 0% 3.74kB ± 0% -0.43% (p=0.008 n=5+5) CompileOnepass/^(?:[^\s\S])$-4 2.46kB ± 0% 2.45kB ± 0% -0.49% (p=0.008 n=5+5) CompileOnepass/^(?:(?:(?:a*)+))$-4 3.13kB ± 0% 3.13kB ± 0% ~ (all equal) CompileOnepass/^[a-c]+$-4 2.48kB ± 0% 2.48kB ± 0% ~ (all equal) CompileOnepass/^[a-c]*$-4 2.52kB ± 0% 2.52kB ± 0% ~ (all equal) CompileOnepass/^(?:a*)$-4 2.63kB ± 0% 2.63kB ± 0% ~ (all equal) CompileOnepass/^(?:(?:aa)|a)$-4 3.64kB ± 0% 3.62kB ± 0% -0.44% (p=0.008 n=5+5) CompileOnepass/^...$-4 2.91kB ± 0% 2.87kB ± 0% -1.37% (p=0.008 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 3.64kB ± 0% 3.62kB ± 0% -0.44% (p=0.008 n=5+5) CompileOnepass/^a((b))c$-4 4.39kB ± 0% 4.38kB ± 0% -0.18% (p=0.008 n=5+5) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 4.32kB ± 0% 4.30kB ± 0% -0.56% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 4.06kB ± 0% 4.05kB ± 0% -0.39% (p=0.008 n=5+5) CompileOnepass/^a(?:(b)|(c))c$-4 5.31kB ± 0% 5.30kB ± 0% -0.15% (p=0.008 n=5+5) CompileOnepass/^a(?:b|c)$-4 2.88kB ± 0% 2.87kB ± 0% -0.28% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c)$-4 4.36kB ± 0% 4.35kB ± 0% -0.18% (p=0.008 n=5+5) CompileOnepass/^a(?:b?|c+)$-4 4.59kB ± 0% 4.58kB ± 0% -0.17% (p=0.008 n=5+5) CompileOnepass/^a(?:bc)+$-4 3.15kB ± 0% 3.15kB ± 0% ~ (all equal) CompileOnepass/^a(?:[bcd])+$-4 2.94kB ± 0% 2.94kB ± 0% ~ (all equal) CompileOnepass/^a((?:[bcd])+)$-4 4.09kB ± 0% 4.08kB ± 0% -0.20% (p=0.008 n=5+5) CompileOnepass/^a(:?b|c)*d$-4 6.15kB ± 0% 6.10kB ± 0% -0.78% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 4.47kB ± 0% 4.46kB ± 0% -0.36% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 135kB ± 0% 135kB ± 0% ~ (p=0.810 n=5+5) name old allocs/op new allocs/op delta CompileOnepass/^(?:(?:(?:.(?:$))?))...-4 49.0 ± 0% 47.0 ± 0% -4.08% (p=0.008 n=5+5) CompileOnepass/^abcd$-4 41.0 ± 0% 41.0 ± 0% ~ (all equal) CompileOnepass/^(?:(?:a{0,})*?)$-4 49.0 ± 0% 49.0 ± 0% ~ (all equal) CompileOnepass/^(?:(?:a+)*)$-4 44.0 ± 0% 44.0 ± 0% ~ (all equal) CompileOnepass/^(?:(?:a|(?:aa)))$-4 54.0 ± 0% 54.0 ± 0% ~ (all equal) CompileOnepass/^(?:[^\s\S])$-4 33.0 ± 0% 33.0 ± 0% ~ (all equal) CompileOnepass/^(?:(?:(?:a*)+))$-4 46.0 ± 0% 46.0 ± 0% ~ (all equal) CompileOnepass/^[a-c]+$-4 36.0 ± 0% 36.0 ± 0% ~ (all equal) CompileOnepass/^[a-c]*$-4 41.0 ± 0% 41.0 ± 0% ~ (all equal) CompileOnepass/^(?:a*)$-4 42.0 ± 0% 42.0 ± 0% ~ (all equal) CompileOnepass/^(?:(?:aa)|a)$-4 53.0 ± 0% 53.0 ± 0% ~ (all equal) CompileOnepass/^...$-4 43.0 ± 0% 39.0 ± 0% -9.30% (p=0.008 n=5+5) CompileOnepass/^(?:a|(?:aa))$-4 53.0 ± 0% 53.0 ± 0% ~ (all equal) CompileOnepass/^a((b))c$-4 53.0 ± 0% 53.0 ± 0% ~ (all equal) CompileOnepass/^a.[l-nA-Cg-j]?e$-4 58.0 ± 0% 56.0 ± 0% -3.45% (p=0.008 n=5+5) CompileOnepass/^a((b))$-4 47.0 ± 0% 47.0 ± 0% ~ (all equal) CompileOnepass/^a(?:(b)|(c))c$-4 65.0 ± 0% 65.0 ± 0% ~ (all equal) CompileOnepass/^a(?:b|c)$-4 40.0 ± 0% 40.0 ± 0% ~ (all equal) CompileOnepass/^a(?:b?|c)$-4 57.0 ± 0% 57.0 ± 0% ~ (all equal) CompileOnepass/^a(?:b?|c+)$-4 63.0 ± 0% 63.0 ± 0% ~ (all equal) CompileOnepass/^a(?:bc)+$-4 46.0 ± 0% 46.0 ± 0% ~ (all equal) CompileOnepass/^a(?:[bcd])+$-4 43.0 ± 0% 43.0 ± 0% ~ (all equal) CompileOnepass/^a((?:[bcd])+)$-4 49.0 ± 0% 49.0 ± 0% ~ (all equal) CompileOnepass/^a(:?b|c)*d$-4 105 ± 0% 101 ± 0% -3.81% (p=0.008 n=5+5) CompileOnepass/^.bc(d|e)*$-4 62.0 ± 0% 60.0 ± 0% -3.23% (p=0.008 n=5+5) CompileOnepass/^loooooooooooooooooo...-4 1.09k ± 0% 1.09k ± 0% ~ (all equal) Fixes #19735 Change-Id: Ib90e18e1b06166407b26b2a68b88afbb1f486024 Reviewed-on: https://go-review.googlesource.com/38751Reviewed-by: -
Cherry Zhang authored
In register allocation, we calculate what values are used in and after the current block. If a value is used only after a function call, since registers are clobbered in call, we don't need to mark the value live at the entrance of the block. Before this CL it is considered live, and unnecessary copy or load may be generated when resolving merge edge. Fixes #14761. On AMD64: name old time/op new time/op delta BinaryTree17-12 2.84s ± 1% 2.81s ± 1% -1.06% (p=0.000 n=10+9) Fannkuch11-12 3.61s ± 0% 3.55s ± 1% -1.77% (p=0.000 n=10+9) FmtFprintfEmpty-12 50.4ns ± 4% 50.0ns ± 1% ~ (p=0.785 n=9+8) FmtFprintfString-12 80.0ns ± 3% 78.2ns ± 3% -2.35% (p=0.004 n=10+9) FmtFprintfInt-12 81.3ns ± 4% 81.8ns ± 2% ~ (p=0.159 n=10+10) FmtFprintfIntInt-12 120ns ± 4% 118ns ± 2% ~ (p=0.218 n=10+10) FmtFprintfPrefixedInt-12 152ns ± 3% 155ns ± 2% +2.11% (p=0.026 n=10+10) FmtFprintfFloat-12 240ns ± 1% 238ns ± 1% -0.79% (p=0.005 n=9+9) FmtManyArgs-12 504ns ± 1% 510ns ± 1% +1.14% (p=0.000 n=8+9) GobDecode-12 7.00ms ± 1% 6.99ms ± 0% ~ (p=0.497 n=9+10) GobEncode-12 5.47ms ± 1% 5.48ms ± 1% ~ (p=0.218 n=10+10) Gzip-12 258ms ± 2% 256ms ± 1% -0.96% (p=0.043 n=10+9) Gunzip-12 38.6ms ± 0% 38.3ms ± 0% -0.64% (p=0.000 n=9+8) HTTPClientServer-12 90.4µs ± 3% 87.2µs ±11% ~ (p=0.053 n=9+10) JSONEncode-12 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.077 n=9+9) JSONDecode-12 55.1ms ± 1% 54.6ms ± 1% -0.85% (p=0.010 n=10+9) Mandelbrot200-12 4.49ms ± 0% 4.47ms ± 0% -0.25% (p=0.000 n=10+8) GoParse-12 3.38ms ± 0% 3.37ms ± 1% ~ (p=0.315 n=8+10) RegexpMatchEasy0_32-12 82.5ns ± 4% 82.0ns ± 0% ~ (p=0.164 n=10+8) RegexpMatchEasy0_1K-12 203ns ± 1% 202ns ± 1% -0.85% (p=0.000 n=9+10) RegexpMatchEasy1_32-12 82.3ns ± 1% 81.1ns ± 0% -1.39% (p=0.000 n=10+8) RegexpMatchEasy1_1K-12 357ns ± 1% 357ns ± 1% ~ (p=0.697 n=8+9) RegexpMatchMedium_32-12 125ns ± 2% 126ns ± 2% ~ (p=0.197 n=10+10) RegexpMatchMedium_1K-12 39.6µs ± 3% 39.6µs ± 1% ~ (p=0.971 n=10+10) RegexpMatchHard_32-12 1.99µs ± 2% 1.99µs ± 4% ~ (p=0.891 n=10+9) RegexpMatchHard_1K-12 60.1µs ± 3% 60.4µs ± 3% ~ (p=0.684 n=10+10) Revcomp-12 531ms ± 6% 441ms ± 0% -16.94% (p=0.000 n=10+9) Template-12 58.9ms ± 1% 58.7ms ± 1% ~ (p=0.315 n=10+10) TimeParse-12 319ns ± 1% 320ns ± 4% ~ (p=0.215 n=9+9) TimeFormat-12 345ns ± 0% 333ns ± 1% -3.36% (p=0.000 n=9+10) [Geo mean] 52.2µs 51.6µs -1.13% On ARM64: name old time/op new time/op delta BinaryTree17-8 8.53s ± 0% 8.36s ± 0% -1.89% (p=0.000 n=10+10) Fannkuch11-8 6.15s ± 0% 6.10s ± 0% -0.67% (p=0.000 n=10+10) FmtFprintfEmpty-8 117ns ± 0% 117ns ± 0% ~ (all equal) FmtFprintfString-8 192ns ± 0% 192ns ± 0% ~ (all equal) FmtFprintfInt-8 198ns ± 0% 198ns ± 0% ~ (p=0.211 n=10+10) FmtFprintfIntInt-8 289ns ± 0% 291ns ± 0% +0.59% (p=0.000 n=7+10) FmtFprintfPrefixedInt-8 320ns ± 2% 317ns ± 0% ~ (p=0.431 n=10+8) FmtFprintfFloat-8 538ns ± 0% 538ns ± 0% ~ (all equal) FmtManyArgs-8 1.17µs ± 1% 1.18µs ± 1% ~ (p=0.063 n=10+10) GobDecode-8 17.0ms ± 1% 17.2ms ± 1% +0.83% (p=0.000 n=10+10) GobEncode-8 14.2ms ± 0% 14.1ms ± 1% -0.78% (p=0.001 n=9+10) Gzip-8 806ms ± 0% 797ms ± 0% -1.12% (p=0.000 n=6+9) Gunzip-8 131ms ± 0% 130ms ± 0% -0.51% (p=0.000 n=10+9) HTTPClientServer-8 206µs ± 9% 212µs ± 2% ~ (p=0.829 n=10+8) JSONEncode-8 40.1ms ± 0% 40.1ms ± 0% ~ (p=0.136 n=9+9) JSONDecode-8 157ms ± 0% 151ms ± 0% -3.32% (p=0.000 n=9+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.05% (p=0.000 n=9+8) GoParse-8 8.43ms ± 0% 8.43ms ± 0% ~ (p=0.912 n=10+10) RegexpMatchEasy0_32-8 228ns ± 1% 227ns ± 0% -0.26% (p=0.026 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.18% (p=0.001 n=7+7) RegexpMatchEasy1_32-8 258ns ± 1% 250ns ± 0% -2.83% (p=0.000 n=10+10) RegexpMatchEasy1_1K-8 2.39µs ± 0% 2.13µs ± 0% -10.94% (p=0.000 n=9+9) RegexpMatchMedium_32-8 352ns ± 0% 351ns ± 0% -0.29% (p=0.004 n=9+10) RegexpMatchMedium_1K-8 104µs ± 0% 105µs ± 0% +0.58% (p=0.000 n=8+9) RegexpMatchHard_32-8 5.84µs ± 0% 5.82µs ± 0% -0.27% (p=0.000 n=9+10) RegexpMatchHard_1K-8 177µs ± 0% 177µs ± 0% -0.07% (p=0.000 n=9+9) Revcomp-8 1.57s ± 1% 1.50s ± 1% -4.60% (p=0.000 n=9+10) Template-8 157ms ± 1% 153ms ± 1% -2.28% (p=0.000 n=10+9) TimeParse-8 779ns ± 1% 770ns ± 1% -1.18% (p=0.013 n=10+10) TimeFormat-8 823ns ± 2% 826ns ± 1% ~ (p=0.324 n=10+9) [Geo mean] 144µs 142µs -1.45% Reduce cmd/go text size by 0.5%. Change-Id: I9288ff983c4a7cf03fc0cb35b9b1750828013117 Reviewed-on: https://go-review.googlesource.com/38457 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
By overwhelming popular demand, exclude vendored packages from ... matches, by making ... never match the "vendor" element above a vendored package. go help packages now reads: An import path is a pattern if it includes one or more "..." wildcards, each of which can match any string, including the empty string and strings containing slashes. Such a pattern expands to all package directories found in the GOPATH trees with names matching the patterns. To make common patterns more convenient, there are two special cases. First, /... at the end of the pattern can match an empty string, so that net/... matches both net and packages in its subdirectories, like net/http. Second, any slash-separted pattern element containing a wildcard never participates in a match of the "vendor" element in the path of a vendored package, so that ./... does not match packages in subdirectories of ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do. Note, however, that a directory named vendor that itself contains code is not a vendored package: cmd/vendor would be a command named vendor, and the pattern cmd/... matches it. Fixes #19090. Change-Id: I985bf9571100da316c19fbfd19bb1e534a3c9e5f Reviewed-on: https://go-review.googlesource.com/38745Reviewed-by:Alan Donovan <adonovan@google.com>
-
Keith Randall authored
This reverts commit 041ecb69. Reason for revert: Not working on S390x and some 386 archs. I have a guess why the S390x is failing. No clue on the 386 yet. Revert until I can figure it out. Change-Id: I64f1ce78fa6d1037ebe7ee2a8a8107cb4c1db70c Reviewed-on: https://go-review.googlesource.com/38790Reviewed-by:
-
Russ Cox authored
Change-Id: I25db1d637dd461cec67ba70659d523b46895c113 Reviewed-on: https://go-review.googlesource.com/38744Reviewed-by:
-
Russ Cox authored
rsc.io/toolstash is gone; use rsc.io/pprof_mac_fix. This fixes a bug in the test. It turns out the code being tested here is also broken, so the test still doesn't pass after this CL (filed #19769). Change-Id: Ieb725c321d7fab600708e133ae28f531e55521ad Reviewed-on: https://go-review.googlesource.com/38743Reviewed-by:
-
David Chase authored
The uintptr-typed Data field in reflect.SliceHeader and reflect.StringHeader needs special treatment because it is really a pointer. Add the special treatment in walk for bug #19168 to escape analysis. Includes extra debugging that was helpful. Fixes #19743. Change-Id: I6dab5002f0d436c3b2a7cdc0156e4fc48a43d6fe Reviewed-on: https://go-review.googlesource.com/38738 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Lazar authored
Previously, an inlined call to wg.Done() in package main would have the following incorrect symbol name: main.(*sync.WaitGroup).Done This change modifies methodname to return the correct symbol name: sync.(*WaitGroup).Done This fix was suggested by @mdempsky. Fixes #19467. Change-Id: I0117838679ac5353789299c618ff8c326712d94d Reviewed-on: https://go-review.googlesource.com/37866Reviewed-by:Austin Clements <austin@google.com>
-
David Lazar authored
Change-Id: If1a3396175f2afa607d56efd1444181334a9ae3e Reviewed-on: https://go-review.googlesource.com/37862Reviewed-by:
-
David Lazar authored
The `skip` argument passed to runtime.Caller and runtime.Callers should be interpreted as the number of logical calls to skip (rather than the number of physical stack frames to skip). This changes runtime.Callers to skip inlined calls in addition to physical stack frames. The result value of runtime.Callers is a slice of program counters ([]uintptr) representing physical stack frames. If the `skip` parameter to runtime.Callers skips part-way into a physical frame, there is no convenient way to encode that in the resulting slice. To avoid changing the API in an incompatible way, our solution is to store the number of skipped logical calls of the first frame in the _second_ uintptr returned by runtime.Callers. Since this number is a small integer, we encode it as a valid PC value into a small symbol called: runtime.skipPleaseUseCallersFrames For example, if f() calls g(), g() calls `runtime.Callers(2, pcs)`, and g() is inlined into f, then the frame for f will be partially skipped, resulting in the following slice: pcs = []uintptr{pc_in_f, runtime.skipPleaseUseCallersFrames+1, ...} We store the skip PC in pcs[1] instead of pcs[0] so that `pcs[i:]` will truncate the captured stack trace rather than grow it for all i. Updates #19348. Change-Id: I1c56f89ac48c29e6f52a5d085567c6d77d499cf1 Reviewed-on: https://go-review.googlesource.com/37854 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
David Lazar authored
Previously, we could not run tests with -l=4 on NaCl since the buildrun action is not supported on NaCl. This lets us run tests with build flags on NaCl. Change-Id: I103370c7b823b4ff46f47df97e802da0dc2bc7c3 Reviewed-on: https://go-review.googlesource.com/38170 Run-TryBot: David Lazar <lazard@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Fixes #19753. Change-Id: Ib20a69b1d0bcc42aa9e924918bcb578d6a560a31 Reviewed-on: https://go-review.googlesource.com/38742 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
The aLongTimeAgo time value in net and net/http is used to cancel in-flight read and writes. It was set to time.Unix(233431200, 0) which seemed like far enough in the past. But Raspberry Pis, lacking a real time clock, had to spoil the fun and boot in 1970 at the Unix epoch time, breaking assumptions in net and net/http. So change aLongTimeAgo to time.Unix(1, 0), which seems like the earliest safe value. I don't trust subsecond values on all operating systems, and I don't trust the Unix zero time. The Raspberry Pis do advance their clock at least. And the reported problem was that Hijack on a ResponseWriter hung forever, waiting for the connection read operation to finish. So now, even if kernel + userspace boots in under a second (unlikely), the Hijack will just have to wait for up to a second. Fixes #19747 Change-Id: Id59430de2e7b5b5117d4903a788863e9d344e53a Reviewed-on: https://go-review.googlesource.com/38785 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Keith Randall authored
We have lots of rewrite rules that vary only in the fact that we have 2 versions for the 2 different orderings of various commuting ops. For example: (ADDL x (MOVLconst [c])) -> (ADDLconst [c] x) (ADDL (MOVLconst [c]) x) -> (ADDLconst [c] x) It can get unwieldly quickly, especially when there is more than one commuting op in a rule. Our existing "fix" for this problem is to have rules that canonicalize the operations first. For example: (Eq64 x (Const64 <t> [c])) && x.Op != OpConst64 -> (Eq64 (Const64 <t> [c]) x) Subsequent rules can then assume if there is a constant arg to Eq64, it will be the first one. This fix kinda works, but it is fragile and only works when we remember to include the required extra rules. The fundamental problem is that the rule matcher doesn't know anything about commuting ops. This CL fixes that fact. We already have information about which ops commute. (The register allocator takes advantage of commutivity.) The rule generator now automatically generates multiple rules for a single source rule when there are commutative ops in the rule. We can now drop all of our almost-duplicate source-level rules and the canonicalization rules. I have some CLs in progress that will be a lot less verbose when the rule generator handles commutivity for me. I had to reorganize the load-combining rules a bit. The 8-way OR rules generated 128 different reorderings, which was causing the generator to put too much code in the rewrite*.go files (the big ones were going from 25K lines to 132K lines). Instead I reorganized the rules to combine pairs of loads at a time. The generated rule files are now actually a bit (5%) smaller. [Note to reviewers: check these carefully. Most of the other rule changes are trivial.] Make.bash times are ~unchanged. Compiler benchmarks are not observably different. Probably because we don't spend much compiler time in rule matching anyway. I've also done a pass over all of our ops adding commutative markings for ops which hadn't had them previously. Fixes #18292 Change-Id: I999b1307272e91965b66754576019dedcbe7527a Reviewed-on: https://go-review.googlesource.com/38666 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Austin Clements authored
reflect.callReflect heap-allocates a stack frame and then constructs pointers to the arguments and result areas of that frame. However, if there are no results, the results pointer will point past the end of the frame allocation. If there are also no arguments, the arguments pointer will also point past the end of the frame allocation. If the GC observes either these pointers, it may panic. Fix this by not constructing these pointers if these areas of the frame are empty. This adds a test of calling no-argument/no-result methods via reflect, since nothing in std did this before. However, it's quite difficult to demonstrate the actual failure because it depends on both exact allocation patterns and on GC scanning the goroutine's stack while inside one of the typedmemmovepartial calls. I also audited other uses of typedmemmovepartial and memclrNoHeapPointers in reflect, since these are the most susceptible to this. These appear to be the only two cases that can construct out-of-bounds arguments to these functions. Fixes #19724. Change-Id: I4b83c596b5625dc4ad0567b1e281bad4faef972b Reviewed-on: https://go-review.googlesource.com/38736 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Rick Hudson authored
Currently for spans with up to 1 MBytes (128 pages) we maintain an array indexed by the number of pages in the span. This is efficient both in terms of space as well as time to insert or remove a span of a particular size. Unfortunately for spans larger than 1 MByte we currently place them on a separate linked list. This results in O(n) behavior. Now that we are seeing heaps approaching 100 GBytes n is large enough to be noticed in real programs. This change replaces the linked list now used with a balanced binary tree structure called a treap. A treap is a probabilistically balanced tree offering O(logN) behavior for inserting and removing spans. To verify that this approach will work we start with noting that only spans with sizes > 1MByte will be put into the treap. This means that to support 1 TByte a treap will need at most 1 million nodes and can ideally be held in a treap with a depth of 20. Experiments with adding and removing randomly sized spans from the treap seem to result in treaps with depths of about twice the ideal or 40. A petabyte would require a tree of only twice again that depth again so this algorithm should last well into the future. Fixes #19393 Go1 benchmarks indicate this is basically an overall wash. Tue Mar 28 21:29:21 EDT 2017 name old time/op new time/op delta BinaryTree17-4 2.42s ± 1% 2.42s ± 1% ~ (p=0.980 n=21+21) Fannkuch11-4 3.00s ± 1% 3.18s ± 4% +6.10% (p=0.000 n=22+24) FmtFprintfEmpty-4 40.5ns ± 1% 40.3ns ± 3% ~ (p=0.692 n=22+25) FmtFprintfString-4 65.9ns ± 3% 64.6ns ± 1% -1.98% (p=0.000 n=24+23) FmtFprintfInt-4 69.6ns ± 1% 68.0ns ± 7% -2.30% (p=0.001 n=21+22) FmtFprintfIntInt-4 102ns ± 2% 99ns ± 1% -3.07% (p=0.000 n=23+23) FmtFprintfPrefixedInt-4 126ns ± 0% 125ns ± 0% -0.79% (p=0.000 n=19+17) FmtFprintfFloat-4 206ns ± 2% 205ns ± 1% ~ (p=0.671 n=23+21) FmtManyArgs-4 441ns ± 1% 445ns ± 1% +0.88% (p=0.000 n=22+23) GobDecode-4 5.73ms ± 1% 5.86ms ± 1% +2.37% (p=0.000 n=23+22) GobEncode-4 4.51ms ± 1% 4.89ms ± 1% +8.32% (p=0.000 n=22+22) Gzip-4 197ms ± 0% 202ms ± 1% +2.75% (p=0.000 n=23+24) Gunzip-4 32.9ms ± 8% 32.7ms ± 2% ~ (p=0.466 n=23+24) HTTPClientServer-4 57.3µs ± 1% 56.7µs ± 1% -0.94% (p=0.000 n=21+22) JSONEncode-4 13.8ms ± 1% 13.9ms ± 2% +1.14% (p=0.000 n=22+23) JSONDecode-4 47.4ms ± 1% 48.1ms ± 1% +1.49% (p=0.000 n=23+23) Mandelbrot200-4 3.92ms ± 0% 3.92ms ± 1% +0.21% (p=0.000 n=22+22) GoParse-4 2.89ms ± 1% 2.87ms ± 1% -0.68% (p=0.000 n=21+22) RegexpMatchEasy0_32-4 73.6ns ± 1% 72.0ns ± 2% -2.15% (p=0.000 n=21+22) RegexpMatchEasy0_1K-4 173ns ± 1% 173ns ± 1% ~ (p=0.847 n=22+24) RegexpMatchEasy1_32-4 71.9ns ± 1% 69.8ns ± 1% -2.99% (p=0.000 n=23+20) RegexpMatchEasy1_1K-4 314ns ± 1% 308ns ± 1% -1.91% (p=0.000 n=22+23) RegexpMatchMedium_32-4 106ns ± 0% 105ns ± 1% -0.58% (p=0.000 n=19+21) RegexpMatchMedium_1K-4 34.3µs ± 1% 34.3µs ± 1% ~ (p=0.871 n=23+22) RegexpMatchHard_32-4 1.67µs ± 1% 1.67µs ± 7% ~ (p=0.224 n=22+23) RegexpMatchHard_1K-4 51.5µs ± 1% 50.4µs ± 1% -1.99% (p=0.000 n=22+23) Revcomp-4 383ms ± 1% 415ms ± 0% +8.51% (p=0.000 n=22+22) Template-4 51.5ms ± 1% 51.5ms ± 1% ~ (p=0.555 n=20+23) TimeParse-4 279ns ± 2% 277ns ± 1% -0.95% (p=0.000 n=24+22) TimeFormat-4 294ns ± 1% 296ns ± 1% +0.58% (p=0.003 n=24+23) [Geo mean] 43.7µs 43.8µs +0.32% name old speed new speed delta GobDecode-4 134MB/s ± 1% 131MB/s ± 1% -2.32% (p=0.000 n=23+22) GobEncode-4 170MB/s ± 1% 157MB/s ± 1% -7.68% (p=0.000 n=22+22) Gzip-4 98.7MB/s ± 0% 96.1MB/s ± 1% -2.68% (p=0.000 n=23+24) Gunzip-4 590MB/s ± 7% 593MB/s ± 2% ~ (p=0.466 n=23+24) JSONEncode-4 141MB/s ± 1% 139MB/s ± 2% -1.13% (p=0.000 n=22+23) JSONDecode-4 40.9MB/s ± 1% 40.3MB/s ± 0% -1.47% (p=0.000 n=23+23) GoParse-4 20.1MB/s ± 1% 20.2MB/s ± 1% +0.69% (p=0.000 n=21+22) RegexpMatchEasy0_32-4 435MB/s ± 1% 444MB/s ± 2% +2.21% (p=0.000 n=21+22) RegexpMatchEasy0_1K-4 5.89GB/s ± 1% 5.89GB/s ± 1% ~ (p=0.439 n=22+24) RegexpMatchEasy1_32-4 445MB/s ± 1% 459MB/s ± 1% +3.06% (p=0.000 n=23+20) RegexpMatchEasy1_1K-4 3.26GB/s ± 1% 3.32GB/s ± 1% +1.97% (p=0.000 n=22+23) RegexpMatchMedium_32-4 9.40MB/s ± 1% 9.44MB/s ± 1% +0.43% (p=0.000 n=23+21) RegexpMatchMedium_1K-4 29.8MB/s ± 1% 29.8MB/s ± 1% ~ (p=0.826 n=23+22) RegexpMatchHard_32-4 19.1MB/s ± 1% 19.1MB/s ± 7% ~ (p=0.233 n=22+23) RegexpMatchHard_1K-4 19.9MB/s ± 1% 20.3MB/s ± 1% +2.03% (p=0.000 n=22+23) Revcomp-4 664MB/s ± 1% 612MB/s ± 0% -7.85% (p=0.000 n=22+22) Template-4 37.6MB/s ± 1% 37.7MB/s ± 1% ~ (p=0.558 n=20+23) [Geo mean] 134MB/s 133MB/s -0.76% Tue Mar 28 22:16:54 EDT 2017 Change-Id: I4a4f5c2b53d3fb85ef76c98522d3ed5cf8ae5b7e Reviewed-on: https://go-review.googlesource.com/38732Reviewed-by:
-
haya14busa authored
"go env" prints Go environment information as a shell script format by default but it's difficult for some tools (e.g. editor packages) to interpret it. The -json flag prints the environment in JSON format which can be easily interpreted by a lot of tools. $ go env -json { "CC": "gcc", "CGO_CFLAGS": "-g -O2", "CGO_CPPFLAGS": "", "CGO_CXXFLAGS": "-g -O2", "CGO_ENABLED": "1", "CGO_FFLAGS": "-g -O2", "CGO_LDFLAGS": "-g -O2", "CXX": "g++", "GCCGO": "gccgo", "GOARCH": "amd64", "GOBIN": "/home/haya14busa/go/bin", "GOEXE": "", "GOGCCFLAGS": "-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build498013955=/tmp/go-build -gno-record-gcc-switches", "GOHOSTARCH": "amd64", "GOHOSTOS": "linux", "GOOS": "linux", "GOPATH": "/home/haya14busa", "GORACE": "", "GOROOT": "/home/haya14busa/src/go.googlesource.com/go", "GOTOOLDIR": "/home/haya14busa/src/go.googlesource.com/go/pkg/tool/linux_amd64", "PKG_CONFIG": "pkg-config" } Also, it supports arguments with -json flag. $ go env -json GOROOT GOPATH GOBIN { "GOBIN": "/home/haya14busa/go/bin", "GOPATH": "/home/haya14busa", "GOROOT": "/home/haya14busa/src/go.googlesource.com/go" } Fixes #12567 Change-Id: I75db3780f14a8ab8c7fa58cc3c9cc488ef7b66a1 Reviewed-on: https://go-review.googlesource.com/38757Reviewed-by: -
Dave Cheney authored
gc.state.placeholder was added in 5a6e511c but never used. Change-Id: I5a621507279d5bb1f3991b7a412d9a63039c464e Reviewed-on: https://go-review.googlesource.com/38755Reviewed-by:
-
Dave Cheney authored
Make byteswapreg more Go like. Change-Id: Ibdf3603cae9cad2b3465b4c224a28a4c4c745c2e Reviewed-on: https://go-review.googlesource.com/38615 Run-TryBot: Dave Cheney <dave@cheney.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 28 Mar, 2017 2 commits
-
-
Matthew Dempsky authored
Use namedfield consistently. Passes toolstash-check. Change-Id: Ic5a3acb4bfaa1f60dd2eac94612160509e8d7f94 Reviewed-on: https://go-review.googlesource.com/38741 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Automated refactoring using gofmt. Passes toolstash-check. Change-Id: I8624e1c231dc736e1bb4cc800acaf629a0af91d7 Reviewed-on: https://go-review.googlesource.com/38740 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
