- 31 May, 2016 10 commits
-
-
Michael Hudson-Doyle authored
golang.org/issue/15443 complained that a race-enabled PIE binary crashed at startup, but other ways of linking in tsan (or other sanitizers) such as #cgo CFLAGS: -fsanitize=thread #cgo LDFLAGS: -fsanitize=thread have the same problem. Pass -no-pie to the host linker (if supported) if any -fsanitizer=foo cgo LDFLAG is seen when linking. Fixes #15887 Change-Id: Id799770f8d045f6f40fa8c463563937a5748d1a8 Reviewed-on: https://go-review.googlesource.com/23535 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Fixes #15900 Change-Id: Ieada5f4e3b3b2ae358414e013f3090b4b820569b Reviewed-on: https://go-review.googlesource.com/23536 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ian Lance Taylor authored
Add TSAN acquire/release calls to runtime/cgo to match the ones generated by cgo. This avoids a false positive race around the malloc memory used in runtime/cgo when other goroutines are simultaneously calling malloc and free from cgo. These new calls will only be used when building with CGO_CFLAGS and CGO_LDFLAGS set to -fsanitize=thread, which becomes a requirement to avoid all false positives when using TSAN. These are needed not just for runtime/cgo, but also for any runtime package that uses cgo (such as net and os/user). Add an unused attribute to the _cgo_tsan_acquire and _cgo_tsan_release functions, in case there are no actual cgo function calls. Add a test that checks that setting CGO_CFLAGS/CGO_LDFLAGS avoids a false positive report when using os/user. Change-Id: I0905c644ff7f003b6718aac782393fa219514c48 Reviewed-on: https://go-review.googlesource.com/23492 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Josh Bleecher Snyder authored
Fixes #15898. Change-Id: I66e2ad21f283563c7142aa820f0354711d964768 Reviewed-on: https://go-review.googlesource.com/23573 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Joe Tsai authored
As rendered on https://tip.golang.org/pkg/compress/flate/, there is an extra new-line because of the unexported constants in the same block. <<< const ( NoCompression = 0 BestSpeed = 1 BestCompression = 9 DefaultCompression = -1 HuffmanOnly = -2 // Disables match search and only does Huffman entropy reduction. ) >>> Instead, seperate the exported compression level constants into its own const block. This is both more readable and also fixes the issue. Change-Id: I60b7966c83fb53356c02e4640d05f55a3bee35b7 Reviewed-on: https://go-review.googlesource.com/23557Reviewed-by:
-
Ian Lance Taylor authored
In order to support pprof for position independent executables, pprof needs to adjust the PC addresses stored in the profile by the address at which the program is loaded. The legacy profiling support which we use already supports recording the GNU/Linux /proc/self/maps data immediately after the CPU samples, so do that. Also change the pprof symbolizer to use the information, if available, when looking up addresses in the Go pcline data. Fixes #15714. Change-Id: I4bf679210ef7c51d85cf873c968ce82db8898e3e Reviewed-on: https://go-review.googlesource.com/23525Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Andrew Gerrand authored
The Windows builders run the throughput benchmarks really slowly with a 64kb buffer. Lowering it to 16kb brings the performance back into line with the other builders. This is a work-around to get the build green until we can figure out why the Windows builders are slow with the larger buffer size. Update #15899 Change-Id: I215ebf115e8295295c87f3b3e22a4ef1f9e77f81 Reviewed-on: https://go-review.googlesource.com/23574Reviewed-by:
-
Richard Miller authored
This is a correction to CL 22610. The gbit16 function is called in StartProcess between fork and exec, and therefore must not split the stack. Normally it's inlined so this is not an issue, but on one occasion I've observed it to be compiled without inlining, and the result was a panic. Mark it go:nosplit to be safe. Change-Id: I0381754397b766431bf406d9767c73598d23b901 Reviewed-on: https://go-review.googlesource.com/23560Reviewed-by:
David du Colombier <0intro@gmail.com> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Minux Ma <minux@golang.org> Reviewed-by:
-
Andrew Gerrand authored
Fixes #15418 Change-Id: Ibc51d602eb28819d0e44e5ca13a5c61573e4111c Reviewed-on: https://go-review.googlesource.com/23570Reviewed-by:
-
Josh Bleecher Snyder authored
This is a minimal fix to prevent this and other possible future infinite recursion. We can put in a proper fix for UNC in Go 1.8. Updates #15879 Change-Id: I3653cf5891bab8511adf66fa3c1a1d8912d1a293 Reviewed-on: https://go-review.googlesource.com/23572 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
- 30 May, 2016 3 commits
-
-
Andrew Gerrand authored
Updates #15810 Change-Id: I37f14a0ed1f5ac24ea2169a7e65c0469bfddd928 Reviewed-on: https://go-review.googlesource.com/23559Reviewed-by:
Michael McGreevy <mcgreevy@golang.org> Reviewed-by:
-
Mikio Hara authored
forceCloseSockets is just designed as a kingston valve for TestMain function and is not suitable to keep track of inflight sockets. Fixes #15525. Change-Id: Id967fe5b8da99bb08b699cc45e07bbc3dfc3ae3d Reviewed-on: https://go-review.googlesource.com/23505Reviewed-by:
-
Augusto Roman authored
The original draft mentioned support for json.Marshaler, but that's not the case. JSON supports only string keys (not arbitrary JSON) so only encoding.TextMarshaller is supported. Change-Id: I7788fc23ac357da88e92aa0ca17b513260840cee Reviewed-on: https://go-review.googlesource.com/23529Reviewed-by:
-
- 29 May, 2016 4 commits
-
-
Keith Randall authored
Add a bunch of tests for shifts. Fix triple-shift rules to always take constant shifts as 64 bits. (Earlier rules always promote shift amounts to 64 bits.) Add overflow checks. Increases generic rule coverage to 91% Change-Id: I6b42d368d19d36ac482dbb8e0d4f67e30ad7145d Reviewed-on: https://go-review.googlesource.com/23555Reviewed-by:
Todd Neal <todd@tneal.org>
-
Keith Randall authored
Increases generic.rules coverage from 91% to 95%. Change-Id: I981eb94f3cd10d2f87c836576a43786787a25d83 Reviewed-on: https://go-review.googlesource.com/23556 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
The documentation previously used C style enumerations: 0, 1, 2. While this is pretty much universally correct, it does not help a user become aware of the existence of the SeekStart, SeekCurrent, and SeekEnd constants. Thus, we should use them in the documentation to direct people's attention to them. Updates #6885 Change-Id: I44b5e78d41601c68a0a1c96428c853df53981d52 Reviewed-on: https://go-review.googlesource.com/23551Reviewed-by:
-
Joe Tsai authored
Document the following: * That the algorithmic changes are still compliant with RFC 1951. I remember people having questions regarding this issue, and it would be good to re-assure them that it is still standards compliant. * io.EOF can now be returned early (c27efce6) * Use the term "decompress" when referred to as an action. The term "uncompressed" or "decompressed" are both valid as ways to represent the current state of the data. Change-Id: Ie29ebce709357359e7c36d3e7f3d53b260eaadfa Reviewed-on: https://go-review.googlesource.com/23552Reviewed-by:
-
- 28 May, 2016 1 commit
-
-
Emmanuel Odeke authored
Fixes #15868 Change-Id: I4e4471e77091309c4ea1d546b2c4f20dfbb4314e Reviewed-on: https://go-review.googlesource.com/23550Reviewed-by:
-
- 27 May, 2016 22 commits
-
-
Robert Griesemer authored
Also: Added some test cases for issue #10709. No impact when debugging output is disabled (default). For #10709. Change-Id: I0751befb222c86d46225377a674f6bad2990349e Reviewed-on: https://go-review.googlesource.com/23442Reviewed-by:
Alan Donovan <adonovan@google.com>
-
Ilya Tocar authored
Fixes #15689 Change-Id: I56d0103738cc35cd5bc5e77a0e0341c0dd55530e Reviewed-on: https://go-review.googlesource.com/23440Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
Keith Randall authored
When we do *p = f(), we might need to copy the return value from f to p with a write barrier. The write barrier itself is a call, so we need to copy the return value of f to a temporary location before we call the write barrier function. Otherwise, the call itself (specifically, marshalling the args to typedmemmove) will clobber the value we're trying to write. Fixes #15854 Change-Id: I5703da87634d91a9884e3ec098d7b3af713462e7 Reviewed-on: https://go-review.googlesource.com/23522Reviewed-by:
David Chase <drchase@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
For #15840. Change-Id: I2ecf5c7b00afc2034cf3d7a1fd78636a908beb67 Reviewed-on: https://go-review.googlesource.com/23517 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Austin Clements authored
Commit fa3543e3 introduced formatting errors. Change-Id: I4b921f391a9b463cefca4318ad63b70ae6ce6865 Reviewed-on: https://go-review.googlesource.com/23514Reviewed-by:
-
Austin Clements authored
Commit 36a80c59 introduced formatting errors. Change-Id: I6d5b231200cd7abcd5b94c1a3f4e99f10ee11c4f Reviewed-on: https://go-review.googlesource.com/23513Reviewed-by:
-
Mikio Hara authored
Fixes #15864. Change-Id: Ic12aa3654bf0b7e4a26df20ea92d07d7efe7339c Reviewed-on: https://go-review.googlesource.com/23504Reviewed-by:
-
Mikio Hara authored
Change-Id: I6dc3666398b4cd7a7195bb9c0e321fa8b733fa15 Reviewed-on: https://go-review.googlesource.com/23502Reviewed-by:
-
Mikio Hara authored
Also adds missing copyright notice. Updates #15603. Change-Id: Icf4bb45ba5edec891491fe5f0039a8a25125d168 Reviewed-on: https://go-review.googlesource.com/23501Reviewed-by:
-
Austin Clements authored
Currently when the garbage collector frees stacks of dead goroutines in markrootFreeGStacks, it calls stackfree on a regular user stack. This is a problem, since stackfree manipulates the stack cache in the per-P mcache, so if it grows the stack or gets preempted in the middle of manipulating the stack cache (which are both possible since it's on a user stack), it can easily corrupt the stack cache. Fix this by calling markrootFreeGStacks on the system stack, so that all calls to stackfree happen on the system stack. To prevent this bug in the future, mark stack functions that manipulate the mcache as go:systemstack. Fixes #15853. Change-Id: Ic0d1c181efb342f134285a152560c3a074f14a3d Reviewed-on: https://go-review.googlesource.com/23511 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
Rick Hudson <rlh@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
For #15599. Change-Id: Icc2e58a3f314b7a098d78fe164ba36f5b2897de6 Reviewed-on: https://go-review.googlesource.com/23481 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
The current code, introduced after Go 1.6 to improve latency on low-bandwidth connections, sends 1 kB packets until 1 MB has been sent, and then sends 16 kB packets (the maximum record size). Unfortunately this decreases throughput for 1-16 MB responses by 20% or so. Following discussion on #15713, change cutoff to 128 kB sent and also grow the size allowed for successive packets: 1 kB, 2 kB, 3 kB, ..., 15 kB, 16 kB. This fixes the throughput problems: the overhead is now closer to 2%. I hope this still helps with latency but I don't have a great way to test it. At the least, it's not worse than Go 1.6. Comparing MaxPacket vs DynamicPacket benchmarks: name maxpkt time/op dyn. time/op delta Throughput/1MB-8 5.07ms ± 7% 5.21ms ± 7% +2.73% (p=0.023 n=16+16) Throughput/2MB-8 15.7ms ±201% 8.4ms ± 5% ~ (p=0.604 n=20+16) Throughput/4MB-8 14.3ms ± 1% 14.5ms ± 1% +1.53% (p=0.000 n=16+16) Throughput/8MB-8 26.6ms ± 1% 26.8ms ± 1% +0.47% (p=0.003 n=19+18) Throughput/16MB-8 51.0ms ± 1% 51.3ms ± 1% +0.47% (p=0.000 n=20+20) Throughput/32MB-8 100ms ± 1% 100ms ± 1% +0.24% (p=0.033 n=20+20) Throughput/64MB-8 197ms ± 0% 198ms ± 0% +0.56% (p=0.000 n=18+7) The small MB runs are bimodal in both cases, probably GC pauses. But there's clearly no general slowdown anymore. Fixes #15713. Change-Id: I5fc44680ba71812d24baac142bceee0e23f2e382 Reviewed-on: https://go-review.googlesource.com/23487Reviewed-by:
-
Russ Cox authored
Change-Id: Ia540c890767dcb001d3b3b55d98d9517b13b21da Reviewed-on: https://go-review.googlesource.com/23510Reviewed-by:
-
Russ Cox authored
New in Go 1.7 so still possible to change. This allows implementations not tied to *net.Dialer. Fixes #15748. Change-Id: I5fabbf13c7f1951c06587a4ccd120def488267ce Reviewed-on: https://go-review.googlesource.com/23489Reviewed-by:
-
Russ Cox authored
Requested during CL 23431. Change-Id: I513ae42166b3a9fcfe51231ff55c163ab672e7d2 Reviewed-on: https://go-review.googlesource.com/23485Reviewed-by:
-
Russ Cox authored
This was just storage for a linked list. Change-Id: I850e8db1e1f5e72410f5c904be9409179b56a94a Reviewed-on: https://go-review.googlesource.com/23484Reviewed-by:
-
Russ Cox authored
For #15810. Change-Id: Ib529808f664392feb9b36770f3d3d875fcb54528 Reviewed-on: https://go-review.googlesource.com/23488 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel Odeke authored
Document new behavior about signal name printing in panics as per CL golang.org/cl/22753. For #15810 Change-Id: I9c677d5dd779b41e82afa25e3c797d8e739600d3 Reviewed-on: https://go-review.googlesource.com/23493Reviewed-by:
-
Russ Cox authored
The main check here is that liveness now crashes if it finds an instruction using a variable that should be tracked but is not. Comments and adjustments in nodarg to explain what's going on and to remove the "-1" argument added a few months ago, plus a sketch of a future simplification. The need for n.Orig in the earlier CL seems to have been an intermediate problem rather than fundamental: the new explanations in nodarg make clear that nodarg is not causing the problem I thought, and in fact now using n instead of n.Orig works fine in plive.go. Change-Id: I3f5cf9f6e4438a6d27abac7d490e7521545cd552 Reviewed-on: https://go-review.googlesource.com/23450 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Dmitri Shuralyov authored
This is a fixup change for commit 5cd29448 that added parsing of SCP-like addresses. To get the expected output from (*url.URL).String(), Path needs to be set, not RawPath. Add a test for this, since it has already regressed multiple times. Updates #11457. Change-Id: I806f5abbd3cf65e5bdcef01aab872caa8a5b8891 Reviewed-on: https://go-review.googlesource.com/23447 Run-TryBot: Andrew Gerrand <adg@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Russ Cox authored
As in the elimination of PHEAP|PPARAM in CL 23393, this is something the front end can trivially take care of and then not bother the back ends with. It also eliminates some suspect (and only lightly exercised) code paths in the back ends. I don't have a smoking gun for this one but it seems more clearly correct. Change-Id: I3b3f5e669b3b81d091ff1e2fb13226a6f14c69d5 Reviewed-on: https://go-review.googlesource.com/23431Reviewed-by:
-
Russ Cox authored
The liveness computation of parameters generally was never correct, but forcing all parameters to be live throughout the function covered up that problem. The new SSA back end is too clever: even though it currently keeps the parameter values live throughout the function, it may find optimizations that mean the current values are not written back to the original parameter stack slots immediately or ever (for example if a parameter is set to nil, SSA constant propagation may replace all later uses of the parameter with a constant nil, eliminating the need to write the nil value back to the stack slot), so the liveness code must now track the actual operations on the stack slots, exposing these problems. One small problem in the handling of arguments is that nodarg can return ONAME PPARAM nodes with adjusted offsets, so that there are actually multiple *Node pointers for the same parameter in the instruction stream. This might be possible to correct, but not in this CL. For now, we fix this by using n.Orig instead of n when considering PPARAM and PPARAMOUT nodes. The major problem in the handling of arguments is general confusion in the liveness code about the meaning of PPARAM|PHEAP and PPARAMOUT|PHEAP nodes, especially as contrasted with PAUTO|PHEAP. The difference between these two is that when a local variable "moves" to the heap, it's really just allocated there to start with; in contrast, when an argument moves to the heap, the actual data has to be copied there from the stack at the beginning of the function, and when a result "moves" to the heap the value in the heap has to be copied back to the stack when the function returns This general confusion is also present in the SSA back end. The PHEAP bit worked decently when I first introduced it 7 years ago (!) in 391425ae. The back end did nothing sophisticated, and in particular there was no analysis at all: no escape analysis, no liveness analysis, and certainly no SSA back end. But the complications caused in the various downstream consumers suggest that this should be a detail kept mainly in the front end. This CL therefore eliminates both the PHEAP bit and even the idea of "heap variables" from the back ends. First, it replaces the PPARAM|PHEAP, PPARAMOUT|PHEAP, and PAUTO|PHEAP variable classes with the single PAUTOHEAP, a pseudo-class indicating a variable maintained on the heap and available by indirecting a local variable kept on the stack (a plain PAUTO). Second, walkexpr replaces all references to PAUTOHEAP variables with indirections of the corresponding PAUTO variable. The back ends and the liveness code now just see plain indirected variables. This may actually produce better code, but the real goal here is to eliminate these little-used and somewhat suspect code paths in the back end analyses. The OPARAM node type goes away too. A followup CL will do the same to PPARAMREF. I'm not sure that the back ends (SSA in particular) are handling those right either, and with the framework established in this CL that change is trivial and the result clearly more correct. Fixes #15747. Change-Id: I2770b1ce3cbc93981bfc7166be66a9da12013d74 Reviewed-on: https://go-review.googlesource.com/23393Reviewed-by:
-
