- 18 Jan, 2016 2 commits
-
-
Mikio Hara authored
Updates #13981. Change-Id: Id8f3cd56a81a7a993cea5c757e619407da491fed Reviewed-on: https://go-review.googlesource.com/18710Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This is testing code in asm_GOARCH.s, so it's not necessary to run the test on systems where it doesn't build. Fixes #13991. Change-Id: Ia7a2d3a34b32e6987dc67428c1e09e63baf0518a Reviewed-on: https://go-review.googlesource.com/18707Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 16 Jan, 2016 3 commits
-
-
Brad Fitzpatrick authored
Wire up Transport.CloseIdleConnections to http2.Transport.CloseIdleConnections. Updates x/net/http2 to git rev c92cdcb0 for https://golang.org/cl/18678 Fixes #13975 Change-Id: I1183a31256104ff95ae7621e5788cfeee741b1aa Reviewed-on: https://go-review.googlesource.com/18679Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
GC assists check gcBlackenEnabled under the assist queue lock to avoid going to sleep after gcWakeAllAssists has already woken all assists. However, currently we clear gcBlackenEnabled shortly *after* waking all assists, which opens a window where this exact race can happen. Fix this by clearing gcBlackenEnabled before waking blocked assists. However, it's unlikely this actually matters because the world is stopped between waking assists and clearing gcBlackenEnabled and there aren't any obvious allocations during this window, so I don't think an assist could actually slip in to this race window. Updates #13645. Change-Id: I7571f059530481dc781d8fd96a1a40aadebecb0d Reviewed-on: https://go-review.googlesource.com/18682 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Mikio Hara authored
Also adds missing nosplit to unminit. Fixes #13964. Change-Id: I07d93a8c872a255a89f91f808b66c889f0a6a69c Reviewed-on: https://go-review.googlesource.com/18658Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 15 Jan, 2016 2 commits
-
-
Brad Fitzpatrick authored
If a user starts two HTTP requests when no http2 connection is available, both end up creating new TCP connections, since the server's protocol (h1 or h2) isn't yet known. Once it turns out that the server supports h2, one of the connections is useless. Previously we kept upgrading both TLS connections to h2 (SETTINGS frame exchange, etc). Now the unnecessary connections are closed instead, before the h2 preface/SETTINGS. Updates x/net/http2 to git rev a8e212f3d for https://golang.org/cl/18675 This CL contains the tests for https://golang.org/cl/18675 Semi-related change noticed while writing the tests: now that we have TLSNextProto in Go 1.6, which consults the TLS ConnectionState.NegotiatedProtocol, we have to gurantee that the TLS handshake has been done before we look at the ConnectionState. So add that check after the DialTLS hook. (we never documented that users have to call Handshake, so do it for them, now that it matters) Updates #13957 Change-Id: I9a70e9d1282fe937ea654d9b1269c984c4e366c0 Reviewed-on: https://go-review.googlesource.com/18676Reviewed-by: Andrew Gerrand <adg@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
While the default behavior of eliding runtime frames from tracebacks usually makes sense, this is not the case when you're trying to test the runtime itself. Fix this by forcing the traceback level to at least "system" in the runtime tests. This will specifically help with debugging issue #13645, which has proven remarkably resistant to reproduction outside of the build dashboard itself. Change-Id: I2a8356ba6c3c5badba8bb3330fc527357ec0d296 Reviewed-on: https://go-review.googlesource.com/18648 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
- 14 Jan, 2016 15 commits
-
-
Matthew Dempsky authored
Fixes #13916. Change-Id: If2cad5473a749460909519ac20aca19dea8a2e7a Reviewed-on: https://go-review.googlesource.com/18671Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Russ Cox authored
Fixes build. Change-Id: Idd7d87f0bf3fe553b3ab00dd32eee4925a4fe3ff Reviewed-on: https://go-review.googlesource.com/18647 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
Change-Id: I6b1dc789e54a385c958961e7ba16bfd9d0f3b313 Reviewed-on: https://go-review.googlesource.com/18629Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Brad Fitzpatrick authored
Passes with go test -race -count=1000 -name=TestServerValidatesHostHeader now without hanging. Fixes #13950 Change-Id: I41c3a555c642595c95c8c52f19a05a4c68e67630 Reviewed-on: https://go-review.googlesource.com/18660 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This doesn't fix a bug, but may improve performance in programs that have many concurrent calls from C to Go. The old code made several system calls between lockextra and unlockextra. That could be happening while another thread is spinning acquiring lockextra. This changes the code to not make any system calls while holding the lock. Change-Id: I50576478e478670c3d6429ad4e1b7d80f98a19d8 Reviewed-on: https://go-review.googlesource.com/18548Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #12217. Change-Id: I5ee6cb18eaa66bdec1affe689aa531c05e719fc9 Reviewed-on: https://go-review.googlesource.com/18645Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
TestFutexsleep is supposed to clean up before returning by waking up the goroutines it started and left blocked in futex sleeps. However, it currently fails at this in several ways: 1. Both the sleep and wakeup are done on the address of tt.mtx, but in both cases tt is a *local copy* of the futexsleepTest created by a loop, so the sleep and wakeup happen on completely different addresses. Fix this by making them both use the address of the global tt.mtx. 2. If the sleep happens after the wakeup (not likely, but not impossible), it won't wake up. Fix this by using the futex protocol properly: sleep if the mutex's value is 0, and set the mutex's value to non-zero before doing the wakeup. 3. If TestFutexsleep runs more than once, channels and mutex values left over from the first run will interfere with later runs. Fix this by clearing the mutex value and creating a new channel for each test and waiting for goroutines to finish before returning (lest they send their completion to the channel for the next run). As an added bonus, this test now actually tests that futex sleep/wakeup work. Previously this test would have been satisfied if futexsleep was an infinite loop and futexwakeup was a no-op. Change-Id: I1cbc6871cc9dcb8f4601b3621913bec2b79b0fc3 Reviewed-on: https://go-review.googlesource.com/18617Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
-
Russ Cox authored
Otherwise it is impossible to vendor a/b/c without hiding the real a/b. I also updated golang.org/s/go15vendor. Fixes #13832. Change-Id: Iee3d53c11ea870721803f6e8e67845b405686e79 Reviewed-on: https://go-review.googlesource.com/18644Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Shenghou Ma authored
Fixes #13948. Change-Id: I37d734c1241f3d72d8fe33dfdf79b573e5476b1f Reviewed-on: https://go-review.googlesource.com/18643Reviewed-by: Russ Cox <rsc@golang.org>
-
Andrew Gerrand authored
Fixes #12489 Change-Id: I25dd3f76e4cfe9a71b987c3b31445724568391e9 Reviewed-on: https://go-review.googlesource.com/18625Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #13647. Change-Id: I28df7ade9b5abd79ce6b9c3d14ceaa988e86fc01 Reviewed-on: https://go-review.googlesource.com/18642 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
Currently readType simultaneously constructs a type graph and resolves the sizes of the types. However, these two operations are fundamentally at odds: the order we parse a cyclic structure in may be different than the order we need to resolve type sizes in. As a result, it's possible that when readType attempts to resolve the size of a typedef, it may dereference a nil Type field of another typedef retrieved from the type cache that's only partially constructed. To fix this, we delay resolving typedef sizes until the end of the readType recursion, when the full type graph is constructed. Fixes #13039. Change-Id: I9889af37fb3be5437995030fdd61e45871319d07 Reviewed-on: https://go-review.googlesource.com/18459Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Fixes build on those systems. Also fix printing of AVARLIVE. Change-Id: I1b38cca0125689bc08e4e1bdd0d0c140b1ea079a Reviewed-on: https://go-review.googlesource.com/18641Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
This will allow the compiler to crunch Prog lists down to code as each function is compiled, instead of waiting until the end, which should reduce the working set of the compiler. But not until Go 1.7. This also makes it easier to write some machine code output tests for the assembler, which is why it's being done now. For #13822. Change-Id: I0811123bc6e5717cebb8948f9cea18e1b9baf6f7 Reviewed-on: https://go-review.googlesource.com/18311Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Consider this code: func f(*int) func g() { p := new(int) f(p) } where f is an assembly function. In general liveness analysis assumes that during the call to f, p is dead in this frame. If f has retained p, p will be found alive in f's frame and keep the new(int) from being garbage collected. This is all correct and works. We use the Go func declaration for f to give the assembly function liveness information (the arguments are assumed live for the entire call). Now consider this code: func h1() { p := new(int) syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p))) } Here syscall.Syscall is taking the place of f, but because its arguments are uintptr, the liveness analysis and the garbage collector ignore them. Since p is no longer live in h once the call starts, if the garbage collector scans the stack while the system call is blocked, it will find no reference to the new(int) and reclaim it. If the kernel is going to write to *p once the call finishes, reclaiming the memory is a mistake. We can't change the arguments or the liveness information for syscall.Syscall itself, both for compatibility and because sometimes the arguments really are integers, and the garbage collector will get quite upset if it finds an integer where it expects a pointer. The problem is that these arguments are fundamentally untyped. The solution we have taken in the syscall package's wrappers in past releases is to insert a call to a dummy function named "use", to make it look like the argument is live during the call to syscall.Syscall: func h2() { p := new(int) syscall.Syscall(1, 2, 3, uintptr(unsafe.Pointer(p))) use(unsafe.Pointer(p)) } Keeping p alive during the call means that if the garbage collector scans the stack during the system call now, it will find the reference to p. Unfortunately, this approach is not available to users outside syscall, because 'use' is unexported, and people also have to realize they need to use it and do so. There is much existing code using syscall.Syscall without a 'use'-like function. That code will fail very occasionally in mysterious ways (see #13372). This CL fixes all that existing code by making the compiler do the right thing automatically, without any code modifications. That is, it takes h1 above, which is incorrect code today, and makes it correct code. Specifically, if the compiler sees a foreign func definition (one without a body) that has uintptr arguments, it marks those arguments as "unsafe uintptrs". If it later sees the function being called with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x as having escaped, and it makes sure to hold x in a live temporary variable until the call returns, so that the garbage collector cannot reclaim whatever heap memory x points to. For now I am leaving the explicit calls to use in package syscall, but they can be removed early in a future cycle (likely Go 1.7). The rule has no effect on escape analysis, only on liveness analysis. Fixes #13372. Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500 Reviewed-on: https://go-review.googlesource.com/18584Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 13 Jan, 2016 18 commits
-
-
Brad Fitzpatrick authored
Per https://groups.google.com/forum/#!topic/golang-dev/javNmryAh0I Change-Id: I08d7cbc94da4fc61c848f3dbee4637bf8fcfeb01 Reviewed-on: https://go-review.googlesource.com/18630Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Chris Broadfoot <cbro@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Keith Randall authored
CMOVs were not introduced until P6. We need 386 to run on Pentium MMX. Fixes #13923 Change-Id: Iee9572cd83e64c3a1336bc1e6b300b048fbcc996 Reviewed-on: https://go-review.googlesource.com/18621Reviewed-by: Minux Ma <minux@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev 341cd08 for https://golang.org/cl/18576 Change-Id: If5dcb60ac449b798c34fe332ede5ec74e66eb9db Reviewed-on: https://go-review.googlesource.com/18579Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Update #13925 Change-Id: I7cd0625fad841eb0e3f364629f9bc225aa2fdce9 Reviewed-on: https://go-review.googlesource.com/18575Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Robert Griesemer authored
This is the equivalent of https://golang.org/cl/18549 for the binary importer (which is usually not used because by default the gc compiler produces the traditional textual export format). For #13898. Change-Id: Idb6b515f2ee49e6d0362c71846994b0bd4dae8f7 Reviewed-on: https://go-review.googlesource.com/18598Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Robert Griesemer <gri@golang.org>
-
Ian Lance Taylor authored
GCC 4.8 exits 1 on an unrecognized option, but GCC 4.4 and 4.5 exit 0. I didn't check other versions, or try to figure out just when this changed. Fixes #13937. Change-Id: If193e9053fbb535999c9bde99f430f465a8c7c57 Reviewed-on: https://go-review.googlesource.com/18597 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
The package of anonymous fields is the package in which they were declared, not the package of the anonymous field's type. Was correct before and incorrectly changed with https://golang.org/cl/18549. Change-Id: I9fd5bfbe9d0498c8733b6ca7b134a85defe16113 Reviewed-on: https://go-review.googlesource.com/18596Reviewed-by: Alan Donovan <adonovan@google.com>
-
Russ Cox authored
This makes lldb willing to debug them. The minimum version is hard-coded at OS X 10.7, because that is the minimum that Go requires. For more control over the version, users can use linkmode=external and pass the relevant flags to the host linker. Fixes #12941. Change-Id: I20027be8aa034d07dd2a3326828f75170afe905f Reviewed-on: https://go-review.googlesource.com/18588Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
Fixes #13928. Change-Id: Ia04c6bdef5ae6924d03982682ee195048f8f387f Reviewed-on: https://go-review.googlesource.com/18611Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
For #13934. Change-Id: Id399e35598def96f8bb89b9fcd1bf14ee06e2e62 Reviewed-on: https://go-review.googlesource.com/18612Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
In gc export data, exported struct field and interface method names appear in unqualified form (i.e., w/o package name). The (gc)importer assumed that unqualified exported names automatically belong to the package being imported. This is not the case if the field or method belongs to a struct or interface that was declared in another package and re-exported. The issue becomes visible if a type T (say an interface with a method M) is declared in a package A, indirectly re-exported by a package B (which imports A), and then imported in C. If C imports both A and B, if A is imported before B, T.M gets associated with the correct package A. If B is imported before A, T.M appears to be exported by B (even though T itself is correctly marked as coming from A). If T.M is imported again via the import of A if gets dropped (as it should) because it was imported already. The fix is to pass down the parent package when we parse imported types so that the importer can use the correct package when creating fields and methods. Fixes #13898. Change-Id: I7ec2ee2dda15859c582b65db221c3841899776e1 Reviewed-on: https://go-review.googlesource.com/18549Reviewed-by: Alan Donovan <adonovan@google.com>
-
Joe Sylve authored
* Enable c-shared buildmode on darwin/386 * dyld does not support text relocation on i386. Add -read_only_relocs suppress flag to linker Fixes #13904 Change-Id: I9adbd20d3f36ce9bbccf1bffb746b391780d088f Reviewed-on: https://go-review.googlesource.com/18500Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Updates x/net/http2 to git rev c93a9b4f2a for https://golang.org/cl/18474 Forgot to submit this four days ago. Change-Id: Id96ab164ec765911c31874cca39b44aa55e80153 Reviewed-on: https://go-review.googlesource.com/18574Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #11489 Change-Id: I887ebac2dcb772e73ee393891c487f694028aaf2 Reviewed-on: https://go-review.googlesource.com/18520Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
When the Transport was creating an bound HTTP connection (protocol unknown initially) and then ends up deciding it doesn't need it, a goroutine sits around to clean up whatever the result was. That goroutine made the false assumption that the result was always an HTTP/1 connection or an error. It may also be an alternate protocol in which case the *persistConn.conn net.Conn field is nil, and the alt field is non-nil. Fixes #13839 Change-Id: Ia4972e5eb1ad53fa00410b3466d4129c753e0871 Reviewed-on: https://go-review.googlesource.com/18573Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Russ Cox authored
Change-Id: I9b4b76abfba66ff655aef55b43d9b4721aba604a Reviewed-on: https://go-review.googlesource.com/18587Reviewed-by: Chris Broadfoot <cbro@golang.org>
-
Emmanuel Odeke authored
Change-Id: If4a90c4017ef4b5c9f497cf117c8ad62b7e15c62 Reviewed-on: https://go-review.googlesource.com/18501 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
The fucomi* opcodes were only introduced for the Pentium Pro. They do not exist for an MMX Pentium. Use the fucom* instructions instead and move the condition codes from the fp flags register to the integer flags register explicitly. The use of fucomi* opcodes in ggen.go was introduced in 1.5 (CL 8738). The bad ops were generated for 64-bit floating-point comparisons. The use of fucomi* opcodes in gsubr.go dates back to at least 1.1. The bad ops were generated for float{32,64} to uint64 conversions. Fixes #13923 Change-Id: I5290599f5edea8abf8fb18036f44fa78bd1fc9e6 Reviewed-on: https://go-review.googlesource.com/18590Reviewed-by: Minux Ma <minux@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-