- 15 Nov, 2017 7 commits
-
-
Ian Lance Taylor authored
Permit the C preamble to use the _GoString_ type. Permit Go code to pass string values directly to those C types. Add accessors for C code to retrieve sizes and pointers. Fixes #6907 Change-Id: I190c88319ec88a3ef0ddb99f342a843ba69fcaa3 Reviewed-on: https://go-review.googlesource.com/70890 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Tim Cooper authored
Change-Id: Ib9ec3524b712e016a9dd2fbee5555362c1a0cb59 Reviewed-on: https://go-review.googlesource.com/77770Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
wei xiao authored
Update runtime asm_arm64.s and memclr_arm64.s to improve performance by using SIMD instructions to do more in parallel. It shows improvement on bytes, html and go1 benchmarks (particualrly regexp, which uses IndexByte frequently). Benchmark results of bytes: name old time/op new time/op delta IndexByte/10-8 28.5ns ± 0% 19.5ns ± 0% -31.58% (p=0.000 n=10+10) IndexByte/32-8 52.6ns ± 0% 19.0ns ± 0% -63.88% (p=0.000 n=10+10) IndexByte/4K-8 4.12µs ± 0% 0.49µs ± 0% -88.16% (p=0.000 n=10+10) IndexByte/4M-8 4.29ms ± 1% 0.70ms ±26% -83.65% (p=0.000 n=10+10) IndexByte/64M-8 69.7ms ± 0% 16.0ms ± 0% -76.97% (p=0.000 n=9+10) IndexBytePortable/10-8 34.0ns ± 0% 34.0ns ± 0% ~ (all equal) IndexBytePortable/32-8 66.1ns ± 0% 66.1ns ± 0% ~ (p=0.471 n=9+9) IndexBytePortable/4K-8 6.17µs ± 0% 6.17µs ± 0% ~ (all equal) IndexBytePortable/4M-8 6.33ms ± 0% 6.35ms ± 0% +0.21% (p=0.002 n=10+9) IndexBytePortable/64M-8 103ms ± 0% 103ms ± 0% +0.01% (p=0.017 n=9+10) name old speed new speed delta IndexByte/10-8 351MB/s ± 0% 512MB/s ± 0% +46.14% (p=0.000 n=9+10) IndexByte/32-8 609MB/s ± 0% 1683MB/s ± 0% +176.40% (p=0.000 n=10+10) IndexByte/4K-8 994MB/s ± 0% 8378MB/s ± 0% +742.75% (p=0.000 n=10+10) IndexByte/4M-8 977MB/s ± 1% 6149MB/s ±32% +529.29% (p=0.000 n=10+10) IndexByte/64M-8 963MB/s ± 0% 4182MB/s ± 0% +334.29% (p=0.000 n=9+10) IndexBytePortable/10-8 294MB/s ± 0% 294MB/s ± 0% +0.17% (p=0.000 n=8+8) IndexBytePortable/32-8 484MB/s ± 0% 484MB/s ± 0% ~ (p=0.877 n=9+9) IndexBytePortable/4K-8 664MB/s ± 0% 664MB/s ± 0% ~ (p=0.242 n=8+9) IndexBytePortable/4M-8 662MB/s ± 0% 661MB/s ± 0% -0.21% (p=0.002 n=10+9) IndexBytePortable/64M-8 652MB/s ± 0% 652MB/s ± 0% ~ (p=0.065 n=10+10) Benchmark results of html: name old time/op new time/op delta Escape-8 62.0µs ± 1% 61.0µs ± 1% -1.69% (p=0.000 n=9+10) EscapeNone-8 10.2µs ± 0% 10.2µs ± 0% -0.09% (p=0.022 n=9+10) Unescape-8 71.9µs ± 0% 68.7µs ± 0% -4.35% (p=0.000 n=10+10) UnescapeNone-8 4.03µs ± 0% 0.48µs ± 0% -88.08% (p=0.000 n=10+10) UnescapeSparse-8 10.7µs ± 2% 7.1µs ± 3% -33.91% (p=0.000 n=10+10) UnescapeDense-8 53.2µs ± 1% 53.5µs ± 1% ~ (p=0.143 n=10+10) Benchmark results of go1: name old time/op new time/op delta BinaryTree17-8 6.53s ± 0% 6.48s ± 2% ~ (p=0.190 n=4+5) Fannkuch11-8 6.35s ± 1% 6.35s ± 0% ~ (p=1.000 n=5+5) FmtFprintfEmpty-8 108ns ± 1% 101ns ± 2% -6.32% (p=0.008 n=5+5) FmtFprintfString-8 172ns ± 1% 182ns ± 2% +5.70% (p=0.008 n=5+5) FmtFprintfInt-8 207ns ± 0% 207ns ± 0% ~ (p=0.444 n=5+5) FmtFprintfIntInt-8 277ns ± 1% 276ns ± 1% ~ (p=0.873 n=5+5) FmtFprintfPrefixedInt-8 386ns ± 0% 382ns ± 1% -1.04% (p=0.024 n=5+5) FmtFprintfFloat-8 492ns ± 0% 492ns ± 1% ~ (p=0.571 n=4+5) FmtManyArgs-8 1.32µs ± 1% 1.33µs ± 0% ~ (p=0.087 n=5+5) GobDecode-8 16.8ms ± 2% 16.7ms ± 1% ~ (p=1.000 n=5+5) GobEncode-8 14.1ms ± 1% 14.0ms ± 1% ~ (p=0.056 n=5+5) Gzip-8 788ms ± 0% 802ms ± 0% +1.71% (p=0.008 n=5+5) Gunzip-8 83.6ms ± 0% 83.9ms ± 0% +0.40% (p=0.008 n=5+5) HTTPClientServer-8 120µs ± 0% 120µs ± 1% ~ (p=0.548 n=5+5) JSONEncode-8 33.2ms ± 0% 33.0ms ± 1% -0.71% (p=0.008 n=5+5) JSONDecode-8 152ms ± 1% 152ms ± 1% ~ (p=1.000 n=5+5) Mandelbrot200-8 10.0ms ± 0% 10.0ms ± 0% -0.05% (p=0.008 n=5+5) GoParse-8 7.97ms ± 0% 7.98ms ± 0% ~ (p=0.690 n=5+5) RegexpMatchEasy0_32-8 233ns ± 1% 206ns ± 0% -11.44% (p=0.016 n=5+4) RegexpMatchEasy0_1K-8 1.86µs ± 0% 0.77µs ± 1% -58.54% (p=0.008 n=5+5) RegexpMatchEasy1_32-8 250ns ± 0% 205ns ± 0% -18.07% (p=0.008 n=5+5) RegexpMatchEasy1_1K-8 2.28µs ± 0% 1.11µs ± 0% -51.09% (p=0.029 n=4+4) RegexpMatchMedium_32-8 332ns ± 1% 301ns ± 2% -9.45% (p=0.008 n=5+5) RegexpMatchMedium_1K-8 85.5µs ± 2% 78.8µs ± 0% -7.83% (p=0.008 n=5+5) RegexpMatchHard_32-8 4.34µs ± 1% 4.27µs ± 0% -1.49% (p=0.008 n=5+5) RegexpMatchHard_1K-8 130µs ± 1% 127µs ± 0% -2.53% (p=0.008 n=5+5) Revcomp-8 1.35s ± 1% 1.13s ± 1% -16.17% (p=0.008 n=5+5) Template-8 160ms ± 2% 162ms ± 2% ~ (p=0.222 n=5+5) TimeParse-8 795ns ± 2% 778ns ± 1% ~ (p=0.095 n=5+5) TimeFormat-8 782ns ± 0% 786ns ± 1% +0.59% (p=0.040 n=5+5) name old speed new speed delta GobDecode-8 45.8MB/s ± 2% 45.9MB/s ± 1% ~ (p=1.000 n=5+5) GobEncode-8 54.3MB/s ± 1% 55.0MB/s ± 1% ~ (p=0.056 n=5+5) Gzip-8 24.6MB/s ± 0% 24.2MB/s ± 0% -1.69% (p=0.008 n=5+5) Gunzip-8 232MB/s ± 0% 231MB/s ± 0% -0.40% (p=0.008 n=5+5) JSONEncode-8 58.4MB/s ± 0% 58.8MB/s ± 1% +0.71% (p=0.008 n=5+5) JSONDecode-8 12.8MB/s ± 1% 12.8MB/s ± 1% ~ (p=1.000 n=5+5) GoParse-8 7.27MB/s ± 0% 7.26MB/s ± 0% ~ (p=0.762 n=5+5) RegexpMatchEasy0_32-8 137MB/s ± 1% 155MB/s ± 0% +12.93% (p=0.008 n=5+5) RegexpMatchEasy0_1K-8 551MB/s ± 0% 1329MB/s ± 1% +141.11% (p=0.008 n=5+5) RegexpMatchEasy1_32-8 128MB/s ± 0% 156MB/s ± 0% +22.00% (p=0.008 n=5+5) RegexpMatchEasy1_1K-8 449MB/s ± 0% 920MB/s ± 0% +104.68% (p=0.016 n=4+5) RegexpMatchMedium_32-8 3.00MB/s ± 0% 3.32MB/s ± 2% +10.60% (p=0.016 n=4+5) RegexpMatchMedium_1K-8 12.0MB/s ± 2% 13.0MB/s ± 0% +8.48% (p=0.008 n=5+5) RegexpMatchHard_32-8 7.38MB/s ± 1% 7.49MB/s ± 0% +1.49% (p=0.008 n=5+5) RegexpMatchHard_1K-8 7.88MB/s ± 1% 8.08MB/s ± 0% +2.59% (p=0.008 n=5+5) Revcomp-8 188MB/s ± 1% 224MB/s ± 1% +19.29% (p=0.008 n=5+5) Template-8 12.2MB/s ± 2% 12.0MB/s ± 2% ~ (p=0.206 n=5+5) Change-Id: I94116620a287d173a6f60510684362e500f54887 Reviewed-on: https://go-review.googlesource.com/33597 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
OneOfOne authored
Fixes #20924 Change-Id: If89f31da63cbea38d7e615a428b7b07629770a45 Reviewed-on: https://go-review.googlesource.com/47851 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Tim Cooper <tim.cooper@layeh.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Tim Cooper authored
Included in a warning that EncodeToMemory may return an incomplete PEM encoded structure if invalid headers are supplied. Example: pem.EncodeToMemory(&pem.Block{ Headers: map[string]string{ "a": "test1", "b:c": "test2", }, }) Returns: -----BEGIN ----- a: test1 Change-Id: Ia9cf0202f985e3cf210aabb6f07667e581ff081f Reviewed-on: https://go-review.googlesource.com/77790Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Tw authored
We set Content-Type to "text/plain; charset=utf-8" even with blank body before. Let's strip this unnecessary header though it's harmless in most cases. Fixes #20784 Signed-off-by:
Tw <tw19881113@gmail.com> Change-Id: Ic58a410dcbc89f457c6ddd92961d9cbf545b2f4f Reviewed-on: https://go-review.googlesource.com/46631 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Roger Peppe authored
Unless you go back and read the hash package documentation, it's not clear that all the hash packages implement marshaling and unmarshaling. Document the behaviour specifically in each package that implements it as it this is hidden behaviour and easy to miss. Change-Id: Id9d3508909362f1a3e53872d0319298359e50a94 Reviewed-on: https://go-review.googlesource.com/77251Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
- 14 Nov, 2017 15 commits
-
-
Ian Lance Taylor authored
If the Linux kernel was built with CONFIG_OPTIMIZE_INLINING=n and was built with hardening options turned on, GCC will insert a stack probe in the VDSO function that requires a full page of stack space. The stack probe can corrupt memory if another thread is using it. Avoid sporadic crashes by calling the VDSO on the g0 or gsignal stack. While we're at it, align the stack as C code expects. We've been getting away with a misaligned stack, but it's possible that the VDSO code will change in the future to break that assumption. Benchmarks show a 11% hit on time.Now, but it's only 6ns. name old time/op new time/op delta AfterFunc-12 1.66ms ± 0% 1.66ms ± 1% ~ (p=0.905 n=9+10) After-12 1.90ms ± 6% 1.86ms ± 0% -2.05% (p=0.012 n=10+8) Stop-12 113µs ± 3% 115µs ± 2% +1.60% (p=0.017 n=9+10) SimultaneousAfterFunc-12 145µs ± 1% 144µs ± 0% -0.68% (p=0.002 n=10+8) StartStop-12 39.5µs ± 3% 40.4µs ± 5% +2.19% (p=0.023 n=10+10) Reset-12 10.2µs ± 0% 10.4µs ± 0% +2.45% (p=0.000 n=10+9) Sleep-12 190µs ± 1% 190µs ± 1% ~ (p=0.971 n=10+10) Ticker-12 4.68ms ± 2% 4.64ms ± 2% -0.83% (p=0.043 n=9+10) Now-12 48.4ns ±11% 54.0ns ±11% +11.42% (p=0.017 n=10+10) NowUnixNano-12 48.5ns ±13% 56.9ns ± 8% +17.30% (p=0.000 n=10+10) Format-12 489ns ±11% 504ns ± 6% ~ (p=0.289 n=10+10) FormatNow-12 436ns ±23% 480ns ±13% +10.25% (p=0.026 n=9+10) MarshalJSON-12 656ns ±14% 587ns ±24% ~ (p=0.063 n=10+10) MarshalText-12 647ns ± 7% 638ns ± 9% ~ (p=0.516 n=10+10) Parse-12 348ns ± 8% 328ns ± 9% -5.66% (p=0.030 n=10+10) ParseDuration-12 136ns ± 9% 140ns ±11% ~ (p=0.425 n=10+10) Hour-12 14.8ns ± 6% 15.6ns ±11% ~ (p=0.085 n=10+10) Second-12 14.0ns ± 6% 14.3ns ±12% ~ (p=0.443 n=10+10) Year-12 32.4ns ±11% 33.4ns ± 6% ~ (p=0.492 n=10+10) Day-12 41.5ns ± 9% 42.3ns ±12% ~ (p=0.239 n=10+10) Fixes #20427 Change-Id: Ia395cbb863215f4499b8e7ef95f4b99f51090911 Reviewed-on: https://go-review.googlesource.com/76990Reviewed-by:
Austin Clements <austin@google.com>
-
Michael Stapelberg authored
I verified this change on a corpus of > 200 GB of emails since the mid-90s. With this change, more addresses parse than before, and anything which parsed before still parses. In said corpus, I came across the edge case of comments preceding an addr-spec (with angle brackets!), e.g. “(John Doe) <john@example.com>”, which does not satisfy the conditions to be treated as a fallback, as per my reading of RFC2822. This change does not parse quoted-strings within comments (a corresponding TODO is in the code), but I have not seen that in the wild. Fixes #22670 Change-Id: I526fcf7c6390aa1c219fdec1852f26c514506f76 Reviewed-on: https://go-review.googlesource.com/77474Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Hana Kim authored
GDB 7.5 recognizes DWARF4 by default. GDB 7.5 release note does not explicitly mention DWARF4 support but according to GCC 4.8 release note https://gcc.gnu.org/gcc-4.8/changes.html "DWARF4 is now the default when generating DWARF debug information. ... GDB 7.5, Valgrind 3.8.0 and elfutils 0.154 debug information consumers support DWARF4 by default." Change-Id: I56b011c7c38fbc103bbd366ceaea3b709c66ab7f Reviewed-on: https://go-review.googlesource.com/77570Reviewed-by:
Alberto Donizetti <alb.donizetti@gmail.com>
-
Fangming.Fang authored
change hash/crc32 package to use cpu package instead of using runtime internal variables to check crc32 instruction Change-Id: I8f88d2351bde8ed4e256f9adf822a08b9a00f532 Reviewed-on: https://go-review.googlesource.com/76490Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
I submitted two CLs which broke the build. Add temporary placeholder with false bools to fix the build and restore old behavior. Updates golang/go#22718 (details of why it broke) Change-Id: I1f30624e14f631a95f4eff5aae462f1091f723a2 Reviewed-on: https://go-review.googlesource.com/77590Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
fanzha02 authored
Optimize with ARMv8 SHA256 instructions. Result (Cortex-A72) name old time/op new time/op delta Hash8Bytes-64 1.54µs ± 1% 0.61µs ± 9% -60.67% (p=0.008 n=5+5) Hash1K-64 17.2µs ± 1% 1.4µs ± 2% -91.91% (p=0.008 n=5+5) Hash8K-64 127µs ± 0% 7µs ± 1% -94.42% (p=0.008 n=5+5) name old speed new speed delta Hash8Bytes-64 5.20MB/s ± 1% 13.23MB/s ±10% +154.58% (p=0.008 n=5+5) Hash1K-64 59.4MB/s ± 1% 735.1MB/s ± 2% +1136.96% (p=0.008 n=5+5) Hash8K-64 64.5MB/s ± 0% 1156.3MB/s ± 1% +1692.75% (p=0.008 n=5+5) Change-Id: I47eca6471b75cd07cb0c77477053a07d0de7494f Reviewed-on: https://go-review.googlesource.com/61570Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
fanzha02 authored
Optimize with ARMv8 SHA1 instructions. Results (Cortex-A72) name old time/op new time/op delta Hash8Bytes-64 1.06µs ± 4% 0.56µs ± 4% -47.19% (p=0.008 n=5+5) Hash320Bytes-64 3.92µs ± 1% 0.82µs ± 2% -79.07% (p=0.008 n=5+5) Hash1K-64 10.2µs ± 2% 1.5µs ± 2% -85.71% (p=0.008 n=5+5) Hash8K-64 73.9µs ± 1% 7.6µs ± 1% -89.66% (p=0.008 n=5+5) name old speed new speed delta Hash8Bytes-64 7.55MB/s ± 4% 14.29MB/s ± 4% +89.27% (p=0.008 n=5+5) Hash320Bytes-64 81.6MB/s ± 1% 390.0MB/s ± 2% +377.64% (p=0.008 n=5+5) Hash1K-64 100MB/s ± 2% 701MB/s ± 2% +599.65% (p=0.008 n=5+5) Hash8K-64 111MB/s ± 1% 1072MB/s ± 1% +867.44% (p=0.008 n=5+5) Change-Id: I84397f980db9518f4150ac4c5ffa2c5a97a34444 Reviewed-on: https://go-review.googlesource.com/61550Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
A clarifying comment was added to indicate that overflow of a single Word is not possible in the single digit calculation. Lehmer's paper includes a proof of the bounds on the size of the cosequences (u0, u1, u2, v0, v1, v2). Change-Id: I98127a07aa8f8fe44814b74b2bc6ff720805194b Reviewed-on: https://go-review.googlesource.com/77451Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Akhil Indurti authored
Previously when RoundTrip returned a non-nil error, the proxy returned a StatusBadGateway error, instead of first calling ModifyResponse. This commit first calls ModifyResponse, whether or not the error returned from RoundTrip is nil. Also closes response body when ModifyResponse returns an error. See #22658. Fixes #21255 Change-Id: I5b5bf23a69ae5608f87d4ece756a1b4985ccaa9c Reviewed-on: https://go-review.googlesource.com/54030Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alberto Donizetti authored
In the doc for QueryUnescape and PathUnescape, clarify that by 0xAB we means a substring with any two valid hexadecimal digits. Fixes #18642 Change-Id: Ib65b130995ae5fcf07e25ee0fcc41fad520c5662 Reviewed-on: https://go-review.googlesource.com/77050Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Fixes #22703 The fix was already done by Cherry for defer/go of an interface call (CL 23820). We just need to do it everywhere. Change-Id: I0115d22e443931fe1bcce44c93c4d0770b5fd268 Reviewed-on: https://go-review.googlesource.com/77450 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ryoichi KATO authored
Use maxConsecutiveEmptyReads const instead of hardcoded 100 in scan.go too. Change-Id: I993f353a3748f0d6bdefab38bf5cb224eea8a969 Reviewed-on: https://go-review.googlesource.com/46915Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Brainman authored
Just copy some code to make TestWindowsStackMemory build when CGO_ENABLED is set to 0. Fixes #22680 Change-Id: I63f9b409a3a97b7718f5d37837ab706d8ed92e81 Reviewed-on: https://go-review.googlesource.com/77430Reviewed-by:
Chris Hines <chris.cs.guy@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Stephen McQuay (smcquay) authored
Fixes #19579 Change-Id: Id99ca6de94d8d895dfaed1ed507e9d36c7f60670 Reviewed-on: https://go-review.googlesource.com/48869Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Theophanes authored
Before terminating the connectionResetter goroutine the connection pool processes all of the connections on the channel to unlock the driverConn instances so everthing can shutdown cleanly. However the channel was never closed so the goroutine hangs on the range. Close the channel prior to ranging over it. Also prevent additional connections from being sent to the resetter after the connection pool has been closed. Fixes #22699 Change-Id: I440d2b13cbedec2e04621557f5bd0b1526933dd7 Reviewed-on: https://go-review.googlesource.com/77390 Run-TryBot: Daniel Theophanes <kardianos@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 13 Nov, 2017 15 commits
-
-
Joe Tsai authored
The cryptographic checksums operate in blocks of 64 or 128 bytes, which means that the last 128 bytes or so of the input may be encoded in its original (plaintext) form as part of the state. Document this so users do not falsely assume that the encoded state carries no reversible information about the input. Change-Id: I823dbb87867bf0a77aa20f6ed7a615dbedab3715 Reviewed-on: https://go-review.googlesource.com/77372Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
CL 45412 started hiding autogenerated wrapper functions from call stacks so that call stack semantics better matched language semantics. This is based on the theory that the wrapper function will call the "real" function and all the programmer knows about is the real function. However, this theory breaks down in two cases: 1. If the wrapper is at the top of the stack, then it didn't call anything. This can happen, for example, if the "stack" was actually synthesized by the user. 2. If the wrapper panics, for example by calling panicwrap or by dereferencing a nil pointer, then it didn't call the wrapped function and the user needs to see what panicked, even if we can't attribute it nicely. This commit modifies the traceback logic to include the wrapper function in both of these cases. Fixes #22231. Change-Id: I6e4339a652f73038bd8331884320f0b8edd86eb1 Reviewed-on: https://go-review.googlesource.com/76770 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Michael Munday authored
The Go compiler assumes that pointers escape when passed into assembly functions. To override this behavior we can annotate assembly functions with go:noescape, telling the compiler that we know pointers do not escape from it. By annotating the assembly functions in the s390x P256 code in this way we enable more variables to be allocated on the stack rather than the heap, reducing the number of heap allocations required to execute this code: name old alloc/op new alloc/op delta SignP256 3.66kB ± 0% 2.64kB ± 0% -27.95% (p=0.008 n=5+5) VerifyP256 4.46kB ± 0% 1.23kB ± 0% -72.40% (p=0.008 n=5+5) name old allocs/op new allocs/op delta SignP256 40.0 ± 0% 31.0 ± 0% -22.50% (p=0.008 n=5+5) VerifyP256 41.0 ± 0% 24.0 ± 0% -41.46% (p=0.008 n=5+5) Change-Id: Id526c30c9b04b2ad79a55d76cab0e30cc8d60402 Reviewed-on: https://go-review.googlesource.com/66230 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
Split typecheckrange into two, separating the bigger chunk of code that takes care of the range expression. It had to sometimes exit early, which was done via a goto in the larger func. This lets us simplify many declarations and the flow of the code. While at it, also replace the toomany int with a bool. In the case of walkselect, split it into two funcs too since using a defer for all the trailing work would be a bit much. It also lets us simplify the declarations and the flow of the code, since now walkselectcases has a narrower scope and straightforward signature. Also replace the gotos in typecheckaste with a lineno defer. Passes toolstash -cmp on std cmd. Change-Id: Iacfaa0a34c987c44f180a792c473558785cf6823 Reviewed-on: https://go-review.googlesource.com/72374 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Kevin Burke authored
If people are interested in contributing to Go, but not sure what change they'd like to make just yet, we can point them to the scratch repo, so they can go through the process of submitting and merging something now, and make more useful contributions later. My evidence that sending people to the scratch repo would encourage future contributions is that a number of people who went through the workshop at Gophercon have continued to send CL's after submitting to the scratch repo, even though I doubt they planned to before going through the workshop. Change-Id: Ieb48415773c0ee7dc400f8bf6f57f752eca8eeb5 Reviewed-on: https://go-review.googlesource.com/49970Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
This test fails on 1.9.2, but is ok on tip. CL 77331 has both the 1.9.2 fix and this test, and is on the 1.9 release branch. This CL is just the test, and is on HEAD. The buggy code doesn't exist on tip. Update #22683 Change-Id: I04a24bd6c2d3068e18ca81da3347e2c1366f4447 Reviewed-on: https://go-review.googlesource.com/77332 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Adrian Hesketh authored
Change-Id: Ie64eba5b57b609a343ddb381fe83c01f172c0bf4 Reviewed-on: https://go-review.googlesource.com/60890Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
CL 60410 fixes a bug in reflect that allows assignments to an embedded field of a pointer to an unexported struct type. This breaks the json package because unmarshal is now unable to assign a newly allocated struct to such fields. In order to be consistent in the behavior for marshal and unmarshal, this CL changes both marshal and unmarshal to always ignore embedded pointers to unexported structs. Fixes #21357 Change-Id: If62ea11155555e61115ebb9cfa5305caf101bde5 Reviewed-on: https://go-review.googlesource.com/76851 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Chris Hines authored
Fixes #22608. Change-Id: Id85eb86b0b262156646e55f102fe888b345b20cf Reviewed-on: https://go-review.googlesource.com/77230 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Leigh McCulloch authored
GitHub has defined a set of standard meta files to include with projects hosted on GitHub. According to the GitHub Insights Community page for go project the only one missing is the code of conduct. Go has a code of conduct on it's website and we should link to it in the prescribed `.github/CODE_OF_CONDUCT.md` so that people can find it in the standard location on GitHub. This would be consistent with the contribution guidelines that are linked to in `.github/CONTRIBUTING.md`. Ref: https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/ Fixes #22685 Change-Id: Ie89aa39d3df741d7d6ed2dba5c8ba3d0e0dbf618 Reviewed-on: https://go-review.googlesource.com/77231Reviewed-by:
Gabriel Aszalos <gabriel.aszalos@gmail.com> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
griesemer authored
Also, with this change, error locations don't print absolute positions in [] brackets following positions relative to line directives. To get the absolute positions as well, specify the -L flag. Fixes #22660. Change-Id: I9ecfa254f053defba9c802222874155fa12fee2c Reviewed-on: https://go-review.googlesource.com/77090Reviewed-by:
David Crawshaw <crawshaw@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Russ Cox authored
cmd/cover rewrites Go source code to add coverage annotations. The approach to date has been to parse the code to AST, analyze it, rewrite the AST, and print it back out. This approach fails to preserve line numbers in the original code and has a very difficult time with comments, because go/printer does as well. This CL changes cmd/cover to decide what to modify based on the AST but to apply the modifications as purely textual substitutions. In this way, cmd/cover can be sure it never adds or removes a newline character, nor a comment, so all line numbers and comments are preserved. This also allows us to emit a single //line comment at the beginning of the translated file and have the compiler report errors with correct line numbers in the original file. Fixes #6329. Fixes #15757. Change-Id: Ia95f6f894bb498e80d1f91fde56cd4a8009d7f9b Reviewed-on: https://go-review.googlesource.com/77150Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Per discussion with David Chase, need to check GOSSAHASH$n for increasing n until one is missing. Also if GSHS_LOGFILE is set, the compiler writes to that file, so arrange never to cache in that case. Change-Id: I3931b4e296251b99abab9bbbbbdcf94ae8c1e2a6 Reviewed-on: https://go-review.googlesource.com/77111Reviewed-by:
David Chase <drchase@google.com>
-
Russ Cox authored
It's nice that go build -gcflags=-m errors go build -gcflags=-m errors uses the cache for the second command. Even nicer is to make the second command print the same output as the first command. Fixes #22587. Change-Id: I64350839f01c86c9a095d9d22f6924cd7a0b9105 Reviewed-on: https://go-review.googlesource.com/77110Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Daniel Martí authored
Another one that is possible thanks to the new -trimprefix stringer flag. The only subtle difference is that, in the previous version, some values such as TUNSAFEPTR were stringified as "TUNSAFEPTR" instead of "UNSAFEPTR". The new String method is always consistent in removing the "T" prefix. Passes toolstash -cmp on std cmd. Change-Id: I68407f391795403dfcbbfa68c813018c0235bbb5 Reviewed-on: https://go-review.googlesource.com/77250 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 12 Nov, 2017 2 commits
-
-
Daniel Martí authored
Since the slice of names is almost exactly the same as what stringer is already generating for us. Passes toolstash -cmp on std cmd. Change-Id: I3f1e95efc690c0108236689e721627f00f79a461 Reviewed-on: https://go-review.googlesource.com/77190 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Adam Langley authored
This allows better precision and (the motivation) empty strings to be handled correctly. With that in place tests for the behaviour of empty name constraints can be added. Also fixes a compatibility issue with NSS. See #22616. Fixes #22616 Change-Id: I5139439bb58435d5f769828a4eebf8bed2d858e8 Reviewed-on: https://go-review.googlesource.com/74271Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 11 Nov, 2017 1 commit
-
-
Edan B authored
Fixes #22658 Change-Id: I00e2b007d77b6f54798f7755d0b08e4fea824392 Reviewed-on: https://go-review.googlesource.com/77170Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-