Factor out duplicated race thunks from sync, syscall net
and fmt packages into a separate package and use it.

Fixes #8593

Change-Id: I156869c50946277809f6b509463752e7f7d28cdb
Reviewed-on: https://go-review.googlesource.com/14870Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Transactional memory, will later be used for semaphore implementation.
Nacl not supported yet.

Change-Id: Ic18453dcaa08d07bb217c0b95461584f007d518b
Reviewed-on: https://go-review.googlesource.com/16479Reviewed-by: Russ Cox <rsc@golang.org>

The kernel rejects attempts to create user namespaces when in a chroot.

Change-Id: I6548302732c8f5be52f4167cd7233aea16839ad8
Reviewed-on: https://go-review.googlesource.com/17214Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Updates #13402.

Change-Id: Ia7b729d81fb78206d214444911f2e6573b88717a
Reviewed-on: https://go-review.googlesource.com/17240Reviewed-by: Ian Lance Taylor <iant@golang.org>

This also fixes an unintended behavior where C's "complex float" and
"complex double" types were interchangeable with Go's "complex64" and
"complex128" types.

Fixes #13402.

Change-Id: I73f96d9a4772088d495073783c6982e9634430e8
Reviewed-on: https://go-review.googlesource.com/17208Reviewed-by: Ian Lance Taylor <iant@golang.org>

Without the fix:

    $ CC=clang-3.5 ./test.bash
    misc/cgo/errors/test.bash: BUG: expected error output to contain "C.ushort" but saw:
    # command-line-arguments
    ./issue13129.go:13: cannot use int(0) (type int) as type C.unsignedshort in assignment

Fixes #13129.

Change-Id: I2c019d2d000f5bfa3e33c477e533aff97031a84f
Reviewed-on: https://go-review.googlesource.com/17207
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13365.

Change-Id: I5a447ff806dbbb11c8c75e2b5cfa7fd4a845fb92
Reviewed-on: https://go-review.googlesource.com/17206
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The one-pass transformation is structured as a search over the input
machine for conditions that violate the one-pass requisites. At each
iteration, we should fully explore all non-input paths that proceed from
the current instruction; this is implemented via recursive check calls.
But when we reach instructions that demand input (InstRune*), these
should be put onto the search queue.

Instead of searching this way, the routine previously (effectively)
proceeded through the machine one instruction at a time until finding an
Inst{Match,Fail,Rune*}, calling check on each instruction. This caused
bug #11905, where the transformation stopped before rewriting all
InstAlts as InstAltMatches.

Further, the check function unnecessarily recurred on InstRune*
instructions. (I believe this helps to mask the above bug.)

This change also deletes some unused functions and duplicate test cases.

Fixes #11905.

Change-Id: I5b0b26efea3d3bd01c7479a518b5ed1b886701cd
Reviewed-on: https://go-review.googlesource.com/17195Reviewed-by: Russ Cox <rsc@golang.org>

The prefix computation for onepass was incorrectly returning
complete=true when it encountered a beginning-of-text empty width match
(^) in the middle of an expression.

Fix by returning complete only when the prefix is followed by $ and then
an accepting state.

Fixes #11175.

Change-Id: Ie9c4cf5f76c1d2c904a6fb2f016cedb265c19fde
Reviewed-on: https://go-review.googlesource.com/16200
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

This helps users who wish to use separate Regexps in each goroutine to
avoid lock contention. Previously they had to parse the expression
multiple times to achieve this.

I used variants of the included benchmark to evaluate this change. I
used the arguments -benchtime 20s -cpu 1,2,4,8,16 on a machine with 16
hardware cores.

Comparing a single shared Regexp vs. copied Regexps, we can see that
lock contention causes huge slowdowns at higher levels of parallelism.
The copied version shows the expected linear speedup.

name              old time/op  new time/op  delta
MatchParallel      366ns ± 0%   370ns ± 0%   +1.09%   (p=0.000 n=10+8)
MatchParallel-2    324ns ±28%   184ns ± 1%  -43.37%  (p=0.000 n=10+10)
MatchParallel-4    352ns ± 5%    93ns ± 1%  -73.70%   (p=0.000 n=9+10)
MatchParallel-8    480ns ± 3%    46ns ± 0%  -90.33%    (p=0.000 n=9+8)
MatchParallel-16   510ns ± 8%    24ns ± 6%  -95.36%   (p=0.000 n=10+8)

I also compared a modified version of Regexp that has no mutex and a
single machine (the "RegexpForSingleGoroutine" rsc mentioned in
https://github.com/golang/go/issues/8232#issuecomment-66096128).

In this next test, I compared using N copied Regexps vs. N separate
RegexpForSingleGoroutines. This shows that, even for this relatively
simple regex, avoiding the lock entirely would only buy about 10-12%
further improvement.

name              old time/op  new time/op  delta
MatchParallel      370ns ± 0%   322ns ± 0%  -12.97%    (p=0.000 n=8+8)
MatchParallel-2    184ns ± 1%   162ns ± 1%  -11.60%  (p=0.000 n=10+10)
MatchParallel-4   92.7ns ± 1%  81.1ns ± 2%  -12.43%  (p=0.000 n=10+10)
MatchParallel-8   46.4ns ± 0%  41.8ns ±10%   -9.78%   (p=0.000 n=8+10)
MatchParallel-16  23.7ns ± 6%  20.6ns ± 1%  -13.14%    (p=0.000 n=8+8)

Updates #8232.

Change-Id: I15201a080c363d1b44104eafed46d8df5e311902
Reviewed-on: https://go-review.googlesource.com/16110Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #12980.

Change-Id: I936db2f57f7c4dc80bb8ec32715c4c6b7bf0d708
Reviewed-on: https://go-review.googlesource.com/16112Reviewed-by: Russ Cox <rsc@golang.org>

From the XML spec: "XML processors should match character encoding
names in a case-insensitive way"

Fixes #12417.

Change-Id: I678c50152a49c14364be62b3f21ab9b9b009b24b
Reviewed-on: https://go-review.googlesource.com/14084Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #11112.

Change-Id: I16e7363549a0dec8c61addfa14af0866c1fd7c40
Reviewed-on: https://go-review.googlesource.com/14173Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #12963

Change-Id: Icc50dfb6130fe1e189d45f923c2f7408d3cf9401
Reviewed-on: https://go-review.googlesource.com/16047Reviewed-by: Russ Cox <rsc@golang.org>

Benchmark results:

benchmark                              old ns/op     new ns/op     delta
BenchmarkEndToEndPipe-4                7547          7294          -3.35%
BenchmarkEndToEndByteBuffer-4          5146          5092          -1.05%
BenchmarkEndToEndSliceByteBuffer-4     552779        439768        -20.44%
BenchmarkEncodeComplex128Slice-4       266370        266184        -0.07%
BenchmarkEncodeFloat64Slice-4          111891        110258        -1.46%
BenchmarkEncodeInt32Slice-4            74482         74080         -0.54%
BenchmarkEncodeStringSlice-4           84404         84279         -0.15%
BenchmarkEncodeInterfaceSlice-4        3942925       3045995       -22.75%
BenchmarkDecodeComplex128Slice-4       451837        415282        -8.09%
BenchmarkDecodeFloat64Slice-4          283584        262558        -7.41%
BenchmarkDecodeInt32Slice-4            246571        237383        -3.73%
BenchmarkDecodeStringSlice-4           734210        479625        -34.67%
BenchmarkDecodeInterfaceSlice-4        4778225       4160935       -12.92%

benchmark                              old allocs     new allocs     delta
BenchmarkEndToEndPipe-4                3              2              -33.33%
BenchmarkEndToEndByteBuffer-4          3              2              -33.33%
BenchmarkEndToEndSliceByteBuffer-4     1002           402            -59.88%
BenchmarkEncodeComplex128Slice-4       1              1              +0.00%
BenchmarkEncodeFloat64Slice-4          1              1              +0.00%
BenchmarkEncodeInt32Slice-4            1              1              +0.00%
BenchmarkEncodeStringSlice-4           1              1              +0.00%
BenchmarkEncodeInterfaceSlice-4        3001           1              -99.97%
BenchmarkDecodeComplex128Slice-4       188            185            -1.60%
BenchmarkDecodeFloat64Slice-4          188            185            -1.60%
BenchmarkDecodeInt32Slice-4            188            185            -1.60%
BenchmarkDecodeStringSlice-4           2188           1185           -45.84%
BenchmarkDecodeInterfaceSlice-4        6197           4194           -32.32%

benchmark                              old bytes     new bytes     delta
BenchmarkEndToEndPipe-4                64            48            -25.00%
BenchmarkEndToEndByteBuffer-4          64            48            -25.00%
BenchmarkEndToEndSliceByteBuffer-4     34551         10554         -69.45%
BenchmarkEncodeComplex128Slice-4       55            55            +0.00%
BenchmarkEncodeFloat64Slice-4          33            33            +0.00%
BenchmarkEncodeInt32Slice-4            32            32            +0.00%
BenchmarkEncodeStringSlice-4           36            36            +0.00%
BenchmarkEncodeInterfaceSlice-4        144555        347           -99.76%
BenchmarkDecodeComplex128Slice-4       28240         28097         -0.51%
BenchmarkDecodeFloat64Slice-4          11840         11697         -1.21%
BenchmarkDecodeInt32Slice-4            10817         10673         -1.33%
BenchmarkDecodeStringSlice-4           56128         39985         -28.76%
BenchmarkDecodeInterfaceSlice-4        132565        100421        -24.25%

Change-Id: Ief7c7706b1f2916486ab7190b81aafbb16b70f1e
Reviewed-on: https://go-review.googlesource.com/13660Reviewed-by: Russ Cox <rsc@golang.org>

json.Number is a special case which didn't have any checks and could result in invalid JSON.

Fixes #10281

Change-Id: Ie3e726e4d6bf6a6aba535d36f6107013ceac913a
Reviewed-on: https://go-review.googlesource.com/12250Reviewed-by: Russ Cox <rsc@golang.org>

CRC-32 computation is stateless and the p slice does not get stored
anywhere. Thus, we mark the assembly functions as noescape so that
it doesn't believe that p leaks in:
	func Update(crc uint32, tab *Table, p []byte) uint32

Before:
	./crc32.go:153: leaking param: p

After:
	./crc32.go:153: Update p does not escape

Change-Id: I52ba35b6cc544fff724327140e0c27898431d1dc
Reviewed-on: https://go-review.googlesource.com/17069Reviewed-by: Russ Cox <rsc@golang.org>

This compares the behavior of server handlers and the net/http
Transport in both HTTP/1 and HTTP/2 mode and verifies they're the
same.

This also moves some client<->server tests into clientserver_test.go.
Many of them were in serve_test.go or transport_test.go but were
basically testing both.

h2_bundle.go is an update of the golang.org/x/net/http2 code
from https://golang.org/cl/17204 (x/net git rev c745c36eab10)

Fixes #13315
Fixes #13316
Fixes #13317
Fixes other stuff found in the process too
Updates #6891 (http2 support in general)

Change-Id: Id9c45fad44cdf70ac95d2b89e578d66e882d3cc2
Reviewed-on: https://go-review.googlesource.com/17205Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

Fixes testshared on arm64 and ppc64le.

Change-Id: Ie94bc0c85c7666fbb5ab6fc6d3dbb180407a9955
Reviewed-on: https://go-review.googlesource.com/17212Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

We need a runtime check because the original issue is encountered
when running cross compiled windows program from linux. It's better
to give a meaningful crash message earlier than to segfault later.

The added test should not impose any measurable overhead to Go
programs.

For #12415.

Change-Id: Ib4a24ef560c09c0585b351d62eefd157b6b7f04c
Reviewed-on: https://go-review.googlesource.com/14207Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This is a comment/documentation change only but for a minor
code change in the file and package_ methods (move recognition
of semi to match grammar better).

Per request from r.

Change-Id: I81ec985cc5831074d9eb5e8ffbf7e59466284819
Reviewed-on: https://go-review.googlesource.com/17202Reviewed-by: Rob Pike <r@golang.org>

The prefix includes a semicolon.

Change-Id: I4bdb79aa9931e835e297f3ea2c46a001cd123d56
Reviewed-on: https://go-review.googlesource.com/17200Reviewed-by: Andrew Gerrand <adg@golang.org>

This change strips non-free license from Mark.Twain-Tom.Sawyer.txt along with all reference to Project Gutenberg in the file and the whole source tree. Making the file public domain again.

Fixes #13216

Change-Id: I2f41b0de225f627dde152efe93c006a4c24be668
Reviewed-on: https://go-review.googlesource.com/17196Reviewed-by: Andrew Gerrand <adg@golang.org>

Write barriers in gcFlushBgCredit lead to very subtle bugs because it
executes after the getfull barrier. I tracked some bugs of this form
down before go:nowritebarrierrec was implemented. Ensure that they
don't reappear by making gcFlushBgCredit go:nowritebarrierrec.

Change-Id: Ia5ca2dc59e6268bce8d8b4c87055bd0f6e19bed2
Reviewed-on: https://go-review.googlesource.com/17052Reviewed-by: Russ Cox <rsc@golang.org>

sighandler may run during STW, so write barriers are not allowed.

Change-Id: Icdf46be10ea296fd87e73ab56ebb718c5d3c97ac
Reviewed-on: https://go-review.googlesource.com/17007Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #13378

Change-Id: Ia78624ca1aa36ee906cef15416ea5554fa8229f2
Reviewed-on: https://go-review.googlesource.com/17201Reviewed-by: Ian Lance Taylor <iant@golang.org>

On multiprocessor machines, a file descriptor could be
closed twice in forkAndExecInChild. Consequently, the close
syscall returns the "fd out of range or not open" error
and forkAndExecInChild fails.

This changes forkAndExecInChild to ignore the error
returned by close(fd), as on other operating systems.

Fixes #12851.

Change-Id: I96a8463ce6599bfd1362353283e0329a00f738da
Reviewed-on: https://go-review.googlesource.com/17188Reviewed-by: Rob Pike <r@golang.org>

Replace the cross platform but unsafe [4]uintptr type with a OS
specific type, sigset. Most OSes already define sigset, and this
change defines a suitable sigset for the OSes that don't (darwin,
openbsd). The OSes that don't use m.sigmask (windows, plan9, nacl)
now defines sigset as the empty type, struct{}.

The gain is strongly typed access to m.sigmask, saving a dynamic
size sanity check and unsafe.Pointer casting. Also, some storage is
saved for each M, since [4]uinptr was conservative for most OSes.

The cost is that OSes that don't need m.sigmask has to define sigset.

completes ./all.bash with GOOS linux, on amd64
completes ./make.bash with GOOSes openbsd, android, plan9, windows,
darwin, solaris, netbsd, freebsd, dragonfly, all amd64.

With GOOS=nacl ./make.bash failed with a seemingly unrelated error.

[Replay of CL 16942 by Elias Naur.]

Change-Id: I98f144d626033ae5318576115ed635415ac71b2c
Reviewed-on: https://go-review.googlesource.com/17033Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

This is a bit ugly but it's a useful test. Run go install -buildmode=shared std
and then go run run.go -linkshared (it passes on linux/amd64).

Change-Id: I5684c79cd03817fa1fc399788b7320f8535c08da
Reviewed-on: https://go-review.googlesource.com/16343Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I9e968c03c6615a539b18701c84f830898242441d
Reviewed-on: https://go-review.googlesource.com/13926Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: Idd9523949ee4f2f304b12be39f8940ba34a420be
Reviewed-on: https://go-review.googlesource.com/16361Reviewed-by: Russ Cox <rsc@golang.org>

Before, we reset the timer at the end of T.Parallel, which is okay
assuming that T.Parallel is the first thing in the test.

Snapshot the elapsed time at the beginning of Parallel and include it in
the total duration so that any time spent in the test before calling
Parallel is reported in the test duration as well.

Updates #12243.

Change-Id: Ieca553e1f801e16b9b6416463fa8f7fa65425185
Reviewed-on: https://go-review.googlesource.com/16989Reviewed-by: Russ Cox <rsc@golang.org>

These tests were failing on one of the versions of cl/9345
("runtime: simplify buffered channels").

Change-Id: I920ffcd28de428bcb7c2d5a300068644260e1017
Reviewed-on: https://go-review.googlesource.com/16416Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Results are a bit noisy, but show good improvement (haswell)

name            old time/op    new time/op     delta
Memclr5-48        6.06ns ± 8%     5.65ns ± 8%    -6.81%  (p=0.000 n=20+20)
Memclr16-48       5.75ns ± 6%     5.71ns ± 6%      ~     (p=0.545 n=20+19)
Memclr64-48       6.54ns ± 5%     6.14ns ± 9%    -6.12%  (p=0.000 n=18+20)
Memclr256-48      10.1ns ±12%      9.9ns ±14%      ~     (p=0.285 n=20+19)
Memclr4096-48      104ns ± 8%       57ns ±15%   -44.98%  (p=0.000 n=20+20)
Memclr65536-48    2.45µs ± 5%     2.43µs ± 8%      ~     (p=0.665 n=16+20)
Memclr1M-48       58.7µs ±13%     56.4µs ±11%    -3.92%  (p=0.033 n=20+19)
Memclr4M-48        233µs ± 9%      234µs ± 9%      ~     (p=0.728 n=20+19)
Memclr8M-48        469µs ±11%      472µs ±16%      ~     (p=0.947 n=20+20)
Memclr16M-48       947µs ±10%      916µs ±10%      ~     (p=0.050 n=20+19)
Memclr64M-48      10.9ms ±10%      4.5ms ± 9%   -58.43%  (p=0.000 n=20+20)
GoMemclr5-48      3.80ns ±13%     3.38ns ± 6%   -11.02%  (p=0.000 n=20+20)
GoMemclr16-48     3.34ns ±15%     3.40ns ± 9%      ~     (p=0.351 n=20+20)
GoMemclr64-48     4.10ns ±15%     4.04ns ±10%      ~     (p=1.000 n=20+19)
GoMemclr256-48    7.75ns ±20%     7.88ns ± 9%      ~     (p=0.227 n=20+19)

name            old speed      new speed       delta
Memclr5-48       826MB/s ± 7%    886MB/s ± 8%    +7.32%  (p=0.000 n=20+20)
Memclr16-48     2.78GB/s ± 5%   2.81GB/s ± 6%      ~     (p=0.550 n=20+19)
Memclr64-48     9.79GB/s ± 5%  10.44GB/s ±10%    +6.64%  (p=0.000 n=18+20)
Memclr256-48    25.4GB/s ±14%   25.6GB/s ±12%      ~     (p=0.647 n=20+19)
Memclr4096-48   39.4GB/s ± 8%   72.0GB/s ±13%   +82.81%  (p=0.000 n=20+20)
Memclr65536-48  26.6GB/s ± 6%   27.0GB/s ± 9%      ~     (p=0.517 n=17+20)
Memclr1M-48     17.9GB/s ±12%   18.5GB/s ±11%      ~     (p=0.068 n=20+20)
Memclr4M-48     18.0GB/s ± 9%   17.8GB/s ±14%      ~     (p=0.547 n=20+20)
Memclr8M-48     17.9GB/s ±10%   17.8GB/s ±14%      ~     (p=0.947 n=20+20)
Memclr16M-48    17.8GB/s ± 9%   18.4GB/s ± 9%      ~     (p=0.050 n=20+19)
Memclr64M-48    6.19GB/s ±10%  14.87GB/s ± 9%  +140.11%  (p=0.000 n=20+20)
GoMemclr5-48    1.31GB/s ±10%   1.48GB/s ± 6%   +13.06%  (p=0.000 n=19+20)
GoMemclr16-48   4.81GB/s ±14%   4.71GB/s ± 8%      ~     (p=0.341 n=20+20)
GoMemclr64-48   15.7GB/s ±13%   15.8GB/s ±11%      ~     (p=0.967 n=20+19)

Change-Id: I393f3f20e2f31538d1b1dd70d6e5c201c106a095
Reviewed-on: https://go-review.googlesource.com/16773
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Klaus Post <klauspost@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>

Fixes #11959
Fixes #12035

Skip the CallbackGC test on linux/arm. This test takes between 30 and 60
seconds to run by itself, and is run 4 times over the course of ./run.bash
(once during the runtime test, three times more later in the build).

Change-Id: I4e7d3046031cd8c08f39634bdd91da6e00054caf
Reviewed-on: https://go-review.googlesource.com/14485Reviewed-by: Russ Cox <rsc@golang.org>

Original code is mistakenly panics on VirtualAlloc failure - we want
it to go looking for smaller memory region that VirtualAlloc will
succeed to allocate. Also return immediately if VirtualAlloc succeeds.
See rsc comment on issue #12587 for details.

I still don't have a test for this. So I can only hope that this

Fixes #12587

Change-Id: I052068ec627fdcb466c94ae997ad112016f734b7
Reviewed-on: https://go-review.googlesource.com/17169Reviewed-by: Russ Cox <rsc@golang.org>

See https://go-review.googlesource.com/#/c/17047/ for the bug fix.

Change-Id: Id5b0a37439d0f8f1e668f7c2ac84335b37f3a300
Reviewed-on: https://go-review.googlesource.com/17177Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #13073

Change-Id: I4fd9c6c61f1b9d49f66816839ca35209b4147ae3
Reviewed-on: https://go-review.googlesource.com/17167Reviewed-by: Russ Cox <rsc@golang.org>

Get rid of residue after removing old parser.

Change-Id: I0dace1037d50959071a082c276f9f374eef6edb2
Reviewed-on: https://go-review.googlesource.com/17179
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It relates to an obsolete notion of 'skipped-but-okay' tests.

Fixes #12394

Change-Id: Ib7e6444dc8565e1390bd42d65d30fac136593f78
Reviewed-on: https://go-review.googlesource.com/17000
Run-TryBot: Caleb Spare <cespare@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <shurcool@gmail.com>