Fixes #10135.

Change-Id: Ic4c5ab15bcb7b9c3fcc685a788d3b59c60c26e1e
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/7400Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-on: https://go-review.googlesource.com/14248Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #12345.

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

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

Change-Id: Ia87047cbc720fb03d2f67aec48abe18bce8dbf78
Reviewed-on: https://go-review.googlesource.com/5112Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/5113Reviewed-by: Andrew Gerrand <adg@golang.org>

The 32-bit heap may have holes in it.  Pointers to (non-heap) objects
in those holes shouldn't cause the GC to throw.

This change is somewhat of a band-aid fix for 1.4.2.  We should do
a more thorough fix for tip (keep track of the holes in the heap
with special MSpans, say).

Update #9872

Change-Id: Ife9ba27b77ae6ac5a6792d249c68893b3df62134
Reviewed-on: https://go-review.googlesource.com/4920
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The compiler has a phase ordering problem.  Escape analysis runs
before wrapper generation.  When a generated wrapper calls a method
defined in a different package, if that call is inlined, there will be
no escape information for the variables defined in the inlined call.
Those variables will be placed on the stack, which fails if they
actually do escape.

There are probably various complex ways to fix this.  This is a simple
way to avoid it: when a generated wrapper calls a method defined in a
different package, treat all local variables as escaping.

Fixes #9537.

Change-Id: I530f39346de16ad173371c6c3f69cc189351a4e9
Reviewed-on: https://go-review.googlesource.com/3092Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit ec0ebc22)
Reviewed-on: https://go-review.googlesource.com/5003
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

[release-branch.go1.4] cmd/gc: don't recurse infinitely when a recursive type references itself more than once

Fixes #9432

Change-Id: I08c92481afa7c7fac890aa780efc1cb2fabad528
Reviewed-on: https://go-review.googlesource.com/2115Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit fcff3ba7)
Reviewed-on: https://go-review.googlesource.com/5004
Run-TryBot: Andrew Gerrand <adg@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #9871 for Go 1.4.

Change-Id: I550a5bdb29e9a872652e0dd468a434227d7d9502
Reviewed-on: https://go-review.googlesource.com/4937
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #9634.

Change-Id: I7b18f26c2fb812978fc7adc5bfd39ebfffe48701
Reviewed-on: https://go-review.googlesource.com/3080Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit f5b8813e)
Reviewed-on: https://go-review.googlesource.com/5000
Run-TryBot: Andrew Gerrand <adg@golang.org>

We were failing ^uint16(0xffff) == 0, as we computed 0xffff0000 instead.

I could only trigger a failure for the above case, the other two tests
^uint16(0xfffe) == 1 and -uint16(0xffff) == 1 didn't seem to fail
previously.  Somehow they get MOVHUs inserted for other reasons (used
by CMP instead of TST?).  I fixed OMINUS anyway, better safe than
sorry.

Fixes #9604

Change-Id: I4c2d5bdc667742873ac029fdbe3db0cf12893c27
Reviewed-on: https://go-review.googlesource.com/2940Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit daa64ddf)
Reviewed-on: https://go-review.googlesource.com/5002

The comment says to use (y-1), but then we did add(y.abs, natOne).  We meant sub.

Fixes #9609

Change-Id: I4fe4783326ca082c05588310a0af7895a48fc779
Reviewed-on: https://go-review.googlesource.com/2961Reviewed-by: Robert Griesemer <gri@golang.org>
(cherry picked from commit c6ddca2a)
Reviewed-on: https://go-review.googlesource.com/5001

Remove carriage returns from //go:generate lines.
Carriage returns are the predecessor of BOMs and still
live on Windows.

Fixes #9264

Change-Id: I637748c74335c696b3630f52f2100061153fcdb4
Reviewed-on: https://go-review.googlesource.com/1564Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
(cherry picked from commit fde3ab84)
Reviewed-on: https://go-review.googlesource.com/4999Reviewed-by: David Symonds <dsymonds@golang.org>

I am an idiot but the failure to implement this means we can decide
exactly what its design should be for 1.5

Change-Id: Ie2b025fcd899d306ddeddd09d1d0e8f9a99ab7a8
Reviewed-on: https://go-review.googlesource.com/4291Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 1e5d8bb5)
Reviewed-on: https://go-review.googlesource.com/4998Reviewed-by: David Symonds <dsymonds@golang.org>

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

Change-Id: I4e9737497f4995657c46e52e0722d921499f8d17
Reviewed-on: https://go-review.googlesource.com/2854Reviewed-by: Rob Pike <r@golang.org>
(cherry picked from commit 7785be8f)
Reviewed-on: https://go-review.googlesource.com/2855

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

OpenBSD 5.5 changed its kernel ABI and OpenBSD 5.6 enabled it.
This CL works on both 5.5 and 5.6.

Fixes #9102.

Change-Id: I4a295be9ab8acbc99e550d8cb7e8f8dacf3a03c5
Reviewed-on: https://go-review.googlesource.com/1932Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 13e16b39)
Reviewed-on: https://go-review.googlesource.com/2826Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ieb305b2a4d4ef28d70a8b8ece703f495c5af0529
Reviewed-on: https://go-review.googlesource.com/2051Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit c6669e7a)
Reviewed-on: https://go-review.googlesource.com/2820Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Before:

	...
	imports golang.org/x/net/context: /Users/rsc/g/src/golang.org/x/net is from https://code.google.com/p/go.net, should be from https://go.googlesource.com/net

After:

	...
	imports golang.org/x/net/context: golang.org/x/net is a custom import path for https://go.googlesource.com/net, but /Users/rsc/g/src/golang.org/x/net is checked out from https://code.google.com/p/go.net

Change-Id: I93c35b85f955c7de684f71fbd4baecc717405318
Reviewed-on: https://go-review.googlesource.com/2808Reviewed-by: Andrew Gerrand <adg@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
(cherry picked from commit b8d67596)
Reviewed-on: https://go-review.googlesource.com/2813Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It shouldn't semacquire() inside an acquirem(), the runtime
thinks that means deadlock.  It actually isn't a deadlock, but it
looks like it because acquirem() does m.locks++.

Candidate for inclusion in 1.4.1.  runtime.Stack with all=true
is pretty unuseable in GOMAXPROCS>1 environment.

fixes #9321

Change-Id: Iac6b664217d24763b9878c20e49229a1ecffc805
Reviewed-on: https://go-review.googlesource.com/1600Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
(cherry picked from commit 50bc3d5b)
Reviewed-on: https://go-review.googlesource.com/2807Reviewed-by: Andrew Gerrand <adg@golang.org>

CL 2789 backported a change that required a barrage of followup CLs.
This CL backports all the followup CLs together.

There are manual edits to os_plan9.go and syscall_windows.go to take
the place of edits to defs_windows_{amd64,386}.go and os2_plan9.go
in the original. Those files do not exist in the release branch, but the
definition being added must go somewhere.

Original change descriptions below.

---

runtime/cgo: initialize our pthread_create wrapper earlier on openbsd

This is a genuine bug exposed by our test for issue 9456: our wrapper
for pthread_create is not initialized until we initialize cgo itself,
but it is possible that a static constructor could call pthread_create,
and in that case, it will be calling a nil function pointer.

Fix that by also initializing the sys_pthread_create function pointer
inside our pthread_create wrapper function, and use a pthread_once to
make sure it is only initialized once.

Fix build for openbsd.

Change-Id: Ica4da2c21fcaec186fdd3379128ef46f0e767ed7
Reviewed-on: https://go-review.googlesource.com/2232Reviewed-by: David Crawshaw <crawshaw@golang.org>
(cherry picked from commit 77cd6197)

---

runtime: provide a dummy value of _SIGPROF on plan9 and windows

Fixes build on plan9 and windows.

Change-Id: Ic9b02c641ab84e4f6d8149de71b9eb495e3343b2
Reviewed-on: https://go-review.googlesource.com/2233Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
(cherry picked from commit 1f282385)

---

runtime/cgo: remove unused variable

I missed this one in golang.org/cl/2232 and only tested the patch
on openbsd/amd64.

Change-Id: I4ff437ae0bfc61c989896c01904b6d33f9bdf0ec
Reviewed-on: https://go-review.googlesource.com/2234Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 0b2a74e8)

---

runtime: skip TestCgoExternalThreadSIGPROF on OS X 10.6

The test program requires static constructor, which in turn needs
external linking to work, but external linking never works on 10.6.

This should fix the darwin-{386,amd64} builders.

Change-Id: I714fdd3e35f9a7e5f5659cf26367feec9412444f
Reviewed-on: https://go-review.googlesource.com/2235Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 2cbe27a2)

---

runtime: fix TestCgoExternalThreadSIGPROF again

Shell out to `uname -r` this time, so that the test will compile
even if the platform doesn't have syscall.Sysctl.

Change-Id: I3a19ab5d820bdb94586a97f4507b3837d7040525
Reviewed-on: https://go-review.googlesource.com/2271Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 865e5e98)

---

runtime: remove unnecessary GOOS switch

Change-Id: I8f518e273c02110042b08f7c50c3d38a648c8b6e
Reviewed-on: https://go-review.googlesource.com/2281Reviewed-by: Minux Ma <minux@golang.org>
(cherry picked from commit 1ebfb082)

---

Change-Id: Ifee9667ca90eda2b074817c319b1b7c66d4f741d
Reviewed-on: https://go-review.googlesource.com/2805Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

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

Fixes #9359.

Change-Id: Iba62935b5a14de23d914f433a09a40417d7e88ed
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1889Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 1c0c611f)
Reviewed-on: https://go-review.googlesource.com/2802Reviewed-by: Andrew Gerrand <adg@golang.org>

Pointers to zero-sized values may end up pointing to the next
object in memory, and possibly off the end of a span.  This
can cause memory leaks and/or confuse the garbage collector.

By putting the overflow pointer at the end of the bucket, we
make sure that pointers to any zero-sized keys or values don't
accidentally point to the next object in memory.

fixes #9384

Change-Id: I5d434df176984cb0210b4d0195dd106d6eb28f73
Reviewed-on: https://go-review.googlesource.com/1869Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit fbc56cf0)
Reviewed-on: https://go-review.googlesource.com/2801Reviewed-by: Andrew Gerrand <adg@golang.org>

malloc checks kindNoPointers and if it is not set and the object
is one pointer in size, it assumes it contains a pointer.  So we
must set kindNoPointers correctly; it isn't just a hint.

Fixes #9425

Change-Id: Ia43da23cc3298d6e3d6dbdf66d32e9678f0aedcf
Reviewed-on: https://go-review.googlesource.com/2055Reviewed-by: Russ Cox <rsc@golang.org>
(cherry picked from commit d11f4111)
Reviewed-on: https://go-review.googlesource.com/2800Reviewed-by: Andrew Gerrand <adg@golang.org>

[release-branch.go1.4] runtime: ignore SIGPROF to foreign threads before cgocallback is fully initialized

Some libraries, for example, OpenBLAS, create work threads in a global constructor.
If we're doing cpu profiling, it's possible that SIGPROF might come to some of the
worker threads before we make our first cgo call. Cgocallback used to terminate the
process when that happens, but it's better to miss a couple profiling signals than
to abort in this case.

Fixes #9456.

Change-Id: I112b8e1a6e10e6cc8ac695a4b518c0f577309b6b
Reviewed-on: https://go-review.googlesource.com/2141Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 5da9c8cd)
Reviewed-on: https://go-review.googlesource.com/2789Reviewed-by: Andrew Gerrand <adg@golang.org>

This incorporates the various git-related updates that have
happened since the Go 1.4 release. Since Go 1.4.1 will be issued
from Git, it is appropriate to replace the Mercurial instructions
with Git instructions.

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

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

LGTM=bradfitz, minux, dsymonds
R=rsc, bradfitz, iant, dsymonds, minux
CC=golang-codereviews
https://golang.org/cl/188920043

LGTM=dave, dsymonds
R=golang-codereviews, dave, dsymonds
CC=golang-codereviews
https://golang.org/cl/184350043

LGTM=bradfitz
R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/189810043

LGTM=bradfitz
R=iant, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/191750043

Also: checkout sub-repos from Mercurial manually
instead of using "go get". (for the 1.4 release)

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/190720043

I read through and vetted these but others should look too.

LGTM=bradfitz, adg
R=r, minux, bradfitz, adg
CC=adg, golang-codereviews, gri, iant
https://golang.org/cl/182560043

These are the references that affect current Go users.
I left intact references in older release notes;
we can figure out what to do with them later.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/186140043

LGTM=minux, adg, rsc
R=rsc, r, dsymonds, minux, bradfitz, adg, dave, iant
CC=golang-codereviews
https://golang.org/cl/185190043

««« CL 185130043 / 586738173884
misc/cgo/test: skip test8694 on ARM.

LGTM=dave, bradfitz, rsc
R=golang-codereviews, dave, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/185130043

»»»

LGTM=minux
R=golang-codereviews, minux, bradfitz
CC=golang-codereviews
https://golang.org/cl/188870043

LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/189760043

««« CL 182580043 / 2d1ab17a670a
encoding/xml: remove SyntaxError.Byte

It is unused. It was introduced in the CL that added InputOffset.
I suspect it was an editing mistake.

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/182580043
»»»

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/180630043

TBR=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/178710043