This makes it cheaper to copy string literals.
This happens just about anywhere that they are used.

Example:

func f() string {
	return "f"
}

Using 6g, compiler output before:

"".f t=1 size=32 value=0 args=0x10 locals=0x0
	0x0000 00000 (p.go:3)	TEXT	"".f+0(SB),4,$0-16
	0x0000 00000 (p.go:3)	FUNCDATA	$0,gclocals·d64e51a4c4bfeaa840e480961ec6b0b3+0(SB)
	0x0000 00000 (p.go:3)	FUNCDATA	$1,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
	0x0000 00000 (p.go:4)	LEAQ	go.string."f"+0(SB),BX
	0x0007 00007 (p.go:4)	MOVQ	(BX),BP
	0x000a 00010 (p.go:4)	MOVQ	BP,"".~r0+8(FP)
	0x000f 00015 (p.go:4)	MOVQ	8(BX),BP
	0x0013 00019 (p.go:4)	MOVQ	BP,"".~r0+16(FP)
	0x0018 00024 (p.go:4)	RET	,

After:

"".f t=1 size=32 value=0 args=0x10 locals=0x0
	0x0000 00000 (p.go:3)	TEXT	"".f+0(SB),4,$0-16
	0x0000 00000 (p.go:3)	FUNCDATA	$0,gclocals·d64e51a4c4bfeaa840e480961ec6b0b3+0(SB)
	0x0000 00000 (p.go:3)	FUNCDATA	$1,gclocals·3280bececceccd33cb74587feedb1f9f+0(SB)
	0x0000 00000 (p.go:4)	MOVQ	$go.string."f"+16(SB),BX
	0x0007 00007 (p.go:4)	MOVQ	BX,"".~r0+8(FP)
	0x000c 00012 (p.go:4)	MOVQ	$1,"".~r0+16(FP)
	0x0015 00021 (p.go:4)	RET	,

The leading MOVQ here will be converted into a LEAQ by the linker,
but there is still a net reduction of two MOVQs.

Before:

TEXT main.f(SB)
        p.go:4  0x2000  488d1d49500500  LEAQ 0x55049(IP), BX
        p.go:4  0x2007  488b2b          MOVQ 0(BX), BP
        p.go:4  0x200a  48896c2408      MOVQ BP, 0x8(SP)
        p.go:4  0x200f  488b6b08        MOVQ 0x8(BX), BP
        p.go:4  0x2013  48896c2410      MOVQ BP, 0x10(SP)
        p.go:4  0x2018  c3              RET

After:

TEXT main.f(SB)
        p.go:4  0x2000  488d1dd94c0500          LEAQ 0x54cd9(IP), BX
        p.go:4  0x2007  48895c2408              MOVQ BX, 0x8(SP)
        p.go:4  0x200c  48c744241001000000      MOVQ $0x1, 0x10(SP)
        p.go:4  0x2015  c3                      RET

The performance improvement is small but widespread.

As a nice small example, net/url's sole benchmark using 6g:

benchmark           old ns/op     new ns/op     delta
BenchmarkString     16372         16118         -1.55%

And with 8g:

benchmark           old ns/op     new ns/op     delta
BenchmarkString     22034         21709         -1.47%

Change-Id: I4ce202ee7dbd4057be869e2faaaa638c28a1fff0
Reviewed-on: https://go-review.googlesource.com/2587Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>

This change provides a convenient way to monitor database connection pool.

Change-Id: I4b3757855b43f3b254acf9312e2a16e2f87840d0
Reviewed-on: https://go-review.googlesource.com/7950
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

This CL is an amagamation of several fixes Canonical have made on their
fork of the cmd/go tool (packaged as gccgo-go.deb on Ubuntu 14.04+).

Additionally this CL brings gccgoToolchain.ldi() up to date with the version
that will ship in gccgo-5.0. As gccgo is most likely to be used with its
own version of the go tool that it supples it makes good sense that the libgo
version should dictate the contents of gccgotoolchain.ld()

Please see https://codereview.appspot.com/222890043/ for more details on the
issues fixed.

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

Currently, scanner uses -1 to represent 2 different states:

1. I haven't yet scanned anything, call it "Beginning of File"
2. I've reached the end of the input, ie EOF

The result of this behavior is that calling Peek() when next()
has detected the end of the input and set s.ch to scanner.EOF,
is that Peek() things "oh, s.ch is < 0, which to me means that
I haven't scanned any next yet, let me try and clear the BOM
marker."

When this behavior is run on a typical IO, next() will issue
a Read and get (0, io.EOF) back for the second time without
blocking and Peek() will return scanner.EOF.

The bug comes into play when, inside a terminal, hitting Control-D.
This causes the terminal to return a EOF condition to the reader
but it does not actually close the fd.

So, combining these 2 situations, we arrive at the bug:

What is expected: hitting Control-D in a terminal will make Peek()
return scanner.EOF instantly.

What actually happens:

0. Code waiting in Next()
1. User hits Control-D
2. fd returns EOF condition
3. EOF bubbles it's way out to line 249 in scanner.go
4. next() returns scanner.EOF
5. Next() saves the scanner.EOF to s.ch and returns the previous value
6. Peek() runs, sees s.ch < 0, mistakenly thinks it hasn't run yet and
   tries to read the BOM marker.
7. next() sees the buffer is empty and tries to fill it again, blocking
   on line 249.

The fix is simple: use a different code to indicate that no data
has been scanned.

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

The tests in the basic string section are now covering more code paths
for encoding a string into the hexadecimal representation of its bytes.

Changed the basic string and basic bytes tests so that they mirror each other.

Change-Id: Ib5dc7b33876769965f9aba2ac270040abc4b2451
Reviewed-on: https://go-review.googlesource.com/2611Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

This change adds socket system call hooks to existing test cases for
simulating a bit complicated network conditions to help making timeout
and dual IP stack test cases work more properly in followup changes.

Also test cases print debugging information in non-short mode like the
following:

Leaked goroutines:
net.TestWriteTimeout.func2(0xc20802a5a0, 0xc20801d000, 0x1000, 0x1000, 0xc2081d2ae0)
	/go/src/net/timeout_test.go:170 +0x98
created by net.TestWriteTimeout
	/go/src/net/timeout_test.go:173 +0x745
net.runDatagramPacketConnServer(0xc2080730e0, 0x2bd270, 0x3, 0x2c1770, 0xb, 0xc2081d2ba0, 0xc2081d2c00)
	/go/src/net/server_test.go:398 +0x667
created by net.TestTimeoutUDP
	/go/src/net/timeout_test.go:247 +0xc9
	(snip)

Leaked sockets:
3: {Cookie:615726511685632 Err:<nil> SocketErr:0}
5: {Cookie:7934075906097152 Err:<nil> SocketErr:0}

Socket statistical information:
{Family:1 Type:805306370 Protocol:0 Opened:17 Accepted:0 Connected:5 Closed:17}
{Family:2 Type:805306369 Protocol:0 Opened:450 Accepted:234 Connected:279 Closed:636}
{Family:1 Type:805306369 Protocol:0 Opened:11 Accepted:5 Connected:5 Closed:16}
{Family:28 Type:805306369 Protocol:0 Opened:95 Accepted:22 Connected:16 Closed:116}
{Family:2 Type:805306370 Protocol:0 Opened:84 Accepted:0 Connected:34 Closed:83}
{Family:28 Type:805306370 Protocol:0 Opened:52 Accepted:0 Connected:4 Closed:52}

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

NaNs make the API more complicated for no real good reasons.
There are few operations that produce NaNs with IEEE arithmetic,
there's no need to copy the behavior. It's easy to test for these
scenarios and avoid them (on the other hand, it's not easy to test
for overflow or underflow, so we want to keep +/-Inf).

Also:
- renamed IsNeg -> Signbit (clearer, especially for x == -0)
- removed IsZero           (Sign() == 0 is sufficient and efficient)
- removed IsFinite         (now same as !IsInf)

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

In preparation for being able to run a go program that has code
in several objects, this changes from having several linker
symbols used by the runtime into having one linker symbol that
points at a structure containing the needed data.  Multiple
object support will construct a linked list of such structures.

A follow up will initialize the slices in the themoduledata
structure directly from the linker but I was aiming for a minimal
diff for now.

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

Relying on an importing package being linked at the same time as the
imported package does not work in the shared library world.

This also lets us remove some obscure code from the linker.

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

- fix bounds checks for exponent range of denormalized numbers
- use correct rounding precision for denormalized numbers
- added extra tests

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

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

cl8167 introduced internal/syscall/windows.GetVersion, but we already
have that function in syscall.GetVersion. Use that instead.
Also revert all internal/syscall/windows cl8167 changes.

Change-Id: I512a5bf4b3b696e93aaf69e9e8b7df7022670ec0
Reviewed-on: https://go-review.googlesource.com/8302Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Minux Ma <minux@golang.org>

Currently, gcDrainN is documented saying that it must be run on the
system stack. In fact, the problem and solution here are somewhat
subtler. First, it doesn't have to happen on the system stack, it just
has to be non-stoppable (that is, non-preemptible). Second, this isn't
specific to gcDrainN (though gcDrainN is perhaps the most surprising
instance); it's general to anything that uses the gcWork structure.

Move the comment to gcWork and generalize it.

Change-Id: I5277b5abb070e47f8d783bc15a310b379c6adc22
Reviewed-on: https://go-review.googlesource.com/8247Reviewed-by: Rick Hudson <rlh@golang.org>

gcDrain used to be passed a *workbuf to start draining from, but now
it takes a gcWork, which hides whether or not there's an initial
workbuf. Update the comment to match this.

Change-Id: I976b58e5bfebc451cfd4fa75e770113067b5cc07
Reviewed-on: https://go-review.googlesource.com/8246Reviewed-by: Rick Hudson <rlh@golang.org>

The strings.Trim function and variants allocate memory on the heap when creating a function to pass into TrimFunc.
Add a benchmark to document the behavior; an issue will be submitted to address this behavior in the compiler if possible.

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

Being able to printer pointers to strings means one will able to output
the result of things like the flag library and other components that use
string pointers.

While here, adjusted the tests for gdb to test original string pretty
printing as well as pointers to them. It was doing it via the map before
but for completeness this ensures it's tested as a unit.

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

A residue of the automatic translation, this closure is easily rewritten
to a simpler, smaller, and faster construct.

Discovered while analyzing #10269, which I still plan to fix.

Change-Id: I76b12290280d81880c446b4cf75da633a94482d4
Reviewed-on: https://go-review.googlesource.com/8270Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Minux Ma <minux@golang.org>

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

runtime·main·f is normalized by the linker to runtime.main.f, as is
the compiler-generated symbol runtime.main·f.  Change the former to
runtime·mainPC instead.

Fixes issue #9934

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

For shared libraries we need to be more flexible in how these symbols
are handled (e.g. sometimes tlsg needs to be global, or you can get
a SDYNIMPORT symbol that has .Hide == true) so handling these cases
in genasmsym makes everything much more regular.

Even ignoring shared libraries, I think this is a bit cleaner.

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

After moving the darwin/arm builder to new hardware several new flaky
error messages appeared. This provided enough information to Google
to make it clear that iOS build systems have been flaky for many
years, and that is unlikely to change any time soon.

However, all of the pain of lldb and using a breakpoint early in
program initialization gives us an advantage: all install and
initialization flakiness appears to happen before the Go program ever
gets going. So if we see an error or we timeout before we reach our
breakpoint (before any test code has executed), we can assume it is
the fault of the builder and restart without risking hiding a flaky
Go test.

This code has successfully processed the last 8 builds. I am hopeful.

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

In the spirit of nacltest.bash and androidtest.bash. Sets up the
exec script and reboots the device.

The reboot helps make sure previous runs do not interfere with the
current run. It is reasonably easy for a bad program, e.g. one with
a corrupt stack, to get the device stuck.

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

Change-Id: Icbc42bcff5a3eabe9f43cff7fcc126141e209ded
Reviewed-on: https://go-review.googlesource.com/8203Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Extend escape analysis to convT2E and conT2I. If the interface value
does not escape supply runtime with a stack buffer for the object copy.

This is a straight port from .c to .go of Dmitry's patch

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

Windows XP SP2 and Windows 2003 do not support SHA2.

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

Currently, various functions are marked with the comment

  // May run without a P, so write barriers are not allowed.

However, "running without a P" is ambiguous. We intended these to mean
that m.p may be nil (which is the condition checked by the write
barrier). The comment could also be taken to mean that a
stop-the-world may happen, which is not the case for these functions
because they run in situations where there is in fact a function on
the stack holding a P locally, it just isn't in m.p.

Change these comments to state precisely what we mean, that m.p may be
nil.

Change-Id: I4a4a1d26aebd455e5067540e13b9f96a7482146c
Reviewed-on: https://go-review.googlesource.com/8209Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

Change-Id: Id82c3111d7571263208ced3d011ad80f3fe55984
Reviewed-on: https://go-review.googlesource.com/7892Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

False positives (var incorrectly escapes) are marked with BAD.

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

The previous wording implied that reads would return no error, rather
than EOF. It's convenient for users to know that Close() is equivalent
to CloseWithError(nil) because it can remove a branch from their error
handling code where they want to close the pipe in the appropriate way.
For example:

    https://github.com/jacobsa/gcloud/blob/6e9a8cec0a3f0834da3e9c9725dfe0bf79cccebb/gcs/bucket.go#L637-L643

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

Don't test so much at once.

Fixes #10278

Change-Id: I32a9cb81a3cffecc7ce4f83c35a4b589bcd3a9f7
Reviewed-on: https://go-review.googlesource.com/8213Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

When Windows Error Reporting dialog is disabled on amd64
Windows XP or 2003, the continue handler does not fire. Newer
versions work correctly regardless of WER.

Fixes #10162

Change-Id: I84ea36ee188b34d1421a8db6231223cf61b4111b
Reviewed-on: https://go-review.googlesource.com/8165Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

rp.Close happened concurrently with rp.Read. Order them.

Fixes #10280

Change-Id: I7b083bcc336d15396c4e42fc4654ba34fad4a4cc
Reviewed-on: https://go-review.googlesource.com/8211Reviewed-by: Dave Cheney <dave@cheney.net>

The false positives (var incorrectly escapes) are marked with BAD.

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

10 false positives (var incorrectly escapes to heap) are marked with BAD.

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

Fix build after http://golang.org/cl/5297
The compiler was changed to not print implicit map capacity in error messages.

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

The false positive (var incorrectly escapes to heap) is marked with BAD.

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

False positives (var incorrectly escapes) are marked with BAD.

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

False positives (var incorrectly escapes) are marked with BAD.

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

False positives (var incorrectly escapes) are marked with BAD.

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

False positives (var incorrectly escapes) are marked with BAD.

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