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

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

MinPrec returns the minimum precision required to represent a Float
without loss of precision. Added test.

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

There is only one process under the iOS sandboxd.

Change-Id: I21b5528366a0248a034801a717f24c60f0733c5f
Reviewed-on: https://go-review.googlesource.com/6101Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Needs the Go tool, which we do not have on iOS. (No Fork.)

Change-Id: Iedf69f5ca81d66515647746546c9b304c8ec10c4
Reviewed-on: https://go-review.googlesource.com/6102Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Section 4.3.14.1 of the ZIP file format
spec (https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) says,

    The value stored into the "size of zip64 end of central directory
    record" should be the size of the remaining record and should not
    include the leading 12 bytes.

We were previously writing the full size, including the 12 bytes.

Fixes #9857

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

Change-Id: Ief78a10c4aaa43f300f34519911ff73b6f510d73
Reviewed-on: https://go-review.googlesource.com/6100Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

There is no sense in trying to netpoll while there is
already a thread blocked in netpoll. And in most cases
there must be a thread blocked in netpoll, because
the first otherwise idle thread does blocking netpoll.

On some program I see that netpoll called from findrunnable
consumes 3% of time.

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

This makes Go's CPU profiling code somewhat more idiomatic; e.g.,
using := instead of forward declaring variables, using "int" for
element counts instead of "uintptr", and slices instead of C-style
pointer+length.  This makes the code easier to read and eliminates a
lot of type conversion clutter.

Additionally, in sigprof we can collect just maxCPUProfStack stack
frames, as cpuprof won't use more than that anyway.

Change-Id: I0235b5ae552191bcbb453b14add6d8c01381bd06
Reviewed-on: https://go-review.googlesource.com/6072
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

The test data was generated by:
convert video-001.png tmp.tga
cjpeg -quality 50 -sample 4x2,1x1,1x1 tmp.tga > video-001.q50.410.jpeg
cjpeg -quality 50 -sample 4x1,1x1,1x1 tmp.tga > video-001.q50.411.jpeg
cjpeg -quality 50 -sample 4x2,1x1,1x1 -progressive tmp.tga > video-001.q50.410.progressive.jpeg
cjpeg -quality 50 -sample 4x1,1x1,1x1 -progressive tmp.tga > video-001.q50.411.progressive.jpeg
rm tmp.tga

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

This reduces the number of allocs when
running the rotate.go tests by
about 20%, after applying CL 5700.

Combining

s = "const str"
s += <another string>

generally saves an alloc and might be a candidate for
rsc's grind tool. However, I'm sending this CL now
because this also reuses the result of calling lexbuf.String.

Change-Id: If3a7300b7da9612ab62bb910ee90349dca88dde3
Reviewed-on: https://go-review.googlesource.com/5821Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The first call is pointless. It appears to simply be a mistake.

benchmark                  old ns/op     new ns/op     delta
BenchmarkComplexAlgMap     90.7          76.1          -16.10%

Change-Id: Id0194c9f09cea8b68f17b2ac751a8e3240e47f19
Reviewed-on: https://go-review.googlesource.com/5284Reviewed-by: Keith Randall <khr@golang.org>

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

Some real world JPEG images are in 4:1:1 and 4:1:0 formats.

See also http://en.wikipedia.org/wiki/Chroma_subsampling

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

There are no behavior changes in this CL, only specifying the status
quo. A follow-up CL, https://go-review.googlesource.com/#/c/5910/, will
change marshaling behavior.

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

The existing Hostname function uses the GetComputerName system
function in windows to determine the hostname. It has some downsides:

  - The name is limited to 15 characters.
  - The name returned is for NetBIOS, other OS's return a DNS name

This change adds to the internal/syscall/windows package a
GetComputerNameEx function, and related enum constants. They are used
instead of the syscall.ComputerName function to implement os.Hostname
on windows.

Fixes #9982

Change-Id: Idc8782785eb1eea37e64022bd201699ce9c4b39c
Reviewed-on: https://go-review.googlesource.com/5852Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Carlos Castillo <cookieo9@gmail.com>
Reviewed-by: Yasuhiro MATSUMOTO <mattn.jp@gmail.com>

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

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

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

Macro definition ordering.

Change-Id: I0def4702d19a21a68ffa52ea5b7c22578830c578
Reviewed-on: https://go-review.googlesource.com/6030Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Gives tests a way to find the bundle that contains their testdata, and
is generally useful for finding resources.

Change-Id: Idfa03e8543af927c17bc8ec8aadc5014ec82df28
Reviewed-on: https://go-review.googlesource.com/6000Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>

Updates #10002

The gdb test added in 1c82e236 is failing on most arm systems.

Temporarily disable this test so that we can return to a working arm build.

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

Change-Id: Iee319c9f5375c172fb599da77234c10ccb0fd314
Reviewed-on: https://go-review.googlesource.com/6020Reviewed-by: Keith Randall <khr@golang.org>

Change-Id: I42929abe5cefd84a1daf4f36ee1806c490ce16ec
Reviewed-on: https://go-review.googlesource.com/5960Reviewed-by: Minux Ma <minux@golang.org>

We return memory to the kernel with madvise(..., DONTNEED).
Also mark returned memory with NOHUGEPAGE to keep the kernel from
merging this memory into a huge page, effectively reallocating it.

Only known to be a problem on linux/{386,amd64,amd64p32} at the moment.
It may come up on other os/arch combinations in the future.

Fixes #8832

Change-Id: Ifffc6627a0296926e3f189a8a9b6e4bdb54c79eb
Reviewed-on: https://go-review.googlesource.com/5660Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

We need to distinguish pointers to free spans, which indicate bugs in
our pointer analysis, from pointers to never-in-the-heap spans, which
can legitimately arise from sysAlloc/mmap/etc.  This normally isn't a
problem because the heap is contiguous, but in some situations (32
bit, particularly) the heap must grow around an already allocated
region.

The bad pointer test is disabled so this fix doesn't actually do
anything, but it removes one barrier from reenabling it.

Fixes #9872.

Change-Id: I0a92db4d43b642c58d2b40af69c906a8d9777f88
Reviewed-on: https://go-review.googlesource.com/5780Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Each architecture had its own Dconv (operand printer) but the syntax is
close to uniform and the code overlap was considerable. Consolidate these
into a single top-level function. A similar but smaller unification is done
for Mconv ("Name" formatter) as well.

The signature is changed. The flag was unused so drop it. Add a
function argument, Rconv, that must be supplied by the caller.
TODO: A future change will unify Rconv as well and this argument
will go away.

Some formats changed, because of the automatic consistency
created by unification. For instance, 0(R1) always prints as (R1)
now, and foo+0(SB) is just foo(SB). Before, some made these
simplifications and some didn't; now they all do.

Update the asm tests that depend on the format.

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

Fixes #9083.

Change-Id: Ifbdebafb39a73a1dacf7e67171e8e88028d1f10b
Reviewed-on: https://go-review.googlesource.com/1219Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Available darwin/arm devices sporadically have trouble mapping 256M.

I would really appreciate it if anyone could check my working on
this, and make sure sure there aren't obviously bad consequences I
haven't considered.

Change-Id: Id1a8edae104d974fcf5f9333274f958625467f79
Reviewed-on: https://go-review.googlesource.com/5752Reviewed-by: Keith Randall <khr@golang.org>

Fixes #9076.

Change-Id: Ib41a452fa9aa9fecf19f65c36d13715923548041
Reviewed-on: https://go-review.googlesource.com/1250Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #9017.

Change-Id: I26cb1e7d6e137ff145773169cfe2d8bd4e1b339c
Reviewed-on: https://go-review.googlesource.com/1252Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Chris Manghane <cmang@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Also introduce actual data structure for table.

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

The dummy implementation was causing lots of argument lists
to be prepared and thrown away.

Change-Id: Id0040dec6b0937f3daa8a8d8911fa3280123e863
Reviewed-on: https://go-review.googlesource.com/5700Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

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

verifyAsm is still on, but this CL changes the order to asm then 6a.
Before, it was 6a then asm, but that meant that any bugs in asm
for bad input would be prevented from happening because 6a would
catch them. Now asm gets first crack, as it must.

Also implement the -trimpath flag in asm. It's necessary and trivial.

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

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

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

Missing cases for JMP $4 and foo+4(SB):AX. Both are odd but 8a accepts them
and they seem valid.

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

Since allglock is held in this function, there's no point to
tip-toeing around allgs.  Just use a for-range loop.

Change-Id: I1ee61c7e8cac8b8ebc8107c0c22f739db5db9840
Reviewed-on: https://go-review.googlesource.com/5882Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Previously, we had three loops in the garbage collector that all
cleared the per-G GC flags.  Consolidate these into one function.
This one function is designed to work in a concurrent setting.  As a
result, it's slightly more expensive than the loops it replaces during
STW phases, but these happen at most twice per GC.

Change-Id: Id1ec0074fd58865eb0112b8a0547b267802d0df1
Reviewed-on: https://go-review.googlesource.com/5881Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>