- 14 Jan, 2016 2 commits
-
-
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 27 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>
-
Ian Lance Taylor authored
Install pkg.h rather than libpkg.h. Link against -lc. Fixes #13860. Change-Id: I4e429426f8363712a5dbbd2655b9aab802ab2888 Reviewed-on: https://go-review.googlesource.com/18592 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Russ Cox <rsc@golang.org>
-
Ilya Tocar authored
Add several instructions that were used via BYTE and use them. Instructions added: PEXTRB, PEXTRD, PEXTRQ, PINSRB, XGETBV, POPCNT. Change-Id: I5a80cd390dc01f3555dbbe856a475f74b5e6df65 Reviewed-on: https://go-review.googlesource.com/18593 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Mikio Hara authored
This change applies the fix for #13564 to Plan 9 and Windows. Also enables Lookup API test cases on builders. Updates #13564. Change-Id: I863f03c7cb6fbe58b3a55223bfa0ac5f9bf9c3df Reviewed-on: https://go-review.googlesource.com/18559 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
Update bundled http2 to git rev 76365a4 for https://golang.org/issue/18571 Fixes golang/go#13924 Change-Id: Ibb48cd6935b35d9965df70fb8761be5986d79ffc Reviewed-on: https://go-review.googlesource.com/18591Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Conn.Close sends an encrypted "close notify" to signal secure EOF. But writing that involves acquiring mutexes (handshake mutex + the c.out mutex) and writing to the network. But if the reason we're calling Conn.Close is because the network is already being problematic, then Close might block, waiting for one of those mutexes. Instead of blocking, and instead of introducing new API (at least for now), distinguish between a normal Close (one that sends a secure EOF) and a resource-releasing destructor-style Close based on whether there are existing Write calls in-flight. Because io.Writer and io.Closer aren't defined with respect to concurrent usage, a Close with active Writes is already undefined, and should only be used during teardown after failures (e.g. deadlines or cancelations by HTTP users). A normal user will do a Write then serially do a Close, and things are unchanged for that case. This should fix the leaked goroutines and hung net/http.Transport requests when there are network errors while making TLS requests. Change-Id: If3f8c69d6fdcebf8c70227f41ad042ccc3f20ac9 Reviewed-on: https://go-review.googlesource.com/18572Reviewed-by: Adam Langley <agl@golang.org> Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Chase authored
Brief background on "why heap allocate". Things can be forced to the heap for the following reasons: 1) address published, hence lifetime unknown. 2) size unknown/too large, cannot be stack allocated 3) multiplicity unknown/too large, cannot be stack allocated 4) reachable from heap (not necessarily published) The bug here is a case of failing to enforce 4) when an object Y was reachable from a heap allocation X forced because of 3). It was found in the case of a closure allocated within a loop (X) and assigned to a variable outside the loop (multiplicity unknown) where the closure also captured a map (Y) declared outside the loop (reachable from heap). Note the variable declared outside the loop (Y) is not published, has known size, and known multiplicity (one). The only reason for heap allocation is that it was reached from a heap allocated item (X), but because that was not forced by publication, it has to be tracked by loop level, but escape-loop level was not tracked and thus a bug results. The fix is that when a heap allocation is newly discovered, use its looplevel as the minimum loop level for downstream escape flooding. Every attempt to generalize this bug to X-in-loop- references-Y-outside loop succeeded, so the fix was aimed to be general. Anywhere that loop level forces heap allocation, the loop level is tracked. This is not yet tested for all possible X and Y, but it is correctness- conservative and because it caused only one trivial regression in the escape tests, it is probably also performance-conservative. The new test checks the following: 1) in the map case, that if fn escapes, so does the map. 2) in the map case, if fn does not escape, neither does the map. 3) in the &x case, that if fn escapes, so does &x. 4) in the &x case, if fn does not escape, neither does &x. Fixes #13799. Change-Id: Ie280bef2bb86ec869c7c206789d0b68f080c3fdb Reviewed-on: https://go-review.googlesource.com/18234 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Hudson-Doyle authored
A bit cleanuppy for 1.6 maybe, but something I happened to notice. Change-Id: I70f3b48445f4f527d67f7b202b6171195440b09f Reviewed-on: https://go-review.googlesource.com/18550Reviewed-by: Russ Cox <rsc@golang.org>
-
Russ Cox authored
[Repeat of CL 18343 with build fixes.] Before, NumGoroutine counted system goroutines and Stack (usually) didn't show them, which was inconsistent and confusing. To resolve which way they should be consistent, it seems like package main import "runtime" func main() { println(runtime.NumGoroutine()) } should print 1 regardless of internal runtime details. Make it so. Fixes #11706. Change-Id: If26749fec06aa0ff84311f7941b88d140552e81d Reviewed-on: https://go-review.googlesource.com/18432Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Russ Cox <rsc@golang.org>
-
Russ Cox authored
Fixes #13907. Change-Id: Ieaa5183f399b12a9177372212adf481c8f0b4a0d Reviewed-on: https://go-review.googlesource.com/18491Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Vlad Krasnov <vlad@cloudflare.com> Reviewed-by: Adam Langley <agl@golang.org>
-
- 12 Jan, 2016 6 commits
-
-
Ian Lance Taylor authored
Update #9401. Update #11925. Update #13919. Change-Id: I52c679353693e8165b2972d4d3974ee8bb1207ef Reviewed-on: https://go-review.googlesource.com/18542 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Denys Honsiorovskyi authored
Many browsers now support schemeless URLs in the Location headers and also it is allowed in the draft HTTP/1.1 specification (see http://stackoverflow.com/q/4831741#comment25926312_4831741), but Go standard library lacks support for them. This patch implements schemeless URLs support in http.Redirect(). Since url.Parse() correctly handles schemeless URLs, I've just added an extra condition to verify URL's Host part in the absoulute/relative check in the http.Redirect function. Also I've moved oldpath variable initialization inside the block of code where it is used. Change-Id: Ib8a6347816a83e16576f00c4aa13224a89d610b5 Reviewed-on: https://go-review.googlesource.com/14172Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
It would certainly be a mistake to invoke a write barrier while greying an object. Change-Id: I34445a15ab09655ea8a3628a507df56aea61e618 Reviewed-on: https://go-review.googlesource.com/18533 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
It used to be the case that repeatedly getting one GC pointer and enqueuing one GC pointer could cause contention on the work buffers as each operation passed over the boundary of a work buffer. As of b6c0934a, we use a two buffer cache that prevents this sort of contention. Change-Id: I4f1111623f76df9c5493dd9124dec1e0bfaf53b7 Reviewed-on: https://go-review.googlesource.com/18532 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
This comment is probably a hold-over from when the heap bitmap was interleaved and the shift was 0, 2, 4, or 6. Now the shift is 0, 1, 2, or 3. Change-Id: I096ec729e1ca31b708455c98b573dd961d16aaee Reviewed-on: https://go-review.googlesource.com/18531 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Andrew Gerrand authored
Fixes #9228 Change-Id: Ic4df4a39f6f363bdd6eb9228c8164e6e9dccee1b Reviewed-on: https://go-review.googlesource.com/5561Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
- 11 Jan, 2016 5 commits
-
-
Michael Hudson-Doyle authored
Go fails to build on a system which has PIE enabled by default like this: /usr/bin/ld: -r and -pie may not be used together collect2: error: ld returned 1 exit status The only system I know that has this property right now is Ubuntu Xenial running on s390x, which is hardly the most accessible system, but it's planned to enable this on amd64 soon too. The fix is to pass -no-pie along with -Wl,-r to the compiler, but unfortunately that flag is very new as well. So this does a test compile of a trivial file to see if the flag is supported. Change-Id: I1345571142b7c3a96212e43297d19e84ec4a3d41 Reviewed-on: https://go-review.googlesource.com/18359Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
There are reports of corruption. Let's disable it for now (for Go 1.6, especially) until we can investigate and fix properly. Update #13892 Change-Id: I557275e5142fe616e8a4f89c00ffafb830eb3b78 Reviewed-on: https://go-review.googlesource.com/18540Reviewed-by: Dave Cheney <dave@cheney.net>
-
Ian Lance Taylor authored
Change-Id: I5a4a842cab2173357e8d3e349011c0c2b63be4f9 Reviewed-on: https://go-review.googlesource.com/18512Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Change-Id: I5a0206e8074f3a2790954c45a217922b7b3fe851 Reviewed-on: https://go-review.googlesource.com/18487Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
Per suggestion from adonovan. Change-Id: Icbb4d2f201590bc94672b8d8141b6e7901e11dc5 Reviewed-on: https://go-review.googlesource.com/18510Reviewed-by: Robert Griesemer <gri@golang.org>
-