- 20 Apr, 2016 17 commits
-
-
Robert Griesemer authored
Follow-up to https://golang.org/cl/21755. This turned out to be a bit more than just a few nits as originally expected in that CL. 1) The actual mantissa may be shorter than required for the given precision (because of trailing 0's): no need to allocate space for it (and transmit 0's). This can save a lot of space when the precision is high: E.g., for prec == 1000, 16 words or 128 bytes are required at the most, but if the actual number is short, it may be much less (for the test cases present, it's significantly less). 2) The actual mantissa may be longer than the number of words required for the given precision: make sure to not overflow when encoding in bytes. 3) Add more documentation. 4) Add more tests. Change-Id: I9f40c408cfdd9183a8e81076d2f7d6c75e7a00e9 Reviewed-on: https://go-review.googlesource.com/22324Reviewed-by: Alan Donovan <adonovan@google.com>
-
Keith Randall authored
mapaccess{1,2} returns a pointer to the value. When the key is not in the map, it returns a pointer to zeroed memory. Currently, for large map values we have a complicated scheme which dynamically allocates zeroed memory for this purpose. It is ugly code and requires an atomic.Load in a bunch of places we'd rather not have it. Switch to a scheme where callsites of mapaccess{1,2} which expect large return values pass in a pointer to zeroed memory that mapaccess can return if the key is not found. This avoids the atomic.Load on all map accesses with a few extra instructions only for the large value acccesses, plus a bit of bss space. There was a time (1.4 & 1.5?) where we did something like this but all the tricks to make the right size zero value were done by the linker. That scheme broke in the presence of dyamic linking. The scheme in this CL works even when dynamic linking. Fixes #12337 Change-Id: Ic2d0319944af33bbb59785938d9ab80958d1b4b1 Reviewed-on: https://go-review.googlesource.com/22221 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Rob Pike authored
A late response to CL 22163. Change-Id: I5275a22af7081875af0256da296811f4fe9832dc Reviewed-on: https://go-review.googlesource.com/22296Reviewed-by: David Symonds <dsymonds@golang.org>
-
David Crawshaw authored
(Split out from CL 22243.) Change-Id: I07709a0c417e7a57e839e5085a37db7d5fbf3a35 Reviewed-on: https://go-review.googlesource.com/22322 Run-TryBot: David Crawshaw <crawshaw@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David Crawshaw authored
(Split out from CL 22243.) Change-Id: Idac1748c8db2b2ed0484e4afadb105c471c6ce34 Reviewed-on: https://go-review.googlesource.com/22321Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
(Split out from CL 22205.) Change-Id: Id32698f48ce02b55c15b6f2842215e0ffdbf425b Reviewed-on: https://go-review.googlesource.com/22298Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
OneOfOne authored
Added GobEncode/Decode and a test for them. Fixes #14593 Change-Id: Ic8d3efd24d0313a1a66f01da293c4c1fd39764a8 Reviewed-on: https://go-review.googlesource.com/21755Reviewed-by: Robert Griesemer <gri@golang.org>
-
David Crawshaw authored
(Split out from CL 22205.) Change-Id: Iab66ac2a1cd3716966d8e59c570931bce95aba9b Reviewed-on: https://go-review.googlesource.com/22297Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Munday authored
Adds support for single block encryption using the cipher message (KM) instruction. KM handles key expansion internally and therefore it is not done up front when using the assembly implementation on s390x. Change-Id: I69954b8ae36d549e1dc40d7acd5a10bedfaaef9c Reviewed-on: https://go-review.googlesource.com/22194 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bill O'Farrell <billotosyr@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Keith Randall authored
Improve forward-looking desired register calculations. It is now inter-block and handles a bunch more cases. Fixes #14504 Fixes #14828 Fixes #15254 Change-Id: Ic240fa0ec6a779d80f577f55c8a6c4ac8c1a940a Reviewed-on: https://go-review.googlesource.com/22160 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Jamil Djadala authored
In BenchmarkDup fuction, heap is created as h := make(myHeap, n) and then n elements are added, so first time there are 2*n elements in heap. Fixes #15380 Change-Id: I0508486a847006b3cd545fd695e8b09af339134f Reviewed-on: https://go-review.googlesource.com/22310Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
mallocgc can calculate noscan itself. The only remaining flag argument is needzero, so we just make that a boolean arg. Fixes #15379 Change-Id: I839a70790b2a0c9dbcee2600052bfbd6c8148e20 Reviewed-on: https://go-review.googlesource.com/22290Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
Just moving code. No code changes. Updates #15345 Change-Id: I89c257b7aae4fbd78ce59a42909ecb3ff493659d Reviewed-on: https://go-review.googlesource.com/22300Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alex Brainman authored
PE specification requires that long section and symbol names are stored in PE string table. Introduce StringTable that implements this functionality. Only string table reading is implemented. Updates #15345 Change-Id: Ib9638617f2ab1881ad707111d96fc68b0e47340e Reviewed-on: https://go-review.googlesource.com/22181 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Alex Brainman authored
No code changes. Just moved ImportDirectory next to ImportedSymbols. And moved useless FormatError to the bottom of file.go. Updates #15345 Change-Id: I91ff243cefd18008b1c5ee9ec4326583deee431b Reviewed-on: https://go-review.googlesource.com/22182Reviewed-by: David Crawshaw <crawshaw@golang.org> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
No point in passing the slice type to these functions. All they need is the element type. One less indirection, maybe a few less []T type descriptors in the binary. Change-Id: Ib0b83b5f14ca21d995ecc199ce8ac00c4eb375e6 Reviewed-on: https://go-review.googlesource.com/22275Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Josh Bleecher Snyder authored
The extra checks provided by newarray are redundant in these cases. This shrinks by one frame the call stack expected by the pprof test. name old time/op new time/op delta MakeSlice-8 34.3ns ± 2% 30.5ns ± 3% -11.03% (p=0.000 n=24+22) GrowSlicePtr-8 134ns ± 2% 129ns ± 3% -3.25% (p=0.000 n=25+24) Change-Id: Icd828655906b921c732701fd9d61da3fa217b0af Reviewed-on: https://go-review.googlesource.com/22276 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
- 19 Apr, 2016 20 commits
-
-
Andrew Gerrand authored
Change-Id: Ib3063719cf90dfad139dd723b3b16ef0b45e312e Reviewed-on: https://go-review.googlesource.com/22251Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Matthew Dempsky authored
There's no need for Eiota, Eindir, Eaddr, or Eproc; the values are threaded through to denote various typechecking contexts, but they don't actually influence typechecking behavior at all. Also, while here, switch the Efoo const declarations to use iota. Passes toolstash -cmp. Change-Id: I5cea869ccd0755c481cf071978f863474bc9c1ed Reviewed-on: https://go-review.googlesource.com/22271 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Julia Hansbrough authored
On GNU/Linux, SIGSYS is specified to cause the process to terminate without a core dump. In https://codereview.appspot.com/3749041 , it appears that Golang accidentally introduced incorrect behavior for this signal, which caused Golang processes to keep running after receiving SIGSYS. This change reverts it to the old/correct behavior. Updates #15204 Change-Id: I3aa48a9499c1bc36fa5d3f40c088fdd7599e0db5 Reviewed-on: https://go-review.googlesource.com/22202Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
Fixes #15364. Change-Id: Id2a349896064c7c9e00e36c55162068bf18162b2 Reviewed-on: https://go-review.googlesource.com/22272Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #15371 Change-Id: Iff8d36e1bd9b5641f6b577a30ac6e967f973c939 Reviewed-on: https://go-review.googlesource.com/22240Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Keith Randall authored
We now inline type to interface conversions when the type is pointer-shaped. No need to keep code to handle that in convT2{I,E}. Change-Id: I3a6668259556077cbb2986a9e8fe42a625d506c9 Reviewed-on: https://go-review.googlesource.com/22249 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michel Lespinasse <walken@google.com>
-
Alexandru Moșoi authored
func f(a, b bool) bool { return a || b } is now a single instructions (excluding loading and unloading the arguments): v10 = ORB <bool> v11 v12 : AX Change-Id: Iff63399410cb46909f4318ea1c3f45a029f4aa5e Reviewed-on: https://go-review.googlesource.com/21872 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Robert Griesemer authored
Fixes #15376. Change-Id: I9ece80f26b83be129671c961120c157da2ac0079 Reviewed-on: https://go-review.googlesource.com/22270Reviewed-by: Alan Donovan <adonovan@google.com>
-
Josh Bleecher Snyder authored
This avoids expensive division calculations for many common slice element sizes. name old time/op new time/op delta MakeSlice-8 51.9ns ± 3% 35.1ns ± 2% -32.41% (p=0.000 n=10+10) GrowSliceBytes-8 44.1ns ± 2% 44.1ns ± 1% ~ (p=0.984 n=10+10) GrowSliceInts-8 60.9ns ± 3% 60.9ns ± 3% ~ (p=0.698 n=10+10) GrowSlicePtr-8 131ns ± 1% 120ns ± 2% -8.41% (p=0.000 n=8+10) GrowSliceStruct24Bytes-8 111ns ± 2% 103ns ± 3% -7.23% (p=0.000 n=8+8) Change-Id: I2630eb3d73c814db030cad16e620ea7fecbbd312 Reviewed-on: https://go-review.googlesource.com/22223Reviewed-by: Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
This extends CL 22192. This removes the remaining performance disparity between non-SSA and SSA on the AppendInPlace benchmarks. Going from non-SSA to SSA: AppendInPlace/NoGrow/2Ptr-8 1.60µs ± 5% 1.53µs ± 5% -4.04% (p=0.000 n=15+14) AppendInPlace/NoGrow/3Ptr-8 2.04µs ± 3% 1.96µs ± 2% -3.90% (p=0.000 n=13+14) AppendInPlace/NoGrow/4Ptr-8 2.83µs ± 8% 2.62µs ± 4% -7.39% (p=0.000 n=13+15) Previously these were 20% regressions. Change-Id: Ie87810bffd598730658e07585f5e2ef979a12b8f Reviewed-on: https://go-review.googlesource.com/22248Reviewed-by: Keith Randall <khr@golang.org>
-
Josh Bleecher Snyder authored
Previously, isStaticCompositeLiteral would return the wrong value for literals like: [1]struct{ b []byte }{b: []byte{1}} Note that the outermost component is an array, but once we recurse into isStaticCompositeLiteral, we never check again that arrays are actually arrays. Instead of adding more logic to the guts of isStaticCompositeLiteral, allow it to accept any Node and return the correct answer. Change-Id: I6af7814a9037bbc7043da9a96137fbee067bbe0e Reviewed-on: https://go-review.googlesource.com/22247Reviewed-by: Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Per the latest spec refinement (https://golang.org/cl/19981). Fixes #14537. Change-Id: I2dedee942c4da21dc94bdeda466f133827ab5bb9 Reviewed-on: https://go-review.googlesource.com/22241 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
There is currently only one assembly implementation of AES (amd64). While it is possible to fit other implementations to the same pattern it complicates the code. For example s390x does not use expanded keys, so having enc and dec in the aesCipher struct is confusing. By separating out the asm implementations we can more closely match the data structures to the underlying implementation. This also opens the door for AES implementations that support block cipher modes other than GCM (e.g. CTR and CBC). This commit changes BenchmarkExpandKey to test the go implementation of key expansion. It might be better to have some sort of 'initialisation' benchmark instead to cover the startup costs of the assembly implementations (which might be doing key expansion in a different way, or not at all). Change-Id: I094a7176b5bbe2177df73163a9c0b711a61c12d6 Reviewed-on: https://go-review.googlesource.com/22193 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
CL 21891 was too clever in its attempts to avoid spills. Storing newlen too early caused uses of append in the runtime itself to receive an inconsistent view of a slice, leading to corruption. This CL makes the generate code much more similar to the old backend. It spills more than before, but those spills have been contained to the grow path. It recalculates newlen unnecessarily on the fast path, but that's measurably cheaper than spilling it. CL 21891 caused runtime failures in 6 of 2000 runs of net/http and crypto/x509 in my test setup. This CL has gone 6000 runs without a failure. Benchmarks going from master to this CL: name old time/op new time/op delta AppendInPlace/NoGrow/Byte-8 439ns ± 2% 436ns ± 2% -0.72% (p=0.001 n=28+27) AppendInPlace/NoGrow/1Ptr-8 901ns ± 0% 856ns ± 0% -4.95% (p=0.000 n=26+29) AppendInPlace/NoGrow/2Ptr-8 2.15µs ± 1% 1.95µs ± 0% -9.07% (p=0.000 n=28+30) AppendInPlace/NoGrow/3Ptr-8 2.66µs ± 0% 2.45µs ± 0% -7.93% (p=0.000 n=29+26) AppendInPlace/NoGrow/4Ptr-8 3.24µs ± 1% 3.02µs ± 1% -6.75% (p=0.000 n=28+30) AppendInPlace/Grow/Byte-8 269ns ± 1% 271ns ± 1% +0.84% (p=0.000 n=30+29) AppendInPlace/Grow/1Ptr-8 275ns ± 1% 280ns ± 1% +1.75% (p=0.000 n=30+30) AppendInPlace/Grow/2Ptr-8 384ns ± 0% 391ns ± 0% +1.94% (p=0.000 n=27+30) AppendInPlace/Grow/3Ptr-8 455ns ± 0% 462ns ± 0% +1.43% (p=0.000 n=29+29) AppendInPlace/Grow/4Ptr-8 478ns ± 0% 479ns ± 0% +0.23% (p=0.000 n=30+27) However, for the large no-grow cases, there is still more work to be done. Going from this CL to the non-SSA backend: name old time/op new time/op delta AppendInPlace/NoGrow/Byte-8 436ns ± 2% 436ns ± 2% ~ (p=0.967 n=27+29) AppendInPlace/NoGrow/1Ptr-8 856ns ± 0% 884ns ± 0% +3.28% (p=0.000 n=29+26) AppendInPlace/NoGrow/2Ptr-8 1.95µs ± 0% 1.56µs ± 0% -20.28% (p=0.000 n=30+29) AppendInPlace/NoGrow/3Ptr-8 2.45µs ± 0% 1.89µs ± 0% -22.88% (p=0.000 n=26+28) AppendInPlace/NoGrow/4Ptr-8 3.02µs ± 1% 2.56µs ± 1% -15.35% (p=0.000 n=30+28) AppendInPlace/Grow/Byte-8 271ns ± 1% 283ns ± 1% +4.56% (p=0.000 n=29+29) AppendInPlace/Grow/1Ptr-8 280ns ± 1% 288ns ± 1% +2.99% (p=0.000 n=30+30) AppendInPlace/Grow/2Ptr-8 391ns ± 0% 409ns ± 0% +4.66% (p=0.000 n=30+29) AppendInPlace/Grow/3Ptr-8 462ns ± 0% 481ns ± 0% +4.13% (p=0.000 n=29+30) AppendInPlace/Grow/4Ptr-8 479ns ± 0% 502ns ± 0% +4.81% (p=0.000 n=27+26) New generated code: var x []byte func a() { x = append(x, 1) } "".a t=1 size=208 args=0x0 locals=0x48 0x0000 00000 (a.go:5) TEXT "".a(SB), $72-0 0x0000 00000 (a.go:5) MOVQ (TLS), CX 0x0009 00009 (a.go:5) CMPQ SP, 16(CX) 0x000d 00013 (a.go:5) JLS 190 0x0013 00019 (a.go:5) SUBQ $72, SP 0x0017 00023 (a.go:5) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0017 00023 (a.go:5) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0017 00023 (a.go:6) MOVQ "".x+16(SB), CX 0x001e 00030 (a.go:6) MOVQ "".x+8(SB), DX 0x0025 00037 (a.go:6) MOVQ "".x(SB), BX 0x002c 00044 (a.go:6) LEAQ 1(DX), BP 0x0030 00048 (a.go:6) CMPQ BP, CX 0x0033 00051 (a.go:6) JGT $0, 73 0x0035 00053 (a.go:6) LEAQ 1(DX), AX 0x0039 00057 (a.go:6) MOVQ AX, "".x+8(SB) 0x0040 00064 (a.go:6) MOVB $1, (BX)(DX*1) 0x0044 00068 (a.go:7) ADDQ $72, SP 0x0048 00072 (a.go:7) RET 0x0049 00073 (a.go:6) LEAQ type.[]uint8(SB), AX 0x0050 00080 (a.go:6) MOVQ AX, (SP) 0x0054 00084 (a.go:6) MOVQ BX, 8(SP) 0x0059 00089 (a.go:6) MOVQ DX, 16(SP) 0x005e 00094 (a.go:6) MOVQ CX, 24(SP) 0x0063 00099 (a.go:6) MOVQ BP, 32(SP) 0x0068 00104 (a.go:6) PCDATA $0, $0 0x0068 00104 (a.go:6) CALL runtime.growslice(SB) 0x006d 00109 (a.go:6) MOVQ 40(SP), CX 0x0072 00114 (a.go:6) MOVQ 48(SP), DX 0x0077 00119 (a.go:6) MOVQ DX, "".autotmp_0+64(SP) 0x007c 00124 (a.go:6) MOVQ 56(SP), BX 0x0081 00129 (a.go:6) MOVQ BX, "".x+16(SB) 0x0088 00136 (a.go:6) MOVL runtime.writeBarrier(SB), AX 0x008e 00142 (a.go:6) TESTB AL, AL 0x0090 00144 (a.go:6) JNE $0, 162 0x0092 00146 (a.go:6) MOVQ CX, "".x(SB) 0x0099 00153 (a.go:6) MOVQ "".x(SB), BX 0x00a0 00160 (a.go:6) JMP 53 0x00a2 00162 (a.go:6) LEAQ "".x(SB), BX 0x00a9 00169 (a.go:6) MOVQ BX, (SP) 0x00ad 00173 (a.go:6) MOVQ CX, 8(SP) 0x00b2 00178 (a.go:6) PCDATA $0, $0 0x00b2 00178 (a.go:6) CALL runtime.writebarrierptr(SB) 0x00b7 00183 (a.go:6) MOVQ "".autotmp_0+64(SP), DX 0x00bc 00188 (a.go:6) JMP 153 0x00be 00190 (a.go:6) NOP 0x00be 00190 (a.go:5) CALL runtime.morestack_noctxt(SB) 0x00c3 00195 (a.go:5) JMP 0 Fixes #14969 again Change-Id: Ia50463b1f506011aad0718a4fef1d4738e43c32d Reviewed-on: https://go-review.googlesource.com/22197 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Per a suggestion from mdempsky. Both gc and gccgo consider a statement list as terminating if the last _non_empty_ statement is terminating; i.e., trailing semis are ok. Only gotype followed the current stricter rule in the spec. This change adjusts the spec to match gc and gccgo behavior. In support of this change, the spec has a matching rule for fallthrough, which in valid positions may be followed by trailing semis as well. For details and examples, see the issue below. Fixes #14422. Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade Reviewed-on: https://go-review.googlesource.com/19981Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Munday authored
The encryptBlock and decryptBlock functions are already tested (via the public API) by TestCipherEncrypt and TestCipherDecrypt respectively. Both sets of tests check the output of the two functions against the same set of FIPS 197 examples. I therefore think it is safe to delete these two tests without losing any coverage. Deleting these two tests will make it easier to modify the internal API, which I am hoping to do in future CLs. Change-Id: I0dd568bc19f47b70ab09699b507833e527d39ba7 Reviewed-on: https://go-review.googlesource.com/22115Reviewed-by: Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Mikio Hara authored
This change adds Zone field to IPNet structure for making it possible to determine which network interface is associated with IPv6 link-local address. Also makes ParseCIDR and IPNet.String capable handling literal IPv6 address prefixes with zone identifier. Fixes #14518. Change-Id: I8f8a40d3b4f500ffef25728d4995651379d8408a Reviewed-on: https://go-review.googlesource.com/19946Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Alex Brainman authored
Go 1.6 requires Windows XP or later. I have: C:\>systeminfo | findstr /B /C:"OS Name" /C:"OS Version" OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 3 Build 2600 Running "go test" PASSes on my system after this CL is applied. Change-Id: Id59d169138c4a4183322c89ee7e766fb74d381fa Reviewed-on: https://go-review.googlesource.com/22209Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
DualStack mode requires dialTCP to support cancellation, which has been implemented for Plan 9 in CL 22144. Updates #11225. Updates #11932. Change-Id: I6e468363dc147326b097b604c122d5af80362787 Reviewed-on: https://go-review.googlesource.com/22204Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
David du Colombier authored
TestDialParallel, TestDialerFallbackDelay and TestDialCancel require dialTCP to support cancellation, which has been implemented for Plan 9 in CL 22144. Updates #11225. Updates #11932. Change-Id: I3b30a645ef79227dfa519cde8d46c67b72f2485c Reviewed-on: https://go-review.googlesource.com/22203 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 18 Apr, 2016 3 commits
-
-
Robert Griesemer authored
Per feedback from mdempsky from https://go-review.googlesource.com/22096. Also fix emitted position info. Change-Id: I7ff1967430867d922be8784832042c75d81df28b Reviewed-on: https://go-review.googlesource.com/22198 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
On Plan 9, when closing a TCP connection, we write the "hangup" string to the TCP ctl file. The next read on the TCP data file will return an error like "/net/tcp/18/data: Hangup", while in Go, we expect to return io.EOF. This change makes Read to return io.EOF when an error string containing "Hangup" is returned. Change-Id: I3f71ed543704190b441cac4787488a77f46d88a1 Reviewed-on: https://go-review.googlesource.com/22149Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David du Colombier <0intro@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
Use (part of) a SHA-1 checksum to replace type symbol names. In typical programs this has no effect because types are not included in the symbol table. But when dynamically linking, types are in the table to make sure there is only one *rtype per Go type. Eventually we may be able to get rid of all pointers to rtype values in the binary, but probably not by 1.7. And this has a nice effect on binary size today: libstd.so: before 27.4MB after 26.2MB For #6853. Change-Id: I603d7f3e5baad84f59f2fd37eeb1e4ae5acfe44a Reviewed-on: https://go-review.googlesource.com/21583Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-