- 27 Sep, 2019 8 commits
-
-
Matthew Dempsky authored
This CL updates the export data format to include column details when writing out position data. cmd/compile is updated to generate and make use of the new details, but go/internal/gcimporter only knows how to read the data. It doesn't yet actually make use of it. Experimentally across a wide range of packages, this increases export data size by around 4%. However, it has no impact on binary size. (Notably, it actually shrinks k8s.io/kubernetes/cmd/kubelet's binary size by 24kB, but it's unclear to me why at this time.) Updates #28259. Change-Id: I351fb340839df8d3adced49b3757c4537fb91b3f Reviewed-on: https://go-review.googlesource.com/c/go/+/196963 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Justin Nuß authored
Attributes with a namespace or a data- prefix are handled as if they had no namespace/data- prefix. There is also a special case, where attributes with a "xmlns" namespace are always treated as containing URLs. This could surprise users of the package, since this behaviour was not documented anywhere, so this change adds some documentation for all three cases. Fixes #12648 Change-Id: If57a2ec49fec91a330fc04795726e8cffa9b75c0 Reviewed-on: https://go-review.googlesource.com/c/go/+/79895 Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Bonventre <andybons@golang.org>
-
Bryan C. Mills authored
The relative path element ".." is already rejected by the checks for leading and trailing dots. Fixes #27299 Change-Id: Ia8ab543c93288cdc0615abd6d22521d44bc56d72 Reviewed-on: https://go-review.googlesource.com/c/go/+/197720 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel T Odeke authored
Removes TestTimeoutHandlerAndFlusher due to flakes on one of the builders due to timing issues. Perhaps later, we might need to bring it back when we've figured out the timing issues. Fixes #34573. Change-Id: Ia88d4da31fb228296144dc31f9a4288167fb4a53 Reviewed-on: https://go-review.googlesource.com/c/go/+/197757 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Than McIntosh authored
Remove linker reading and processing of automs (no longer needed, now that the compiler is emitting R_USETYPE relocations on functions). So as to avoid changing the object file format, the object still contains a count of automs, but this count is required to be zero. Updates #34554. Change-Id: I10230e191057c5c5705541eeb06f747d5f73c42d Reviewed-on: https://go-review.googlesource.com/c/go/+/197500Reviewed-by: Jeremy Faller <jeremy@golang.org>
-
Than McIntosh authored
Don't write Autom records when writing a function to the object file; we no longer need them in the linker for DWARF processing. So as to keep the object file format unchanged, write out a zero-length list of automs to the object, as opposed to removing all references. Updates #34554. Change-Id: I42a1d67207ea7114ae4f3a315cf37effba57f190 Reviewed-on: https://go-review.googlesource.com/c/go/+/197499Reviewed-by: Jeremy Faller <jeremy@golang.org>
-
Than McIntosh authored
Switch the linker over to use dummy R_USETYPE relocations on DWARF subprogram DIEs as a means of insuring that DWARF types are created for types of autotmp values used in live functions. This change is part of a series intended to clean up handling of autotmp types and remove use of autom's in the compiler and linker. Updates #34554. Change-Id: Ic74da6bd723ab7e4d8a16ad46e23228650d4b525 Reviewed-on: https://go-review.googlesource.com/c/go/+/197498 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
-
Than McIntosh authored
During DWARF processing, keep track of the go type symbols for types directly or indirectly referenced by auto variables in a function, and add a set of dummy R_USETYPE relocations to the function's DWARF subprogram DIE symbol. This change is not useful on its own, but is part of a series of changes intended to clean up handling of autom's in the compiler and linker. Updates #34554. Change-Id: I974afa9b7092aa5dba808f74e00aa931249d6fe9 Reviewed-on: https://go-review.googlesource.com/c/go/+/197497 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>
-
- 26 Sep, 2019 30 commits
-
-
Matthew Dempsky authored
ORUNESTR represents the special case of integer->string conversion. If the integer is a constant, then the string is a constant too, so evconst needs to perform constant folding here. Passes toolstash-check. Fixes #34563. Change-Id: Ieab3d76794d8ce570106b6b707a4bcd725d156e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/197677 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Giovanni Bajo authored
Instead of returning an error, just panic: the function is used only for debugging purposes anyway. Change-Id: Ie81b2309daaf1efb9470992391534bce2141b3c2 Reviewed-on: https://go-review.googlesource.com/c/go/+/196779Reviewed-by: David Chase <drchase@google.com>
-
Giovanni Bajo authored
In poset, all constants are always related to each other, so they are part of the same DAG. Currently, it can be any of the DAGs in the forest. Since we're about to start visiting that DAG for the task of calculating bounds, make sure that it's conventionally always the first, so that we don't need to search for it. Change-Id: Ia7ca312b52336b4731b070d45cf0d768a0d6aeeb Reviewed-on: https://go-review.googlesource.com/c/go/+/196599Reviewed-by: David Chase <drchase@google.com>
-
Emmanuel T Odeke authored
Also added a test to ensure that any interactions between TimeoutHandler and Flusher result in the correct status code and body, but also that we don't get superfluous logs from stray writes as was seen in the bug report. Fixes #34439. Change-Id: I4af62db256742326f9353f98a2fcb5f71d2a5fd9 Reviewed-on: https://go-review.googlesource.com/c/go/+/197659 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
Currently we handle [...]T array literals by treating [...]T as special "DDD array" types. However, these array literals are just composite literal syntax, not a distinct Go type. Moreover, representing them as Go types contributes to complexity in a number of unrelated bits of code. This CL changes OCOMPLIT typechecking to look for the [...]T syntax and handle it specially, so we can remove DDD arrays. Passes toolstash-check. Change-Id: Ibbf701eac4caa7a321e2d10e256658fdfaa8a160 Reviewed-on: https://go-review.googlesource.com/c/go/+/197604 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Brad Fitzpatrick authored
Fixes #33977 Change-Id: I4b136788f08b08c53087af8d3cd56125e620b51b Reviewed-on: https://go-review.googlesource.com/c/go/+/197602 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Matthew Dempsky authored
Typechecking slice literals, array literals, and array literals using "..." notation all use very similar logic, but tie into the logic for checking the OCOMPLIT node in slightly different ways. By refactoring this function out into a separate helper, it makes it easier to separate slice and array literals, and the subsequent CL will further separate array literals that do use "..." notation from those that do not. Passes toolstash-check. Change-Id: I4c572e0d9d08bcc86b5c224bd6f9e1c498726c19 Reviewed-on: https://go-review.googlesource.com/c/go/+/197603 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Giovanni Bajo authored
Change-Id: I29e24c734e5e0041008771c805a0285aac3e02e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/196598Reviewed-by: David Chase <drchase@google.com>
-
Giovanni Bajo authored
prove wasn't able to detect induction variables that was bound by another inducation variable. This happened because an indvar is a Phi, and thus in case of a dependency, the loop bounding condition looked as Phi < Phi. This triggered an existing codepath that checked whether the upper bound was a Phi to detect loop conditions written in reversed order respect to the idiomatic way (eg: for i:=0; len(n)>i; i++). To fix this, we call the indvar pattern matching on both operands of the loop condition, so that the first operand that matches will be treated as the indvar. Updates #24660 (removes a boundcheck from Fannkuch) Change-Id: Iade83d8deb54f14277ed3f2e37b190e1ed173d11 Reviewed-on: https://go-review.googlesource.com/c/go/+/195220Reviewed-by: David Chase <drchase@google.com>
-
Giovanni Bajo authored
This CL extracts the logic for pattern-matching an induction variable into a separate function, in preparation for next CL where we would need to call it multiple times. No functional changes, passes toolstash -cmp. Change-Id: Ic52391e6c1b2e72bae32a0f3f65dfea321caaf4f Reviewed-on: https://go-review.googlesource.com/c/go/+/195737Reviewed-by: David Chase <drchase@google.com>
-
Matthew Dempsky authored
Removes TODO left by previous commit to appease toolstash. Change-Id: I5c0bf25f21ba5c0abe3b1b2ed0b17c604717f39b Reviewed-on: https://go-review.googlesource.com/c/go/+/197121Reviewed-by: Robert Griesemer <gri@golang.org>
-
Matthew Dempsky authored
Previously, we would recognize &(T{...}) expressions during type checking, rewrite them into (*T){...}, and then do a lot of extra work to make sure the user doesn't write (*T){...} themselves and resynthesizing the OPTRLIT later on. This CL simply handles &T{...} directly in the straight forward manner, by changing OADDR directly to OPTRLIT when appropriate. While here, match go/types's invalid composite literal type error message. Passes toolstash-check. Change-Id: I902b14c7e2cd9fa93e6915dd58272d2352ba38f8 Reviewed-on: https://go-review.googlesource.com/c/go/+/197120 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Giovanni Bajo authored
Now that OpSliceMake is called by runtime.makeslice callers, prove can see and record the actual length and cap of each slice being constructed. This small patch is enough to remove 260 additional bound checks from cmd+std. Thanks to Martin Möhrmann for pointing me to CL141822 that I had missed. Updates #24660 Change-Id: I14556850f285392051f3f07d13b456b608b64eb9 Reviewed-on: https://go-review.googlesource.com/c/go/+/196784 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Joel Sing authored
This allows for `LD 4(X5), X6' rather than `LD $4, X5, X6'. Similar for other load and store instructions. It is worth noting that none of these are likely to be used directly once the MOV pseudo-instructions are implemented. Updates #27532 Change-Id: Ie043c2dedd2cdaceb258b27976cfb3f74aa1cc1d Reviewed-on: https://go-review.googlesource.com/c/go/+/196842Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Fixes #34297 Change-Id: I4584a97d4562d7af0412d683ba1c206e3c1d9edb Reviewed-on: https://go-review.googlesource.com/c/go/+/197539 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joel Sing authored
Add support for assembling control transfer instructions. Based on the riscv-go port. Updates #27532 Change-Id: I205d3ccd0a48deeaace0f20fca8516f382a83fae Reviewed-on: https://go-review.googlesource.com/c/go/+/196841Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joel Sing authored
Add support for assembling AUIPC and LUI instructions. Based on the riscv-go port. Updates #27532 Change-Id: I178868b6dcc6fdc6b8527454569a3538ed50723e Reviewed-on: https://go-review.googlesource.com/c/go/+/196840Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Filippo Valsorda authored
Change-Id: If694ce529393b8ae9c6c55270665efc3a108a3b2 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558778Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/197504Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Filippo Valsorda authored
RFC 7230 is clear about headers with a space before the colon, like X-Answer : 42 being invalid, but we've been accepting and normalizing them for compatibility purposes since CL 5690059 in 2012. On the client side, this is harmless and indeed most browsers behave the same to this day. On the server side, this becomes a security issue when the behavior doesn't match that of a reverse proxy sitting in front of the server. For example, if a WAF accepts them without normalizing them, it might be possible to bypass its filters, because the Go server would interpret the header differently. Worse, if the reverse proxy coalesces requests onto a single HTTP/1.1 connection to a Go server, the understanding of the request boundaries can get out of sync between them, allowing an attacker to tack an arbitrary method and path onto a request by other clients, including authentication headers unknown to the attacker. This was recently presented at multiple security conferences: https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn net/http servers already reject header keys with invalid characters. Simply stop normalizing extra spaces in net/textproto, let it return them unchanged like it does for other invalid headers, and let net/http enforce RFC 7230, which is HTTP specific. This loses us normalization on the client side, but there's no right answer on the client side anyway, and hiding the issue sounds worse than letting the application decide. Fixes CVE-2019-16276 Fixes #34540 Change-Id: I6d272de827e0870da85d93df770d6a0e161bbcf1 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/549719Reviewed-by: Brad Fitzpatrick <bradfitz@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/197503 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
-
Russ Cox authored
If the parent context passed to WithCancel or WithTimeout is a known context implementation (one created by this package), we attach the child to the parent by editing data structures directly; otherwise, for unknown parent implementations, we make a goroutine that watches for the parent to finish and propagates the cancellation. A common problem with this scheme, before this CL, is that users who write custom context implementations to manage their value sets cause WithCancel/WithTimeout to start goroutines that would have not been started before. This CL changes the way we map a parent context back to the underlying data structure. Instead of walking up through known context implementations to reach the *cancelCtx, we look up parent.Value(&cancelCtxKey) to return the innermost *cancelCtx, which we use if it matches parent.Done(). This way, a custom context implementation wrapping a *cancelCtx but not changing Done-ness (and not refusing to return wrapped keys) will not require a goroutine anymore in WithCancel/WithTimeout. For #28728. Change-Id: Idba2f435c81b19fe38d0dbf308458ca87c7381e9 Reviewed-on: https://go-review.googlesource.com/c/go/+/196521Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
This reverts CL 196837 (commit 78baea83). Reason for revert: broke the mips64le build. Change-Id: I531da60d098cb227659c9977a3d229474325b0a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/197538 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Anthony Knyszek authored
There are currently two edges in the lock cycle graph caused by scavenge.lock: with sched.lock and mheap_.lock. These edges appear because of the call to ready() and stack growths respectively. Furthermore, there's already an invariant in the code wherein mheap_.lock must be acquired before scavenge.lock, hence the cycle. The fix to this is to bring scavenge.lock higher in the lock cycle graph, such that sched.lock and mheap_.lock are only acquired once scavenge.lock is already held. To faciliate this change, we move scavenger waking outside of gcSetTriggerRatio such that it doesn't have to happen with the heap locked. Furthermore, we check scavenge generation numbers with the heap locked by using gopark instead of goparkunlock, and specify a function which aborts the park should there be any skew in generation count. Fixes #34047. Change-Id: I3519119214bac66375e2b1262b36ce376c820d12 Reviewed-on: https://go-review.googlesource.com/c/go/+/191977 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Davor Kapsa authored
Change-Id: I59446965b198767af60d617da29b5c2e457829ba Reviewed-on: https://go-review.googlesource.com/c/go/+/197477Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Bryan C. Mills authored
The macOS filesystem seems to have gotten significantly flakier as of macOS 10.14, so this causes frequently flakes in the 10.14 builders. We have no reason to believe that it will be fixed any time soon, so rather than trying to detect the specific macOS version, we'll apply the same workarounds that we use on Windows: classifying (and retrying) the errors known to indicate flakiness and relaxing the success criteria for renameio.TestConcurrentReadsAndWrites. Fixes #33041 Change-Id: I74d8c15677951d7a0df0d4ebf6ea03e43eebddf9 Reviewed-on: https://go-review.googlesource.com/c/go/+/197517 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
-
Jeremy Faller authored
As promised in CL 188238, removing the obsolete symbol. Here are the latest stats. This is baselined at "e53edafb" with only these changes applied, run on magna.cam. The linker looks straight better (in memory and speed). There is still a change I'm working on walking the progs to generate the debug_lines data in the compiler. That will likely result in a compiler speedup. name old time/op new time/op delta Template 324ms ± 3% 317ms ± 3% -2.07% (p=0.043 n=10+10) Unicode 142ms ± 4% 144ms ± 3% ~ (p=0.393 n=10+10) GoTypes 1.05s ± 2% 1.07s ± 2% +1.59% (p=0.019 n=9+9) Compiler 4.09s ± 2% 4.11s ± 1% ~ (p=0.218 n=10+10) SSA 12.5s ± 1% 12.7s ± 1% +1.00% (p=0.035 n=10+10) Flate 199ms ± 7% 203ms ± 5% ~ (p=0.481 n=10+10) GoParser 245ms ± 3% 246ms ± 5% ~ (p=0.780 n=9+10) Reflect 672ms ± 4% 688ms ± 3% +2.42% (p=0.015 n=10+10) Tar 280ms ± 4% 284ms ± 4% ~ (p=0.123 n=10+10) XML 379ms ± 4% 381ms ± 2% ~ (p=0.529 n=10+10) LinkCompiler 1.16s ± 4% 1.12s ± 2% -3.03% (p=0.001 n=10+9) ExternalLinkCompiler 2.28s ± 3% 2.23s ± 3% -2.51% (p=0.011 n=8+9) LinkWithoutDebugCompiler 686ms ± 9% 667ms ± 2% ~ (p=0.277 n=9+8) StdCmd 14.1s ± 1% 14.0s ± 1% ~ (p=0.739 n=10+10) name old user-time/op new user-time/op delta Template 604ms ±23% 564ms ± 7% ~ (p=0.661 n=10+9) Unicode 429ms ±40% 418ms ±37% ~ (p=0.579 n=10+10) GoTypes 2.43s ±12% 2.51s ± 7% ~ (p=0.393 n=10+10) Compiler 9.22s ± 3% 9.27s ± 3% ~ (p=0.720 n=9+10) SSA 26.3s ± 3% 26.6s ± 2% ~ (p=0.579 n=10+10) Flate 328ms ±19% 333ms ±12% ~ (p=0.842 n=10+9) GoParser 387ms ± 5% 378ms ± 9% ~ (p=0.356 n=9+10) Reflect 1.36s ±20% 1.43s ±21% ~ (p=0.631 n=10+10) Tar 469ms ±12% 471ms ±21% ~ (p=0.497 n=9+10) XML 685ms ±18% 698ms ±19% ~ (p=0.739 n=10+10) LinkCompiler 1.86s ±10% 1.87s ±11% ~ (p=0.968 n=10+9) ExternalLinkCompiler 3.20s ±13% 3.01s ± 8% -5.70% (p=0.046 n=8+9) LinkWithoutDebugCompiler 1.08s ±15% 1.09s ±20% ~ (p=0.579 n=10+10) name old alloc/op new alloc/op delta Template 36.3MB ± 0% 36.4MB ± 0% +0.26% (p=0.000 n=10+10) Unicode 28.5MB ± 0% 28.5MB ± 0% ~ (p=0.165 n=10+10) GoTypes 120MB ± 0% 121MB ± 0% +0.29% (p=0.000 n=9+10) Compiler 546MB ± 0% 548MB ± 0% +0.32% (p=0.000 n=10+10) SSA 1.84GB ± 0% 1.85GB ± 0% +0.49% (p=0.000 n=10+10) Flate 22.9MB ± 0% 23.0MB ± 0% +0.25% (p=0.000 n=10+10) GoParser 27.8MB ± 0% 27.9MB ± 0% +0.25% (p=0.000 n=10+8) Reflect 77.5MB ± 0% 77.7MB ± 0% +0.27% (p=0.000 n=9+9) Tar 34.5MB ± 0% 34.6MB ± 0% +0.23% (p=0.000 n=10+10) XML 44.2MB ± 0% 44.4MB ± 0% +0.32% (p=0.000 n=10+10) LinkCompiler 239MB ± 0% 230MB ± 0% -3.86% (p=0.000 n=10+10) ExternalLinkCompiler 243MB ± 0% 243MB ± 0% +0.22% (p=0.000 n=10+10) LinkWithoutDebugCompiler 164MB ± 0% 155MB ± 0% -5.45% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 371k ± 0% 372k ± 0% +0.44% (p=0.000 n=10+10) Unicode 340k ± 0% 340k ± 0% +0.05% (p=0.000 n=10+10) GoTypes 1.32M ± 0% 1.32M ± 0% +0.46% (p=0.000 n=10+10) Compiler 5.34M ± 0% 5.37M ± 0% +0.59% (p=0.000 n=10+10) SSA 17.6M ± 0% 17.7M ± 0% +0.63% (p=0.000 n=10+10) Flate 233k ± 0% 234k ± 0% +0.48% (p=0.000 n=10+10) GoParser 309k ± 0% 310k ± 0% +0.40% (p=0.000 n=10+10) Reflect 964k ± 0% 969k ± 0% +0.54% (p=0.000 n=10+10) Tar 346k ± 0% 348k ± 0% +0.48% (p=0.000 n=10+9) XML 424k ± 0% 426k ± 0% +0.51% (p=0.000 n=10+10) LinkCompiler 751k ± 0% 645k ± 0% -14.13% (p=0.000 n=10+10) ExternalLinkCompiler 1.79M ± 0% 1.69M ± 0% -5.30% (p=0.000 n=10+10) LinkWithoutDebugCompiler 217k ± 0% 222k ± 0% +2.02% (p=0.000 n=10+10) name old object-bytes new object-bytes delta Template 547kB ± 0% 559kB ± 0% +2.17% (p=0.000 n=10+10) Unicode 215kB ± 0% 216kB ± 0% +0.60% (p=0.000 n=10+10) GoTypes 1.99MB ± 0% 2.03MB ± 0% +2.02% (p=0.000 n=10+10) Compiler 7.86MB ± 0% 8.07MB ± 0% +2.73% (p=0.000 n=10+10) SSA 26.4MB ± 0% 27.2MB ± 0% +3.27% (p=0.000 n=10+10) Flate 337kB ± 0% 343kB ± 0% +2.02% (p=0.000 n=10+10) GoParser 432kB ± 0% 441kB ± 0% +2.11% (p=0.000 n=10+10) Reflect 1.33MB ± 0% 1.36MB ± 0% +1.87% (p=0.000 n=10+10) Tar 477kB ± 0% 487kB ± 0% +2.24% (p=0.000 n=10+10) XML 617kB ± 0% 632kB ± 0% +2.33% (p=0.000 n=10+10) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 109kB ± 0% +0.09% (p=0.000 n=10+10) SSA 137kB ± 0% 137kB ± 0% +0.03% (p=0.000 n=10+10) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 760kB ± 0% 760kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.11MB ± 0% 1.13MB ± 0% +1.10% (p=0.000 n=10+10) CmdGoSize 14.9MB ± 0% 15.0MB ± 0% +0.77% (p=0.000 n=10+10) Change-Id: I42e6087cd6231dbdcfff5464e46d373474e455e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/192417Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
-
Michael Munday authored
Prior to this CL conditional branches on s390x always used an extended mnemonic such as BNE, BLT and so on to represent branch instructions with different condition code masks. This CL adds support for numeric condition code masks to the s390x SSA backend so that we can encode the condition under which a Block's successor is chosen as a field in that Block rather than in its type. This change will be useful as we come to add support for combined compare-and-branch instructions. Rather than trying to add extended mnemonics for every possible combination of mask and compare-and- branch instruction we can instead use a single mnemonic for each instruction. Change-Id: Idb7458f187b50906877d683695c291dff5279553 Reviewed-on: https://go-review.googlesource.com/c/go/+/197178Reviewed-by: Keith Randall <khr@golang.org>
-
Jeremy Faller authored
This switches the linker over to using the new debug_lines data generated in the compiler. Change-Id: If8362d6fcea7db60aaebab670ed6f702ab1c4908 Reviewed-on: https://go-review.googlesource.com/c/go/+/191968 Run-TryBot: Jeremy Faller <jeremy@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Tobias Klauser authored
Replace usage of yyerror with yyerrorl in checkdefergo and copytype in typecheck.go. All covered error messages already appear in the tests and the yyerror replacement did not lead to any tests failing. Passes toolstash-check Updates #19683 Change-Id: I735e83bcda7ddc6a14afb22e50200bcbb9192fc4 Reviewed-on: https://go-review.googlesource.com/c/go/+/69910 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel T Odeke authored
CL 192518 was a minimal simplification to get sendfile on Windows to work with chunked files, but as I had mentioned, I would add even more improvements. This CL improves it by: * If the reader is not an *io.LimitedReader, since the underlying reader is anyways an *os.File, we fallback and stat that file to determine the file size and then also invoke the chunked sendFile on the underlying reader. This issue existed even before the prior CL. * Extracting the chunked TransmitFile logic and moving it directly into internal/poll.SendFile. Thus if the callers of net.sendFile don't use *io.LimitedReader, but have a huge file (>2GiB), we can still invoke the chunked internal/poll.SendFile on it directly. The test case is not included in this patch as it requires creating a 3GiB file, but that if anyone wants to view it, they can find it at https://go-review.googlesource.com/c/go/+/194218/13/src/net/sendfile_windows_test.go Updates #33193. Change-Id: I97a67c712d558c84ced716d8df98b040cd7ed7f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/194218 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Tardis Xu authored
Change the comment to make more conformable to the function implementation. Change-Id: I8461e2f09824c50e16223a27d0f61070f04bd21b GitHub-Last-Rev: c25a8493d3938b38e2c318f7a7b94c9f2eb11bb4 GitHub-Pull-Request: golang/go#27404 Reviewed-on: https://go-review.googlesource.com/c/go/+/132477Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
-
- 25 Sep, 2019 2 commits
-
-
Dan Scales authored
Add a bunch of extra tests and benchmarks for defer, in preparation for new low-cost (open-coded) implementation of defers (see #34481), - New file defer_test.go that tests a bunch more unusual defer scenarios, including things that might have problems for open-coded defers. - Additions to callers_test.go actually verifying what the stack trace looks like for various panic or panic-recover scenarios. - Additions to crash_test.go testing several more crash scenarios involving recursive panics. - New benchmark in runtime_test.go measuring speed of panic-recover - New CGo benchmark in cgo_test.go calling from Go to C back to Go that shows defer overhead Updates #34481 Change-Id: I423523f3e05fc0229d4277dd00073289a5526188 Reviewed-on: https://go-review.googlesource.com/c/go/+/197017 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Michael Munday authored
The branch-relative-on-condition (BRC) instruction allows us to use an immediate to specify under what conditions the branch is taken. For example, `BRC $7, L1` is equivalent to `BNE L1`. It is sometimes useful to specify branches in this way when either we don't have an extended mnemonic for a particular mask value or we want to generate the condition code mask programmatically. The new load-on-condition (LOCR and LOCGR) and compare-and-branch (CRJ, CGRJ, CLRJ, CLGRJ, CIJ, CGIJ, CLIJ and CLGIJ) instructions provide the same flexibility for conditional loads and combined compare and branch instructions. Change-Id: Ic6f5d399b0157e278b39bd3645f4ee0f4df8e5fc Reviewed-on: https://go-review.googlesource.com/c/go/+/196558 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-