- 07 Feb, 2017 31 commits
-
-
Alex Brainman authored
CL 20845 changed Stdin.Stat() so it returns ModeNamedPipe. But introduced TestStatStdin does not test what Stdin.Stat() returns when Stdin is console. This CL adjusts both TestStatStdin and Stdin.Stat implementations to handle console. Return ModeCharDevice from Stdin.Stat() when Stdin is console on windows, just like it does on unix. Fixes #14853. Change-Id: I54d73caee2aea45a99618d11600d8e82fe20d0c0 Reviewed-on: https://go-review.googlesource.com/34090Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Matt Layher authored
Fixes #18086 Change-Id: Idc501dd37893e04a01c6ed9920147d24c0c1fa18 Reviewed-on: https://go-review.googlesource.com/34202Reviewed-by:
-
Robert Griesemer authored
Change-Id: Ia5ed3919cb492009ac8f66d175b47a69f83ee4f1 Reviewed-on: https://go-review.googlesource.com/36487Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Matthew Dempsky authored
In cmd/compile, we can directly construct obj.Auto to represent local variables and attach them to the function's obj.LSym. In preparation for being able to emit more precise DWARF info based on other compiler available information (e.g., lexical scoping). Change-Id: I9c4225ec59306bec42552838493022e0e9d70228 Reviewed-on: https://go-review.googlesource.com/36420 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Heschi Kreinick <heschi@google.com> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Sameer Ajmani authored
Change-Id: I967d897e812bee63b32bc2a7dcf453861b89b7e3 Reviewed-on: https://go-review.googlesource.com/36533Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Cherry Zhang authored
Also fixes #18687. Change-Id: I7c6d47c71e632adf4c16937a29074621f771844c Reviewed-on: https://go-review.googlesource.com/35261 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Matthew Dempsky authored
Change-Id: I713120f90fd1d2df6698c40622ccac6eae907919 Reviewed-on: https://go-review.googlesource.com/36423 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Passes toolstash -cmp. Change-Id: I202b29495ca1aaf3c52879fa99fdc0a4b86703af Reviewed-on: https://go-review.googlesource.com/36419 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jaana Burcu Dogan authored
Fixes #18504. Change-Id: I3716fc58fc98472eea15ce3617aee3890670c276 Reviewed-on: https://go-review.googlesource.com/36430Reviewed-by:
Russ Cox <rsc@golang.org>
-
Sameer Ajmani authored
Documentation was introduced by CL https://golang.org/cl/14123 but that behavior was changed later by CL https://golang.org/cl/17710. This CL deletes the stale paragraph. Fixes #18980 Change-Id: Ib434f1eac6fc814fde1be112a8f52afe6e3e0fcc Reviewed-on: https://go-review.googlesource.com/36532Reviewed-by:
-
Russ Cox authored
Fixes #18863. Change-Id: I0723563cd23728b0d43ebcc25979bf8d21e2a72c Reviewed-on: https://go-review.googlesource.com/36427 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Austin Clements authored
Currently both _MaxMem and _MaxArena32 represent the maximum arena size on 32-bit hosts (except on MIPS32 where _MaxMem is confusingly smaller than _MaxArena32). Clean up sysAlloc so that it always uses _MaxMem, which is the maximum arena size on both 32- and 64-bit architectures and is the arena size we allocate auxiliary structures for. This lets us simplify and unify some code paths and eliminate _MaxArena32. Fixes #18651. mheap.sysAlloc currently assumes that if the arena is small, we must be on a 32-bit machine and can therefore grow the arena to _MaxArena32. This breaks down on darwin/arm64, where _MaxMem is only 2 GB. As a result, on darwin/arm64, we only reserve spans and bitmap space for a 2 GB heap, and if the application tries to allocate beyond that, sysAlloc takes the 32-bit path, tries to grow the arena beyond 2 GB, and panics when it tries to grow the spans array allocation past its reserved size. This has probably been a problem for several releases now, but was only noticed recently because mapSpans didn't check the bounds on the span reservation until recently. Most likely it corrupted the bitmap before. By using _MaxMem consistently, we avoid thinking that we can grow the arena larger than we have auxiliary structures for. Change-Id: Ifef28cb746a3ead4b31c1d7348495c2242fef520 Reviewed-on: https://go-review.googlesource.com/35253Reviewed-by:
David Crawshaw <crawshaw@golang.org> Reviewed-by:
Elias Naur <elias.naur@gmail.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
mallocinit has evolved organically. Make a pass to clean it up in various ways: 1. Merge the computation of spansSize and bitmapSize. These were computed on every loop iteration of two different loops, but always have the same value, which can be derived directly from _MaxMem. This also avoids over-reserving these on MIPS, were _MaxArena32 is larger than _MaxMem. 2. Remove the ulimit -v logic. It's been disabled for many releases and the dead code paths to support it are even more wrong now than they were when it was first disabled, since now we *must* reserve spans and bitmaps for the full address space. 3. Make it clear that we're using a simple linear allocation to lay out the spans, bitmap, and arena spaces. Previously there were a lot of redundant pointer computations. Now we just bump p1 up as we reserve the spaces. In preparation for #18651. Updates #5049 (respect ulimit). Change-Id: Icbe66570d3a7a17bea227dc54fb3c4978b52a3af Reviewed-on: https://go-review.googlesource.com/35252Reviewed-by:
-
Austin Clements authored
Currently _MaxMem is a uintptr, which is going to complicate some further changes. Make it untyped so we'll be able to do untyped math on it before truncating it to a uintptr. The runtime assembly is identical before and after this change on {linux,windows}/{amd64,386}. Updates #18651. Change-Id: I0f64511faa9e0aa25179a556ab9f185ebf8c9cf8 Reviewed-on: https://go-review.googlesource.com/35251 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Rick Hudson <rlh@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This code is dead as a result of * removing the Follow pass * moving rotation detection from walk to ssa Change-Id: I14599c85bedb4e3148347b547e724187920182c4 Reviewed-on: https://go-review.googlesource.com/36484 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Cherry Zhang authored
The compiler did not emit write barrier for assigning global with struct literal, like global = T{} where T contains pointer. The relevant code path is: walkexpr OAS var_ OSTRUCTLIT oaslit anylit OSTRUCTLIT walkexpr OAS var_ nil return without adding write barrier return true break (without adding write barrier) This CL makes oaslit not apply to globals. See also CL https://go-review.googlesource.com/c/36355/ for an alternative fix. The downside of this is that it generates static data for zeroing struct now. Also this only covers global. If there is any lurking bug with implicit zeroing other than globals, this doesn't fix. Fixes #18956. Change-Id: Ibcd27e4fae3aa38390ffa94a32a9dd7a802e4b37 Reviewed-on: https://go-review.googlesource.com/36410Reviewed-by: -
Russ Cox authored
We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem to the list in response to #17549 - not being able to find any certs otherwise. Now we have #18813, where CentOS 6 apparently has both that file and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while the former is not. Moving the new CentOS 7 file to the bottom of the list should fix both problems: the CentOS 7 system that didn't have any of the other files in the list will still find the new one, and existing systems will still keep using what they were using instead of preferring the new path that may or may not be complete on some systems. Fixes #18813. Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba Reviewed-on: https://go-review.googlesource.com/36429 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
Daniel Martí authored
Change-Id: Ib47e295e8646b769c30fd81e5c7f20f964df163e Reviewed-on: https://go-review.googlesource.com/36335Reviewed-by:
Filippo Valsorda <hi@filippo.io> Reviewed-by:
-
Robert Griesemer authored
Fixes #18950. Change-Id: I9f94748f36a896bcadc96f0642eb1f3bff387950 Reviewed-on: https://go-review.googlesource.com/36481Reviewed-by:
-
Daniel Martí authored
Fixes #18914. Change-Id: Iec90d6aaa62595983db28b17794429f3c9a3dc36 Reviewed-on: https://go-review.googlesource.com/36272Reviewed-by:
-
Russ Cox authored
This reverts commit a855da29. Change-Id: I23c0351b0708877e0b3d1b44a2bc2799cee52cd1 Reviewed-on: https://go-review.googlesource.com/36426Reviewed-by:
-
Seth Vargo authored
It looks like this conditional may have been refactored at some point, but the logic was still very confusing. The outer conditional checks if the function is variadic, so there's no need to verify that in the result. Additionally, since the function isn't variadic, there is no reason to permit the function call if the number of input arguments is less than the function signature requires. Change-Id: Ia957cf83d1c900c08dd66384efcb74f0c368422e Reviewed-on: https://go-review.googlesource.com/35491 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Cherry Zhang authored
The Follow pass in the assembler backend reorders and copies instructions. This even applies to hand-written assembly code, which in many cases don't want to be reordered. Now that the SSA compiler does a good job for laying out instructions, the benefit of this pass is very little: AMD64: (old = with Follow, new = without Follow) name old time/op new time/op delta BinaryTree17-12 2.78s ± 1% 2.79s ± 1% +0.44% (p=0.000 n=20+19) Fannkuch11-12 3.11s ± 0% 3.31s ± 1% +6.16% (p=0.000 n=19+19) FmtFprintfEmpty-12 50.9ns ± 1% 51.6ns ± 3% +1.40% (p=0.000 n=17+20) FmtFprintfString-12 127ns ± 0% 128ns ± 1% +0.88% (p=0.000 n=17+17) FmtFprintfInt-12 122ns ± 0% 123ns ± 1% +0.76% (p=0.000 n=20+19) FmtFprintfIntInt-12 185ns ± 1% 186ns ± 1% +0.65% (p=0.000 n=20+19) FmtFprintfPrefixedInt-12 192ns ± 1% 202ns ± 1% +4.99% (p=0.000 n=20+19) FmtFprintfFloat-12 284ns ± 0% 288ns ± 0% +1.33% (p=0.000 n=15+19) FmtManyArgs-12 807ns ± 0% 804ns ± 0% -0.44% (p=0.000 n=16+18) GobDecode-12 7.23ms ± 1% 7.21ms ± 1% ~ (p=0.052 n=20+20) GobEncode-12 6.09ms ± 1% 6.12ms ± 1% +0.41% (p=0.002 n=19+19) Gzip-12 253ms ± 1% 255ms ± 1% +0.95% (p=0.000 n=18+20) Gunzip-12 38.4ms ± 0% 38.5ms ± 0% +0.34% (p=0.000 n=17+17) HTTPClientServer-12 95.4µs ± 2% 96.1µs ± 1% +0.78% (p=0.002 n=19+19) JSONEncode-12 16.5ms ± 1% 16.6ms ± 1% +1.17% (p=0.000 n=19+19) JSONDecode-12 54.6ms ± 1% 55.3ms ± 1% +1.23% (p=0.000 n=18+18) Mandelbrot200-12 4.47ms ± 0% 4.47ms ± 0% +0.06% (p=0.000 n=18+18) GoParse-12 3.47ms ± 1% 3.47ms ± 1% ~ (p=0.583 n=20+20) RegexpMatchEasy0_32-12 84.8ns ± 1% 85.2ns ± 2% +0.51% (p=0.022 n=20+20) RegexpMatchEasy0_1K-12 206ns ± 1% 206ns ± 1% ~ (p=0.770 n=20+20) RegexpMatchEasy1_32-12 82.8ns ± 1% 83.4ns ± 1% +0.64% (p=0.000 n=20+19) RegexpMatchEasy1_1K-12 363ns ± 1% 361ns ± 1% -0.48% (p=0.007 n=20+20) RegexpMatchMedium_32-12 126ns ± 1% 126ns ± 0% +0.72% (p=0.000 n=20+20) RegexpMatchMedium_1K-12 39.1µs ± 1% 39.8µs ± 0% +1.73% (p=0.000 n=19+19) RegexpMatchHard_32-12 1.97µs ± 0% 1.98µs ± 1% +0.29% (p=0.005 n=18+20) RegexpMatchHard_1K-12 59.5µs ± 1% 59.8µs ± 1% +0.36% (p=0.000 n=18+20) Revcomp-12 442ms ± 1% 445ms ± 2% +0.67% (p=0.000 n=19+20) Template-12 58.0ms ± 1% 57.5ms ± 1% -0.85% (p=0.000 n=19+19) TimeParse-12 311ns ± 0% 314ns ± 0% +0.94% (p=0.000 n=20+18) TimeFormat-12 350ns ± 3% 346ns ± 0% ~ (p=0.076 n=20+19) [Geo mean] 55.9µs 56.4µs +0.80% ARM32: name old time/op new time/op delta BinaryTree17-4 30.4s ± 0% 30.1s ± 0% -1.14% (p=0.000 n=10+8) Fannkuch11-4 13.7s ± 0% 13.6s ± 0% -0.75% (p=0.000 n=10+10) FmtFprintfEmpty-4 664ns ± 1% 651ns ± 1% -1.96% (p=0.000 n=7+8) FmtFprintfString-4 1.83µs ± 2% 1.77µs ± 2% -3.21% (p=0.000 n=10+10) FmtFprintfInt-4 1.57µs ± 2% 1.54µs ± 2% -2.25% (p=0.007 n=10+10) FmtFprintfIntInt-4 2.37µs ± 2% 2.31µs ± 1% -2.68% (p=0.000 n=10+10) FmtFprintfPrefixedInt-4 2.14µs ± 2% 2.10µs ± 1% -1.83% (p=0.006 n=10+10) FmtFprintfFloat-4 3.69µs ± 2% 3.74µs ± 1% +1.60% (p=0.000 n=10+10) FmtManyArgs-4 9.43µs ± 1% 9.17µs ± 1% -2.70% (p=0.000 n=10+10) GobDecode-4 76.3ms ± 1% 75.5ms ± 1% -1.14% (p=0.003 n=10+10) GobEncode-4 70.7ms ± 2% 69.0ms ± 1% -2.36% (p=0.000 n=10+10) Gzip-4 2.64s ± 1% 2.65s ± 0% +0.59% (p=0.002 n=10+10) Gunzip-4 402ms ± 0% 398ms ± 0% -1.11% (p=0.000 n=10+9) HTTPClientServer-4 458µs ± 0% 457µs ± 0% ~ (p=0.247 n=10+10) JSONEncode-4 171ms ± 0% 172ms ± 0% +0.56% (p=0.000 n=10+10) JSONDecode-4 672ms ± 1% 668ms ± 1% ~ (p=0.105 n=10+10) Mandelbrot200-4 33.5ms ± 0% 33.5ms ± 0% ~ (p=0.156 n=9+10) GoParse-4 33.9ms ± 0% 34.0ms ± 0% +0.36% (p=0.031 n=9+9) RegexpMatchEasy0_32-4 823ns ± 1% 835ns ± 1% +1.49% (p=0.000 n=8+8) RegexpMatchEasy0_1K-4 3.99µs ± 0% 4.02µs ± 1% +0.92% (p=0.000 n=8+10) RegexpMatchEasy1_32-4 877ns ± 3% 904ns ± 2% +3.07% (p=0.012 n=10+10) RegexpMatchEasy1_1K-4 5.99µs ± 0% 5.97µs ± 1% -0.38% (p=0.023 n=8+8) RegexpMatchMedium_32-4 1.40µs ± 2% 1.40µs ± 2% ~ (p=0.590 n=10+9) RegexpMatchMedium_1K-4 357µs ± 0% 355µs ± 1% -0.72% (p=0.000 n=7+8) RegexpMatchHard_32-4 22.3µs ± 0% 22.1µs ± 0% -0.49% (p=0.000 n=8+7) RegexpMatchHard_1K-4 661µs ± 0% 658µs ± 0% -0.42% (p=0.000 n=8+7) Revcomp-4 46.3ms ± 0% 46.3ms ± 0% ~ (p=0.393 n=10+10) Template-4 753ms ± 1% 750ms ± 0% ~ (p=0.211 n=10+9) TimeParse-4 4.28µs ± 1% 4.22µs ± 1% -1.34% (p=0.000 n=8+10) TimeFormat-4 9.00µs ± 0% 9.05µs ± 0% +0.59% (p=0.000 n=10+10) [Geo mean] 538µs 535µs -0.55% ARM64: name old time/op new time/op delta BinaryTree17-8 8.39s ± 0% 8.39s ± 0% ~ (p=0.684 n=10+10) Fannkuch11-8 5.95s ± 0% 5.99s ± 0% +0.63% (p=0.000 n=10+10) FmtFprintfEmpty-8 116ns ± 0% 116ns ± 0% ~ (all equal) FmtFprintfString-8 361ns ± 0% 360ns ± 0% -0.31% (p=0.003 n=8+6) FmtFprintfInt-8 290ns ± 0% 290ns ± 0% ~ (p=0.620 n=9+9) FmtFprintfIntInt-8 476ns ± 1% 469ns ± 0% -1.47% (p=0.000 n=10+6) FmtFprintfPrefixedInt-8 412ns ± 2% 417ns ± 2% +1.39% (p=0.006 n=9+10) FmtFprintfFloat-8 652ns ± 1% 652ns ± 0% ~ (p=0.161 n=10+8) FmtManyArgs-8 1.94µs ± 0% 1.94µs ± 2% ~ (p=0.781 n=10+10) GobDecode-8 17.7ms ± 1% 17.7ms ± 0% ~ (p=0.962 n=10+7) GobEncode-8 15.6ms ± 0% 15.6ms ± 1% ~ (p=0.063 n=10+10) Gzip-8 786ms ± 0% 787ms ± 0% ~ (p=0.356 n=10+9) Gunzip-8 127ms ± 0% 127ms ± 0% +0.08% (p=0.028 n=10+9) HTTPClientServer-8 198µs ± 6% 198µs ± 7% ~ (p=0.796 n=10+10) JSONEncode-8 42.5ms ± 0% 42.2ms ± 0% -0.73% (p=0.000 n=9+8) JSONDecode-8 158ms ± 1% 162ms ± 0% +2.28% (p=0.000 n=10+9) Mandelbrot200-8 10.1ms ± 0% 10.1ms ± 0% -0.01% (p=0.000 n=10+9) GoParse-8 8.54ms ± 1% 8.63ms ± 1% +1.06% (p=0.000 n=10+9) RegexpMatchEasy0_32-8 231ns ± 1% 225ns ± 0% -2.52% (p=0.000 n=9+10) RegexpMatchEasy0_1K-8 1.63µs ± 0% 1.63µs ± 0% ~ (p=0.170 n=10+10) RegexpMatchEasy1_32-8 253ns ± 0% 249ns ± 0% -1.41% (p=0.000 n=9+10) RegexpMatchEasy1_1K-8 2.08µs ± 0% 2.08µs ± 0% -0.32% (p=0.000 n=9+10) RegexpMatchMedium_32-8 355ns ± 1% 351ns ± 0% -1.04% (p=0.007 n=10+7) RegexpMatchMedium_1K-8 104µs ± 0% 104µs ± 0% ~ (p=0.148 n=10+10) RegexpMatchHard_32-8 5.79µs ± 0% 5.79µs ± 0% ~ (p=0.578 n=10+10) RegexpMatchHard_1K-8 176µs ± 0% 176µs ± 0% ~ (p=0.137 n=10+10) Revcomp-8 1.37s ± 1% 1.36s ± 1% -0.26% (p=0.023 n=10+10) Template-8 151ms ± 1% 154ms ± 1% +2.14% (p=0.000 n=9+10) TimeParse-8 723ns ± 2% 721ns ± 1% ~ (p=0.592 n=10+10) TimeFormat-8 804ns ± 2% 798ns ± 3% ~ (p=0.344 n=10+10) [Geo mean] 154µs 154µs -0.02% Therefore remove this pass. Also reduce text size by 0.5~2%. Comment out some dead code in runtime/sys_nacl_amd64p32.s which contains undefined symbols. Change-Id: I1473986fe5b18b3d2554ce96cdc6f0999b8d955d Reviewed-on: https://go-review.googlesource.com/36205 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Mura Li authored
For detailed explanation of the adopted (Eric Young's) algorithm, see http://ftp.nluug.nl/security/coast/libs/libdes/ALGORITHM benchmark old ns/op new ns/op delta BenchmarkEncrypt-16 649 164 -74.73% BenchmarkDecrypt-16 546 156 -71.43% BenchmarkTDESEncrypt-16 1651 385 -76.68% BenchmarkTDESDecrypt-16 1645 378 -77.02% benchmark old MB/s new MB/s speedup BenchmarkEncrypt-16 12.31 48.76 3.96x BenchmarkDecrypt-16 14.64 51.03 3.49x BenchmarkTDESEncrypt-16 4.84 20.74 4.29x BenchmarkTDESDecrypt-16 4.86 21.16 4.35x Change-Id: Ic3e1fe3340419ec5a0e6379434911eb41e0246f6 Reviewed-on: https://go-review.googlesource.com/36490 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alan Donovan authored
This code may be pointless, but it is legal. Fixes golang/go#18268 Change-Id: Ibacae583606e1a6fdf0c0f01abe2e22e9e608393 Reviewed-on: https://go-review.googlesource.com/34194Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Nigel Tao authored
The doc comment for Rectangle.Intersect clearly states, "If the two rectangles do not overlap then the zero rectangle will be returned." Prior to this fix, calling Intersect on adjacent but non-overlapping rectangles would return an empty but non-zero rectangle. The fix essentially changes if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc } to if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc } (note that the > signs have become >= signs), but changing that line to: if r.Empty() { etc } seems clearer (and equivalent). Change-Id: Ia654e4b9dc805978db3e94d7a9718b6366005360 Reviewed-on: https://go-review.googlesource.com/34853Reviewed-by: -
Michael Matloob authored
When generating pprof profiles in proto format, symbolize the profiles. Change-Id: I2471ed7f919483e5828868306418a63e41aff5c5 Reviewed-on: https://go-review.googlesource.com/34192 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Shintaro Kaneko authored
Change-Id: Iad5ff820a95f5082b75aa5260e40c33c7b0ecf22 Reviewed-on: https://go-review.googlesource.com/35990Reviewed-by:
-
Robert Griesemer authored
This is a follow-up on https://go-review.googlesource.com/36470 and leads to a more stable fix. The above CL relied on filtering of multiple errors on the same line to avoid more than one error for an `if` statement of the form `if a := 10 {}`. This CL avoids the secondary error ("missing condition in if statement") in the first place. For #18915. Change-Id: I8517f485cc2305965276c17d8f8797d61ef9e999 Reviewed-on: https://go-review.googlesource.com/36479 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Quentin Smith authored
When running benchmarks, print "goos", "goarch", and "pkg" labels. This makes it easier to refer to benchmark logs and understand how they were generated. "pkg" is printed only for benchmarks located in GOPATH. Change-Id: I397cbdd57b9fe8cbabbb354ec7bfba59f5625c42 Reviewed-on: https://go-review.googlesource.com/36356 Run-TryBot: Quentin Smith <quentin@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
This CL picks up a couple of minor fixes that were present in https://go-review.googlesource.com/#/c/36213/6..5 but accidentally got dropped in https://go-review.googlesource.com/#/c/36213/ because I submitted from the wrong client. Change-Id: I3ad0d20457152ea9a116cbb65a23eb0dc3a8525e Reviewed-on: https://go-review.googlesource.com/36471Reviewed-by:
-
- 06 Feb, 2017 9 commits
-
-
Robert Griesemer authored
To avoid confusion caused by the term "named type" (which now just means a type with a name, but formerly meant a type declared with a non-alias type declaration), a type declaration now comes in two forms: alias declarations and type definitions. Both declare a type name, but type definitions also define new types. Replace the use of "named type" with "defined type" elsewhere in the spec. For #18130. Change-Id: I49f5ddacefce90354eb65ee5fbf10ba737221995 Reviewed-on: https://go-review.googlesource.com/36213Reviewed-by:
Rob Pike <r@golang.org>
-
Robert Griesemer authored
For code such as if a := 10 { ... the 1.7 compiler reported a := 10 used as value while the 1.8 compiler reported invalid condition, tag, or type switch guard Changed the error message to match the 1.7 compiler. Fixes #18915. Change-Id: I01308862e461922e717f9f8295a9db53d5a914eb Reviewed-on: https://go-review.googlesource.com/36470 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: -
Matthew Dempsky authored
Removes all external uses of Linksym and Pkglookup, which are the only two exported functions that return Syms. Also add Duffcopy and Duffzero since they're used often enough across SSA backends. Passes toolstash -cmp. Change-Id: I8d3fd048ad5cd676fc46378f09a917569ffc9b2c Reviewed-on: https://go-review.googlesource.com/36418 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Crawshaw authored
Now `go test -buildmode=pie std -short` passes on linux/amd64. Updates #18968 Change-Id: Ide21877713e00edc64c1700c950016d6bff8de0e Reviewed-on: https://go-review.googlesource.com/36417Reviewed-by:
-
Matthew Dempsky authored
The arch-specific SSA backends now no longer use gc.Sym either. Passes toolstash -cmp. Change-Id: Ic13b934b92a1b89b4b79c6c4796ab0a137608163 Reviewed-on: https://go-review.googlesource.com/36416 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Gc's Sym type represents a package-qualified identifier, which is a frontend concept and doesn't belong in SSA. Bonus: we can replace some interface{} types with *obj.LSym. Passes toolstash -cmp. Change-Id: I456eb9957207d80f99f6eb9b8eab4a1f3263e9ed Reviewed-on: https://go-review.googlesource.com/36415 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Andrew Gerrand authored
Dave and Jason have moved on to other things. Change-Id: I702d11bedfab1f47a33679a48c2309f49021229e Reviewed-on: https://go-review.googlesource.com/36450Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Michael Matloob authored
This change defines runtime/pprof.SetGoroutineLabels and runtime/pprof.Do, which are used to set profiler labels on goroutines. The change defines functions in the runtime for setting and getting profile labels, and sets and unsets profile labels when goroutines are created and deleted. The change also adds the package runtime/internal/proflabel, which defines the structure the runtime uses to store profile labels. Change-Id: I747a4400141f89b6e8160dab6aa94ca9f0d4c94d Reviewed-on: https://go-review.googlesource.com/34198 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
Original code fixed in https://go-review.googlesource.com/#/c/36359/. Fixes #18820. Change-Id: I060e6c9d0e312b4fd5d0674aff131055bf5cf61d Reviewed-on: https://go-review.googlesource.com/36412 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
