| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The runtime was detecting the cycle already,
but we can give a better error without even
building the binary.
Fixes issue 7789.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/96290043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change requires using SWIG version 3.0 or later. Earlier
versions of SWIG do not generate the pragmas required to use
the external linker.
Fixes issue 7155.
Fixes issue 7156.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/97120046
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7931.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/100390044
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before we used line 1 of the first source file.
This should be clearer.
Fixes issue 4388.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/92250044
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7915.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/96210044
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most code is copy from addr2line change 01dd67e5827f
Update issue 7406
Fixes issue 7937
LGTM=iant
R=golang-codereviews, iant, 0intro
CC=golang-codereviews
https://codereview.appspot.com/95090044
|
|
|
|
|
|
|
| |
LGTM=bradfitz
R=bradfitz, 0intro
CC=golang-codereviews
https://codereview.appspot.com/95280043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a trivial change to make use of an existing `nl` byte slice
containing a single '\n' character. It's already declared and
used in another place in this file, so it might as well be used
in the other location instead of
a new slice literal. There should be no change in behavior,
aside from potentially less allocations.
This is my first CL, so I wanted to use a simple, hopefully non-controversial,
minor improvement to get more comfortable with golang contribution process.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/97280043
Committer: Brad Fitzpatrick <bradfitz@golang.org>
|
|
|
|
|
|
|
|
|
| |
LGTM=minux.ma
R=cespare, rsc, minux.ma
CC=golang-codereviews
https://codereview.appspot.com/96210043
Committer: Shenghou Ma <minux.ma@gmail.com>
|
|
|
|
|
|
|
| |
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/91250043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
list has been adding them one at a time haphazardly
(race and tags were there and documented; compiler
was there and undocumented).
clean -i needs -compiler in order to clean the
installed targets for alternate compilers.
Fixes issue 7302.
While we're here, tweak the language in the 'go get' docs
about build flags.
Fixes issue 7807.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/99130043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you write:
var x = 3
then the compiler arranges for x to be initialized in the linker
with an actual 3 from the data segment, rather than putting
x in the bss and emitting init-time "x = 3" assignment code.
If you write:
var y = x
var x = 3
then the compiler is clever and treats this the same as if
the code said 'y = 3': they both end up in the data segment
with no init-time assignments.
If you write
var y = x
var x int
then the compiler was treating this the same as if the
code said 'x = 0', making both x and y zero and avoiding
any init-time assignment.
This copying optimization to avoid init-time assignment of y
is incorrect if 'var x int' doesn't mean 'x = 0' but instead means
'x is initialized in C or assembly code'. The program ends up
with 'y = 0' instead of 'y = the value specified for x in that other code'.
Disable the propagation if there is no initializer for x.
This comes up in some uses of cgo, because cgo generates
Go globals that are initialized in accompanying C files.
Fixes issue 7665.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/93200044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the ... element type contained no pointers,
then the escape analysis did not track the ... itself.
This manifested in an escaping ...byte being treated
as non-escaping.
Fixes issue 7934.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/100310043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register allocator decides which variables should be placed into registers by charging for each load/store and crediting for each use, and then selecting an allocation with minimal cost. NOPs will be eliminated, however, so using a variable in a NOP should not generate credit.
Issue 7867 arises from attempted registerization of multi-word variables because they are used in NOPs. By not crediting for that use, they will no longer be considered for registerization.
This fix could theoretically lead to better register allocation, but NOPs are rare relative to other instructions.
Fixes issue 7867.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/94810044
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 6844.
LGTM=rsc
R=golang-codereviews, rsc
CC=golang-codereviews
https://codereview.appspot.com/97840043
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7936.
LGTM=alex.brainman, bradfitz, iant
R=golang-codereviews, alex.brainman, bradfitz, iant
CC=golang-codereviews
https://codereview.appspot.com/100060043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
benchmark old ns/op new ns/op delta
BenchmarkCopyFat512 1307 329 -74.83%
BenchmarkCopyFat256 666 169 -74.62%
BenchmarkCopyFat1024 2617 671 -74.36%
BenchmarkCopyFat128 343 89.0 -74.05%
BenchmarkCopyFat64 182 48.9 -73.13%
BenchmarkCopyFat32 103 28.8 -72.04%
BenchmarkClearFat128 102 46.6 -54.31%
BenchmarkClearFat512 344 167 -51.45%
BenchmarkClearFat64 50.5 26.5 -47.52%
BenchmarkClearFat256 147 87.2 -40.68%
BenchmarkClearFat32 22.7 16.4 -27.75%
BenchmarkClearFat1024 511 662 +29.55%
Fixes issue 7624
LGTM=rsc
R=golang-codereviews, khr, bradfitz, josharian, dave, rsc
CC=golang-codereviews
https://codereview.appspot.com/92760044
|
|
|
|
|
|
|
|
|
| |
Update issue 7947
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/100180043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7071.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/93770044
|
|
|
|
|
|
|
|
|
| |
Update issue 7899
LGTM=iant
R=golang-codereviews, rsc, iant
CC=golang-codereviews
https://codereview.appspot.com/97920044
|
|
|
|
|
|
|
|
|
|
|
| |
Where the spelling changed from British to
US norm (e.g., optimise -> optimize) it follows
the style in that file.
LGTM=adonovan
R=golang-codereviews, adonovan
CC=golang-codereviews
https://codereview.appspot.com/96980043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change allows us to give an hg tag such as "go1.3beta1" to
revisions in the main branch without breaking the build.
This is helpful for community members who want to build the beta
from source.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/90190044
|
|
|
|
|
|
|
|
|
|
|
|
| |
go test may call builder.init() multiple times which will create a new work directory. The cleanup needs to hoist the current work directory.
Fixes issue 7904.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/95900044
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
LGTM=ruiu, bradfitz
R=golang-codereviews, bradfitz, ruiu
CC=golang-codereviews
https://codereview.appspot.com/91840044
Committer: Brad Fitzpatrick <bradfitz@golang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For gccgo we rename exported functions so that the compiler
will make them visible. This CL adds a #define so that C
functions that #include "cgo_export.h" can use the expected
names of the function.
The test for this is the existing issue6833 test in
misc/cgo/test. Without this CL it fails when using
-compiler=gccgo.
LGTM=minux.ma, rsc
R=golang-codereviews, gobot, rsc, minux.ma
CC=golang-codereviews
https://codereview.appspot.com/91830046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we used strndup(3) to implement C.CString for gccgo. This
is wrong because strndup assumes the string to be null terminated,
and stops at the first null terminator. Instead, use malloc
and memmove to create a copy of the string, as we do in the
gc implementation.
LGTM=iant
R=iant
CC=golang-codereviews
https://codereview.appspot.com/96790047
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/96850043
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7829
LGTM=dave
R=golang-codereviews, aram, dave
CC=golang-codereviews
https://codereview.appspot.com/89830043
|
|
|
|
|
|
|
|
|
| |
Update issue 7829
LGTM=dave
R=golang-codereviews, dave
CC=golang-codereviews
https://codereview.appspot.com/89810043
|
|
|
|
|
|
|
|
|
|
|
| |
This should have been part of 36eb4a62fbb6,
but I later discovered that addresses are all wrong.
Appropriate test added now.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://codereview.appspot.com/89470043
|
|
|
|
|
|
|
|
|
| |
Update issue 7331
LGTM=dave, iant
R=golang-codereviews, dave, gobot, iant
CC=golang-codereviews
https://codereview.appspot.com/89520043
|
|
|
|
|
|
|
|
|
|
|
|
| |
CL 89050043 only allows -ccflags for 'go test', this
CL really handles the flag like the other -??flags.
Many thanks to Dobros?aw ?ybort for pointing this out.
Fixes issue 7810 (again).
LGTM=iant, matrixik
R=golang-codereviews, iant, matrixik
CC=golang-codereviews
https://codereview.appspot.com/89230044
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7783
LGTM=minux.ma
R=rsc, minux.ma
CC=golang-codereviews
https://codereview.appspot.com/89290043
|
|
|
|
|
|
|
|
|
| |
Fixes issue 6973
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://codereview.appspot.com/88820043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
following on CL https://codereview.appspot.com/76810045 and
issue 7563, i now see there's another "remove(outfile)" a few
dozen lines down that also needs fixing.
LGTM=iant
R=golang-codereviews, iant
CC=0intro, golang-codereviews, r
https://codereview.appspot.com/89030043
Committer: Ian Lance Taylor <iant@golang.org>
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7810.
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/89050043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to use ./ imports on Windows but it
requires some extra command-line work
('go build' does this automatically, but we can't use 'go build' here).
Instead, use an ordinary import and -I/-L, which are easier to use.
LGTM=iant
R=iant
CC=golang-codereviews
https://codereview.appspot.com/89040043
|
|
|
|
|
|
|
| |
LGTM=rsc, bradfitz
R=golang-codereviews, rsc, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/88170049
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7800.
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/87790051
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Variables declared with 'var' have no sym->def.
Fixes issue 7794.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/88360043
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 7675
LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/85040044
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the switch to liblink, the linkers accepted the -c flag
to print the call graph. This change restores the functionality.
This came in handy when I was trying to audit the use of SSE
instructions inside the Plan 9 note handler.
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/73990043
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.appspot.com/60590044 edited
doc.go without editing the file it is generated from.
The edit was lost at the next mkdoc.sh.
Make the change in help.go and rerun mkdoc.sh.
Pointed out in the review of CL 68580043.
TBR=iant
CC=golang-codereviews
https://codereview.appspot.com/88760043
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue 6936
LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://codereview.appspot.com/87770048
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- output absolute addresses, not relative;
- accept negative section numbers.
Update issue 6936
Fixes issue 7738
LGTM=rsc
R=golang-codereviews, bradfitz, ruiu, rsc
CC=golang-codereviews
https://codereview.appspot.com/85240046
Committer: Russ Cox <rsc@golang.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new code is adapted from the Go 1.2 nosplit code,
but it does not have the bug reported in issue 7623:
g% go run nosplit.go
g% go1.2 run nosplit.go
BUG
rejected incorrectly:
main 0 call f; f 120
linker output:
# _/tmp/go-test-nosplit021064539
main.main: nosplit stack overflow
120 guaranteed after split check in main.main
112 on entry to main.f
-8 after main.f uses 120
g%
Fixes issue 6931.
Fixes issue 7623.
LGTM=iant
R=golang-codereviews, iant, ality
CC=golang-codereviews, r
https://codereview.appspot.com/88190043
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The name linkwriteobj is misleading because it implies that
the function has something to do with the linker, which it
does not. The name is historical: the function performs an
operation that was previously performed by the linker, but no
longer is.
LGTM=rsc
R=rsc, minux.ma
CC=golang-codereviews
https://codereview.appspot.com/88210045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without the leaf bit, the linker cannot record
the correct frame size in the symbol table, and
then stack traces get mangled. (Only for ARM.)
Fixes issue 7338.
Fixes issue 7347.
LGTM=iant
R=iant
CC=golang-codereviews
https://codereview.appspot.com/88550043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In large functions with many variables, the register optimizer
may give up and choose not to track certain variables at all.
In this case, the "nextinnode" information linking together
all the words from a given variable will be incomplete, and
the result may be that only some of a multiword value is
preserved across a call. That confuses the garbage collector,
so don't do that. Instead, mark those variables as having
their address taken, so that they will be preserved at all
calls. It's overkill, but correct.
Tested by hand using the 6g -S output to see that it does fix
the buggy generated code leading to the issue 7726 failure.
There is no automated test because I managed to break the
compiler while writing a test (see issue 7727). I will check
in a test along with the fix to issue 7727.
Fixes issue 7726.
LGTM=khr
R=khr, bradfitz, dave
CC=golang-codereviews
https://codereview.appspot.com/85200043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
linklookup uses hash(name, v) as the hash table index but then
only compares name to find a symbol to return.
If hash(name, v1) == hash(name, v2) for v1 != v2, the lookup
for v2 will return the symbol with v1.
The input routines assume that each symbol is found only once,
and then each symbol is added to a linked list, with the list header
in the symbol. Adding a symbol to such a list multiple times
short-circuits the list the second time it is added, causing symbols
to be dropped.
The liblink rewrite introduced an elegant, if inefficient, handling
of duplicated symbols by creating a dummy symbol to read the
duplicate into. The dummy symbols are named .dup with
sequential version numbers. With many .dup symbols, eventually
there will be a conflict, causing a duplicate list add, causing elided
symbols, causing a crash when calling one of the elided symbols.
The bug is old (2011) but could not have manifested until the
liblink rewrite introduced this heavily duplicated symbol .dup.
(See History section below.)
1. Correct the lookup function.
2. Since we want all the .dup symbols to be different, there's no
point in inserting them into the table. Call linknewsym directly,
avoiding the lookup function entirely.
3. Since nothing can refer to the .dup symbols, do not bother
adding them to the list of functions (textp) at all.
4. In lieu of a unit test, introduce additional consistency checks to
detect adding a symbol to a list multiple times. This would have
caught the short-circuit more directly, and it will detect a variety
of double-use bugs, including the one arising from the bad lookup.
Fixes issue 7749.
History
On April 9, 2011, I submitted CL 4383047, making ld 25% faster.
Much of the focus was on the hash table lookup function, and
one of the changes was to remove the s->version == v comparison [1].
I don't know if this was a simple editing error or if I reasoned that
same name but different v would yield a different hash slot and
so the name test alone sufficed. It is tempting to claim the former,
but it was probably the latter.
Because the hash is an iterated multiply+add, the version ends up
adding v*3? to the hash, where n is the length of the name.
A collision would need x*3? ? y*3? (mod 2?? mod 100003),
or equivalently x*3? ? x*3? + (y-x)*3? (mod 2?? mod 100003),
so collisions will actually be periodic: versions x and y collide
when d = y-x satisfies d*3? ? 0 (mod 2?? mod 100003).
Since we allocate version numbers sequentially, this is actually
about the best case one could imagine: the collision rate is
much lower than if the hash were more random.
http://play.golang.org/p/TScD41c_hA computes the collision
period for various name lengths.
The most common symbol in the new linker is .dup, and for n=4
the period is maximized: the 100004th symbol is the first collision.
Unfortunately, there are programs with more duplicated symbols
than that.
In Go 1.2 and before, duplicate symbols were handled without
creating a dummy symbol, so this particular case for generating
many duplicate symbols could not happen. Go does not use
versioned symbols. Only C does; each input file gives a different
version to its static declarations. There just aren't enough C files
for this to come up in that context.
So the bug is old but the realization of the bug is new.
[1] https://codereview.appspot.com/4383047/diff/5001/src/cmd/ld/lib.c
LGTM=minux.ma, iant, dave
R=golang-codereviews, minux.ma, bradfitz, iant, dave
CC=golang-codereviews, r
https://codereview.appspot.com/87910047
|