| Age | Commit message (Collapse) | Author |
|---|
|
operate by word as much as they can
Not only is this an obvious optimization:
benchmark old MB/s new MB/s speedup
BenchmarkMemmove1-4 35.35 29.65 0.84x
BenchmarkMemmove2-4 63.78 52.53 0.82x
BenchmarkMemmove3-4 89.72 73.96 0.82x
BenchmarkMemmove4-4 109.94 95.73 0.87x
BenchmarkMemmove5-4 127.60 112.80 0.88x
BenchmarkMemmove6-4 143.59 126.67 0.88x
BenchmarkMemmove7-4 157.90 138.92 0.88x
BenchmarkMemmove8-4 167.18 231.81 1.39x
BenchmarkMemmove9-4 175.23 252.07 1.44x
BenchmarkMemmove10-4 165.68 261.10 1.58x
BenchmarkMemmove11-4 174.43 263.31 1.51x
BenchmarkMemmove12-4 180.76 267.56 1.48x
BenchmarkMemmove13-4 189.06 284.93 1.51x
BenchmarkMemmove14-4 186.31 284.72 1.53x
BenchmarkMemmove15-4 195.75 281.62 1.44x
BenchmarkMemmove16-4 202.96 439.23 2.16x
BenchmarkMemmove32-4 264.77 775.77 2.93x
BenchmarkMemmove64-4 306.81 1209.64 3.94x
BenchmarkMemmove128-4 357.03 1515.41 4.24x
BenchmarkMemmove256-4 380.77 2066.01 5.43x
BenchmarkMemmove512-4 385.05 2556.45 6.64x
BenchmarkMemmove1024-4 381.23 2804.10 7.36x
BenchmarkMemmove2048-4 379.06 2814.83 7.43x
BenchmarkMemmove4096-4 387.43 3064.96 7.91x
BenchmarkMemmoveUnaligned1-4 28.91 25.40 0.88x
BenchmarkMemmoveUnaligned2-4 56.13 47.56 0.85x
BenchmarkMemmoveUnaligned3-4 74.32 69.31 0.93x
BenchmarkMemmoveUnaligned4-4 97.02 83.58 0.86x
BenchmarkMemmoveUnaligned5-4 110.17 103.62 0.94x
BenchmarkMemmoveUnaligned6-4 124.95 113.26 0.91x
BenchmarkMemmoveUnaligned7-4 142.37 130.82 0.92x
BenchmarkMemmoveUnaligned8-4 151.20 205.64 1.36x
BenchmarkMemmoveUnaligned9-4 166.97 215.42 1.29x
BenchmarkMemmoveUnaligned10-4 148.49 221.22 1.49x
BenchmarkMemmoveUnaligned11-4 159.47 239.57 1.50x
BenchmarkMemmoveUnaligned12-4 163.52 247.32 1.51x
BenchmarkMemmoveUnaligned13-4 167.55 256.54 1.53x
BenchmarkMemmoveUnaligned14-4 175.12 251.03 1.43x
BenchmarkMemmoveUnaligned15-4 192.10 267.13 1.39x
BenchmarkMemmoveUnaligned16-4 190.76 378.87 1.99x
BenchmarkMemmoveUnaligned32-4 259.02 562.98 2.17x
BenchmarkMemmoveUnaligned64-4 317.72 842.44 2.65x
BenchmarkMemmoveUnaligned128-4 355.43 1274.49 3.59x
BenchmarkMemmoveUnaligned256-4 378.17 1815.74 4.80x
BenchmarkMemmoveUnaligned512-4 362.15 2180.81 6.02x
BenchmarkMemmoveUnaligned1024-4 376.07 2453.58 6.52x
BenchmarkMemmoveUnaligned2048-4 381.66 2568.32 6.73x
BenchmarkMemmoveUnaligned4096-4 398.51 2669.36 6.70x
BenchmarkMemclr5-4 113.83 107.93 0.95x
BenchmarkMemclr16-4 223.84 389.63 1.74x
BenchmarkMemclr64-4 421.99 1209.58 2.87x
BenchmarkMemclr256-4 525.94 2411.58 4.59x
BenchmarkMemclr4096-4 581.66 4372.20 7.52x
BenchmarkMemclr65536-4 565.84 4747.48 8.39x
BenchmarkGoMemclr5-4 194.63 160.31 0.82x
BenchmarkGoMemclr16-4 295.30 630.07 2.13x
BenchmarkGoMemclr64-4 480.24 1884.03 3.92x
BenchmarkGoMemclr256-4 540.23 2926.49 5.42x
but it turns out that it's necessary to avoid the GC seeing partially written
pointers.
It's of course possible to be more sophisticated (using ldp/stp to move 16
bytes at a time in the core loop and unrolling the tail copying loops being
the obvious ideas) but I wanted something simple and (reasonably) obviously
correct.
Fixes #12552
Change-Id: Iaeaf8a812cd06f4747ba2f792de1ded738890735
Reviewed-on: https://go-review.googlesource.com/14813
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/16909
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Currently, amd64p32's memmove and memclr use 8 byte writes as much as
possible and 1 byte writes for the tail of the object. However, if an
object ends with a 4 byte pointer at an 8 byte aligned offset, this
may copy/zero the pointer field one byte at a time, allowing the
garbage collector to observe a partially copied pointer.
Fix this by using 4 byte writes instead of 8 byte writes.
Updates #12552.
Change-Id: I13324fd05756fb25ae57e812e836f0a975b5595c
Reviewed-on: https://go-review.googlesource.com/15370
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/16908
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
by word as much as it can
Issue #12552 can happen on ppc64 too, although much less frequently in my
testing. I'm fairly sure this fixes it (2 out of 200 runs of oracle.test failed
without this change and 0 of 200 failed with it). It's also a lot faster for
large moves/clears:
name old speed new speed delta
Memmove1-6 157MB/s ± 9% 144MB/s ± 0% -8.20% (p=0.004 n=10+9)
Memmove2-6 281MB/s ± 1% 249MB/s ± 1% -11.53% (p=0.000 n=10+10)
Memmove3-6 376MB/s ± 1% 328MB/s ± 1% -12.64% (p=0.000 n=10+10)
Memmove4-6 475MB/s ± 4% 345MB/s ± 1% -27.28% (p=0.000 n=10+8)
Memmove5-6 540MB/s ± 1% 393MB/s ± 0% -27.21% (p=0.000 n=10+10)
Memmove6-6 609MB/s ± 0% 423MB/s ± 0% -30.56% (p=0.000 n=9+10)
Memmove7-6 659MB/s ± 0% 468MB/s ± 0% -28.99% (p=0.000 n=8+10)
Memmove8-6 705MB/s ± 0% 1295MB/s ± 1% +83.73% (p=0.000 n=9+9)
Memmove9-6 740MB/s ± 1% 1241MB/s ± 1% +67.61% (p=0.000 n=10+8)
Memmove10-6 780MB/s ± 0% 1162MB/s ± 1% +48.95% (p=0.000 n=10+9)
Memmove11-6 811MB/s ± 0% 1180MB/s ± 0% +45.58% (p=0.000 n=8+9)
Memmove12-6 820MB/s ± 1% 1073MB/s ± 1% +30.83% (p=0.000 n=10+9)
Memmove13-6 849MB/s ± 0% 1068MB/s ± 1% +25.87% (p=0.000 n=10+10)
Memmove14-6 877MB/s ± 0% 911MB/s ± 0% +3.83% (p=0.000 n=10+10)
Memmove15-6 893MB/s ± 0% 922MB/s ± 0% +3.25% (p=0.000 n=10+9)
Memmove16-6 897MB/s ± 1% 2418MB/s ± 1% +169.67% (p=0.000 n=10+9)
Memmove32-6 908MB/s ± 0% 3927MB/s ± 2% +332.64% (p=0.000 n=10+8)
Memmove64-6 1.11GB/s ± 0% 5.59GB/s ± 0% +404.64% (p=0.000 n=9+9)
Memmove128-6 1.25GB/s ± 0% 6.71GB/s ± 2% +437.49% (p=0.000 n=9+10)
Memmove256-6 1.33GB/s ± 0% 7.25GB/s ± 1% +445.06% (p=0.000 n=10+10)
Memmove512-6 1.38GB/s ± 0% 8.87GB/s ± 0% +544.43% (p=0.000 n=10+10)
Memmove1024-6 1.40GB/s ± 0% 10.00GB/s ± 0% +613.80% (p=0.000 n=10+10)
Memmove2048-6 1.41GB/s ± 0% 10.65GB/s ± 0% +652.95% (p=0.000 n=9+10)
Memmove4096-6 1.42GB/s ± 0% 11.01GB/s ± 0% +675.37% (p=0.000 n=8+10)
Memclr5-6 269MB/s ± 1% 264MB/s ± 0% -1.80% (p=0.000 n=10+10)
Memclr16-6 600MB/s ± 0% 887MB/s ± 1% +47.83% (p=0.000 n=10+10)
Memclr64-6 1.06GB/s ± 0% 2.91GB/s ± 1% +174.58% (p=0.000 n=8+10)
Memclr256-6 1.32GB/s ± 0% 6.58GB/s ± 0% +399.86% (p=0.000 n=9+10)
Memclr4096-6 1.42GB/s ± 0% 10.90GB/s ± 0% +668.03% (p=0.000 n=8+10)
Memclr65536-6 1.43GB/s ± 0% 11.37GB/s ± 0% +697.83% (p=0.000 n=9+8)
GoMemclr5-6 359MB/s ± 0% 360MB/s ± 0% +0.46% (p=0.000 n=10+10)
GoMemclr16-6 750MB/s ± 0% 1264MB/s ± 1% +68.45% (p=0.000 n=10+10)
GoMemclr64-6 1.17GB/s ± 0% 3.78GB/s ± 1% +223.58% (p=0.000 n=10+9)
GoMemclr256-6 1.35GB/s ± 0% 7.47GB/s ± 0% +452.44% (p=0.000 n=10+10)
Update #12552
Change-Id: I7192e9deb9684a843aed37f58a16a4e29970e893
Reviewed-on: https://go-review.googlesource.com/14840
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/16907
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Commit c257dfb attempted to fix recursive allocation in gcAssistAlloc;
however, it only reduced it: setting gp.gcalloc to 0 isn't sufficient
to disable assists at the beginning of the GC cycle when gp.gcscanwork
is also small or zero.
Fix this recursion more completely by setting gcalloc to a sentinel
value that directly disables assists.
Fixes #12894 (again).
Change-Id: I9599566222d8f540d0b39806846bfc702e6666e5
Reviewed-on: https://go-review.googlesource.com/15891
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
If gcAssistAlloc is unable to steal or perform enough scan work, it
calls timeSleep, which allocates. If this allocation requires
obtaining a new span, it will in turn attempt to assist GC. Since
there's likely still no way to satisfy the assist, it will sleep
again, and so on, leading to potentially deep (not infinite, but also
not bounded) recursion.
Fix this by disallowing assists during the timeSleep.
This same problem was fixed on master by 65aa2da. That commit built on
several other changes and hence can't be directly cherry-picked. This
commit implements the same idea.
Fixes #12894.
Change-Id: I152977eb1d0a3005c42ff3985d58778f054a86d4
Reviewed-on: https://go-review.googlesource.com/15720
Reviewed-by: Rick Hudson <rlh@golang.org>
|
|
Change-Id: I8da1c7a86adf6672e5e5c44cbab422706833c1da
Reviewed-on: https://go-review.googlesource.com/15350
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/15244
|
|
Change-Id: Ib1bfe4038e2b125a31acd9ff7772e462b0a6358f
Reviewed-on: https://go-review.googlesource.com/14852
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14854
|
|
Change-Id: I98d9fefd923e2a35031385045382ba372f1d614a
Reviewed-on: https://go-review.googlesource.com/14401
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Change-Id: I56452559acc432e06c15844d3f25dbeacafe77b7
Reviewed-on: https://go-review.googlesource.com/14402
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14403
|
|
These instructions are special cases that were missed in the translation.
The second argument must go into the Reg field not the To field.
Fixes #12458
For Go 1.5.1
Change-Id: Iad57c60c7e38e3bcfafda483ed5037ce670e8816
Reviewed-on: https://go-review.googlesource.com/14183
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14358
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
spaces at %c
In short, %c should just give you the next rune, period.
Apparently this is the design. I use the term loosely.
Fixes #12275
Change-Id: I6f30bed442c0e88eac2244d465c7d151b29cf393
Reviewed-on: https://go-review.googlesource.com/13821
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14395
|
|
by go build
Fixes #12288.
For inclusion in the 1.5.1 release.
Change-Id: I9354b7eaa76000498465c4a5cbab7246de9ecb7c
Reviewed-on: https://go-review.googlesource.com/14382
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/14394
|
|
Some commits made by Aram from his personal email address are
actually copyright Oracle:
a77fcb3 net: fix comment in sendFile
b0e71f4 net: link with networking libraries when net package is in use
92e959a syscall, net: use sendfile on Solaris
db8d5b7 net: try to fix setKeepAlivePeriod on Solaris
fe5ef5c runtime, syscall: link Solaris binaries directly instead of using dlopen/dlsym
2b90c3e go/build: enable cgo by default on solaris/amd64
2d18ab7 doc/progs: disable cgo tests that use C.Stdout on Solaris
2230e9d misc/cgo: add various solaris build lines
649c7b6 net: add cgo support for Solaris
24396da os/user: small fixes for Solaris
121489c runtime/cgo: add cgo support for solaris/amd64
83b25d9 cmd/ld: make .rela and .rela.plt sections contiguous
c94f1f7 runtime: always load address of libcFunc on Solaris
e481aac cmd/6l: use .plt instead of .got on Solaris
See bug for clarification.
Fixes #12452
Change-Id: I0aeb1b46c0c7d09c5c736e383ecf40240d2cf85f
Reviewed-on: https://go-review.googlesource.com/14380
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/14393
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
in sync"
This reverts commit f265044a489c9e572ffc141ed2d0e95f05d451c9.
Change-Id: I454f9da3a40d6724ab106aae904b8e77756aae99
Reviewed-on: https://go-review.googlesource.com/14383
Run-TryBot: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Currently the stack barrier stub blindly unwinds the next stack
barrier from the G's stack barrier array without checking that it's
the right stack barrier. If through some bug the stack barrier array
position gets out of sync with where we actually are on the stack,
this could return to the wrong PC, which would lead to difficult to
debug crashes. To address this, this commit adds a check to the amd64
stack barrier stub that it's unwinding the correct stack barrier.
Updates #12238.
Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02
Reviewed-on: https://go-review.googlesource.com/13948
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14241
Reviewed-by: Austin Clements <austin@google.com>
|
|
ReverseProxy
Accepting a request with a nil body was never explicitly supported but
happened to work in the past.
This doesn't happen in most cases because usually people pass
a Server's incoming Request to the ReverseProxy's ServeHTTP method,
and incoming server requests are guaranteed to have non-nil bodies.
Still, it's a regression, so fix.
Fixes #12344
Change-Id: Id9a5a47aea3f2875d195b66c9a5f8581c4ca2aed
Reviewed-on: https://go-review.googlesource.com/13935
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/14245
|
|
This worked in Go 1.4 but was lost in the "pure Go" lookup
routines substituted late in the Go 1.5 cycle.
Fixes #12263.
Change-Id: I77ec9d97cd8e67ace99d6ac965e5bc16c151ba83
Reviewed-on: https://go-review.googlesource.com/13915
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-on: https://go-review.googlesource.com/14243
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
packages rooted at GOPATH
Fixes #12232.
Change-Id: Ide3fb7f5fc5ae377ae8683fbb94fd0dc01480549
Reviewed-on: https://go-review.googlesource.com/13924
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14228
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The issue 12226 has been caused by the allocation of the same register
for the equality check of two byte values. The code in cgen.go freed the
register for the second operand before the allocation of the register
for the first operand.
Fixes #12226
Change-Id: Ie4dc33a488bd48a17f8ae9b497fd63c1ae390555
Reviewed-on: https://go-review.googlesource.com/13771
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14227
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
cgocallback_gofunc's frame
Currently the runtime can install stack barriers in any frame.
However, the frame of cgocallback_gofunc is special: it's the one
function that switches from a regular G stack to the system stack on
return. Hence, the return PC slot in its frame on the G stack is
actually used to save getg().sched.pc (so tracebacks appear to unwind
to the last Go function running on that G), and not as an actual
return PC for cgocallback_gofunc.
Because of this, if we install a stack barrier in cgocallback_gofunc's
return PC slot, when cgocallback_gofunc does return, it will move the
stack barrier stub PC in to getg().sched.pc and switch back to the
system stack. The rest of the runtime doesn't know how to deal with a
stack barrier stub in sched.pc: nothing knows how to match it up with
the G's stack barrier array and, when the runtime removes stack
barriers, it doesn't know to undo the one in sched.pc. Hence, if the C
code later returns back in to Go code, it will attempt to return
through the stack barrier saved in sched.pc, which may no longer have
correct unwinding information.
Fix this by blacklisting cgocallback_gofunc's frame so the runtime
won't install a stack barrier in it's return PC slot.
Fixes #12238.
Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8
Reviewed-on: https://go-review.googlesource.com/13944
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14229
Reviewed-by: Austin Clements <austin@google.com>
|
|
Currently enabling the debugging mode where stack barriers are
installed at every frame requires recompiling the runtime. However,
this is potentially useful for field debugging and for runtime tests,
so make this mode a GODEBUG.
Updates #12238.
Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5
Reviewed-on: https://go-review.googlesource.com/13947
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14240
Reviewed-by: Austin Clements <austin@google.com>
|
|
interface value
A comparison of the form l == r where l is an interface and r is
concrete performs a type assertion on l to convert it to r's type.
However, the compiler fails to zero the temporary where the result of
the type assertion is written, so if the type is a pointer type and a
stack scan occurs while in the type assertion, it may see an invalid
pointer on the stack.
Fix this by zeroing the temporary. This is equivalent to the fix for
type switches from c4092ac.
Fixes #12253.
Change-Id: Iaf205d456b856c056b317b4e888ce892f0c555b9
Reviewed-on: https://go-review.googlesource.com/13872
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14242
Reviewed-by: Austin Clements <austin@google.com>
|
|
Change-Id: I1b9f6ad322a7f68fa160c4f09d7fb56815e505a7
Reviewed-on: https://go-review.googlesource.com/13828
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-on: https://go-review.googlesource.com/14244
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
|
|
For ARM machines, the assembler supports list of registers
operands such as [R1,R2].
A list missing a ']' results in the parser issuing many errors
and consuming all the tokens. At EOF (i.e. end of the line),
it still loops.
Normally, a counter is maintained to make sure the parser
stops after 10 errors. However, multiple errors occuring on the
same line are simply ignored. Only the first one is reported.
At most one error per line is accounted.
Missing ']' in a register list therefore results in an
infinite loop.
Fixed the parser by explicitly checking for ']' to interrupt
this loops
In the operand tests, also fixed a wrong entry which I think was
not set on purpose (but still led to a successful result).
Fixes #11764
Change-Id: Ie87773388ee0d21b3a2a4cb941d4d911d0230ba4
Reviewed-on: https://go-review.googlesource.com/13920
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-on: https://go-review.googlesource.com/14225
|
|
This changed in https://golang.org/cl/10761.
Update #12203.
Change-Id: Ia37ebb7ecba689ad3cb2559213d675f21cf03a95
Reviewed-on: https://go-review.googlesource.com/13799
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/14226
Reviewed-by: Minux Ma <minux@golang.org>
|
|
Some symbols, for example, masks requires 16-byte alignment, and
they are placed in the text section. Before this change, the text
section is only aligned to 4-byte, and it's making masks unaligned.
Fixes #12415.
Change-Id: I7767778d1b4f7d3e74c2719a02848350782a4160
Reviewed-on: https://go-review.googlesource.com/14166
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 821e124c24c2b2d753be22a04a3b20b7bf579627)
Reviewed-on: https://go-review.googlesource.com/14279
|
|
At the moment, bootstrap.bash assumes it is called from a git working
copy. Hence, it fails to complete when running in an unpacked official
source tarball where .git and .gitignore do not exist. This fix adds a
test for existence for .git and a -f switch for the removal of
.gitignore.
Fixes #12223
Change-Id: I7f305b83b38d5115504932bd38dadb7bdeb5d487
Reviewed-on: https://go-review.googlesource.com/13770
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14281
|
|
Fixes external linking of net/http tests (or anything that uses
sendfile).
Fixes #12390.
Change-Id: Iee08998cf66e7b0ce851db138a00ebae6dc2395e
Reviewed-on: https://go-review.googlesource.com/14072
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Reviewed-on: https://go-review.googlesource.com/14246
Run-TryBot: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
|
|
Bring in the text from the proposal (with minor edits):
https://github.com/golang/proposal/blob/master/design/11502-securitypolicy.md
Fixes #11502
Change-Id: I92a987be66a0df60c1fad6c6c79f89bd8e9c12a8
Reviewed-on: https://go-review.googlesource.com/13955
Reviewed-by: Jason Buberel <jbuberel@google.com>
Reviewed-on: https://go-review.googlesource.com/14224
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Change-Id: I571965bc38a8b1060642a942b898797327f0c19c
Reviewed-on: https://go-review.googlesource.com/14195
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-on: https://go-review.googlesource.com/14199
Reviewed-by: Chris Broadfoot <cbro@golang.org>
|
|
This updates the VERSION file.
The release proper has not happened yet.
Change-Id: I3e33b5f95aede0da8ca1aef0d9c381942873c9a8
Reviewed-on: https://go-review.googlesource.com/13702
Reviewed-by: Rob Pike <r@golang.org>
|
|
Using merge instead of cherry-picks to simplify initial release.
Minor releases like Go 1.5.1 will have to use cherry-picks.
Fixes #12093.
Change-Id: If00393c58ace0da6f359b387cea9b779b123b920
|
|
This makes sure the release page in the release will mention the release.
Fixes #12102.
Change-Id: I36befd7dba7ba9e70ae3335e21c8841179ac4eff
Reviewed-on: https://go-review.googlesource.com/13490
Reviewed-by: Rob Pike <r@golang.org>
|
|
This is especially important for LookupAddr, which used to be pure Go
(lightweight, one goroutine per call) and without this CL is now
unconditionally cgo (heavy, one thread per call).
Fixes #12190.
Change-Id: I43436a942bc1838b024225893e156f280a1e80cf
Reviewed-on: https://go-review.googlesource.com/13698
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Go 1.4 and before have always returned DNS names with a trailing dot
for reverse lookups, as they do for basically all other routines returning
DNS names. Go 1.4 and before always implemented LookupAddr using
pure Go (not C library calls).
Go 1.5 added the ability to make a C library call to implement LookupAddr.
Unfortunately the C library call returns a DNS name without a trailing dot
(an unrooted name), meaning that if turn off cgo during make.bash then
you still get the rooted name but with cgo on you get an unrooted name.
The unrooted name is inconsistent with the pure Go implementation
and with all previous Go releases, so change it to a rooted name.
Fixes #12189.
Change-Id: I3d6b72277c121fe085ea6af30e5fe8019fc490ad
Reviewed-on: https://go-review.googlesource.com/13697
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes #12191.
Change-Id: I5c7659ccb0566dad3613041d9e76be87ceacae61
Reviewed-on: https://go-review.googlesource.com/13700
Reviewed-by: Rob Pike <r@golang.org>
|
|
Thanks to Nathan Youngman for spotting them.
Change-Id: I1856527af66a5d1965265ec3dcd639d3f6d74bcc
Reviewed-on: https://go-review.googlesource.com/13711
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Saying "Power 64" was wrong for reasons I don't remember.
(Those reasons are why we stopped using GOARCH=power64.)
Change-Id: Ifaac78d5733bfc780df01b1a66da766af0b17726
Reviewed-on: https://go-review.googlesource.com/13675
Reviewed-by: Rob Pike <r@golang.org>
|
|
Make clear that this list is the list of supported systems
for binary distributions, and that other systems may be
able to build the distribution from source, in addition
to using gccgo.
Drop freebsd/arm from the list on this page.
We have never issued a binary distribution for freebsd/arm,
and we're not going to start in Go 1.5, since we don't even
have a working builder for it.
Drop freebsd/386 from the list on the page,
because we are unable to build binary distributions, per adg.
I think the wording here should probably be revised further,
but not now.
Change-Id: Ib43b6b64f5c438bfb9aa4d3daa43393f1e33b71f
Reviewed-on: https://go-review.googlesource.com/13690
Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
This was missed when we did the rename months ago
because cmd/vet did not live in the main tree.
Now vet's asmdecl checks will apply to ppc64 assembly too.
Change-Id: I687cba89fef702f29dd118de76a7ca1041c414f6
Reviewed-on: https://go-review.googlesource.com/13677
Reviewed-by: Andrew Gerrand <adg@golang.org>
|
|
Change-Id: Iaeba7c55bbb9e11ac30f3b61369aa597acc30190
Reviewed-on: https://go-review.googlesource.com/13691
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Update #11184 (linux/ppc64).
Filed #12178 (solaris) for Go 1.6.
Change-Id: I9e3a456aaccb49590ad4e14b53ddfefca5b0801c
Reviewed-on: https://go-review.googlesource.com/13679
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Tested by hand.
Only lines of code changing are protected by Fieldtrack_enabled > 0,
which is never true in standard Go distributions.
Fixes #12171.
Change-Id: I963b9997dac10829db8ad4bfc97a7d6bf14b55c6
Reviewed-on: https://go-review.googlesource.com/13676
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #12156.
Change-Id: I2d71163b98bcc770147eb9e78dc551a9d0b5b817
Reviewed-on: https://go-review.googlesource.com/13674
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The text segment starts farther into the binary when using
external linking on the mac. Test and fix.
Fixes #12173.
Change-Id: I1f0c81814bf70cd9decfceac3022784f4608eeef
Reviewed-on: https://go-review.googlesource.com/13672
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #12154.
Change-Id: I1e6d1a3479a8a6fc8f53aebd18fb142506110809
Reviewed-on: https://go-review.googlesource.com/13673
Reviewed-by: Rob Pike <r@golang.org>
|
|
Found in a Google program running under the race detector.
No test, but verified that this fixes the race with go run -race of:
package main
import (
"crypto/tls"
"fmt"
"net"
"net/http"
"net/http/httptest"
)
func main() {
for {
ts := httptest.NewTLSServer(http.HandlerFunc(func(rw http.ResponseWriter, r *http.Request) {}))
conf := &tls.Config{} // non-nil
a, b := net.Pipe()
go func() {
sconn := tls.Server(a, conf)
sconn.Handshake()
}()
tr := &http.Transport{
TLSClientConfig: conf,
}
req, _ := http.NewRequest("GET", ts.URL, nil)
_, err := tr.RoundTrip(req)
println(fmt.Sprint(err))
a.Close()
b.Close()
ts.Close()
}
}
Also modified cmd/vet to report the copy-of-mutex bug statically
in CL 13646, and fixed two other instances in the code found by vet.
But vet could not have told us about cloneTLSConfig vs cloneTLSClientConfig.
Confirmed that original report is also fixed by this.
Fixes #12099.
Change-Id: Iba0171549e01852a5ec3438c25a1951c98524dec
Reviewed-on: https://go-review.googlesource.com/13453
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
|
|
The SetOutput function has been there since Go 1.
Fixes #12162.
Change-Id: I66210374877581e42689f9943532141659a55ca7
Reviewed-on: https://go-review.googlesource.com/13637
Reviewed-by: Rob Pike <r@golang.org>
|
|
Correct 'an' to 'on' in the comment above the Stable() function.
Change-Id: I714e38b2d3a79dfd539d5368967d1c6b519cb948
Reviewed-on: https://go-review.googlesource.com/13662
Reviewed-by: Rob Pike <r@golang.org>
|
|
Fixes golang/go#12133
CL 13630 fixed the use of a stale reg[] array in the various arch
backends which was causing the check in clearfat to pass
unconditionally on arm64.
With this check fixed, arm64 now considers REGRT1 to always be in use
as it is part of the reserved register set, see arm64/gsubr.go.
However, ppc64 does not consider REGRT1 and REGRT2 to be part of its
reserved set, so its identical clearfat check passes.
This CL removes the Reginuse check inside clearfat as REGRT1 is
guarenteed always be free on arm64.
Change-Id: I4719150d3c3378fae155b863c474529df18d4c17
Reviewed-on: https://go-review.googlesource.com/13650
Reviewed-by: Russ Cox <rsc@golang.org>
|
