Added a lineno parameter to treecopy and listtreecopy
(ignored if = 0).  When nodes are copied the copy is
assigned the non-zero lineno (normally this would be
the destination).

Fixes #8183

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

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

We already read the address of a gcmask/gcprog out of the type data, but I
didn't know how many bytes to read. But it turns out that it's easy to
calculate, so change to do that. This means that we no longer depend on the
local symbols being present, allowing me to strip the shared libraries for
distribution and make them a lot smaller.

As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now.

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

The motivation for this is the innocuous looking test case that is added. This
creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem
comes from the fact that a function from libdep.so gets inlined all the way
into exe. This (unsurprisingly) means that the object file for exe references
symbols from libdep.so, which means that -ldep needs to be passed when linking
exe and it isn't. The fix is simply to pass it -- there is no harm in passing
it when it's not needed.

The thing is, it's not clear at all in the current code to see how the linker
can know that libdep2 is linked against libdep. It could look through the
DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it
feels better to be explicit. So this adds another SHT_NOTE section that lists
the shared libraries a shared library was linked against, and makes sure the
complete set of depended upon shared libraries is passed to the external
linker.

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

Fixes #10959.
Fixes #10960.

Change-Id: I9a81a0e2b8275338d0d1c3f7f7265e0fd91f3de2
Reviewed-on: https://go-review.googlesource.com/10402
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>

This makes for a more stable API for tools (including cmd/link itself) to
extract the abi hash from a shared library and makes it possible at all for a
library that has had the local symbol table removed.

The existing note-writing code only supports writing notes into the very start
of the object file so they are easy to find in core dumps. This doesn't apply
to the "go" notes and means that all notes have to fit into a fixed size
budget. That's annoying now we have more notes (and the next CL will add
another one) so this does a little bit of work to make adding notes that do not
have to go at the start of the file easier and moves the writing of the package
list note over to that mechanism, which lets me revert a hack that increased
the size budget mentioned above for -buildmode=shared builds.

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

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

The LSym.Section and Section.Elfsect fields were defined as interface{} but
always had the same concrete type (*Section and *ElfShdr respectively) so just
define them with that type. Reduces size of LSym from 328 to 320 bytes and
reduces best-of-10 maxresident size from 246028k to 238036k when linking
libstd.so.

Change-Id: Ie7112c53e4c2c7ce5fe233b81372aa5633f572e8
Reviewed-on: https://go-review.googlesource.com/10410Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This allows objdump to disassemble gcc generated binaries on OS X 10.6.

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

Fixes #10957

Change-Id: I75fe25133dfcebd1682a8058b1c354ec894cc997
Reviewed-on: https://go-review.googlesource.com/10384
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

At some point this code should probably move to cmd/link/internal/ld,
but at least for now just handle c-archive like c-shared.

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

- no "visible" change to spec but for updated date
- retired several outdated TODO items
- filed non-urgent issues 10953, 10954, 10955 for current TODOs

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

Add the AddressParser type to allow decoding any charset in
mail addresses.

Fixes #7079

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

The new lower-level barriers work fine and don't need special handling,
because they appear to the race detector as (visible) ordinary assignments.

Change-Id: I7477d73a3deecbebf68716580678c595cc4151e3
Reviewed-on: https://go-review.googlesource.com/10316Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

It can be useful when debugging to be able to see what the external
linker is doing even when it succeeds.  In particular this permits
passing -v to the external linker to see precisely what it is doing.

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

They will be compiled and added to the archive, just as though the
package used cgo.  In effect all SWIG packages now use cgo anyhow.

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

Fixes #10806

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

Updates #10806

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

Implement the changes from CL 10173 on OpenBSD.

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

As mentioned in
http://gitweb.dragonflybsd.org/dragonfly.git/commit/727ccde8cce813911d885b7f6ed749dcea68a886,
DragonFly BSD is dropping support for IPv6 IPv4-mapped address.
Unfortunately, on some released versions we see the kernels pretend to
support the feature but actually not (unless tweaking some kernel states
via sysctl.)

To avoid unpredictable behavior, the net package assumes that all
DragonFly BSD kernels don't support IPv6 IPv4-mapped address.

Fixes #10764.

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

Updates #10845.

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

Float.Format supports the 'b' and 'p' format, both of which print
a binary ('p') exponent. The 'b' format always printed a sign ('+'
or '-') for the exponent; the 'p' format only printed a negative
sign for the exponent. This change makes the two consistent. It
also makes the 'p' format easier to read if the exponent is >= 0.

Also:
- Comments added elsewhere.

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

Fix build error when CL=clang introduced by CL 10173.

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

Package-external tests must use the vendored math/big package, not
the original one, otherwise tests may fail if there are discrepancies
in the implementation.

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

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

This resolves the compiler part of issue #10321.

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

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

No manual code changes.

This will permit addressing the compiler aspect of issue #10321 in a
subsequent change.

Change-Id: I3376dc38cafa0ec98bf54de33293015d0183cc82
Reviewed-on: https://go-review.googlesource.com/10354Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>

- This change uses the same code as for Float32 and fixes the case
  of a number that gets rounded up to the smallest denormal.

- Enabled correspoding test case.

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

- structure the Float64 conversion tests the same way as for Float32
- add additional test cases, including one that exposes a current issue
  (currently disabled, same issue as was fixed for Float32)

The Float64 fix will be in a subsequent change for easier reviewing.

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

The existing code was incorrect for numbers that after rounding would
become the smallest denormal float32 (instead the result was 0). This
caused all.bash to fail if Float32() were used in the compiler for
constant arithmetic (there's currently a work-around - see also issue
10321.

This change fixes the implementation of Float.Float32 and adds
corresponding test cases. Float32 and Float64 diverge at this point.
For ease of review, this change only fixes Float32. Float64 will be
made to match in a subsequent change.

Fixes #10321.

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

Ian proposed an improved way of handling signals masks in Go, motivated
by a problem where the Android java runtime expects certain signals to
be blocked for all JVM threads. Discussion here

https://groups.google.com/forum/#!topic/golang-dev/_TSCkQHJt6g

Ian's text is used in the following:

A Go program always needs to have the synchronous signals enabled.
These are the signals for which _SigPanic is set in sigtable, namely
SIGSEGV, SIGBUS, SIGFPE.

A Go program that uses the os/signal package, and calls signal.Notify,
needs to have at least one thread which is not blocking that signal,
but it doesn't matter much which one.

Unix programs do not change signal mask across execve.  They inherit
signal masks across fork.  The shell uses this fact to some extent;
for example, the job control signals (SIGTTIN, SIGTTOU, SIGTSTP) are
blocked for commands run due to backquote quoting or $().

Our current position on signal masks was not thought out.  We wandered
into step by step, e.g., http://golang.org/cl/7323067 .

This CL does the following:

Introduce a new platform hook, msigsave, that saves the signal mask of
the current thread to m.sigsave.

Call msigsave from needm and newm.

In minit grab set up the signal mask from m.sigsave and unblock the
essential synchronous signals, and SIGILL, SIGTRAP, SIGPROF, SIGSTKFLT
(for systems that have it).

In unminit, restore the signal mask from m.sigsave.

The first time that os/signal.Notify is called, start a new thread whose
only purpose is to update its signal mask to make sure signals for
signal.Notify are unblocked on at least one thread.

The effect on Go programs will be that if they are invoked with some
non-synchronous signals blocked, those signals will normally be
ignored.  Previously, those signals would mostly be ignored.  A change
in behaviour will occur for programs started with any of these signals
blocked, if they receive the signal: SIGHUP, SIGINT, SIGQUIT, SIGABRT,
SIGTERM.  Previously those signals would always cause a crash (unless
using the os/signal package); with this change, they will be ignored
if the program is started with the signal blocked (and does not use
the os/signal package).

./all.bash completes successfully on linux/amd64.

OpenBSD is missing the implementation.

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

This change ensures that the test does not try to close dual stack
listeners which have not yet been opened.

Spotted in crash here
http://build.golang.org/log/e5843777df400868ce708b7f00c50dc32c2ec478

Change-Id: I79d513e166effb3e018e2b9dfc23751d92fcbe4b
Reviewed-on: https://go-review.googlesource.com/10371Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Before this change, the check for too-large arrays (and other large
types) occurred after escape analysis.  If the data moved off stack
and onto the heap contained any pointers, it would therefore escape,
but because the too-large check occurred after escape analysis this
would not be recorded and a stack pointer would leak to the heap
(see the modified escape_array.go for an example).

Some of these appear to remain, in calls to typecheck from within walk.

Also corrected a few comments in escape_array.go about "BAD"
analysis that is now done correctly.

Enhanced to move aditional EscNone-but-large-so-heap checks into esc.c.

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

Indirect function and method calls should leak everything,
but they didn't.

This fix had no particular effect on the cost of running the
compiler on html/template/*.go and added a single new "escape"
to the standard library:

    syscall/syscall_unix.go:85: &b[0] escapes to heap
in
	if errno := m.munmap(uintptr(unsafe.Pointer(&b[0])),
	                     uintptr(len(b))); errno != nil {

Added specific escape testing to escape_calls.go
(and verified that it fails without this patch)

I also did a little code cleanup around the changes in esc.c.

Fixes #10925

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

Was apparently checked in by https://go-review.googlesource.com/#/c/9253/
without being gofmt-ed.

TBR: agl

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

On Haswell I measure anywhere between 2X to 3.5X speedup for RSA.
I believe other architectures will also greatly improve.
In the future may be upgraded by dedicated assembly routine.

Built-in benchmarks i5-4278U turbo off:

benchmark                         old ns/op     new ns/op     delta
BenchmarkRSA2048Decrypt           6696649       3073769       -54.10%
Benchmark3PrimeRSA2048Decrypt     4472340       1669080       -62.68%

Change-Id: I17df84f85e34208f990665f9f90ea671695b2add
Reviewed-on: https://go-review.googlesource.com/9253Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Vlad Krasnov <vlad@cloudflare.com>
Run-TryBot: Adam Langley <agl@golang.org>

Given a call frame F of size N where the return values start at offset R,
callwritebarrier was instructing heapBitsBulkBarrier to scan the block
of memory [F+R, F+R+N). It should only scan [F+R, F+N). The extra N-R
bytes scanned might lead into the next allocated block in memory.
Because the scan was consulting the heap bitmap for type information,
scanning into the next block normally "just worked" in the sense of
not crashing.

Scanning the extra N-R bytes of memory is a problem mainly because
it causes the GC to consider pointers that might otherwise not be
considered, leading it to retain objects that should actually be freed.
This is very difficult to detect.

Luckily, juju turned up a case where the heap bitmap and the memory
were out of sync for the block immediately after the call frame, so that
heapBitsBulkBarrier saw an obvious non-pointer where it expected a
pointer, causing a loud crash.

Why is there a non-pointer in memory that the heap bitmap records as
a pointer? That is more difficult to answer. At least one way that it
could happen is that allocations containing no pointers at all do not
update the heap bitmap. So if heapBitsBulkBarrier walked out of the
current object and into a no-pointer object and consulted those bitmap
bits, it would be misled. This doesn't happen in general because all
the paths to heapBitsBulkBarrier first check for the no-pointer case.
This may or may not be what happened, but it's the only scenario
I've been able to construct.

I tried for quite a while to write a simple test for this and could not.
It does fix the juju crash, and it is clearly an improvement over the
old code.

Fixes #10844.

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

Currently adjustpointers invokes a write barrier for every stack slot
it updates. This is safe---the write barrier always does nothing
because the new value is never a heap pointer---but it's unnecessary
overhead in performance and complexity.

Fix this by rewriting adjustpointers to work with *uintptrs instead of
*unsafe.Pointers. As an added bonus, this makes the code cleaner.

name                   old mean              new mean              delta
BinaryTree17            3.35s × (0.98,1.01)   3.33s × (0.99,1.02)    ~    (p=0.095 n=20+19)
Fannkuch11              2.49s × (1.00,1.01)   2.52s × (0.99,1.01)  +1.23% (p=0.000 n=19+20)
FmtFprintfEmpty        52.2ns × (0.99,1.02)  52.2ns × (0.99,1.02)    ~    (p=0.766 n=19+19)
FmtFprintfString        181ns × (0.99,1.02)   179ns × (0.99,1.01)  -1.06% (p=0.000 n=20+19)
FmtFprintfInt           177ns × (0.99,1.01)   173ns × (0.99,1.02)  -2.26% (p=0.000 n=17+20)
FmtFprintfIntInt        300ns × (0.99,1.01)   302ns × (0.99,1.01)  +0.76% (p=0.000 n=19+20)
FmtFprintfPrefixedInt   253ns × (0.99,1.02)   256ns × (0.99,1.01)  +0.96% (p=0.000 n=20+19)
FmtFprintfFloat         334ns × (0.99,1.02)   334ns × (1.00,1.01)    ~    (p=0.243 n=20+19)
FmtManyArgs            1.16µs × (0.99,1.01)  1.17µs × (0.99,1.02)  +0.88% (p=0.000 n=20+20)
GobDecode              9.16ms × (0.99,1.02)  9.18ms × (1.00,1.00)  +0.21% (p=0.048 n=20+17)
GobEncode              7.03ms × (0.99,1.01)  7.05ms × (0.99,1.01)    ~    (p=0.091 n=19+19)
Gzip                    374ms × (0.99,1.01)   372ms × (0.99,1.02)  -0.50% (p=0.008 n=18+20)
Gunzip                 92.9ms × (0.99,1.01)  92.5ms × (1.00,1.01)  -0.47% (p=0.002 n=19+19)
HTTPClientServer       53.1µs × (0.98,1.01)  52.5µs × (0.99,1.01)  -0.98% (p=0.000 n=20+19)
JSONEncode             17.4ms × (0.99,1.02)  17.5ms × (0.99,1.01)    ~    (p=0.061 n=19+20)
JSONDecode             66.0ms × (0.99,1.02)  64.7ms × (0.99,1.01)  -1.87% (p=0.000 n=20+20)
Mandelbrot200          3.94ms × (1.00,1.01)  3.95ms × (1.00,1.01)    ~    (p=0.799 n=18+19)
GoParse                3.89ms × (0.99,1.02)  3.86ms × (0.99,1.01)  -0.70% (p=0.016 n=20+19)
RegexpMatchEasy0_32     102ns × (0.99,1.02)   102ns × (1.00,1.01)    ~    (p=0.557 n=20+18)
RegexpMatchEasy0_1K     353ns × (0.99,1.02)   341ns × (0.99,1.01)  -3.38% (p=0.000 n=20+20)
RegexpMatchEasy1_32    85.0ns × (0.99,1.02)  85.0ns × (0.99,1.01)    ~    (p=0.851 n=19+20)
RegexpMatchEasy1_1K     521ns × (0.99,1.02)   506ns × (1.00,1.01)  -2.85% (p=0.000 n=20+18)
RegexpMatchMedium_32    142ns × (0.99,1.02)   141ns × (1.00,1.01)  -1.17% (p=0.000 n=20+19)
RegexpMatchMedium_1K   42.8µs × (0.99,1.01)  42.3µs × (0.99,1.01)  -1.07% (p=0.000 n=20+19)
RegexpMatchHard_32     2.17µs × (0.99,1.01)  2.16µs × (1.00,1.01)  -0.51% (p=0.042 n=20+18)
RegexpMatchHard_1K     65.6µs × (0.99,1.01)  64.8µs × (1.00,1.00)  -1.21% (p=0.000 n=20+17)
Revcomp                 581ms × (0.99,1.04)   536ms × (1.00,1.01)  -7.71% (p=0.000 n=20+18)
Template               77.2ms × (0.99,1.01)  76.8ms × (0.99,1.01)    ~    (p=0.426 n=20+18)
TimeParse               369ns × (0.99,1.02)   371ns × (1.00,1.01)    ~    (p=0.117 n=20+19)
TimeFormat              371ns × (0.99,1.02)   391ns × (0.99,1.01)  +5.33% (p=0.000 n=20+19)

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

F3t was effectively a local variable.
Remove it.

This shrinks obj.Prog from 456 to 448 bytes,
which places it in a smaller malloc class.

This reduces the memory usage of the compiler
while compiling the rotate tests by ~2.75%.

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