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

The new testdata was created by:

convert video-001.png -colorspace cmyk video-001.cmyk.jpeg

video-001.cmyk.jpeg was then converted back to video-001.cmyk.png via
the GIMP. ImageMagick (convert) wasn't used for this second conversion
because IM's default color profiles complicates things.

Fixes #4500.

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

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

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

Change 85e7bee1 introduced a bug:
it marks map buckets as noscan when key and val do not contain pointers.
However, buckets with large/outline key or val do contain pointers.

This change takes key/val size into consideration when
marking buckets as noscan.

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

Some rounding modes are affected by the sign of the value to
be rounded. Make sure the sign is set before round is called.
Added tests (that failed before the fix).

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

e.g. ·Name instead of package·Name for automatic stack map to
be applied from its Go prototype.

The underlying reason is that liblink look up name with suffix
".args_stackmap" for the stackmap coming from its Go prototype,
but all the Go functions are named "".Name as this stage. Thus
an assembly function named package·Name will never find its
stackmap, which is named "".package.Name.args_stackmap.

Perhaps cmd/vet should give a warning for this.

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

Fixes #9824.

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

This is an update of http://golang.org/cl/151410043 by Tim Shen.

Change-Id: I43ab7fcedd785059c535f45a3c8cdb7b618c1499
Reviewed-on: https://go-review.googlesource.com/4873Reviewed-by: David Crawshaw <crawshaw@golang.org>

TBR r, adonovan

Change-Id: I1a38e2d724bf1147c7307a7e5ae855c42c60428c
Reviewed-on: https://go-review.googlesource.com/4875Reviewed-by: Robert Griesemer <gri@golang.org>

TBR adonovan

Change-Id: I842cbc855dbd560f65e76c9a557dff1a22c5d610
Reviewed-on: https://go-review.googlesource.com/4882Reviewed-by: Robert Griesemer <gri@golang.org>

TBR adonovan

Change-Id: I4fd694101c2cf1c0c39bf73d16cab18502742dd9
Reviewed-on: https://go-review.googlesource.com/4881Reviewed-by: Robert Griesemer <gri@golang.org>

TBR adonovan

Change-Id: I30020f39be9183b37275e10a4fd1e1a3b4c48c89
Reviewed-on: https://go-review.googlesource.com/4880Reviewed-by: Robert Griesemer <gri@golang.org>

Also: remove NewFloat - not needed anymore. Work-around for places
where has been used so far:

NewFloat(x, prec, mode) === new(Float).SetMode(mode).SetPrec(prec).SetFloat64(x)

However, if mode == ToNearestEven, SetMode is not needed. SetPrec
is needed if the default precision (53 after SetFloat64) is not
adequate.

TBR adonovan

Change-Id: Ifda12c479ba157f2dea306c32b47c7afbf31e759
Reviewed-on: https://go-review.googlesource.com/4842Reviewed-by: Robert Griesemer <gri@golang.org>

Also:
- make representation more flexible (no need to store trailing 0 digits to match precision)
- simplify rounding as a consequence
- minor related fixes

TBR adonovan

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

TBR adonovan

Change-Id: If77afa6474af6cad6512f6866725e3ae5acf2e3f
Reviewed-on: https://go-review.googlesource.com/4840Reviewed-by: Robert Griesemer <gri@golang.org>

Per the comment at top, this test is about whether the GC runs during
init, but it was testing more than that, and testing how much the GC
collected in a certain amount of time.

Instead, loosen this test to just see whether it ran at all and not
how well it did.

Fixes #9848

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

In CL 4050, NULL was used instead of nil.
However, Plan 9 doesn't declare NULL.

Change-Id: I8295a3102509a1ce417278f23a37cbf65938cce1
Reviewed-on: https://go-review.googlesource.com/4814Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Android apps build again.

Defining TLSG in runtime/tls_arm.s gives it the type SNOPTRBSS, so its
type was never being set when GOOS=android. I considered modifying the
if statement, but I no longer understand the intention of the original
change (in d738c6b0). We were always setting it before, what
platform is this not valid for?

Fixes #9829

Change-Id: I3eaa4a9590893eff67695797eb22547a170cdbcd
Reviewed-on: https://go-review.googlesource.com/4834Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>

--preserve flag is not a valid flag for some versions of cp.

Change-Id: I57f5bf21cbe726057fdadcd55b040ef7ff5d7479
Reviewed-on: https://go-review.googlesource.com/4835Reviewed-by: David Crawshaw <crawshaw@golang.org>

Fixes #9802.

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

Make cmd/ld a real library invoked by the individual linkers.
There are no reverse symbol references anymore
(symbols referred to in cmd/ld but defined in cmd/5l etc).

This means that in principle we could do an automatic
conversion of these to Go, as a stopgap until cmd/link is done
or as a replacement for cmd/link.

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

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

- remove a few uses of ? :
- rename variables named len
- rewrite a few gotos as nested switches
- move goto targets to scope allowed by Go
- use consistent return type of anyregalloc
  (was int or int32 in different places)
- remove unused nr variable in agen
- include proper headers in generated builtin1.c
- avoid strange sized %E formats (%-6E, %2E)
- change gengcmask argument from uint8[16] to uint8*
  (diagnosed by c2go; not an array in any real sense).
- replace #ifdef XXX with comment block in 5g/peep.c
- expand and remove FAIL macro from 5g
- expand and remove noimpl macro from 9g
- print regalloc errors to stdout in 8g
  (only use of fprint(2, ...) in all compilers)

Still producing bit-for-bit identical output.

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

In mparith, all the a1-- are problematic. Rewrite it all without pointers.
It's clearer anyway.

In popt, v is problematic because it is used both as a fixed pointer
(v = byvar[i]) and as a moving pointer (v = var; v++) aka slice.
Eliminate pointer movement.

Tested that this still produces bit-for-bit output for 'go build -a std'
compared to d260756 (current master).

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

Otherwise the exported variable collides with the type Arch.

While we're here, remove arch.dumpit (now in portable code)
and add arch.defframe (forgotten originally, somehow).

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

If the Go source says x.y, and x is undefined, today we get

	undefined: x

Change to:

	undefined: x in x.y

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

Even with debugmerge = 1, the debugging output only happens
with the -v command-line flag. This is useful because it gets added
in automatically when debugging things like registerization with -R -v.

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

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

Noticed last week.
Just saw a strange build failure in the revised rcmp (called by qsort on region)
and this fixed it.

Submitting first to avoid finding out which of my pending CLs tickled the
problem.

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

When the compiler echoes back an expression, it shows the
generated yacc expression. Change the generated code to
use a slice so that $3 shows up as yyDollar[3] in such messages.

Consider changing testdata/expr/expr.y to say:

	$$.Sub(float64($1), $3)

(The float64 conversion is incorrect.)

Before:
expr.y:70[expr.go:486]: cannot convert exprS[exprpt - 2].num (type *big.Rat) to type float64

After:
expr.y:70[expr.go:492]: cannot convert exprDollar[1].num (type *big.Rat) to type float64

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

The current XML printer does not understand the xmlns
attribute. This change changes it so that it interprets the
xmlns attributes in the tokens being printed, and uses
appropriate prefixes.

Fixes #7535.

Change-Id: I20fae291d20602d37deb41ed42fab4c9a50ec85d
Reviewed-on: https://go-review.googlesource.com/2660Reviewed-by: Nigel Tao <nigeltao@golang.org>

MOVQ RARG0, 0(SP) smashes exactly what was saved by PUSHQ R15.
This code managed to work somehow with the current race runtime,
but corrupts caller arguments with new race runtime that I am testing.

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

New race runtime is more scrupulous about env flags format.

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

drainworkbuf is now gcDrain, since it drains until there's
nothing left to drain.  drainobjects is now gcDrainN because it's
the bounded equivalent to gcDrain.

The new names use the Go camel case convention because we have to
start somewhere.  The "gc" prefix is because we don't have runtime
packages yet and just "drain" is too ambiguous.

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

All calls to drainworkbuf now pass true for this argument, so remove
the argument and update the documentation to reflect the simplified
interface.

At a higher level, there are no longer any situations where we drain
"one wbuf" (though drainworkbuf didn't guarantee this anyway).  We
either drain everything, or we drain a specific number of objects.

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

scanblock is only called during _GCscan and _GCmarktermination.
During _GCscan, scanblock didn't call drainworkbufs anyway.  During
_GCmarktermination, there's really no point in draining some (largely
arbitrary) amount of work during the scanblock, since the GC is about
to drain everything anyway, so simply eliminate this case.

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

We no longer ever call scanblock with b == 0.

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

scanblock(0, 0, nil, nil) was just a confusing way of saying

  wbuf = getpartialorempty()
  drainworkbuf(wbuf, true)

Make drainworkbuf accept a nil workbuf and perform the
getpartialorempty itself and replace all uses of scanblock(0, 0, nil,
nil) with direct calls to drainworkbuf(nil, true).

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

Previously, scanblock called checknocurrentwbuf() after
drainworkbuf().  Move this call into drainworkbuf so that every return
path from drainworkbuf calls checknocurrentwbuf().  This is equivalent
to the previous code because scanblock was the only caller of
drainworkbuf.

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