- 03 Sep, 2015 5 commits
-
-
Michael Hudson-Doyle authored
cmd/internal/obj: some platform independent bits of proper toolchain support for thread local storage Also simplifies some silliness around making the .tbss section wrt internal vs external linking. The "make TLS make sense" project has quite a few more steps to go. Issue #11270 Change-Id: Ia4fa135cb22d916728ead95bdbc0ebc1ae06f05c Reviewed-on: https://go-review.googlesource.com/13990Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Andrew Gerrand authored
Bring in the text from the proposal (with minor edits): https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md Fixes #11502 Change-Id: I92a987be66a0df60c1fad6c6c79f89bd8e9c12a8 Reviewed-on: https://go-review.googlesource.com/13955Reviewed-by:
Jason Buberel <jbuberel@google.com>
-
Michael Hudson-Doyle authored
Nothing uses it any more. Change-Id: I42ee7222b06b1a79b8b44894f3071752f9166d7a Reviewed-on: https://go-review.googlesource.com/14193 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Joe Tsai authored
The flate library contains generator code, which is used to generate the fixed huffman table. This is done so that fixed blocks can be processed quicker since there is no need generate the decoder table for fixed codes. Instead, delete the precomputed table, and use sync.Once to generate it at runtime when used. Advantages: * Reduces duplicated logic in flate package * Reduces binary size by approximately 2KiB Disadvantages: * For the simplest possible program that simply decodes the fixed block "\x03\x00" once, the modified code takes 4.7% longer for the first decode. Compression performance for subsequent blocks afterwards has no noticeable slow down. Change-Id: I8f351218debf7d732118808859eda481b01011f6 Reviewed-on: https://go-review.googlesource.com/14181Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Michael Hudson-Doyle authored
Building for shared libraries requires that all functions that are declared have an implementation and vice versa so make that so on arm64. It would be nicer to not require the stub sigreturn (it will never be called) but that seems a bit awkward. Change-Id: I3cec81697161b452af81fa35939f748bd1acf7fd Reviewed-on: https://go-review.googlesource.com/13995Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
- 02 Sep, 2015 5 commits
-
-
Didier Spezia authored
The parser tries to read as much information as possible, issuing some errors when needed. Errors generally do not stop the parsing. With some pathological input, it may result in various panics when the error message itself is built, or when the next operand is parsed. It happens while parsing pseudo-instructions. For instance, the following lines all generate a panic: TEXT TEXT% TEXT 1,1 TEXT $"toto", 0, $1 FUNCDATA DATA 0 DATA(0),1 FUNCDATA(SB GLOBL 0, 1 PCDATA 1 Added corresponding tests. Introduced a writer in the parser to capture error messages for testing purpose. It defaults to os.Stderr. Added an explicit check when symbol names cannot be displayed. Interrupted parsing early when the number of operands is wrong for pseudo-instructions. Note that the last point is a change of behavior, because some operands will not get parsed anymore in case of early error. IMO, it is acceptable, because only the first error of the line is considered anyway. If it is not acceptable, it can probably be improved at the price of a more verbose CL. Fixes #11765 Fixes #11760 Fixes #11759 Change-Id: I9602a848132e358a1bccad794d7555e0823970dd Reviewed-on: https://go-review.googlesource.com/13925Reviewed-by:
Rob Pike <r@golang.org>
-
Håvard Haugen authored
Change-Id: Ib3960321a4c8164f6b221bfd15977d2f34dbc65b Reviewed-on: https://go-review.googlesource.com/14175Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Pike authored
Refine the documentation in cmd/doc and go help doc. Fixes #12377. Change-Id: I670c0a5cf18c9c9d5bb9bb222d8a3dd3722a3934 Reviewed-on: https://go-review.googlesource.com/14121Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Rob Pike authored
Printing a function value is nearly useless outside of debugging, but can occur by mistake when one forgets to call it. Diagnose this. I did this myself just the other day and it arose in cl/14031. Easy to fix and seems worthwhile. Fixes #12295. Change-Id: Ice125a84559f0394f7fa7272b5d31ae602b07f83 Reviewed-on: https://go-review.googlesource.com/14122Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Andrew Gerrand authored
Change-Id: I571965bc38a8b1060642a942b898797327f0c19c Reviewed-on: https://go-review.googlesource.com/14195Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
- 01 Sep, 2015 8 commits
-
-
Håvard Haugen authored
Change-Id: I021c95df24edbff24ff2922769ef2b2acd47016a Reviewed-on: https://go-review.googlesource.com/14081 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Håvard Haugen authored
See report in commit 3c9fa388. Change-Id: I74a5995a1c1ca62b8d01857e89b084502e7da928 Reviewed-on: https://go-review.googlesource.com/14170Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dan Peterson authored
Fixes #11879 Change-Id: If021f86b2764e01c69674e6a423699b822596f15 Reviewed-on: https://go-review.googlesource.com/14161Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Fabian Wickborn authored
At the moment, bootstrap.bash assumes it is called from a git working copy. Hence, it fails to complete when running in an unpacked official source tarball where .git and .gitignore do not exist. This fix adds a test for existence for .git and a -f switch for the removal of .gitignore. Fixes #12223 Change-Id: I7f305b83b38d5115504932bd38dadb7bdeb5d487 Reviewed-on: https://go-review.googlesource.com/13770Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I125a12a2cb7e792f357e4d841f55c0bed2971dce Reviewed-on: https://go-review.googlesource.com/14140 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Brad Fitzpatrick authored
Fixes #11805 Change-Id: I081e16b869dc706bd847ee645bb902bc671c123f Reviewed-on: https://go-review.googlesource.com/12485Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Nigel Tao authored
Change-Id: I6a4ab5a1f44b54cfa81a650055460587ceefb2fc Reviewed-on: https://go-review.googlesource.com/14144Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Nigel Tao authored
We could undoubtedly squeeze even more out of these loops, and in the long term, a better compiler would be smarter with bounds checks, but in the short term, this small change is an easy win. benchmark old ns/op new ns/op delta BenchmarkFillOver-8 1619470 1323192 -18.29% BenchmarkCopyOver-8 1129369 1062787 -5.90% BenchmarkGlyphOver-8 420070 378608 -9.87% On github.com/golang/freetype/truetype's BenchmarkDrawString: benchmark old ns/op new ns/op delta BenchmarkDrawString-8 9561435 8807019 -7.89% Change-Id: Ib1c6271ac18bced85e0fb5ebf250dd57d7747e75 Reviewed-on: https://go-review.googlesource.com/14093Reviewed-by:
Rob Pike <r@golang.org>
-
- 31 Aug, 2015 11 commits
-
-
Paul Marks authored
This may fix the flakiness on Windows/x64, assuming that it's actually due to a variance in the connection time which slightly exceeds 100ms. 150ms + 95ms = 245ms, which is still low enough to avoid triggering Happy Eyeballs (300ms) on non-Windows platforms. Updates #12309 Change-Id: I816a36fbc0a3e5c90e3cf1b75a134faf0d91557c Reviewed-on: https://go-review.googlesource.com/14120 Run-TryBot: Paul Marks <pmarks@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Dave Cheney authored
Update #10994 CASE and BCASE were used by 5c in switch statements, cmd/compile does not use them. Change-Id: I7a578c461b52b94690e35460926849b28971b770 Reviewed-on: https://go-review.googlesource.com/14009Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
The hash tests generate occasional failures, quiet them some more. In particular we can get 1 collision when the expected number is .001 or so. That shouldn't be a dealbreaker. Fixes #12311 Change-Id: I784e91b5d21f4f1f166dc51bde2d1cd3a7a3bfea Reviewed-on: https://go-review.googlesource.com/13902Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
Shenghou Ma authored
Fixes #12340. Change-Id: I17a8b3711a8593ec60882a0dcadb38f0cc138f4b Reviewed-on: https://go-review.googlesource.com/13949Reviewed-by:
Rob Pike <r@golang.org>
-
Shenghou Ma authored
Change-Id: I15bf55aa5ac3588c05f0a253f583c52bab209892 Reviewed-on: https://go-review.googlesource.com/14041Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Alexander Morozov authored
Change-Id: If0d00999c58f7421e4da06e1822ba5abccf72cac Reviewed-on: https://go-review.googlesource.com/14111Reviewed-by:
Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alexander Morozov authored
This is basic validation and should be performed early Fixes #12412 Change-Id: I903f7eeafdc22376704985a53d649698cf9d8ef4 Reviewed-on: https://go-review.googlesource.com/14110Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Dave Cheney authored
Fixes #10994 CASE and BCASE were used by 7c in switch statements, cmd/compile does not use them, cmd/assemble couldn't assemble them, and the arm64 peephole optimiser didn't know about them. Change-Id: Id04835fcb37e207f76d211ce54a4db9c057d6112 Reviewed-on: https://go-review.googlesource.com/14100Reviewed-by:
Aram Hăvărneanu <aram@mgk.ro> Run-TryBot: Aram Hăvărneanu <aram@mgk.ro> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Aaron Jacobs authored
All implementations of File.read ensure that n >= 0. This is usually via fixCount, except for Windows console reads, which only ever add to n. Change-Id: Ic019d6a2da5ef1ac68d2690c908deca4fcc6b4a4 Reviewed-on: https://go-review.googlesource.com/12624Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Håvard Haugen authored
This helps vet see a real issue: cmd/internal/gc$ go vet gen.go:1223: unreachable code Fixes #12106. Change-Id: I720868b07ae6b6d5a4dc6b238baa8c9c889da6d8 Reviewed-on: https://go-review.googlesource.com/14083Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Hudson-Doyle authored
And clean up the mess on arm64 (the mess on arm is too confusing). See issue #10050 Change-Id: I2ce813fe8646d4e818eb660612a7e4b2bb04de4c Reviewed-on: https://go-review.googlesource.com/13884Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 30 Aug, 2015 6 commits
-
-
Shenghou Ma authored
Fixes external linking of net/http tests (or anything that uses sendfile). Fixes #12390. Change-Id: Iee08998cf66e7b0ce851db138a00ebae6dc2395e Reviewed-on: https://go-review.googlesource.com/14072Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Aram Hăvărneanu <aram@mgk.ro>
-
Austin Clements authored
Currently the stack barrier stub blindly unwinds the next stack barrier from the G's stack barrier array without checking that it's the right stack barrier. If through some bug the stack barrier array position gets out of sync with where we actually are on the stack, this could return to the wrong PC, which would lead to difficult to debug crashes. To address this, this commit adds a check to the amd64 stack barrier stub that it's unwinding the correct stack barrier. Updates #12238. Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02 Reviewed-on: https://go-review.googlesource.com/13948Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently enabling the debugging mode where stack barriers are installed at every frame requires recompiling the runtime. However, this is potentially useful for field debugging and for runtime tests, so make this mode a GODEBUG. Updates #12238. Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5 Reviewed-on: https://go-review.googlesource.com/13947Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Currently the runtime can install stack barriers in any frame. However, the frame of cgocallback_gofunc is special: it's the one function that switches from a regular G stack to the system stack on return. Hence, the return PC slot in its frame on the G stack is actually used to save getg().sched.pc (so tracebacks appear to unwind to the last Go function running on that G), and not as an actual return PC for cgocallback_gofunc. Because of this, if we install a stack barrier in cgocallback_gofunc's return PC slot, when cgocallback_gofunc does return, it will move the stack barrier stub PC in to getg().sched.pc and switch back to the system stack. The rest of the runtime doesn't know how to deal with a stack barrier stub in sched.pc: nothing knows how to match it up with the G's stack barrier array and, when the runtime removes stack barriers, it doesn't know to undo the one in sched.pc. Hence, if the C code later returns back in to Go code, it will attempt to return through the stack barrier saved in sched.pc, which may no longer have correct unwinding information. Fix this by blacklisting cgocallback_gofunc's frame so the runtime won't install a stack barrier in it's return PC slot. Fixes #12238. Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8 Reviewed-on: https://go-review.googlesource.com/13944Reviewed-by:
Russ Cox <rsc@golang.org>
-
Adam Langley authored
(See referenced bug for details.) Fixes #11966. Change-Id: I91f9c95594cf4fd6d25d9a81f155a643c7a1f8e0 Reviewed-on: https://go-review.googlesource.com/13038Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Adam Langley authored
https://tools.ietf.org/html/rfc7301#section-3.1 specifies that a ProtocolName may not be empty. This change enforces this for ServerHello messages—it's already enforced for ClientHello messages. Change-Id: Ic5a5be6bebf07fba90a3cabd10b07ab7b4337f53 Reviewed-on: https://go-review.googlesource.com/12003Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 29 Aug, 2015 5 commits
-
-
aubble authored
In Go 1.5, Config.Certificates is no longer required if Config.GetCertificate has been set. This change updated four comments to reflect that. Change-Id: Id72cc22fc79e931b2d645a7c3960c3241042762c Reviewed-on: https://go-review.googlesource.com/13800Reviewed-by:
Adam Langley <agl@golang.org>
-
Vlad Krasnov authored
The existing implementation didn't use the CLMUL instructions for fast and constant time binary-field multiplication. With this change, amd64 CPUs that support both AES and CLMUL instructions will use an optimised asm implementation. benchmark old ns/op new ns/op delta BenchmarkAESGCMSeal8K 91723 3200 -96.51% BenchmarkAESGCMOpen8K 91487 3324 -96.37% BenchmarkAESGCMSeal1K 11873 546 -95.40% BenchmarkAESGCMOpen1K 11833 594 -94.98% benchmark old MB/s new MB/s speedup BenchmarkAESGCMSeal8K 89.31 2559.62 28.66x BenchmarkAESGCMOpen8K 89.54 2463.78 27.52x BenchmarkAESGCMSeal1K 86.24 1872.49 21.71x BenchmarkAESGCMOpen1K 86.53 1721.78 19.90x Change-Id: Idd63233098356d8b353d16624747b74d0c3f193e Reviewed-on: https://go-review.googlesource.com/10484 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Adam Langley <agl@golang.org>
-
aubble authored
Go 1.5 allowed TLS connections where Config.Certificates was nil as long as the GetCertificate callback was given. However, tls.Listen wasn't updated accordingly until this change. Change-Id: I5f67f323f63c988ff79642f3daf8a6b2a153e6b2 Reviewed-on: https://go-review.googlesource.com/13801Reviewed-by:
Adam Langley <agl@golang.org>
-
Håvard Haugen authored
Recursive types R containing slices of R's did not terminate despite the effort in CL 10821. For recursive types there was a competition between slice expansion by a factor 'complexSize', and termination with probability '1/complexSize' which lead to stack overflow as soon as a recursive struct had slices pointing to its own type. Fix this by shrinking the size hint as a function of recursion depth. This has the dual effect of reducing the number of elements generated per slice and also increasing the probability for termination. Fixes #11148. Change-Id: Ib61155b4f2e2de3873d508d63a1f4be759426d67 Reviewed-on: https://go-review.googlesource.com/13830Reviewed-by:
Adam Langley <agl@golang.org>
-
David Leon Gil authored
For primes which are 3 mod 4, using Tonelli-Shanks is slower and more complicated than using the identity a**((p+1)/4) mod p == sqrt(a) For 2^450-2^225-1 and 2^10860-2^5430-1, which are 3 mod 4: BenchmarkModSqrt225_TonelliTri 1000 1135375 ns/op BenchmarkModSqrt225_3Mod4 10000 156009 ns/op BenchmarkModSqrt5430_Tonelli 1 3448851386 ns/op BenchmarkModSqrt5430_3Mod4 2 914616710 ns/op ~2.6x to 7x faster. Fixes #11437 (which is a prime choice of issues to fix) Change-Id: I813fb29454160483ec29825469e0370d517850c2 Reviewed-on: https://go-review.googlesource.com/11522Reviewed-by:
Adam Langley <agl@golang.org>
-