- 09 May, 2017 12 commits
-
-
Cherry Zhang authored
ARM64 assembler backend only accepts loads and stores with small or aligned offset. The compiler therefore can only fold small or aligned offsets into loads and stores. For locals and args, their offsets to SP are not known until very late, and the compiler makes conservative decision not folding some of them. However, in most cases, the offset is indeed small or aligned, and can be folded into load and store (but actually not). This CL adds support of loads and stores with large and unaligned offsets. When the offset doesn't fit into the instruction, it uses two instructions and (for very large offset) the constant pool. This way, the compiler doesn't need to be conservative, and can simply fold the offset. To make it work, the assembler's optab matching rules need to be changed. Before, MOVD accepts C_UAUTO32K which matches multiple of 8 between 0 and 32K, and also C_UAUTO16K, which may not be multiple of 8 and does not fit into MOVD instruction. The assembler errors in the latter case. This change makes it only matches multiple of 8 (or offsets within ±256, which also fits in instruction), and uses the large-or-unaligned-offset rule for things doesn't fit (without error). Other sized move rules are changed similarly. Class C_UAUTO64K and C_UOREG64K are removed, as they are never used. In shared library, load/store of global is rewritten to using GOT and temp register, which conflicts with the use of temp register for assembling large offset. So the folding is disabled for globals in shared library mode. Reduce cmd/go binary size by 2%. name old time/op new time/op delta BinaryTree17-8 8.67s ± 0% 8.61s ± 0% -0.60% (p=0.000 n=9+10) Fannkuch11-8 6.24s ± 0% 6.19s ± 0% -0.83% (p=0.000 n=10+9) FmtFprintfEmpty-8 116ns ± 0% 116ns ± 0% ~ (all equal) FmtFprintfString-8 196ns ± 0% 192ns ± 0% -1.89% (p=0.000 n=10+10) FmtFprintfInt-8 199ns ± 0% 198ns ± 0% -0.35% (p=0.001 n=9+10) FmtFprintfIntInt-8 294ns ± 0% 293ns ± 0% -0.34% (p=0.000 n=8+8) FmtFprintfPrefixedInt-8 318ns ± 1% 318ns ± 1% ~ (p=1.000 n=10+10) FmtFprintfFloat-8 537ns ± 0% 531ns ± 0% -1.17% (p=0.000 n=9+10) FmtManyArgs-8 1.19µs ± 1% 1.18µs ± 1% -1.41% (p=0.001 n=10+10) GobDecode-8 17.2ms ± 1% 17.3ms ± 2% ~ (p=0.165 n=10+10) GobEncode-8 14.7ms ± 1% 14.7ms ± 2% ~ (p=0.631 n=10+10) Gzip-8 837ms ± 0% 836ms ± 0% -0.14% (p=0.006 n=9+10) Gunzip-8 141ms ± 0% 139ms ± 0% -1.24% (p=0.000 n=9+10) HTTPClientServer-8 256µs ± 1% 253µs ± 1% -1.35% (p=0.000 n=10+10) JSONEncode-8 40.1ms ± 1% 41.3ms ± 1% +3.06% (p=0.000 n=10+9) JSONDecode-8 157ms ± 1% 156ms ± 1% -0.83% (p=0.001 n=9+8) Mandelbrot200-8 8.94ms ± 0% 8.94ms ± 0% +0.02% (p=0.000 n=9+9) GoParse-8 8.69ms ± 0% 8.54ms ± 1% -1.69% (p=0.000 n=8+10) RegexpMatchEasy0_32-8 227ns ± 1% 228ns ± 1% +0.48% (p=0.016 n=10+9) RegexpMatchEasy0_1K-8 1.92µs ± 0% 1.63µs ± 0% -15.08% (p=0.000 n=10+9) RegexpMatchEasy1_32-8 256ns ± 0% 251ns ± 0% -2.19% (p=0.000 n=10+9) RegexpMatchEasy1_1K-8 2.38µs ± 0% 2.09µs ± 0% -12.49% (p=0.000 n=10+9) RegexpMatchMedium_32-8 352ns ± 0% 354ns ± 0% +0.39% (p=0.002 n=10+9) RegexpMatchMedium_1K-8 106µs ± 0% 106µs ± 0% -0.05% (p=0.005 n=10+9) RegexpMatchHard_32-8 5.92µs ± 0% 5.89µs ± 0% -0.40% (p=0.000 n=9+8) RegexpMatchHard_1K-8 180µs ± 0% 179µs ± 0% -0.14% (p=0.000 n=10+9) Revcomp-8 1.20s ± 0% 1.13s ± 0% -6.29% (p=0.000 n=9+8) Template-8 159ms ± 1% 154ms ± 1% -3.14% (p=0.000 n=9+10) TimeParse-8 800ns ± 3% 769ns ± 1% -3.91% (p=0.000 n=10+10) TimeFormat-8 826ns ± 2% 817ns ± 2% -1.04% (p=0.050 n=10+10) [Geo mean] 145µs 143µs -1.79% Change-Id: I5fc42087cee9b54ea414f8ef6d6d020b80eb5985 Reviewed-on: https://go-review.googlesource.com/42172 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
David Chase <drchase@google.com>
-
Josh Bleecher Snyder authored
It can be disabled by setting the environment variable GO19CONCURRENTCOMPILATION=0, or with -gcflags=-c=1. Fixes #15756. Change-Id: I7acbf16330512b62ee14ecbab1f46b53ec5a67b6 Reviewed-on: https://go-review.googlesource.com/41820 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
It is disabled by default. It can be enabled by setting the environment variable GO19CONCURRENTCOMPILATION=1. Benchmarking results are presented in a grid. Columns are different values of c (compiler backend concurrency); rows are different values of p (process concurrency). 'go build -a std cmd', a 4 core raspberry pi 3: c=1 c=2 c=4 StdCmd/p=1 504s ± 2% 413s ± 4% 367s ± 3% StdCmd/p=2 314s ± 3% 266s ± 4% 267s ± 4% StdCmd/p=4 254s ± 5% 241s ± 5% 238s ± 6% 'go build -a std cmd', an 8 core darwin/amd64 laptop: c=1 c=2 c=4 c=6 c=8 StdCmd/p=1 40.4s ± 7% 31.0s ± 1% 27.3s ± 1% 27.8s ± 0% 27.7s ± 0% StdCmd/p=2 21.9s ± 1% 17.9s ± 1% 16.9s ± 1% 17.0s ± 1% 17.2s ± 0% StdCmd/p=4 17.4s ± 2% 14.5s ± 2% 13.3s ± 2% 13.5s ± 2% 13.6s ± 2% StdCmd/p=6 16.9s ± 1% 14.2s ± 2% 13.1s ± 2% 13.2s ± 2% 13.3s ± 2% StdCmd/p=8 16.7s ± 2% 14.2s ± 2% 13.2s ± 3% 13.2s ± 2% 13.4s ± 2% 'go build -a std cmd', a 96 core arm64 server: c=1 c=2 c=4 c=6 c=8 c=16 c=32 c=64 c=96 StdCmd/p=1 173s ± 1% 133s ± 1% 114s ± 1% 109s ± 1% 106s ± 0% 106s ± 1% 107s ± 1% 110s ± 1% 113s ± 1% StdCmd/p=2 94.2s ± 2% 71.5s ± 1% 61.7s ± 1% 58.7s ± 1% 57.5s ± 2% 56.9s ± 1% 58.0s ± 1% 59.6s ± 1% 61.0s ± 1% StdCmd/p=4 74.1s ± 2% 53.5s ± 1% 43.7s ± 2% 40.5s ± 1% 39.2s ± 2% 38.9s ± 2% 39.5s ± 3% 40.3s ± 2% 40.8s ± 1% StdCmd/p=6 69.3s ± 1% 50.2s ± 2% 40.3s ± 2% 37.3s ± 3% 36.0s ± 3% 35.3s ± 2% 36.0s ± 2% 36.8s ± 2% 37.5s ± 2% StdCmd/p=8 66.1s ± 2% 47.7s ± 2% 38.6s ± 2% 35.7s ± 2% 34.4s ± 1% 33.6s ± 2% 34.2s ± 2% 34.6s ± 1% 35.0s ± 1% StdCmd/p=16 63.4s ± 2% 45.3s ± 2% 36.3s ± 2% 33.3s ± 2% 32.0s ± 3% 31.6s ± 2% 32.1s ± 2% 32.5s ± 2% 32.7s ± 2% StdCmd/p=32 62.2s ± 1% 44.2s ± 2% 35.3s ± 2% 32.4s ± 2% 31.2s ± 2% 30.9s ± 2% 31.1s ± 2% 31.7s ± 2% 32.0s ± 2% StdCmd/p=64 62.2s ± 1% 44.3s ± 2% 35.4s ± 2% 32.4s ± 2% 31.2s ± 2% 30.9s ± 2% 31.2s ± 2% 31.8s ± 3% 32.2s ± 3% StdCmd/p=96 62.2s ± 2% 44.4s ± 2% 35.3s ± 2% 32.3s ± 2% 31.1s ± 2% 30.9s ± 3% 31.3s ± 2% 31.7s ± 1% 32.1s ± 2% benchjuju, an 8 core darwin/amd64 laptop: c=1 c=2 c=4 c=6 c=8 BuildJuju/p=1 55.3s ± 0% 46.3s ± 0% 41.9s ± 0% 41.4s ± 1% 41.3s ± 0% BuildJuju/p=2 33.7s ± 1% 28.4s ± 1% 26.7s ± 1% 26.6s ± 1% 26.8s ± 1% BuildJuju/p=4 24.7s ± 1% 22.3s ± 1% 21.4s ± 1% 21.7s ± 1% 21.8s ± 1% BuildJuju/p=6 20.6s ± 1% 19.3s ± 2% 19.4s ± 1% 19.7s ± 1% 19.9s ± 1% BuildJuju/p=8 20.6s ± 2% 19.5s ± 2% 19.3s ± 2% 19.6s ± 1% 19.8s ± 2% Updates #15756 Change-Id: I8a56e88953071a05eee764002024c54cd888a56c Reviewed-on: https://go-review.googlesource.com/41819 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
A pointer type of underlying type unsafe.Pointer can be used in unsafe conversions. Document unfortunate status quo. Fixes #19306. Change-Id: I28172508a200561f8df366bbf2c2807ef3b48c97 Reviewed-on: https://go-review.googlesource.com/42132Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Russ Cox <rsc@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Ibrahim AshShohail authored
Fixes #20294 Change-Id: I32ac862fe00180210a04103cc94c4d9fef5d1b6c Reviewed-on: https://go-review.googlesource.com/42992Reviewed-by:
-
Austin Clements authored
TestGoroutineCounts currently depends on timing to get 100 goroutines to a known blocking point before taking a profile. This fails frequently, with different goroutines captured at different stacks. The test is disabled on openbsd because it was too flaky, but in fact it flakes on all platforms. Fix this by using Gosched instead of timing. This is both much more reliable and makes the test run faster. Fixes #15156. Change-Id: Ia6e894196d717655b8fb4ee96df53f6cc8bc5f1f Reviewed-on: https://go-review.googlesource.com/42953 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
This permits the user to override the code generation flag when they know better. This is always a good policy for all flags automatically inserted by the build system. Doing this now so that I can write a test for #20290. Update #20290 Change-Id: I5c6708a277238d571b8d037993a5a59e2a442e98 Reviewed-on: https://go-review.googlesource.com/42952 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Rob Phoenix authored
Issue #15228 describes that reserved address blocks should be used for documentation purposes. This change updates the prefix length so the IPv4 address adheres to this. Change-Id: I237d9cce1a71f4fd95f927ec894ce53fa806047f Reviewed-on: https://go-review.googlesource.com/42991 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alex Brainman authored
Change-Id: I19a724ea4eb1ba0ff558721650c89a949e53b7c7 Reviewed-on: https://go-review.googlesource.com/42895Reviewed-by:
-
Alex Brainman authored
This CL improves on my Windows 7 name old time/op new time/op delta Readdirname 58.1µs ± 1% 58.1µs ± 0% ~ (p=0.817 n=8+8) Readdir 58.0µs ± 3% 57.8µs ± 0% ~ (p=0.944 n=9+8) name old alloc/op new alloc/op delta Readdirname 3.03kB ± 0% 2.84kB ± 0% -6.33% (p=0.000 n=10+10) Readdir 3.00kB ± 0% 2.81kB ± 0% -6.40% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Readdirname 34.0 ± 0% 30.0 ± 0% -11.76% (p=0.000 n=10+10) Readdir 33.0 ± 0% 29.0 ± 0% -12.12% (p=0.000 n=10+10) on my Windows XP name old time/op new time/op delta Readdirname-2 85.5µs ± 0% 84.0µs ± 0% -1.83% (p=0.000 n=10+10) Readdir-2 84.6µs ± 0% 83.5µs ± 0% -1.31% (p=0.000 n=10+9) name old alloc/op new alloc/op delta Readdirname-2 6.52kB ± 0% 5.66kB ± 0% -13.25% (p=0.000 n=10+10) Readdir-2 6.39kB ± 0% 5.53kB ± 0% -13.52% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Readdirname-2 78.0 ± 0% 66.0 ± 0% -15.38% (p=0.000 n=10+10) Readdir-2 77.0 ± 0% 65.0 ± 0% -15.58% (p=0.000 n=10+10) Change-Id: I5d698eca86b8e94a46b6cfbd5947898b7b3fbdbd Reviewed-on: https://go-review.googlesource.com/42894Reviewed-by:
-
ltnwgl authored
In down(), if two children are equal, we can choose either one. Inspired by https://codereview.appspot.com/6613064/ Change-Id: Iaad4ca5e2f5111bf3abb87f606584e7d274c620b Reviewed-on: https://go-review.googlesource.com/38612 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Rob Phoenix authored
Further examples to support the net package. See issue #5757 Change-Id: I839fd97a468c8d9195e8f4a0ee886ba50ca3f382 Reviewed-on: https://go-review.googlesource.com/42912Reviewed-by:
-
- 08 May, 2017 4 commits
-
-
Robert Griesemer authored
Also: Removed misleading comment. Fixes #20232. Change-Id: I0b141b1360ac53267b7ebfcec7a2e2a238f3f46c Reviewed-on: https://go-review.googlesource.com/42930 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bill O'Farrell authored
As necessary, math functions were structured to use stubs, so that they can be accelerated with assembly on any platform. Technique used was minimax polynomial approximation using tables of polynomial coefficients, with argument range reduction. Benchmark New Old Speedup BenchmarkAcos 12.2 47.5 3.89 BenchmarkAcosh 18.5 56.2 3.04 BenchmarkAsin 13.1 40.6 3.10 BenchmarkAsinh 19.4 62.8 3.24 BenchmarkAtan 10.1 23 2.28 BenchmarkAtanh 19.1 53.2 2.79 BenchmarkAtan2 16.5 33.9 2.05 BenchmarkCbrt 14.8 58 3.92 BenchmarkErf 10.8 20.1 1.86 BenchmarkErfc 11.2 23.5 2.10 BenchmarkExp 8.77 53.8 6.13 BenchmarkExpm1 10.1 38.3 3.79 BenchmarkLog 13.1 40.1 3.06 BenchmarkLog1p 12.7 38.3 3.02 BenchmarkPowInt 31.7 40.5 1.28 BenchmarkPowFrac 33.1 141 4.26 BenchmarkTan 11.5 30 2.61 Accuracy was tested against a high precision reference function to determine maximum error. Note: ulperr is error in "units in the last place" max ulperr Acos 1.15 Acosh 1.07 Asin 2.22 Asinh 1.72 Atan 1.41 Atanh 3.00 Atan2 1.45 Cbrt 1.18 Erf 1.29 Erfc 4.82 Exp 1.00 Expm1 2.26 Log 0.94 Log1p 2.39 Tan 3.14 Pow will have 99.99% correctly rounded results with reasonable inputs producing numeric (non Inf or NaN) results Change-Id: I850e8cf7b70426e8b54ec49d74acd4cddc8c6cb2 Reviewed-on: https://go-review.googlesource.com/38585Reviewed-by:Michael Munday <munday@ca.ibm.com> Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Marvin Stenger authored
The test "TestTryGrowByResliceInlined" introduced in c08ac367 broke the noopt builder as it fails when inlining is disabled. Since there are currently no other options at hand for checking inlined-ness other than looking at emited symbols of the compilation, we for now skip the problem causing test by default and only run it on one specific builder ("linux-amd64"). Also see CL 42813, which introduced the test and contains comments suggesting this temporary solution. Change-Id: I3978ab0831da04876cf873d78959f821c459282b Reviewed-on: https://go-review.googlesource.com/42820Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
-
Alex Brainman authored
Use closure parameter instead of external variable to remove 1 allocation. I tried to add test, but it is difficult to add something simple and not flake here. I did test this with: diff --git a/src/net/writev_test.go b/src/net/writev_test.go index 4c05be4..e417d68 100644 --- a/src/net/writev_test.go +++ b/src/net/writev_test.go @@ -99,6 +99,15 @@ func TestBuffers_WriteTo(t *testing.T) { } } +func TestBuffers_WriteToAllocs(t *testing.T) { + allocs := testing.AllocsPerRun(10, func() { + testBuffer_writeTo(t, 10, false) + }) + if allocs > 0 { + t.Fatalf("got %v; want 0", allocs) + } +} + func testBuffer_writeTo(t *testing.T, chunks int, useCopy bool) { oldHook := poll.TestHookDidWritev defer func() { poll.TestHookDidWritev = oldHook }() It makes allocation count go down by 1 after the fix. Before: C:\>u:\test -test.v -test.run=WriteToAllocs === RUN TestBuffers_WriteToAllocs --- FAIL: TestBuffers_WriteToAllocs (0.05s) writev_test.go:107: got 66; want 0 FAIL and after: C:\>u:\test -test.v -test.run=WriteToAllocs === RUN TestBuffers_WriteToAllocs --- FAIL: TestBuffers_WriteToAllocs (0.04s) writev_test.go:107: got 65; want 0 FAIL Thanks to @MichaelMonashev for report and the fix. Fixes #19222 Change-Id: I0f73cd9e2c8bbaa0653083f81f3ccb83b5ea84e1 Reviewed-on: https://go-review.googlesource.com/42893Reviewed-by:
-
- 07 May, 2017 5 commits
-
-
Elias Naur authored
Ever since CL 33301 linking darwin/arm64 excutables has resulted in warnings like: ld: warning: -no_pie ignored for arm64 Remove -no_pie on darwin/arm64. Change-Id: I9f7685351fa8cce29795283e1a24fc7a6753d698 Reviewed-on: https://go-review.googlesource.com/42815 Run-TryBot: Elias Naur <elias.naur@gmail.com> Reviewed-by:
-
Kevin Burke authored
Also switch "stating" to "statting" to describe applying os.Stat to a resource; the former is more confusable than the latter. Change-Id: I9d8e3506bd383f8f1479c05948c03b8c633dc4af Reviewed-on: https://go-review.googlesource.com/42855Reviewed-by:
-
Marvin Stenger authored
In the common case, the grow method only needs to reslice the internal buffer. Making another function call to grow can be expensive when Write is called very often with small pieces of data (like a byte or rune). Thus, we add a tryGrowByReslice method that is inlineable so that we can avoid an extra call in most cases. name old time/op new time/op delta WriteByte-4 35.5µs ± 0% 17.4µs ± 1% -51.03% (p=0.000 n=19+20) WriteRune-4 55.7µs ± 1% 38.7µs ± 1% -30.56% (p=0.000 n=18+19) BufferNotEmptyWriteRead-4 304µs ± 5% 283µs ± 3% -6.86% (p=0.000 n=19+17) BufferFullSmallReads-4 87.0µs ± 5% 66.8µs ± 2% -23.26% (p=0.000 n=17+17) name old speed new speed delta WriteByte-4 115MB/s ± 0% 235MB/s ± 1% +104.19% (p=0.000 n=19+20) WriteRune-4 221MB/s ± 1% 318MB/s ± 1% +44.01% (p=0.000 n=18+19) Fixes #17857 Change-Id: I08dfb10a1c7e001817729dbfcc951bda12fe8814 Reviewed-on: https://go-review.googlesource.com/42813Reviewed-by:
-
Damien Lespiau authored
MOVSD is properly handled but its encoding test wasn't enabled. Enable it. For reference this was found with a little tool I wrote [1] to explore which instructions are missing or not tested in the go obj package and assembler: "which SSE2 instructions aren't tested? And don't list instructions which can take MMX operands" $ x86db-gogen list --extension SSE2 --not-tested --not-mmx CLFLUSH mem [m: np 0f ae /7] WILLAMETTE,SSE2 MOVSD xmmreg,xmmreg [rm: f2 0f 10 /r] WILLAMETTE,SSE2 MOVSD xmmreg,xmmreg [mr: f2 0f 11 /r] WILLAMETTE,SSE2 MOVSD mem64,xmmreg [mr: f2 0f 11 /r] WILLAMETTE,SSE2 MOVSD xmmreg,mem64 [rm: f2 0f 10 /r] WILLAMETTE,SSE2 (CLFLUSH was introduced with SSE2, but has its own CPUID bit) [1] https://github.com/dlespiau/x86db Change-Id: Ic3af3028cb8d4f02e53fdebb9b30fb311f4ee454 Reviewed-on: https://go-review.googlesource.com/42814Reviewed-by:
-
Alex Brainman authored
Currently windows Stat uses combination of Lstat and Readlink to walk symlinks until it reaches file or directory. Windows Readlink is implemented via Windows DeviceIoControl(FSCTL_GET_REPARSE_POINT, ...) call, but that call does not work on network shares or inside of Docker container (see issues #18555 ad #19922 for details). But Raymond Chen suggests different approach: https://blogs.msdn.microsoft.com/oldnewthing/20100212-00/?p=14963/ - he suggests to use Windows I/O manager to dereferences the symbolic link. This appears to work for all normal symlinks, but also for network shares and inside of Docker container. This CL implements described procedure. I also had to adjust TestStatSymlinkLoop, because the test is expecting Stat to return syscall.ELOOP for symlink with a loop. But new Stat returns Windows error of ERROR_CANT_RESOLVE_FILENAME = 1921 instead. I could map ERROR_CANT_RESOLVE_FILENAME into syscall.ELOOP, but I suspect the former is broader than later. And ERROR_CANT_RESOLVE_FILENAME message text of "The name of the file cannot be resolved by the system." sounds fine to me. Fixes #10935 Fixes #18555 Fixes #19922 Change-Id: I979636064cdbdb9c7c840cf8ae73fe2c24499879 Reviewed-on: https://go-review.googlesource.com/41834Reviewed-by:
Harshavardhana <hrshvardhana@gmail.com> Reviewed-by:
-
- 06 May, 2017 3 commits
-
-
Egon Elbre authored
gcc on windows writes invalid location for .debug_gdb_scripts which causes the executable loading to fail. Fixes #20183 Change-Id: I5134013bc926b44a55b528f66ab79555855d1f4d Reviewed-on: https://go-review.googlesource.com/42651Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
As discussion in issue #19141, the addend should be the third argument of MULA. This patch fixes it in both the front end and the back end of the assembler. And also tests are added to the encoding test. Fixes #19141 Change-Id: Idbc6f338b8fdfcad97a135f27a98c5b375b27d43 Reviewed-on: https://go-review.googlesource.com/42028 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Nigel Tao authored
Fixes #20249 Change-Id: I5dceaef31de96345f8e6c155e12775dc4cc31bfb Reviewed-on: https://go-review.googlesource.com/42790Reviewed-by:
-
- 05 May, 2017 8 commits
-
-
Robert Griesemer authored
NewPackage required through documentation that the package name not be blank (which wasn't true since each time we check a new package we create one with a blank name (api.go:350). NewPackage also asserted that a package name not be "_". While it is invalid for a package name to be "_", one could conceivably create a package named "_" through export data manipulation. Furthermore, it is ok to import a package with package path "_" as long as the package itself is not named "_". - removed misleading documentation - removed unnecessary assertion - added safety checks when we actually do the import Fixes #20231. Change-Id: I1eb1ab7b5e3130283db715374770cf05d749d159 Reviewed-on: https://go-review.googlesource.com/42852 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Fixes #20230. Change-Id: I2e9b9e9d2540eb66c8411ac7910962933bc2c0e9 Reviewed-on: https://go-review.googlesource.com/42870 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Generated hash and eq routines don't need nil checks. Prior to this CL, this was accomplished by temporarily incrementing the global variable disable_checknil. However, that increment lasted only the lifetime of the call to funccompile. After CL 41503, funccompile may do nothing but enqueue the function for compilation, resulting in nil checks being generated. Fix this by adding an explicit flag to a function indicating whether nil checks should be disabled for that function. While we're here, allow concurrent compilation with the -w and -W flags, since that was needed to investigate this issue. Fixes #20242 Change-Id: Ib9140c22c49e9a09e62fa3cf350f5d3eff18e2bd Reviewed-on: https://go-review.googlesource.com/42591 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by:
-
Carlos Eduardo Seo authored
The Power processor manual states that "Branches not from the last instruction of an aligned quadword and not to the first instruction of an aligned quadword cause inefficiencies in the IBuffer". This changes the function alignment from 8 to 16 bytes to comply with that. Fixes #18963 Change-Id: Ibce9bf8302110a86c6ab05948569af9ffdfcf4bb Reviewed-on: https://go-review.googlesource.com/36390 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Samuel Tan authored
Allow the predefined escapers "html", "urlquery", and "js" to be used in pipelines when they have no potential to affect the correctness or safety of the escaped pipeline output. Specifically: - "urlquery" may be used if it is the last command in the pipeline. - "html" may be used if it is the last command in the pipeline, and the pipeline does not occur in an unquoted HTML attribute value context. - "js" may be used in any pipeline, since it does not affect the merging of contextual escapers. This change will loosens the restrictions on predefined escapers introduced in golang.org/cl/37880, which will hopefully ease the upgrade path for existing template users. This change brings back the escaper-merging logic, and associated unit tests, that were removed in golang.org/cl/37880. However, a few notable changes have been made: - "_html_template_nospaceescaper" is no longer considered equivalent to "html", since the former escapes spaces, while the latter does not (see #19345). This change should not silently break any templates, since pipelines where this substituion will happen will already trigger an explicit error. - An "_eval_args_" internal directive has been added to handle pipelines containing a single explicit call to a predefined escaper, e.g. {{html .X}} (see #19353). Also, the HTMLEscape function called by the predefined text/template "html" function now escapes the NULL character as well. This effectively makes it as secure as the internal html/template HTML escapers (see #19345). While this change is backward-incompatible, it will only affect illegitimate uses of this escaper, since the NULL character is always illegal in valid HTML. Fixes #19952 Change-Id: I9b5570a80a3ea284b53901e6a1f842fc59b33d3a Reviewed-on: https://go-review.googlesource.com/40936Reviewed-by: -
Dieter Plaetinck authored
Execute incurs separate writes for each "step", e.g. each variable that needs to be printed, and the final newline. While it is correct to state that templates can be executed concurrently, there is a more subtle nuance that is easily missed: when writing to the same writer, the writes from concurrent execute calls can be interleaved, leading to unexpected output. Change-Id: I0abbd7960d8a8d15e109a8a3eeff3b43b852bbbf Reviewed-on: https://go-review.googlesource.com/37444Reviewed-by:
Rob Pike <r@golang.org>
-
David Crawshaw authored
The external darwin linker has been printing: ld: warning: -read_only_relocs cannot be used with x86_64 for a long time. Now that it is printed by CL 33301, we may as well get rid of it. Fixes #20246 Change-Id: I1147cf1ff197fdfda228a1349f13627bcf9fc72f Reviewed-on: https://go-review.googlesource.com/42730 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Todd Neal <todd@tneal.org> Reviewed-by:
-
Alex Brainman authored
For .bss section symbol ldelf does not set P (raw symbol data). Make ldpe do the same. Change-Id: Ib3d558456f505ee568d0972465fa9b08b5794a87 Reviewed-on: https://go-review.googlesource.com/42631Reviewed-by:
-
- 04 May, 2017 8 commits
-
-
Josh Bleecher Snyder authored
Fixes #20228 Change-Id: I1893ae3e192da01f9befe5469b2a32e534a691ba Reviewed-on: https://go-review.googlesource.com/42592Reviewed-by:
-
Josh Bleecher Snyder authored
If we've already complained about a type T, don't complain again about further expressions involving it. Fixes #20245 and hopefully all of its ilk. Change-Id: Ic0abe8235d52e8a7ac40e3615aea8f3a54fd7cec Reviewed-on: https://go-review.googlesource.com/42690 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
We already set it for mips32 objects. The native ELF linker warns when linking PIC objects with non-PIC objects. Our objects are PIC, but we were not marking them as such. Fixes #20243. Change-Id: Ifab131200b263e4c72cf81f7b131a65ac02a13a9 Reviewed-on: https://go-review.googlesource.com/42710 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
David Crawshaw authored
This change passes runtime.Version from the go tool to the compiler. If the versions do not match, the compilation fails. The result is a go tool from one GOROOT will complain loudly if it is invoked with a different GOROOT value. Only release versions are checked, so that when developing Go you can still use "go install cmd/go" and "go install cmd/compile" separately. Fixes #19064 Change-Id: I17e184d07d3c1092b1d9af53ba55ed3ecf67791d Reviewed-on: https://go-review.googlesource.com/42595 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Bender authored
- remove <code> from <pre> - replace `` with <code></code> Change-Id: I46f0aec8b7645e2ac8cb53bca73aed55441acd65 Reviewed-on: https://go-review.googlesource.com/42612Reviewed-by:
-
Brad Fitzpatrick authored
(Found by making time.Time uncomparable and rerunning std tests locally.) Change-Id: I4fa6fb0ba7334965362387e2f6541c17a27ac3aa Reviewed-on: https://go-review.googlesource.com/42616 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Martin Möhrmann <moehrmann@google.com> Reviewed-by:
Damien Neil <dneil@google.com> Reviewed-by:
Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
Before this change, building a GOROOT using make.bash, and then moving the entire to a new path confused the go tool. Correct operation of the go tool under these conditions required either running make.bash again (not always possible if the new location was owned by a different system user) or setting the GOROOT environment variable. Setting GOROOT is unfortunate and discouraged, as it makes it too easy to use the go tool from one GOROOT and the compiler from another GOROOT. With this change, the go tool finds its GOROOT relative to its own location, using os.Executable. It checks it is in a GOROOT by searching for the GOROOT/pkg/tool directory, to avoid two plausible situations: ln -s $GOROOT/bin/go /usr/local/bin/go and PATH=$HOME/bin:$PATH GOPATH=$HOME ln -s $GOROOT/bin/go $HOME/bin/go Additionally, if the current executable path is not in a GOROOT, the tool will follow any symlinks for the executable and check to see if its original path is a GOROOT. Fixes #18678 Change-Id: I151d7d449d213164f98193cc176b616849e6332c Reviewed-on: https://go-review.googlesource.com/42533 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Updates text from https://golang.org/cl/42511 Updates #14395 Change-Id: I711100525e074ab360e577520280c37645db1c95 Reviewed-on: https://go-review.googlesource.com/42614Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
-
