- 24 Jan, 2017 7 commits
-
-
Ian Lance Taylor authored
Update docs on correspondence between Go releases and GCC releases. Update C type that corresponds to Go type `int`. Drop out of date comments about Ubuntu and RTEMS. Change-Id: Ic1b5ce9f242789af23ec3b7e7a64c9d257d6913e Reviewed-on: https://go-review.googlesource.com/35631 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
You have to actually run make.bash (or make.bat). Update #18771. Change-Id: Ie6672a4e4abde0150c1ae57cabb1222de2c78716 Reviewed-on: https://go-review.googlesource.com/35632Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Change-Id: I6341b8cce0b4a9922928f73f8b459cbb9ec25e79 Reviewed-on: https://go-review.googlesource.com/35571Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Brad Fitzpatrick authored
The presence of Request.GetBody being set on a request was causing all redirected requests to have a body, even if the redirect status didn't warrant one. This bug came from 307/308 support (https://golang.org/cl/29852) which removed the line that set req.Body to nil after POST/PUT redirects. Change-Id: I2a4dd5320f810ae25cfd8ea8ca7c9700e5dbd369 Reviewed-on: https://go-review.googlesource.com/35633 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
Mikio Hara authored
Change-Id: I31fa5f906ad2e8dc475dbbeb91f568f91e16861b Reviewed-on: https://go-review.googlesource.com/35514 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Otherwise we don't emit any required ELF relocations when doing an external link, because elfrelocsect skips unreachable symbols. Fixes #18745. Change-Id: Ia3583c41bb6c5ebb7579abd26ed8689370311cd6 Reviewed-on: https://go-review.googlesource.com/35590 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Brad Fitzpatrick authored
Fixes #18766 Change-Id: Ic0f72f3b7bbccd0546692993c4ed414f8c88c1c6 Reviewed-on: https://go-review.googlesource.com/35573Reviewed-by: Russ Cox <rsc@golang.org>
-
- 23 Jan, 2017 1 commit
-
-
Keith Randall authored
memmove used to use 2 2-byte load/store pairs to move 4 bytes. When the result is loaded with a single 4-byte load, it caused a store to load fowarding stall. To avoid the stall, special case memmove to use 4 byte ops for the 4 byte copy case. We already have a special case for 8-byte copies. 386 already specializes 4-byte copies. I'll do 2-byte copies also, but not for 1.8. benchmark old ns/op new ns/op delta BenchmarkIssue18740-8 7567 4799 -36.58% 3-byte copies get a bit slower. Other copies are unchanged. name old time/op new time/op delta Memmove/3-8 4.76ns ± 5% 5.26ns ± 3% +10.50% (p=0.000 n=10+10) Fixes #18740 Change-Id: Iec82cbac0ecfee80fa3c8fc83828f9a1819c3c74 Reviewed-on: https://go-review.googlesource.com/35567 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
- 21 Jan, 2017 1 commit
-
-
Michael Munday authored
The constant propagation rules selected the wrong operand to propagate. So MOVDNE (move if not equal) propagated operands as if it were a MOVDEQ (move if equal). Fixes #18735. Change-Id: I87ac469172f9df7d5aabaf7106e2936ce54ae202 Reviewed-on: https://go-review.googlesource.com/35498 Run-TryBot: Michael Munday <munday@ca.ibm.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 20 Jan, 2017 4 commits
-
-
Ian Lance Taylor authored
This is needed for typical tests with gccgo, as it passes the LD_LIBRARY_PATH environment variable to the new program. Change-Id: I9bf4b0dbdff63f5449c7fcb8124eaeab10ed7f34 Reviewed-on: https://go-review.googlesource.com/35481 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
With GCC 7 (not yet released), cgo fails with errors like ./sigaltstack.go:65:8: call of non-function C.restoreSignalStack I do not know precisely why. Explicitly declaring that there are no arguments to the static function is a simple fix for the debug info. Change-Id: Id96e1cb1e55ee37a9f1f5ad243d7ee33e71584ac Reviewed-on: https://go-review.googlesource.com/35480 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
When nilcheck runs, the values in a block are not in any particular order. So any facts derived from examining the blocks shouldn't be used until we reach the next block. This is suboptimal as it won't eliminate nil checks within a block. But it's probably a better fix for now as it is a much smaller change than other strategies for fixing this bug. nilptr3.go changes are mostly because for this pattern: _ = *p _ = *p either nil check is fine to keep, and this CL changes which one the compiler tends to keep. There are a few regressions from code like this: _ = *p f() _ = *p For this pattern, after this CL we issue 2 nil checks instead of one. (For the curious, this happens because intra-block nil check elimination now falls to CSE, not nilcheck proper. The former pattern has two nil checks with the same store argument. The latter pattern has two nil checks with different store arguments.) Fixes #18725 Change-Id: I3721b494c8bc9ba1142dc5c4361ea55c66920ac8 Reviewed-on: https://go-review.googlesource.com/35485Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Josh Bleecher Snyder authored
pprof.WriteHeapProfile is shorthand for pprof.Lookup("heap").WriteTo(f, 0). The second parameter is debug. If it is non-zero, pprof writes legacy-format pprof output, which compilebench can parse. Fixes #18641 Change-Id: Ica69adeb9809e9b5933aed943dcf4a07910e43fc Reviewed-on: https://go-review.googlesource.com/35484 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
- 19 Jan, 2017 2 commits
-
-
Bryan C. Mills authored
fixes #18707. Change-Id: Ibc4efef01197799f66d10bfead22faf8ac00473c Reviewed-on: https://go-review.googlesource.com/35452 Run-TryBot: Bryan Mills <bcmills@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Hironao OTSUBO authored
The doc comment about the Data field of go/ast.Object reflects its old behavior, from when the go/types typechecker depended on ast.Objects. Since when the doc was written, the behavior has changed in https://golang.org/cl/7058060 and https://golang.org/cl/7096048 . Fixes #18631 Change-Id: I10fc3e31cfbf7b303eec44150df917f6eb285f90 Reviewed-on: https://go-review.googlesource.com/35075Reviewed-by: Robert Griesemer <gri@golang.org>
-
- 18 Jan, 2017 4 commits
-
-
Austin Clements authored
Currently we check that all roots are marked as soon as gcMarkDone decides to transition from mark 1 to mark 2. However, issue #16083 indicates that there may be a race where we try to complete mark 1 while a worker is still scanning a stack, causing the root mark check to fail. We don't yet understand this race, but as a simple mitigation, move the root check to after gcMarkDone performs a ragged barrier, which will force any remaining workers to finish their current job. Updates #16083. This may "fix" it, but it would be better to understand and fix the underlying race. Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2 Reviewed-on: https://go-review.googlesource.com/35353 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Russ Cox authored
Fixes #18603. Change-Id: I5760c0a9f862200b7e943058a672eb559ac1b9d9 Reviewed-on: https://go-review.googlesource.com/35354 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates #18609 Change-Id: I8306135660f52cf625bed4c7f53f632e527617de Reviewed-on: https://go-review.googlesource.com/35265 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org>
-
David du Colombier authored
Fixes #18610. Change-Id: I19da4d59a1b6293c9a4722aa696e2cb58d982a15 Reviewed-on: https://go-review.googlesource.com/35333Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 17 Jan, 2017 4 commits
-
-
Keith Randall authored
We already do this for shared libraries. Do it for plugins also. Suggestions on how to test this would be welcome. I'd like to get this in for 1.8. It could lead to mysterious hangs when using plugins. Fixes #18676 Change-Id: I03209b096149090b9ba171c834c5e59087ed0f92 Reviewed-on: https://go-review.googlesource.com/35117Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Alberto Donizetti authored
Fixes #18675 Change-Id: I82e63e8ee3fe4a998b01d9397c3045912588e2f5 Reviewed-on: https://go-review.googlesource.com/35183Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
gulyasm authored
The bug subcommand opens up the browser instead of printing information. Fixes help message to reflect that. Fixes #18630. Change-Id: I660c94bc65ef1994292cfd72d08a544699545701 Reviewed-on: https://go-review.googlesource.com/35150Reviewed-by: Russ Cox <rsc@golang.org>
-
Filippo Valsorda authored
As is, they were fully vulnerable to the Lucky13 attack. The SHA1 variants implement limited countermeasures (see f28cf834) but the SHA256 ones are apparently used rarely enough (see 87415048) that it's not worth the extra code. Instead, disable them by default and update the warning. Updates #13385 Updates #15487 Change-Id: I45b8b716001e2fa0811b17e25be76e2512e5abb2 Reviewed-on: https://go-review.googlesource.com/35290Reviewed-by: Adam Langley <alangley@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Matt Layher <mdlayher@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 16 Jan, 2017 4 commits
-
-
Cherry Zhang authored
It looks like it should be there, although I couldn't find a test case that fails without it. ZeroWB is probably never generated now: zeroing an initialized heap object is done by making an autotmp on stack, zeroing it, and copying (typedmemmove) to heap. Passes "toolstash -cmp" on std. Change-Id: I702a59759e33fb8cc2a34a3b3029e7540aca080a Reviewed-on: https://go-review.googlesource.com/35250Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
Change-Id: Iac713ae1f322f893c92b3fc47fe9b5719052f9eb Reviewed-on: https://go-review.googlesource.com/35240Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Symonds <dsymonds@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
-
Josh Bleecher Snyder authored
Fixes #18661. Change-Id: I865802a9b88ab22560c9914a70901d1924242bdc Reviewed-on: https://go-review.googlesource.com/35236 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
Fixes #18673. Change-Id: Ic827c16ad414733392c348da1c9ed9b308879fef Reviewed-on: https://go-review.googlesource.com/35260 Run-TryBot: Minux Ma <minux@golang.org> Reviewed-by: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 14 Jan, 2017 4 commits
-
-
David du Colombier authored
CL 5232 added TestServerHijackGetsBackgroundByte, which is failing on Plan 9, because CloseWrite is not implemented on Plan 9 yet. Updates #17906. Updates #18657. Change-Id: I3c2f73760b0f767f3f9ed2698c855372170e0481 Reviewed-on: https://go-review.googlesource.com/35178Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
CL 35234 added TestServerHijackGetsBackgroundByte_big, which is failing on Plan 9, because CloseWrite is not implemented on Plan 9 yet. Updates #17906. Updates #18658. Change-Id: Icaf3fe3600d586515ecd92aca874104ea81ce6b9 Reviewed-on: https://go-review.googlesource.com/35179 Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Follow-up test from Ian's comments in https://golang.org/cl/35232 after submit. Change-Id: Ifa504bd8d09e555c3c7738376199dfc9b99130cf Reviewed-on: https://go-review.googlesource.com/35234 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
David Crawshaw authored
The working directory is now adjusted to match the typical Go test working directory in main, as the old trick for adjusting earlier stopped working with the latest version of LLDB bugs. That means the small number of places where testdata files are read before main is called no longer work. This CL adjusts those reads to happen after main is called. (This has the bonus effect of not reading some benchmark testdata files in all.bash.) Fixes compress/bzip2, go/doc, go/parser, os, and time package tests on the iOS builder. Change-Id: If60f026aa7848b37511c36ac5e3985469ec25209 Reviewed-on: https://go-review.googlesource.com/35255 Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 13 Jan, 2017 6 commits
-
-
Brad Fitzpatrick authored
Previously, if the Hijack called stopped the background read call which read a byte, that byte was sitting in memory, buffered, ready to be Read by Hijack's returned bufio.Reader, but it wasn't yet in the bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1 byte fewer. This matters for callers who wanted to stitch together any buffered data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's returned net.Conn. Otherwise there was no way for callers to know a byte was read. Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13 Reviewed-on: https://go-review.googlesource.com/35232 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
-
David Crawshaw authored
Another change in behvaior (bug) in LLDB. Despite the fact that LLDB can dump the symtab of our test binaries and show the function addresses, it can no longer call the functions. This means the chdir trick on signal is failing. This CL uses a new trick. For iOS, the exec script passes the change in directory as an argument, and it is processed early by the test harness generated by cmd/go. For the iOS builders. Change-Id: I8f5d0f831fe18de99f097761f89c5184d5bf2afb Reviewed-on: https://go-review.googlesource.com/35152Reviewed-by: Elias Naur <elias.naur@gmail.com> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
mkpost.go replaces all variables prefixed with 'X_' with '_' on s390x because most of them do not need to be exposed. X__val is being used by a third party library so it turns out we do need to expose it on s390x (it is already exposed on all other Linux architectures). Fixes #17298 and updates #18632. Change-Id: Ic03463229a5f75ca41a4a4b50300da4b4d892d45 Reviewed-on: https://go-review.googlesource.com/30130Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
Also fix a couple of other errors. Fixes #6877 Change-Id: I94c81c5847cc7b0adab19418e71687bc2ee7fe94 Reviewed-on: https://go-review.googlesource.com/34960Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
Make sure that the same type and itab generated in two different plugins are actually the same thing. See also CL 35115 Change-Id: I0c1ecb039d7e2bf5a601d58dfa162a435ae4ef76 Reviewed-on: https://go-review.googlesource.com/35116 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Austin Clements authored
When traceback sees reflect.makeFuncStub (or reflect.methodValueCall) on the stack, it expects to be able to get the *reflect.makeFuncImpl (or *reflect.methodValue) for that call from the first outgoing argument slot of makeFuncStub/methodValueCall. However, currently this object isn't necessarily kept live across makeFuncStub. This means it may get garbage collected while in a reflect call and reused for something else. If we then try to traceback, the runtime will see a corrupted makeFuncImpl object and panic. This was not a problem in previous releases because we always kept arguments live across the whole function. This became a problem when we stopped doing this. Fix this by using reflect.KeepAlive to keep the makeFuncImpl/methodValue live across all of callReflect/callMethod, which in turn keeps it live as long as makeFuncStub/methodValueCall are on the stack. Fixes #18635. Change-Id: I91853efcf17912390fddedfb0230648391c33936 Reviewed-on: https://go-review.googlesource.com/35151 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 12 Jan, 2017 3 commits
-
-
David Crawshaw authored
C-only symbols are excluded from pclntab because of a quirk of darwin, where functions are referred to by an exported symbol so dynamic relocations de-duplicate to the host binary module and break unwinding. This doesn't happen on ELF systems because the linker always refers to unexported module-local symbols, so we don't need this condition. And the current logic for excluding some functions breaks the module verification code in moduledataverify1. So disable this for plugins on linux. (In 1.9, it will probably be necessary to introduce a module-local symbol reference system on darwin to fix a different bug, so all of this onlycsymbol code made be short-lived.) With this CL, the tests in CL 35116 pass. Change-Id: I517d7ca4427241fa0a91276c462827efb9383be9 Reviewed-on: https://go-review.googlesource.com/35190Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Joe Tsai authored
Ranging over an array causes the array to be copied over to the stack, which cause large re-growths. Instead, we should iterate over slices of the array. Also, assigning a large struct literal uses the stack even though the actual fields being populated are small in comparison to the entirety of the struct (see #18636). Fixing the stack growth does not alter CPU-time performance much since the stack-growth and copying was such a tiny portion of the compression work: name old time/op new time/op delta Encode/Digits/Default/1e4-8 332µs ± 1% 332µs ± 1% ~ (p=0.796 n=10+10) Encode/Digits/Default/1e5-8 5.07ms ± 2% 5.05ms ± 1% ~ (p=0.815 n=9+8) Encode/Digits/Default/1e6-8 53.7ms ± 1% 53.9ms ± 1% ~ (p=0.075 n=10+10) Encode/Twain/Default/1e4-8 380µs ± 1% 380µs ± 1% ~ (p=0.684 n=10+10) Encode/Twain/Default/1e5-8 5.79ms ± 2% 5.79ms ± 1% ~ (p=0.497 n=9+10) Encode/Twain/Default/1e6-8 61.5ms ± 1% 61.8ms ± 1% ~ (p=0.247 n=10+10) name old speed new speed delta Encode/Digits/Default/1e4-8 30.1MB/s ± 1% 30.1MB/s ± 1% ~ (p=0.753 n=10+10) Encode/Digits/Default/1e5-8 19.7MB/s ± 2% 19.8MB/s ± 1% ~ (p=0.795 n=9+8) Encode/Digits/Default/1e6-8 18.6MB/s ± 1% 18.5MB/s ± 1% ~ (p=0.072 n=10+10) Encode/Twain/Default/1e4-8 26.3MB/s ± 1% 26.3MB/s ± 1% ~ (p=0.616 n=10+10) Encode/Twain/Default/1e5-8 17.3MB/s ± 2% 17.3MB/s ± 1% ~ (p=0.484 n=9+10) Encode/Twain/Default/1e6-8 16.3MB/s ± 1% 16.2MB/s ± 1% ~ (p=0.238 n=10+10) Updates #18636 Fixes #18625 Change-Id: I471b20339bf675f63dc56d38b3acdd824fe23328 Reviewed-on: https://go-review.googlesource.com/35122Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
Missing from CL 34926. Change-Id: I4a046440c30811f26da53bee0e853dae3b0ac57a Reviewed-on: https://go-review.googlesource.com/35123Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-