- 16 Oct, 2019 4 commits
-
-
Ben Shi authored
Updates golang/go#30439 Change-Id: Ieaf18b7cfd22a768eb1b7ac549ebc03637258876 Reviewed-on: https://go-review.googlesource.com/c/go/+/201377 Run-TryBot: Ben Shi <powerman1st@163.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Agniva De Sarker authored
While building a simple hello world binary, there are total 858277 calls to writeUleb during the assembler phase out of which 836625 (97%) are less than 7 bits. Using a simple micro-benchmark like this: func BenchmarkUleb(b *testing.B) { var buf bytes.Buffer for i := 0; i < b.N; i++ { writeUleb128(&buf, 42) buf.Reset() } } We get the following results with the fast path enabled. name old time/op new time/op delta Uleb-4 8.45ns ± 2% 7.51ns ± 2% -11.16% (p=0.000 n=10+10) Applying the time taken to the number of calls, we get roughly 6% improvement in total time taken for writeUleb128. We also apply the change to the function in linker to make it consistent. Change-Id: I9fe8c41df1209f5f3aa7d8bd0181f1b0e536ceb5 Reviewed-on: https://go-review.googlesource.com/c/go/+/201177 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
bill_ofarrell authored
I used too small a size for buffers, which can cause a panic in some testing. The new buffer size is generous and sufficient for all purposes. Fixes #34927 Fixes #34928 Change-Id: Icdbbfed5da87fe3757be40dfd23182b37ec62d58 Reviewed-on: https://go-review.googlesource.com/c/go/+/201317Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
The Go spec requires If a deferred function value evaluates to nil, execution panics when the function is invoked, not when the "defer" statement is executed. On Wasm and AIX, currently we actually emit a nil check at the point of defer statement, which will make it panic too early. This CL fixes this. Also, on Wasm, now the nil function will be passed through deferreturn to jmpdefer, which does an explicit nil check and calls sigpanic if it is nil. This sigpanic, being called from assembly, is ABI0. So change the assembler backend to also handle sigpanic in ABI0. Fixes #34926. Updates #8047. Change-Id: I28489a571cee36d2aef041f917b8cfdc31d557d4 Reviewed-on: https://go-review.googlesource.com/c/go/+/201297Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 15 Oct, 2019 12 commits
-
-
Ian Lance Taylor authored
Updates #33871 Change-Id: I73b1513a89ad89126159ce03ee72b922cd01916c Reviewed-on: https://go-review.googlesource.com/c/go/+/200837 Run-TryBot: Ian Lance Taylor <iant@golang.org> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Do not modify the underlying Rat denominator when calling one of the accessors Float32, Float64; verify that we don't modify the Rat denominator when calling Inv, Sign, IsInt, Num. Fixes #34919. Reopens #33792. Change-Id: Ife6d1252373f493a597398ee51e7b5695b708df5 Reviewed-on: https://go-review.googlesource.com/c/go/+/201205Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Updates #34810 Fixes #34858 Change-Id: Ie934861e51eeafe8a7fd6653c4223a5f5d45efe8 Reviewed-on: https://go-review.googlesource.com/c/go/+/201198Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Ian Lance Taylor authored
This new facility will be used by future CLs in this series. Change the only blocking call to netpoll to do the right thing when netpoll returns an empty list. Updates #6239 Updates #27707 Change-Id: I58b3c2903eda61a3698b1a4729ed0e81382bb1ed Reviewed-on: https://go-review.googlesource.com/c/go/+/171821 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
Brad Fitzpatrick authored
We now only support ALPN. Updates #28362 Change-Id: I8d9461c7a91315ee92e712448d0bf5c4070d09ae Reviewed-on: https://go-review.googlesource.com/c/go/+/201202 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
Updates #33848 Change-Id: I887d78179d467030f4177d1834ccefee28a55c8a Reviewed-on: https://go-review.googlesource.com/c/go/+/201257 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Ian Lance Taylor authored
In the tzdata database CEST is not recognized as a timezone name. It is used as the abbreviated name for daylight saving time in Central Europe. Avoid using CEST in documentation as it suggests that programs can parse dates that use CEST, which will typically fail on Unix systems. Updates #34913 Change-Id: I4b22f7d06607eb5b066812a48af58edd95498286 Reviewed-on: https://go-review.googlesource.com/c/go/+/201197 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Michael Anthony Knyszek authored
This changes fixes an oversight in wakeScavenger which would cause ready to be called off of the system stack. This change makes it so that wakeScavenger calls goready, which switches to the system stack before calling ready. Fixes #34773. Change-Id: Icb13f180b4d8fdd47c921eac1b896e3dd49e43b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/200999 Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Ben Shi authored
Updates golang/go#30439 Change-Id: I7ef5301fbd650d26a37a1241ddf7ca1ccd58b89d Reviewed-on: https://go-review.googlesource.com/c/go/+/200941Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Chase authored
When a subsequent load/store of a ptr makes the nil check of that pointer unnecessary, if their lines differ, change the line of the load/store to that of the nilcheck, and attempt to rehome the load/store position instead. This fix makes profiling less accurate in order to make panics more informative. Fixes #33724 Change-Id: Ib9afaac12fe0d0320aea1bf493617facc34034b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/200197 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
CL 196781 added map[int64]uint32 to the set of things printed with %v. Fixes #34907 Change-Id: If4a13e86cfb4b691988f5fb70449ae23760f5789 Reviewed-on: https://go-review.googlesource.com/c/go/+/201079 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joel Sing authored
Add support for rewriting MOV pseudo-instructions into appropriate RISC-V instructions. Based on the riscv-go port. Updates #27532 Change-Id: I22da6f5f12c841d56fb676ab2a37f6d0a686b033 Reviewed-on: https://go-review.googlesource.com/c/go/+/198677Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 14 Oct, 2019 15 commits
-
-
Daniel Martí authored
It was possible to get 'go env' to break itself: $ go env -w GO111MODULE=bad $ go env go: unknown environment setting GO111MODULE=bad We already check if the variable name is known. In some cases like GO111MODULE, we also know what the variable's valid values are. Enforce it when writing the variable, not just when fetching it. Fixes #34880. Change-Id: I10d682087c69f3445f314fd4473644f694e255f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/200867 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Giovanni Bajo authored
Before this CL, inequality was recorded in a bit matrix using SSA IDs. This allowed to record inequality for SSA values that we didn't know any relation in the partial order of. Unfortunately, this also means that inequality is harder to use within the poset itself as there is not fast way to map from internal poset indices and SSA values. Since we will need to check for inequality in following CLs within code that lost track of SSA values, switch to use a bit matrix of poset indices instead. This requires always allocate a poset node (as a new root) for values that are first seen in a SetNonEqual call, but it doesn't sound like a big problem. The other solution (creating and maintaining a reverse map from poset indices to SSA values) seem more complicated and memory hungry. Change-Id: Ic917485abbe70aef7ad6fa98408e5430328b6cd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/196782 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Giovanni Bajo authored
No functional changes. Change-Id: I6f5e811e141dd09dc5c47ff2d37fae4c640315e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/200862Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Giovanni Bajo authored
Currently, constants in posets, in addition to being stored in a DAG, are also stored as SSA values in a slice. This allows to quickly go through all stored constants, but it's not easy to search for a specific constant. Following CLs will benefit from being able to quickly find a constants by value in the poset, so change the constants structure to a map. Since we're at it, don't store it as *ssa.Value: poset always uses dense uint32 indices when referring a node, so just switch to it. Using a map also forces us to have a single node per constant value: this is a good thing in the first place, so this CL also make sure we never create two nodes for the same constant value. Change-Id: I099814578af35f935ebf14bc4767d607021f5f8b Reviewed-on: https://go-review.googlesource.com/c/go/+/196781 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Meng Zhuo authored
Benchmark: name old time/op new time/op delta Mul 36.0ns ± 1% 2.8ns ± 0% -92.31% (p=0.000 n=10+10) Mul32 4.37ns ± 0% 4.37ns ± 0% ~ (p=0.429 n=6+10) Mul64 36.4ns ± 0% 2.8ns ± 0% -92.37% (p=0.000 n=10+9) Change-Id: Ic4f4e5958adbf24999abcee721d0180b5413fca7 Reviewed-on: https://go-review.googlesource.com/c/go/+/200582Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Anmol Sethi authored
The comment in both functions referred to the wrong header and I made the checks easier to read. Change-Id: Ifb46729cee631a3305f557863818e3487b8eed71 Reviewed-on: https://go-review.googlesource.com/c/go/+/71753 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Giovanni Bajo authored
Add an internal mode to simplify debugging of posets by checking the integrity after every mutation. Turn it on within SSA checked builds. Change-Id: Idaa8277f58e5bce3753702e212cea4d698de30ca Reviewed-on: https://go-review.googlesource.com/c/go/+/196780 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Emmanuel T Odeke authored
Fixes the docs to correctly match the implementation and also adds a test locking-in the behavior to prevent any accidental future regressions on the docs. Fixes #33545 Change-Id: I6fdac6048cce8ac99beaa2db0dfc81d0dccc10f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200798 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
We don't punctuate compiler diagnostics. Change-Id: I19e1f30fbf04f0d1bfe6648fae26beaf3a06ee92 Reviewed-on: https://go-review.googlesource.com/c/go/+/201077Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
The IsClosureVar, IsOutputParamHeapAddr, Assigned, Addrtaken, InlFormal, and InlLocal flags are only interesting for ONAME nodes, so it's better to set these flags on Name.flags instead of Node.flags. Two caveats though: 1. Previously, we would set Assigned and Addrtaken on the entire expression tree involved in an assignment or addressing operation. However, the rest of the compiler only actually cares about knowing whether the underlying ONAME (if any) was assigned/addressed. 2. This actually requires bumping Name.flags from bitset8 to bitset16, whereas it doesn't allow shrinking Node.flags any. However, Name has some trailing padding bytes, so expanding Name.flags doesn't cost any memory. Passes toolstash-check. Change-Id: I7775d713566a38d5b9723360b1659b79391744c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/200898 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Emmanuel T Odeke authored
For Go 1.13 we introduced Header.Clone and it returns nil if a nil Header is cloned. Unfortunately, though, this exported Header.Clone nil behavior differed from the old Go 1.12 and earlier internal header clone behavior which always returned non-nil Headers. This CL fixes the places where that distinction mattered. Fixes #34878 Change-Id: Id19dea2272948c8dd10883b18ea7f7b8b33ea8eb Reviewed-on: https://go-review.googlesource.com/c/go/+/200977 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cuong Manh Le authored
Passes toolstash-check Change-Id: Iaeaf2575b9f492e45619007438c0138f9d22006c Reviewed-on: https://go-review.googlesource.com/c/go/+/200959 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Than McIntosh authored
Add to the testcase originally created for issue 34577 so as to also trigger the error condition for issue 34852 (the two bugs are closely related). Updates #34577. Updates #34852. Change-Id: I2347369652ce500184347606b2bb3e76d802b204 Reviewed-on: https://go-review.googlesource.com/c/go/+/201017 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Agniva De Sarker authored
For GOROOT packages, we were adding -unsafeptr=false to prevent unsafe.Pointer checks. But the flag also got passed to invocations of go vet with a custom vet tool. To prevent this from happening, we add this flag only when no tools are passed. Fixes #34053 Change-Id: I8bcd637fd8ec423d597fcdab2a0ceedd20786019 Reviewed-on: https://go-review.googlesource.com/c/go/+/200957 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Tobias Klauser authored
These are unused since the darwin port switched to libc calls in CL 148457. Change-Id: I309bb5b0a52c9069484e7a649d4a652efcb8e160 Reviewed-on: https://go-review.googlesource.com/c/go/+/200866 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 13 Oct, 2019 2 commits
-
-
Matthew Dempsky authored
This flag is supposed to indicate whether the expression is "addressable"; but in practice, we infer this from other attributes about the expression (e.g., n.Op and n.Class()). Passes toolstash-check. Change-Id: I19352ca07ab5646e232d98e8a7c1c9aec822ddd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/200897 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
This pseudo-Class was previously used by the importer code to optimize processing duplicate inline bodies, since we didn't actually care about the declarations in those contexts. This functionality is no longer needed with indexed exports, since we now only process function bodies as needed (and never more than once). Passes toolstash-check. Change-Id: I7eab0cb16925ab777079c2a20731dbcfd63cf195 Reviewed-on: https://go-review.googlesource.com/c/go/+/200899Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 12 Oct, 2019 5 commits
-
-
Giovanni Bajo authored
Make it a bit more relaxed on the expected fairness, as fastrand() isn't a truly perfect random number generator. Fixes #34808 Change-Id: Ib55b2bbe3c1bf63fb4f446fd1291eb1236efc33b Reviewed-on: https://go-review.googlesource.com/c/go/+/200857 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Meng Zhuo authored
Some nameservers alter the case of records as they return, e.g .google.COM or .Google.com. However according to RFC4343, DNS name should be treated in case insensitive fashion. This CL will fix case sensitive testcases. Fixes #34781 Change-Id: I5f9f6a41ddc1c61993e8d1f934ef0febddc3adc1 Reviewed-on: https://go-review.googlesource.com/c/go/+/200277Reviewed-by: Andrei Tudor Călin <mail@acln.ro> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
zdjones authored
When assessing whether A <= B, the poset's OrderedOrEqual has a passing condition which permits A <= B, but is not sufficient to infer that A <= B. This CL removes that incorrect passing condition. Having identified that A and B are in the poset, the method will report that A <= B if any of these three conditions are true: (1) A and B are the same node in the poset. - This means we know that A == B. (2) There is a directed path, strict or not, from A -> B - This means we know that, at least, A <= B, but A < B is possible. (3) There is a directed path from B -> A, AND that path has no strict edges. - This means we know that B <= A, but do not know that B < A. In condition (3), we do not have enough information to say that A <= B, rather we only know that B == A (which satisfies A <= B) is possible. The way I understand it, a strict edge shows a known, strictly-ordered relation (<) but the lack of a strict edge does not show the lack of a strictly-ordered relation. The difference is highlighted by the example in #34802, where a bounds check is incorrectly removed by prove, such that negative indexes into a slice succeed: n := make([]int, 1) for i := -1; i <= 0; i++ { fmt.Printf("i is %d\n", i) n[i] = 1 // No Bounds check, program runs, assignment to n[-1] succeeds!! } When prove is checking the negative/failed branch from the bounds check at n[i], in the signed domain we learn (0 > i || i >= len(n)). Because prove can't learn the OR condition, we check whether we know that i is non-negative so we can learn something, namely that i >= len(n). Prove uses the poset to check whether we know that i is non-negative. At this point the poset holds the following relations as a directed graph: -1 <= i <= 0 -1 < 0 In poset.OrderedOrEqual, we are testing for 0 <= i. In this case, condition (3) above is true because there is a non-strict path from i -> 0, and that path does NOT have any strict edges. Because this condition is true, the poset reports to prove that i is known to be >= 0. Knowing, incorrectly, that i >= 0, prove learns from the failed bounds check that i >= len(n) in the signed domain. When the slice, n, was created, prove learned that len(n) == 1. Because i is also the induction variable for the loop, upon entering the loop, prove previously learned that i is in [-1,0]. So when prove attempts to learn from the failed bounds check, it finds the new fact, i > len(n), unsatisfiable given that it previously learned that i <= 0 and len(n) = 1. Fixes #34802 Change-Id: I235f4224bef97700c3aa5c01edcc595eb9f13afc Reviewed-on: https://go-review.googlesource.com/c/go/+/200759 Run-TryBot: Zach Jones <zachj1@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
-
Cuong Manh Le authored
Change-Id: Id0f4955588ae8027a24465b456c90d0543d60db2 Reviewed-on: https://go-review.googlesource.com/c/go/+/200581 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Cuong Manh Le authored
Passes toolstash-check. Updates #23017 Change-Id: I0ae82e28a6e9e732ba2a6aa98f9b35551efcea10 Reviewed-on: https://go-review.googlesource.com/c/go/+/200580 Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 11 Oct, 2019 2 commits
-
-
Ian Lance Taylor authored
Fixes #34854 Change-Id: I7d6819c439e2fdfb19e181b202797fd5851eb002 Reviewed-on: https://go-review.googlesource.com/c/go/+/200839 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jerrin Shaji George authored
nanotime() currently uses the REALTIME clock to get the elapsed time in Solaris. This commit changes it to use the MONOTONIC clock instead, similar to how it's done in Linux and other OSs. Also changed nanotime() and walltime() to call clock_gettime() library function directly from Go code rather than from assembly. Fixes #33674 Change-Id: Ie4a687b17d2140998ecd97af6ce048c86cf5fc02 Reviewed-on: https://go-review.googlesource.com/c/go/+/199502 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
-