If TMP environment variable is set to Z:\, TempDir returns Z:.
But Z: refers to current directory on Z:, while Z:\ refers to root
directory on Z:. Adjust TempDir to return Z:\.

Fixes #29291

Change-Id: If04d0c7977a8ac2d9d558307502e81beb68776ef
Reviewed-on: https://go-review.googlesource.com/c/154384
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Tracing uses cputicks() to generate trace event timestamps. cputicks()
is expected to be a high resolution clock source. On Windows/ARM,
call QueryPerformanceCounter() which is the highest resolution clock
source available.

Updates #26148

Change-Id: I987fa556060b3d60c02f07b87b9e6320b9b026e2
Reviewed-on: https://go-review.googlesource.com/c/154762Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When a locked M has its G exit without calling UnlockOSThread, then
lockedExt on it was getting cleared. Unfortunately, this meant that
during P handoff, if a new M was started, it might get forked (on
most OSs besides Windows) from the locked M, which could have kernel
state attached to it.

To solve this, just don't clear lockedExt. At the point where the
locked M has its G exit, it will also exit in accordance with the
LockOSThread API. So, we can safely assume that it's lockedExt state
will no longer be used. For the case of the main thread where it just
gets wedged instead of exiting, it's probably better for it to keep
the locked marker since it more accurately represents its state.

Fixed #28979.

Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f
Reviewed-on: https://go-review.googlesource.com/c/153078
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>

This change disables the test TestArenaCollision on Darwin in race mode
to deal with the fact that Darwin 10.10 must use MAP_FIXED in race mode
to ensure we retain our heap in a particular portion of the address
space which the race detector needs. The test specifically checks to
make sure a manually mapped region's space isn't re-used, which is
definitely possible with MAP_FIXED because it replaces whatever mapping
already exists at a given address.

This change then also makes it so that MAP_FIXED is only used in race
mode and on Darwin, not all BSDs, because using MAP_FIXED breaks this
test for FreeBSD in addition to Darwin.

Updates #26475.
Fixes #29340.

Change-Id: I1c59349408ccd7eeb30c4bf2593f48316b23ab2f
Reviewed-on: https://go-review.googlesource.com/c/155097
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This reverts change https://golang.org/cl/154758.

Restore the previous implementations of nanotime and time.now, which
are sufficiently high resolution and more efficient than
QueryPerformanceCounter. The intent of the change was to improve
resolution of tracing timestamps, but the change was overly broad
as it was only necessary to fix cputicks(). cputicks() is fixed in
a subsequent change.

Updates #26148

Change-Id: Ib9883d02fe1af2cc4940e866d8f6dc7622d47781
Reviewed-on: https://go-review.googlesource.com/c/154761Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Fix two typos and don't indent the go vet example.

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

This was accidentally broken by CL 127755.

Fixes #29333

Change-Id: I5e92048c64a55c1699d6c38eb4dbbd51c817b820
Reviewed-on: https://go-review.googlesource.com/c/155037
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

startpanic_m could be called correctly in a context where there's a
valid G, a valid M, but no P, for example in a signal handler which
panics. Currently, startpanic_m has write barriers enabled because
write barriers are permitted if a G's M is dying. However, all the
current write barrier implementations assume the current G has a P.

Therefore, in this change we disable write barriers in startpanic_m,
remove the only pointer write which clears g.writebuf, and fix up gwrite
to ignore the writebuf if the current G's M is dying, rather than
relying on it being nil in the dying case.

Fixes #26575.

Change-Id: I9b29e6b9edf00d8e99ffc71770c287142ebae086
Reviewed-on: https://go-review.googlesource.com/c/154837
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

The previous implementation of nanotime and time.now used a time source
that was updated on the system clock tick, which has a maximum
resolution of about 1ms. On 386 and amd64, this time source maps to
the system performance counter, so has much higher resolution.
On ARM, use QueryPerformanceCounter() to get a high resolution timestamp.

Updates #26148

Change-Id: I1abc99baf927a95b472ac05020a7788626c71d08
Reviewed-on: https://go-review.googlesource.com/c/154758Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

Change-Id: I9a30c76d1299a494cce69b1060156bc2932ac8d5
Reviewed-on: https://go-review.googlesource.com/c/154857Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Permission bits are most commonly viewed in string form (rwx-- etc) or
in octal form (0755), but the latter is relatively rare in Go.
Demonstrate how to print a FileMode in readable octal format.

Change-Id: I41feb801bcecb5077d4eabafdea27c149fc179a1
Reviewed-on: https://go-review.googlesource.com/c/154423
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This change makes it so that reserving more of the address space for the
heap calls mmap with MAP_FIXED in race mode. Race mode requires certain
guarantees on where the heap is located in the address space, and on
Darwin 10.10 it appears that the kernel may end up ignoring the hint
quite often (#26475). Using MAP_FIXED is relatively OK in race mode
because nothing else should be mapped in the memory region provided by
the initial hints.

Fixes #26475.

Change-Id: Id7ac1534ee74f6de491bc04441f27dbda09f0285
Reviewed-on: https://go-review.googlesource.com/c/153897Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When using //line directives and unformatted code it is possible for
positions to repeat. Increment the final column position to avoid that.

Fixes #27350

Change-Id: I2faccc31360075e9814d4a024b0f98b117f8ce97
Reviewed-on: https://go-review.googlesource.com/c/153061
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

This ensures that "go test cmd/cover" tests the current cover program,
not the installed cover program.

Change-Id: I58e718ded7eb1cd8da448d0194262209bb025b20
Reviewed-on: https://go-review.googlesource.com/c/153058
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

CL 138675 added the race detector support on Linux/ARM64, but it
didn't enable the race detector tests in cmd/dist (therefore in
all.bash). Enable them.

Updates #28848

Change-Id: I4306dad2fb4167021d568436076b9f535d7f6e07
Reviewed-on: https://go-review.googlesource.com/c/149967
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

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

Also update a Go 1 compatibility promise link to canonical URL.

Updates #27592
Updates #28264

Change-Id: I5994a0a63e0870c1795c65016590dfad829d26a7
Reviewed-on: https://go-review.googlesource.com/c/154618Reviewed-by: Richard Musiol <neelance@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Id68b62138e14d13bb352b14c7f42bcef5601eee3
Reviewed-on: https://go-review.googlesource.com/c/154717Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This commit fixes backtrace if a crash or an exit signal is received
during a C syscall on aix/ppc64.
This is similar to Solaris, Darwin or Windows implementation.

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

This commit changes the second instruction used to retrieve a symbol on
aix/ppc64 if it is in .data or .bss section.

The previous version always retrieves the symbol address via a load on
its TOC symbol. However, as the TOC is also in .data, the symbol's address
is close enough to be fetched directly and the load instruction can be
replaced by an addi.

Bench go1
benchmark                             old ns/op      new ns/op      delta
BenchmarkBinaryTree17-16              5919354000     5824897000     -1.60%
BenchmarkFannkuch11-16                5206937000     5162043000     -0.86%
BenchmarkFmtFprintfEmpty-16           106            105            -0.94%
BenchmarkFmtFprintfString-16          165            165            +0.00%
BenchmarkFmtFprintfInt-16             165            167            +1.21%
BenchmarkFmtFprintfIntInt-16          303            239            -21.12%
BenchmarkFmtFprintfPrefixedInt-16     282            283            +0.35%
BenchmarkFmtFprintfFloat-16           434            381            -12.21%
BenchmarkFmtManyArgs-16               1797           903            -49.75%
BenchmarkGobDecode-16                 16000450       12173630       -23.92%
BenchmarkGobEncode-16                 12007010       10258070       -14.57%
BenchmarkGzip-16                      638581500      456050333      -28.58%
BenchmarkGunzip-16                    111976900      74943900       -33.07%
BenchmarkHTTPClientServer-16          206850         153716         -25.69%
BenchmarkJSONEncode-16                32057380       17517130       -45.36%
BenchmarkJSONDecode-16                182606400      106807700      -41.51%
BenchmarkMandelbrot200-16             6896975        5616903        -18.56%
BenchmarkGoParse-16                   11248260       6094115        -45.82%
BenchmarkRegexpMatchEasy0_32-16       292            148            -49.32%
BenchmarkRegexpMatchEasy0_1K-16       540            327            -39.44%
BenchmarkRegexpMatchEasy1_32-16       243            150            -38.27%
BenchmarkRegexpMatchEasy1_1K-16       1029           657            -36.15%
BenchmarkRegexpMatchMedium_32-16      423            230            -45.63%
BenchmarkRegexpMatchMedium_1K-16      107250         59683          -44.35%
BenchmarkRegexpMatchHard_32-16        3353           3139           -6.38%
BenchmarkRegexpMatchHard_1K-16        107277         93610          -12.74%
BenchmarkRevcomp-16                   1124311500     677442500      -39.75%
BenchmarkTemplate-16                  241286600      109177400      -54.75%
BenchmarkTimeParse-16                 1058           562            -46.88%
BenchmarkTimeFormat-16                1321           581            -56.02%

benchmark                            old MB/s     new MB/s     speedup
BenchmarkGobDecode-16                47.97        63.05        1.31x
BenchmarkGobEncode-16                63.92        74.82        1.17x
BenchmarkGzip-16                     30.39        42.55        1.40x
BenchmarkGunzip-16                   173.29       258.92       1.49x
BenchmarkJSONEncode-16               60.53        110.78       1.83x
BenchmarkJSONDecode-16               10.63        18.17        1.71x
BenchmarkGoParse-16                  5.15         9.50         1.84x
BenchmarkRegexpMatchEasy0_32-16      109.42       215.86       1.97x
BenchmarkRegexpMatchEasy0_1K-16      1896.22      3126.28      1.65x
BenchmarkRegexpMatchEasy1_32-16      131.46       212.99       1.62x
BenchmarkRegexpMatchEasy1_1K-16      994.55       1557.51      1.57x
BenchmarkRegexpMatchMedium_32-16     2.36         4.34         1.84x
BenchmarkRegexpMatchMedium_1K-16     9.55         17.16        1.80x
BenchmarkRegexpMatchHard_32-16       9.54         10.19        1.07x
BenchmarkRegexpMatchHard_1K-16       9.55         10.94        1.15x
BenchmarkRevcomp-16                  226.06       375.19       1.66x
BenchmarkTemplate-16                 8.04         17.77        2.21x

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

Fixes #29315

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

Currently, we flush the write barrier buffer on every write barrier
once throwOnGCWork is set, but not during the mark completion
algorithm itself. As seen in recent failures like

  https://build.golang.org/log/317369853b803b4ee762b27653f367e1aa445ac1

by the time we actually catch a late gcWork put, the write barrier
buffer is full-size again.

As a result, we're probably not catching the actual problematic write
barrier, which is probably somewhere in the buffer.

Fix this by using the gcWork pause generation to also keep the write
barrier buffer small between the mark completion flushes it and when
mark completion is done.

For #27993.

Change-Id: I77618169441d42a7d562fb2a998cfaa89891edb2
Reviewed-on: https://go-review.googlesource.com/c/154638
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

Fixes #27218

Change-Id: I4eb8e8f2486b20fe0ed6e3e2c6ec521c9e8c0032
Reviewed-on: https://go-review.googlesource.com/c/149579Reviewed-by: Austin Clements <austin@google.com>

Add support for cgo on openbsd/arm.The gcc shipped with base OpenBSD armv7
is old/inadequate, so use clang by default.

Change-Id: I945a26d369378952d357727718e69249411e1127
Reviewed-on: https://go-review.googlesource.com/c/154381
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

The formatting routines for types use a depth limit as primitive
mechanism to detect cycles. For now, increase the limit from 100
to 250 and file #29312 so we don't drop this on the floor.

Also, adjust some fatal error messages elsewhere to use
better formatting.

Fixes #29264.
Updates #29312.

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

Fixes #29260

Change-Id: I419b74d06380113f4bd32b9aeb053c3be36208d5
Reviewed-on: https://go-review.googlesource.com/c/154584Reviewed-by: Alan Donovan <adonovan@google.com>

This change modifies the behavior of span allocations to no longer
prefer the free treap over the scavenged treap.

While there is an additional cost to allocating out of the scavenged
treap, the current behavior of preferring the unscavenged spans can
lead to unbounded growth of a program's virtual memory footprint.

In small programs (low # of Ps, low resident set size, low allocation
rate) this behavior isn't really apparent and is difficult to
reproduce.

However, in relatively large, long-running programs we see this
unbounded growth in free spans, and an unbounded amount of heap
growths.

It still remains unclear how this policy change actually ends up
increasing the number of heap growths over time, but switching the
policy back to best-fit does indeed solve the problem.

Change-Id: Ibb88d24f9ef6766baaa7f12b411974cc03341e7b
Reviewed-on: https://go-review.googlesource.com/c/148979
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

This change adds the treapIter type which provides an iterator
abstraction for walking over an mTreap. In particular, the mTreap type
now has iter() and rev() for iterating both forwards (smallest to
largest) and backwards (largest to smallest). It also has an erase()
method for erasing elements at the iterator's current position.

For #28479.

While the expectation is that this change will slow down Go programs,
the impact on Go1 and Garbage is negligible.

Go1:     https://perf.golang.org/search?q=upload:20181214.6
Garbage: https://perf.golang.org/search?q=upload:20181214.11

Change-Id: I60dbebbbe73cbbe7b78d45d2093cec12cc0bc649
Reviewed-on: https://go-review.googlesource.com/c/151537
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

This commit move data addresses to 0x200000000 for XCOFF executables.
.data and .bss must always be position-independent on AIX. This
modification allows to detect more easily if they aren't, as segfault
will be triggered.

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

When a println arg contains a call to an inlineable function
that itself contains a switch, that switch statement will be
walked twice, once by the walkexprlist formerly in the
OPRINT/OPRINTN case, then by walkexprlistcheap in walkprint.

Remove the first walkexprlist, it is not necessary.
walkexprlist =
		s[i] = walkexpr(s[i], init)
walkexprlistcheap = {
		s[i] = cheapexpr(n, init)
		s[i] = walkexpr(s[i], init)
}

Seems like this might be possible in other places, i.e.,
calls to inlineable switch-containing functions.

See also #25776.
Fixes #29220.

Change-Id: I3781e86aad6688711597b8bee9bc7ebd3af93601
Reviewed-on: https://go-review.googlesource.com/c/154497
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

sysUsed on Windows cares about the result from the VirtualAlloc syscall
returning exactly the address that was passed to it. However,
VirtualAlloc aligns the address its given to the kernel's allocation
granularity, so the returned address may not be the same.

Note that this wasn't an issue in the past because we only sysUsed
regions owned by spans, and spans are always a multiple of 8K, which
is a multiple of the allocation granularity on most Windows machines.

Change-Id: I3f5ccd63c6bbbd8b7995945ecedee17573b31667
Reviewed-on: https://go-review.googlesource.com/c/153677
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: I2a5613377a38815fb8746c5bfb07ccbbc2e6dd0b
Reviewed-on: https://go-review.googlesource.com/c/153829Reviewed-by: Adam Langley <agl@golang.org>

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

This captures the stack trace where mark completion observed that each
P had no work, and then dumps this if that P later discovers more
work. Hopefully this will help bound where the work was created.

For #27993.

Change-Id: I4f29202880d22c433482dc1463fb50ab693b6de6
Reviewed-on: https://go-review.googlesource.com/c/154599
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

Many of the crashes observed in #27993 involve committing the new
_defer object at the end of newdefer. It would be helpful to know if
the _defer was just allocated or was retrieved from the defer pool. In
order to indicate this in the traceback, this CL duplicates the tail
of newdefer so that the PC/line number will tell us whether d is new
or not.

For #27993.

Change-Id: Icd3e23dbcf00461877bb082b6f18df701149a607
Reviewed-on: https://go-review.googlesource.com/c/154598
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>

Currently we only know the slot address and the value being written in
the throwOnGCWork crash tracebacks, and we have to infer the old value
from what's dumped by gcWork.checkPut. Sometimes these old values
don't make sense, like when we see a write of a nil pointer to a
freshly-allocated object, yet we observe marking a value (where did
that pointer come from?).

This CL adds the old value of the slot and the first two pointers in
the buffer to the traceback.

For #27993.

Change-Id: Ib70eead1afb9c06e8099e520172c3a2acaa45f80
Reviewed-on: https://go-review.googlesource.com/c/154597
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>