Old:
prog.go:9: invalid operation: this[i] (index of type int)
New:
prog.go:9: invalid operation: this[i] (type int does not support indexing)

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/52540043

Before, an unnamed return value turned into an ONAME node n with n->sym
named ~anon%d, and n->orig == n.

A blank-named return value turned into an ONAME node n with n->sym
named ~anon%d but n->orig == the original blank n. Code generation and
printing uses n->orig, so that this node formatted as _.

But some code does not use n->orig. In particular the liveness code does
not know about the n->orig convention and so mishandles blank identifiers.
It is possible to fix but seemed better to avoid the confusion entirely.

Now the first kind of node is named ~r%d and the second ~b%d; both have
n->orig == n, so that it doesn't matter whether code uses n or n->orig.

After this change the ->orig field is only used for other kinds of expressions,
not for ONAME nodes.

This requires distinguishing ~b from ~r names in a few places that care.
It fixes a liveness analysis bug without actually changing the liveness code.

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/63630043

Make the loop nesting depth of &x depend on where x is declared,
not on where the &x appears. The latter is only a conservative
estimate of the former. Being more careful can avoid some
variables escaping, and it is easier to reason about.

It would have avoided issue 7313, although that was still a bug
worth fixing.

Not much effect in the tree: one variable in the whole tree
is saved from a heap allocation (something in x509 parsing).

LGTM=daniel.morsing
R=daniel.morsing
CC=golang-codereviews
https://golang.org/cl/62380043

The methods MoveAfter and MoveBefore of the container/list package did silently corrupt the interal structure of the list if a mark element is used which is not an element of the list.

LGTM=gri
R=golang-codereviews, gobot, gri
CC=golang-codereviews
https://golang.org/cl/60980043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/63620043

Tweak the ARM assembler to improve its performance.

  * Use TEQ instead of CMP which preserves the carry flag.  This means
    we can avoid saving and restoring CPSR which is very slow.

  * Use conditional instructions to read the value of the carry flag.

  * Use 3 argument ARM instructions to save instructions

  * Improve scheduling for MOVW instructions (LDR)

  * Use RSB constant to save an instruction in bitLen

Results of -test.bench 'VV|VW|VU|WW|Bit' -test.benchtime 3s on Samsung
Exynos5 Chromebook.

There are a few small regressions in the benchmarks which I believe to
be noise, perhaps due to different cacheline alignment.

The changes to bitLen are apparently no faster, however less
instructions means less I-cache usage which is a win. I suspect it
will be a win on older ARM processors.

benchmark                 old ns/op    new ns/op    delta
BenchmarkAddVV_1                 48           14  -70.84%
BenchmarkAddVV_2                 87           17  -80.25%
BenchmarkAddVV_3                126           20  -83.97%
BenchmarkAddVV_4                165           23  -86.00%
BenchmarkAddVV_5                204           26  -87.21%
BenchmarkAddVV_1e1              399           41  -89.72%
BenchmarkAddVV_1e2             3921          315  -91.97%
BenchmarkAddVV_1e3            39085         2972  -92.40%
BenchmarkAddVV_1e4           390330        29623  -92.41%
BenchmarkAddVV_1e5          3935366       343431  -91.27%
BenchmarkAddVW_1                 20           10  -49.04%
BenchmarkAddVW_2                 60           14  -76.53%
BenchmarkAddVW_3                 99           16  -83.38%
BenchmarkAddVW_4                140           18  -86.50%
BenchmarkAddVW_5                179           21  -88.04%
BenchmarkAddVW_1e1              376           33  -91.20%
BenchmarkAddVW_1e2             3933          256  -93.49%
BenchmarkAddVW_1e3            39630         2378  -94.00%
BenchmarkAddVW_1e4           396218        23623  -94.04%
BenchmarkAddVW_1e5          3972901       238403  -94.00%
BenchmarkAddMulVVW_1             11           11   -4.27%
BenchmarkAddMulVVW_2             15           15   +0.00%
BenchmarkAddMulVVW_3             18           19   +4.37%
BenchmarkAddMulVVW_4             21           21   +4.29%
BenchmarkAddMulVVW_5             24           24   -0.82%
BenchmarkAddMulVVW_1e1           40           39   -2.70%
BenchmarkAddMulVVW_1e2          329          326   -0.91%
BenchmarkAddMulVVW_1e3         3200         3098   -3.19%
BenchmarkAddMulVVW_1e4        38457        40013   +4.05%
BenchmarkAddMulVVW_1e5       461880       428580   -7.21%
BenchmarkBitLen0                  5            5   -0.19%
BenchmarkBitLen1                  5            5   +0.00%
BenchmarkBitLen2                  5            5   -0.56%
BenchmarkBitLen3                  5            5   +0.38%
BenchmarkBitLen4                  5            5   +0.19%
BenchmarkBitLen5                  5            5   +0.56%
BenchmarkBitLen8                  5            5   -0.19%
BenchmarkBitLen9                  5            5   -0.56%
BenchmarkBitLen16                 5            5   -0.19%
BenchmarkBitLen17                 5            5   -0.37%
BenchmarkBitLen31                 5            5   -1.30%
BenchmarkBitset                  72           70   -2.49%
BenchmarkBitsetNeg             1584          396  -75.00%
BenchmarkBitsetOrig            1990         1980   -0.50%
BenchmarkBitsetNegOrig         4031         2877  -28.63%

benchmark                  old MB/s     new MB/s  speedup
BenchmarkAddVV_1             657.71      2251.28    3.42x
BenchmarkAddVV_2             730.65      3700.37    5.06x
BenchmarkAddVV_3             757.29      4754.30    6.28x
BenchmarkAddVV_4             772.95      5541.58    7.17x
BenchmarkAddVV_5             781.30      6125.59    7.84x
BenchmarkAddVV_1e1           800.33      7814.14    9.76x
BenchmarkAddVV_1e2           815.98     10129.62   12.41x
BenchmarkAddVV_1e3           818.73     10767.07   13.15x
BenchmarkAddVV_1e4           819.82     10802.12   13.18x
BenchmarkAddVV_1e5           813.14      9317.73   11.46x
BenchmarkAddVW_1            1539.56      3006.13    1.95x
BenchmarkAddVW_2            1057.66      4502.20    4.26x
BenchmarkAddVW_3             960.67      5797.65    6.04x
BenchmarkAddVW_4             913.19      6776.86    7.42x
BenchmarkAddVW_5             891.72      7467.82    8.37x
BenchmarkAddVW_1e1           850.12      9681.85   11.39x
BenchmarkAddVW_1e2           813.48     12494.27   15.36x
BenchmarkAddVW_1e3           807.45     13451.80   16.66x
BenchmarkAddVW_1e4           807.64     13545.64   16.77x
BenchmarkAddVW_1e5           805.46     13422.64   16.66x
BenchmarkAddMulVVW_1        2727.29      2847.66    1.04x
BenchmarkAddMulVVW_2        4162.30      4158.69    1.00x
BenchmarkAddMulVVW_3        5236.91      5015.98    0.96x
BenchmarkAddMulVVW_4        6090.27      5837.52    0.96x
BenchmarkAddMulVVW_5        6549.86      6598.60    1.01x
BenchmarkAddMulVVW_1e1      7850.72      8068.00    1.03x
BenchmarkAddMulVVW_1e2      9724.38      9794.40    1.01x
BenchmarkAddMulVVW_1e3      9997.18     10328.58    1.03x
BenchmarkAddMulVVW_1e4      8320.88      7997.39    0.96x
BenchmarkAddMulVVW_1e5      6928.20      7466.50    1.08x

LGTM=gri
R=golang-codereviews, dave, gri
CC=golang-codereviews
https://golang.org/cl/61290043

4 KB is a bit too small in some situations (e.g. panic during a
template execution), and ends up with an unhelpfully-truncated trace.
64 KB should be much more likely to capture the useful information.
There's not a garbage generation issue, since this code should only
be triggered when there's something seriously wrong with the program.

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

Fixes #6850.

LGTM=agl
R=golang-codereviews, agl
CC=golang-codereviews
https://golang.org/cl/60500046

for example, we now rewrite *_Ctype_int to *C.int.
Fixes #6781.

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

Missed this suggestion in CL 57680046.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/63390043

In file included from src/lib9/utf/utfecpy.c:17:0:
src/lib9/utf/utfdef.h:28:0: error: "nil" redefined [-Werror]
In file included from src/lib9/utf/utfrrune.c:17:0:
src/lib9/utf/utfdef.h:28:0: error: "nil" redefined [-Werror]

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

This change depends on CL 57170052.

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

warning: src/lib9/fmt/dorfmt.c:64 unreachable code RETURN
warning: src/lib9/fmt/fltfmt.c:184 set and not used: p
warning: src/lib9/utf/utflen.c:35 unreachable code RETURN
warning: src/lib9/utf/utfrrune.c:45 unreachable code RETURN
warning: src/lib9/utf/utfrune.c:44 unreachable code RETURN

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

Logically, the init statement is in the enclosing scopes loopdepth, not inside the for loop.

Fixes #7313.

LGTM=rsc
R=golang-codereviews, gobot, rsc
CC=golang-codereviews
https://golang.org/cl/62430043

go/build is changed to list the .m files in a package, and match them for build constraints, adding them to a new field: Package.MFiles.

The go tool is changed to support building .m files and linking in the results during CGO and SWIG builds. This means packages that create a C interface to calls Objective-C code from go are now go-gettable without producing and distributing .syso files. This change is analogous to the one in Go 1.2 made to support C++ built code.

This change doesn't support .mm files (Objective C++).

Also added support for these MFiles to go list's -json mode.

Fixes #6536.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/60590044

This change adds support for parsing and serialisation of PKCS #10,
certificate signature requests.

LGTM=agl
R=golang-codereviews, agl
CC=agl, golang-codereviews, nick
https://golang.org/cl/49830048

TextMarshaller and TextUnmarshaller to ease transport of
unlimited precision rational numbers.

Fixes #7287.

Consists of encode and decode functions and two test
functions, one using JSON and one using XML. Each
verifies round trips for integers (rationals with
denominator == 1) and for fractional vaues.

LGTM=gri
R=gri, cookieo9, bradfitz, mtj
CC=golang-codereviews
https://golang.org/cl/61180043

c:\src\go\pkg\obj\windows_amd64\libgc.a(lex.o): In function `catcher':
c:/src/go/src/cmd/gc/lex.c:181: undefined reference to `noted'

LGTM=0intro
R=0intro
CC=golang-codereviews
https://golang.org/cl/63270043

This cleans up the code significantly, and it avoids any
possible problems with madvise zeroing out some but
not all of the data.

Fixes #6400.

LGTM=dave
R=dvyukov, dave
CC=golang-codereviews
https://golang.org/cl/57680046

The issue was that one of the MSpan_Sweep callers
was doing sweep with preemption enabled.
Additional checks are added.

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

LGTM=rsc
R=rsc, jas, gobot
CC=ality, golang-codereviews
https://golang.org/cl/51650051

TestLookupHost expects that no duplicate addresses are returned. when cs is consulted for a name, e.g net!localhost!1, it will possibly return multiple available paths, e.g. via il and tcp. this confuses the tests.

LGTM=aram
R=jas, 0intro, aram
CC=golang-codereviews
https://golang.org/cl/58120045

This adds support for archives with the SCHILY.xattr field in the
pax header. This is what gnu tar and star generate.
Fixes #7154.

LGTM=dsymonds
R=golang-codereviews, gobot, dsymonds
CC=golang-codereviews
https://golang.org/cl/54570043

While we're at it, fix a wrong for statement in cmd/8g.

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

warning: src/cmd/gc/popt.c:700 format mismatch d VLONG, arg 4
warning: src/cmd/gc/popt.c:700 format mismatch d VLONG, arg 5

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

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/62960043

This seems to be what causes the 'chunk mismatch' errors.
I don't know why the server tells us there's nothing to upload,
but at the least we can warn that it did, so that the user
will try again.

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

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62890043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62880043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62870043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/62860043

copyau1 was assuming that it could deduce the type of the
middle register p->reg from the type of the left or right
argument: in CMPF F1, F2, the p->reg==2 must be a D_FREG
because p->from is F1, and in CMP R1, R2, the p->reg==2 must
be a D_REG because p->from is R1.

This heuristic fails for CMP $0, R2, which was causing copyau1
not to recognize p->reg==2 as a reference to R2, which was
keeping it from properly renaming the register use when
substituting registers.

cmd/5c has the right approach: look at the opcode p->as to
decide the kind of register. It is unclear where 5g's copyau1
came from; perhaps it was an attempt to avoid expanding 5c's
a2type to include new instructions used only by 5g.

Copy a2type from cmd/5c, expand to include additional instructions,
and make it crash the compiler if asked about an instruction
it does not understand (avoid silent bugs in the future if new
instructions are added).

Should fix current arm build breakage.

While we're here, fix the print statements dumping the pred and
succ info in the asm listing to pass an int arg to %.4ud
(Prog.pc is a vlong now, due to the liblink merge).

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/62730043

Fixes #7294.

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

New testdata was created from existing using:
$ lipo gcc-386-darwin-exec gcc-amd64-darwin-exec -create -output fat-gcc-386-amd64-darwin-exec

Fixes #7250.

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

From the description of CL 60190043

debug/macho: Add support for opening fat/universal binaries.

New testdata was created from existing using:
$ lipo gcc-386-darwin-exec gcc-amd64-darwin-exec -create -output
fat-gcc-386-amd64-darwin-exec

Update #7250

LGTM=iant
R=golang-codereviews, gobot, dsymonds, iant
CC=golang-codereviews
https://golang.org/cl/61720044

So it doesn't bitrot.

Like the sha1 version (https://golang.org/cl/62270043)

LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/62420043

State of the world:

CL 46430043 introduced a new concurrent sweep but is broken.

CL 62360043 made the new sweep non-concurrent
to try to fix the world while we understand what's wrong with
the concurrent version.

This CL fixes the non-concurrent form to run finalizers.
This CL is just a band-aid to get the build green again.

Dmitriy is working on understanding and then fixing what's
wrong with the concurrent sweep.

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/62370043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/57680047

We see failures on builders, e.g.:
http://build.golang.org/log/70bb28cd6bcf8c4f49810a011bb4337a61977bf4

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

We now use the %A, %D, %P, and %R routines from liblink
across the board.

Fixes #7178.
Fixes #7055.

LGTM=iant
R=golang-codereviews, gobot, rsc, dave, iant, remyoudompheng
CC=golang-codereviews
https://golang.org/cl/49170043