- 03 May, 2019 6 commits
-
-
Brad Fitzpatrick authored
Fixes #26013 Change-Id: I2c82bd90ea7ce6f7a8e5b6c460d3982dca681a93 Reviewed-on: https://go-review.googlesource.com/c/go/+/174597Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Elias Naur authored
They were already skipped on tethered Android builders because the tests are gated on GO_BUILDER_NAME being set and the Android exec wrapper does not propagate GO_BUILDER_NAME. Updates #31722 Change-Id: Ifd2c7daecc19a4e540d86d1f38083f43cc3e6b15 Reviewed-on: https://go-review.googlesource.com/c/go/+/175177 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Elias Naur authored
iostest.bash might not live much longer, and all.bash is much less confusing and more explicit. Change-Id: If42e8716bbbb02aa3f817dceaabb1aa8076aae1a Reviewed-on: https://go-review.googlesource.com/c/go/+/175178Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
This CL adds intrinsics for the 64-bit addition and subtraction functions in math/bits. These intrinsics use the condition code to propagate the carry or borrow bit. To make the carry chains more efficient I've removed the 'clobberFlags' property from most of the load and store operations. Originally these ops did clobber flags when using offsets that didn't fit in a signed 20-bit integer, however that is no longer true. As with other platforms the intrinsics are faster when executed in a chain rather than a loop because currently we need to spill and restore the carry bit between each loop iteration. We may be able to reduce the need to do this on s390x (e.g. by using compare-and-branch instructions that do not clobber flags) in the future. name old time/op new time/op delta Add64 1.21ns ± 2% 2.03ns ± 2% +67.18% (p=0.000 n=7+10) Add64multiple 2.98ns ± 3% 1.03ns ± 0% -65.39% (p=0.000 n=10+9) Sub64 1.23ns ± 4% 2.03ns ± 1% +64.85% (p=0.000 n=10+10) Sub64multiple 3.73ns ± 4% 1.04ns ± 1% -72.28% (p=0.000 n=10+8) Change-Id: I913bbd5e19e6b95bef52f5bc4f14d6fe40119083 Reviewed-on: https://go-review.googlesource.com/c/go/+/174303 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
LE Manh Cuong authored
golang.org/cl/174498 add ONAME case to isStaticCompositeLiteral, to detect global variable as compile-time constant. It does report wrong for struct field, e.g: o := one{i: two{i: 42}.i} field i in two{i: 42} was reported as static composite literal, while it should not. In general, adding ONAME case for isStaticCompositeLiteral is probably wrong. Fixes #31782 Change-Id: Icde7d43bbb002b75df5c52b948b7126a4265e07b Reviewed-on: https://go-review.googlesource.com/c/go/+/174837Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brian Kessler authored
Int.String had no documentation and the documentation for Int.Text did not mention the handling of the nil pointer case. Change-Id: I9f21921e431c948545b7cabc7829e4b4e574bbe9 Reviewed-on: https://go-review.googlesource.com/c/go/+/175118Reviewed-by: Robert Griesemer <gri@golang.org>
-
- 02 May, 2019 13 commits
-
-
Brad Fitzpatrick authored
Updates #31812 Change-Id: Id9898f89205c116009e25033afb5b9026594e80f Reviewed-on: https://go-review.googlesource.com/c/go/+/175099Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Filippo Valsorda authored
$ go get -u golang.org/x/sys $ go mod vendor $ go mod tidy Change-Id: Ie0a4646aef41b00ec8e27bc6f7e3ec9c270c8ccb Reviewed-on: https://go-review.googlesource.com/c/go/+/174946 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Instead of requiring exact type match, allow assignment conversions (those conversions allowed in the language spec without a cast) on the returned values. Particularly useful when the type being returned is an interface type, but the Value actually returned is a concrete value implementing that type (as it is tricky to return a Value which has interface type). RELNOTE=y Fixes #28761 Change-Id: I69eef07ca51690b2086dfa1eb549db5e4724c657 Reviewed-on: https://go-review.googlesource.com/c/go/+/174531 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates #31784 Change-Id: Iee056c850c03939606b227a12715c76b0339d268 Reviewed-on: https://go-review.googlesource.com/c/go/+/175097 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
We compile package sort as part of the compiler bootstrap, to make sure the compiler uses a consistent sort algorithm no matter what version of Go it is compiled against. (This matters for elements that compare "equal" but are distinguishable.) Package sort was compiled in such a way as to disallow sort.Slice entirely during bootstrap (at least with some compilers), while cmd/internal/obj was compiled in such a way as to make obj.SortSlice available to all compilers, precisely because sort.Slice was not. This is all highly confusing. Simplify by making sort.Slice available all the time. Followup to CL 169137 and #30440 (and also CL 40114 and CL 73951). Change-Id: I127f4e02d6c71392805d256c3a90ef7c51f9ba0c Reviewed-on: https://go-review.googlesource.com/c/go/+/174525 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
erifan01 authored
This CL improves internal link to provide basic support for cgo and PIE: 1, add support for GOT, PLT and GOTPLT. 2, add support for following ELF relocation types which have been used by std packages: R_AARCH64_ADR_GOT_PAGE R_AARCH64_LD64_GOT_LO12_NC R_AARCH64_ADR_PREL_PG_HI21 R_AARCH64_ADD_ABS_LO12_NC R_AARCH64_LDST8_ABS_LO12_NC R_AARCH64_LDST32_ABS_LO12_NC R_AARCH64_LDST64_ABS_LO12_NC R_AARCH64_JUMP26 R_AARCH64_ABS64 R_AARCH64_PREL32 R_AARCH64_PREL64 With this change, Go toolchain can be built in internal linking mode, and pure Go programs can be built with PIE mode in internal linking mode on arm64. Updates #10373 The prototype of this CL is contributed by Wei Xiao <wei.xiao@arm.com> Change-Id: I2253923c69e855fd1524d54def309a961dce6247 Reviewed-on: https://go-review.googlesource.com/c/go/+/163579Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com>
-
Elias Naur authored
This change will allow android/arm64 hosts to build for android/arm, and likewise for iOS. Updates #31722 Change-Id: Id410bd112abbab585ebb13b61fe4d3a38a1a81fb Reviewed-on: https://go-review.googlesource.com/c/go/+/174705 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Pontus Leitzler authored
As pointed out by thepudds in #30634, the 'list -u' documentation states that the current version should be considered for upgrade: The -u flag adds information about available upgrades. When the latest version of a given module is newer than the current one, list -u sets the Module's Update field to information about the newer module. In go 1.12.4 (and current tip), an older version will be suggested as upgrade to a newer pseudo version. Updates: #30634 Change-Id: If2c8887198884b8e7ccb3a604908065aa1f1878a Reviewed-on: https://go-review.googlesource.com/c/go/+/174206 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Baokun Lee authored
Change-Id: I3e75201c56779eda1bcd725691c72d384da56f73 Reviewed-on: https://go-review.googlesource.com/c/go/+/174840 Run-TryBot: Baokun Lee <nototon@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
LE Manh Cuong authored
Mid-stack inlining is enable now, see #19348, but we still can not remove the special case for runtime.heapBits.nextArena, because runtime.heapBits.next is too complex to be inlined (cost 96 exceeds budget 80). Change-Id: I04ea86509074afdc83a3f70d68b8a1a8829763d1 Reviewed-on: https://go-review.googlesource.com/c/go/+/174839Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
For #23011. For #27619. Change-Id: Id1f280993ecdfb07a7420926ca1c0f5b7872afbb Reviewed-on: https://go-review.googlesource.com/c/go/+/174521Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jacob Walker authored
The Unwrap function performs a type assertion looking for the Wrapper interface. The method of that interface is called Unwrap but the interface itself is called Wrapper. Change-Id: Ie3bf296f93b773d36015bcab2a0e6585d39783c7 GitHub-Last-Rev: 32b1a0c2f8bf8f3eaebf6de252571d82313e86e0 GitHub-Pull-Request: golang/go#31794 Reviewed-on: https://go-review.googlesource.com/c/go/+/174917Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Fixes #31747. Updates #19308. Updates #12711. Updates #29008. Updates #28493. Updates #19113. Change-Id: I76d2fdbc7698cc4e0f31b7ae24cbb4d28afbb6a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/174897 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 01 May, 2019 16 commits
-
-
Heschi Kreinick authored
The web package is now used for proxy fetches, so its logs shouldn't start with "Parsing meta tags". Change-Id: I22a7dce09e3a681544ee4b860f93c63336e547ca Reviewed-on: https://go-review.googlesource.com/c/go/+/174740 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
LE Manh Cuong authored
golang.org/cl/174498 removes dynamic map entry handling in maplit, by filtering the static entry only. It panics if it see a dynamic entry. It relies on order to remove all dynamic entries. But after recursively call order on the statics, some static entries become dynamic, e.g OCONVIFACE node: type i interface { j() } type s struct{} func (s) j() {} type foo map[string]i var f = foo{ "1": s{}, } To fix it, we recursively call order on each static entry, if it changed to dynamic, put entry to dynamic then. Fixes #31777 Change-Id: I1004190ac8f2d1eaa4beb6beab989db74099b025 Reviewed-on: https://go-review.googlesource.com/c/go/+/174777 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Right now they are in a deterministic order but one that depends on the shape of the import graph. Sort them instead. Change-Id: Ia0c076a0d6677a511e52acf01f38353e9895dec2 Reviewed-on: https://go-review.googlesource.com/c/go/+/174527 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Martin Möhrmann authored
The newly added functions create a copy of their input with all bytes in invalid UTF-8 byte sequences mapped to the UTF-8 byte sequence given as replacement parameter. Fixes #25805 Change-Id: Iaf65f65b40c0581c6bb000f1590408d6628321d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/142003 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
iOS cannot (directly) run shell scripts. Updates #31722 Change-Id: I69473e9339c50a77338d391c73b4e146bce3fa89 Reviewed-on: https://go-review.googlesource.com/c/go/+/174700 Run-TryBot: Elias Naur <mail@eliasnaur.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Elias Naur authored
Updates #31722 Change-Id: Ib44b46e628e364fff6eacda2b26541db2f0a4261 Reviewed-on: https://go-review.googlesource.com/c/go/+/174701 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Hana Kim authored
Fixes #31768 Change-Id: I3cc0ebc4be34d7c2d2d4fd655bfd0c2515ff3021 Reviewed-on: https://go-review.googlesource.com/c/go/+/174739Reviewed-by: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Pontus Leitzler authored
cmd/go/internal/modfetch/codehost: fix pseudoversions for non-semver tags and tags on other branches Pseudoversion determination depends in part on the results from gitRepo.RecentTag, which currently invokes: git describe --first-parent --always --abbrev=0 --match <prefix>v[0-9]*.[0-9]*.[0-9]* --tags <rev> The comment at https://github.com/golang/go/issues/27171#issuecomment-470134255 describes some problems with the current approach. One problem is Docker and other repos can have tags that are not valid semver tags but that still match a glob pattern of v[0-9]*.[0-9]*.[0-9]* which are found by 'git describe' but then rejected by cmd/go, and hence those repos currently can end up with v0.0.0 pseudoversions instead of finding a proper semver tag to use as input to building a pseudoversion (when then causes problems when the v0.0.0 pseudoversion is fed into MVS). An example problematic tag is a date-based tag such as 'v18.06.16', which matches the glob pattern, but is not a valid semver tag (due to the leading 0 in '06'). Issues #31673, #31287, and #27171 also describe problems where the '--first-parent' argument to 'git describe' cause the current approach to miss relevant semver tags that were created on a separate branch and then subsequently merged to master. In #27171, Bryan described the base tag that is supposed to be used for pseudoversions as: "It is intended to be the semantically-latest tag that appears on any commit that is a (transitive) parent of the commit with the given hash, regardless of branches. (The pseudo-version is supposed to sort after every version — tagged or otherwise — that came before it, but before the next tag that a human might plausibly want to apply to the branch.)" This CL solves the glob problem and tags-on-other-branches problem more directly than the current approach: this CL gets the full list of tags that have been merged into the specific revision of interest, and then sorts and filters the results in cmd/go to select the semantically-latest valid semver tag. Fixes #31673 Fixes #31287 Updates #27171 Change-Id: I7c3e6b46b2b21dd60562cf2893b6bd2afaae61d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/174061 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
David Chase authored
This repairs one of the several causes of pauses uncovered by a GC microbenchmark. A pause can occur when a goroutine's quantum expires "at the same time" a GC is needed. The current M switches to running a GC worker, which means that the amount of available work has expanded by one. The GC worker, however, does not call ready, and does not itself conditionally wake a P (a "normal" thread would do this). This is also true if M switches to a traceReader. This is problem 4 in this list: https://github.com/golang/go/issues/27732#issuecomment-423301252 Updates #27732. Change-Id: I6905365cac8504cde6faab2420f4421536551f0b Reviewed-on: https://go-review.googlesource.com/c/go/+/146817 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Russ Cox authored
The original index/suffixarray used 32-bit ints on 64-bit machines, because that's what 'int' meant in Go at the time. When we changed the meaning of int, that doubled the space overhead of suffix arrays for all uses, even though the vast majority of them describe less than 2 GB of text. The space overhead of a suffix array compared to the text is not insignificant: there's a big difference for many uses between 4X and 8X. This CL adjusts names in qsufsort.go so that a global search and replace s/32/64/g produces a working 64-bit implementation, and then it modifies suffixarray.go to choose between the 32-bit and 64-bit implementation as appropriate depending on the input size. The 64-bit implementation is generated by 'go generate'. This CL also restructures the benchmarks, to test different input sizes, different input texts, and 32-bit vs 64-bit. The serialized form uses varint-encoded numbers and is unchanged, so on-disk suffix arrays written by older versions of Go will be readable by this version, and vice versa. The 32-bit version runs a up to 17% faster than the 64-bit version on real inputs, but more importantly it uses 50% less memory. I have a followup CL that also implements a faster algorithm on top of these improvements, but these are a good first step. name 64-bit speed 32-bit speed delta New/text=opticks/size=100K/bits=*-12 4.44MB/s ± 0% 4.64MB/s ± 0% +4.41% (p=0.008 n=5+5) New/text=opticks/size=500K/bits=*-12 3.70MB/s ± 1% 3.82MB/s ± 0% +3.30% (p=0.008 n=5+5) New/text=go/size=100K/bits=*-12 4.40MB/s ± 0% 4.61MB/s ± 0% +4.82% (p=0.008 n=5+5) New/text=go/size=500K/bits=*-12 3.66MB/s ± 0% 3.77MB/s ± 0% +3.01% (p=0.016 n=4+5) New/text=go/size=1M/bits=*-12 3.29MB/s ± 0% 3.55MB/s ± 0% +7.90% (p=0.016 n=5+4) New/text=go/size=5M/bits=*-12 2.25MB/s ± 1% 2.65MB/s ± 0% +17.81% (p=0.008 n=5+5) New/text=go/size=10M/bits=*-12 1.82MB/s ± 0% 2.09MB/s ± 1% +14.36% (p=0.008 n=5+5) New/text=go/size=50M/bits=*-12 1.35MB/s ± 0% 1.51MB/s ± 1% +12.33% (p=0.008 n=5+5) New/text=zero/size=100K/bits=*-12 3.42MB/s ± 0% 3.32MB/s ± 0% -2.74% (p=0.000 n=5+4) New/text=zero/size=500K/bits=*-12 3.00MB/s ± 1% 2.97MB/s ± 0% -1.13% (p=0.016 n=5+4) New/text=zero/size=1M/bits=*-12 2.81MB/s ± 0% 2.78MB/s ± 2% ~ (p=0.167 n=5+5) New/text=zero/size=5M/bits=*-12 2.46MB/s ± 0% 2.53MB/s ± 0% +3.18% (p=0.008 n=5+5) New/text=zero/size=10M/bits=*-12 2.35MB/s ± 0% 2.42MB/s ± 0% +2.98% (p=0.016 n=4+5) New/text=zero/size=50M/bits=*-12 2.12MB/s ± 0% 2.18MB/s ± 0% +3.02% (p=0.008 n=5+5) New/text=rand/size=100K/bits=*-12 6.98MB/s ± 0% 7.22MB/s ± 0% +3.38% (p=0.016 n=4+5) New/text=rand/size=500K/bits=*-12 5.53MB/s ± 0% 5.64MB/s ± 0% +1.92% (p=0.008 n=5+5) New/text=rand/size=1M/bits=*-12 4.62MB/s ± 1% 5.06MB/s ± 0% +9.61% (p=0.008 n=5+5) New/text=rand/size=5M/bits=*-12 3.09MB/s ± 0% 3.43MB/s ± 0% +10.94% (p=0.016 n=4+5) New/text=rand/size=10M/bits=*-12 2.68MB/s ± 0% 2.95MB/s ± 0% +10.39% (p=0.008 n=5+5) New/text=rand/size=50M/bits=*-12 1.92MB/s ± 0% 2.06MB/s ± 1% +7.41% (p=0.008 n=5+5) SaveRestore/bits=*-12 243MB/s ± 1% 259MB/s ± 0% +6.68% (p=0.000 n=9+10) name 64-bit alloc/op 32-bit alloc/op delta New/text=opticks/size=100K/bits=*-12 1.62MB ± 0% 0.81MB ± 0% -50.00% (p=0.000 n=5+4) New/text=opticks/size=500K/bits=*-12 8.07MB ± 0% 4.04MB ± 0% -49.89% (p=0.008 n=5+5) New/text=go/size=100K/bits=*-12 1.62MB ± 0% 0.81MB ± 0% -50.00% (p=0.008 n=5+5) New/text=go/size=500K/bits=*-12 8.07MB ± 0% 4.04MB ± 0% -49.89% (p=0.029 n=4+4) New/text=go/size=1M/bits=*-12 16.1MB ± 0% 8.1MB ± 0% -49.95% (p=0.008 n=5+5) New/text=go/size=5M/bits=*-12 80.3MB ± 0% 40.2MB ± 0% ~ (p=0.079 n=4+5) New/text=go/size=10M/bits=*-12 160MB ± 0% 80MB ± 0% -50.00% (p=0.008 n=5+5) New/text=go/size=50M/bits=*-12 805MB ± 0% 402MB ± 0% -50.06% (p=0.029 n=4+4) New/text=zero/size=100K/bits=*-12 3.02MB ± 0% 1.46MB ± 0% ~ (p=0.079 n=4+5) New/text=zero/size=500K/bits=*-12 19.7MB ± 0% 8.7MB ± 0% -55.98% (p=0.008 n=5+5) New/text=zero/size=1M/bits=*-12 39.0MB ± 0% 19.7MB ± 0% -49.60% (p=0.000 n=5+4) New/text=zero/size=5M/bits=*-12 169MB ± 0% 85MB ± 0% -49.46% (p=0.029 n=4+4) New/text=zero/size=10M/bits=*-12 333MB ± 0% 169MB ± 0% -49.43% (p=0.000 n=5+4) New/text=zero/size=50M/bits=*-12 1.63GB ± 0% 0.74GB ± 0% -54.61% (p=0.008 n=5+5) New/text=rand/size=100K/bits=*-12 1.61MB ± 0% 0.81MB ± 0% -50.00% (p=0.000 n=5+4) New/text=rand/size=500K/bits=*-12 8.07MB ± 0% 4.04MB ± 0% -49.89% (p=0.000 n=5+4) New/text=rand/size=1M/bits=*-12 16.1MB ± 0% 8.1MB ± 0% -49.95% (p=0.029 n=4+4) New/text=rand/size=5M/bits=*-12 80.7MB ± 0% 40.3MB ± 0% -50.06% (p=0.008 n=5+5) New/text=rand/size=10M/bits=*-12 161MB ± 0% 81MB ± 0% -50.03% (p=0.008 n=5+5) New/text=rand/size=50M/bits=*-12 806MB ± 0% 403MB ± 0% -50.00% (p=0.016 n=4+5) SaveRestore/bits=*-12 9.47MB ± 0% 5.28MB ± 0% -44.29% (p=0.000 n=9+8) https://perf.golang.org/search?q=upload:20190126.1+|+bits:64+vs+bits:32 Fixes #6816. Change-Id: Ied2fbea519a202ecc43719debcd233344ce38847 Reviewed-on: https://go-review.googlesource.com/c/go/+/174097 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Lynn Boger authored
This is a follow up from a review comment at the end of the last Go release, to provide a more meaningful name for ginsnop2. Updates #30475 Change-Id: Ice9efd763bf2204a9e8c55ae230d3e8a80210108 Reviewed-on: https://go-review.googlesource.com/c/go/+/174757 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Than McIntosh authored
Add the issue31540 test to the list of tests that needs to be skipped with old copies of gccgo. Along the way, add an explicit field to the importer test struct that can be used to tag the test (as opposed to having special cases by name in the test routine), so as to make it easier to remember to tag testcases correctly. Fixes #31764. Change-Id: Ib9d98fea2df8ce0b51e5a886fb2c4acd6db490ff Reviewed-on: https://go-review.googlesource.com/c/go/+/174738Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Anthony Knyszek authored
This change modifies the treap implementation to be address-ordered instead of size-ordered, and further augments it so it may be used for allocation. It then modifies the find method to implement a first-fit allocation policy. This change to the treap implementation consequently makes it so that spans are scavenged in highest-address-first order without any additional changes to the scavenging code. Because the treap itself is now address ordered, and the scavenging code iterates over it in reverse, the highest address is now chosen instead of the largest span. This change also renames the now wrongly-named "scavengeLargest" method on mheap to just "scavengeLocked" and also fixes up logic in that method which made assumptions about size. For #30333. Change-Id: I94b6f3209211cc1bfdc8cdaea04152a232cfbbb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/164101 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Lynn Boger authored
This enables more of the testcases in memcombine for ppc64le, and adds more detail to some existing. Change-Id: Ic522a1175bed682b546909c96f9ea758f8db247c Reviewed-on: https://go-review.googlesource.com/c/go/+/174737Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Elias Naur authored
When fixing tests for for self-hosted iOS builds, I broke hosted builds. Updates #31722 Change-Id: Id4e7d234fbd86cb2d29d320d75f4441efd663d12 Reviewed-on: https://go-review.googlesource.com/c/go/+/174698 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Vogt authored
Today it is not possible (AFAICT) to detect if a DNSError if of type EAI_AGAIN, i.e. if it is something temporary that should be retried. This information is available inside addrinfoErrno but when the DNSError is created this information is lost. This PR fixes this so that the addinfoErrno.Temporary information is added to DNSError as well. With that a user who gets a DNSError can check now is its a temporary error (for errors that resulted from a addrinfoErrno this is EAI_AGAIN). Change-Id: I64badb2ebd904e41fc2e0755416f7f32560534d8 GitHub-Last-Rev: ced7238a6597039fb23f36f372bd1cf33d60d4a6 GitHub-Pull-Request: golang/go#31676 Reviewed-on: https://go-review.googlesource.com/c/go/+/174557Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 30 Apr, 2019 5 commits
-
-
bill_ofarrell authored
This CL will check for the Message-Security-Assist Extension 9 facility which enables the KDSA instruction. Change-Id: I659aac09726e0999ec652ef1f5983072c8131a48 Reviewed-on: https://go-review.googlesource.com/c/go/+/174529 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Fraenkel authored
Treat HTTP/2 connections as an ongoing persistent connection. When we are told there is no cached connections, cleanup the associated connection and host connection count. Fixes #27753 Change-Id: I6b7bd915fc7819617cb5d3b35e46e225c75eda29 Reviewed-on: https://go-review.googlesource.com/c/go/+/140357Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Nir Soffer authored
Previously transport was using the hardcoded bufio.defaultBufSize (4096), limiting throughput and increasing cpu usage when uploading or downloading large files. Add options to allow users to configure the buffer sizes as needed. I tested the maximum benefit of this change by uploading data from /dev/zero to a server discarding the bytes. Here is an example upload using the default buffer size: $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 25.13 seconds (407.49m/s) real 0m25.135s user 0m5.167s sys 0m11.643s With this change, using 128k buffer size: $ time ./upload 10 https://localhost:8000/ Uploaded 10.00g in 7.93 seconds (1291.51m/s) real 0m7.935s user 0m4.517s sys 0m2.603s In real world usage the difference will be smaller, depending on the local and remote storage and the network. See https://github.com/nirs/http-bench for more info. Fixes #22618 Change-Id: Iac99ed839c7b95d6dc66602ba8fe1fc5b500c47c Reviewed-on: https://go-review.googlesource.com/c/go/+/76410Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Richard Musiol authored
The underlying buffer of a typed array becomes invalid as soon as we grow the WebAssembly memory, which can happen at any time while Go code runs. This is a known limitation, see https://golang.org/cl/155778. As a consequence, using a typed array with one of the asynchronous read/write operations of Node.js' fs module is dangerous, since it may become invalid while the asynchronous operation has not finished yet. The result of this situation is most likely undefined. I am not aware of any nice solution to this issue, so this change adds a workaround of using an additional typed array which is not backed by WebAssembly memory and copying the bytes between the two typed arrays. Maybe WebAssembly will come up with a better solution in the future. Fixes #31702. Change-Id: Iafc2a0fa03c81db414520bd45a1a17c00080b61e Reviewed-on: https://go-review.googlesource.com/c/go/+/174304 Run-TryBot: Richard Musiol <neelance@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Jay Conrod authored
Currently, 'go get -u' upgrades modules matching command line arguments and any modules they transitively require. 'go get -u' with no positional arguments upgrades all modules transitively required by the main module. This usually adds a large number of indirect requirements, which is surprising to users. With this change, 'go get' will load packages specified by its arguments using a similar process to other commands ('go build', etc). Only modules providing packages will be upgraded. 'go get -u' now upgrades modules providing packages transitively imported by the command-line arguments. 'go get -u' without arguments will only upgrade modules needed by the package in the current directory. 'go get -m' will load all packages within a module. 'go get -m -u' without arguments will upgrade modules needed by the main module. It is equivalent to 'go get -u all'. Neither command will upgrade modules that are required but not used. Note that 'go get -m' and 'go get -d' both download modules in order to load packages. Fixes #26902 Change-Id: I2bad686b3ca8c9de985a81fb42b16a36bb4cc3ea Reviewed-on: https://go-review.googlesource.com/c/go/+/174099 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-