Joe Tsai [Thu, 24 Aug 2017 06:44:33 +0000 (23:44 -0700)]
archive/tar: support arbitrary PAX records
This CL adds the following new publicly visible API:
type Header struct { ...; PAXRecords map[string]string }
The new Header.PAXRecords field is a map of all PAX extended header records.
We suggest (but do not enforce) that users use VENDOR-prefixed keys
according to the following in the PAX specification:
<<<
The standard developers have reserved keyword name space for vendor extensions.
It is suggested that the format to be used is:
VENDOR.keyword
where VENDOR is the name of the vendor or organization in all uppercase letters.
>>>
When reading, the Header.PAXRecords is populated with all PAX records
encountered so far, including basic ones (e.g., "path", "mtime", etc).
When writing, the fields of Header will be merged into PAXRecords,
overwriting any records that may conflict.
Since PAXRecords is a more expressive feature than Xattrs and
is entirely a superset of Xattrs, we mark Xattrs as deprecated,
and steer users towards the new PAXRecords API.
The issue has a discussion about adding a Header.SetPAXRecord method
to help validate records and keep the Header fields in sync.
However, we do not include that in this CL since that helper
method can always be added in the future.
There is no support for global records.
Fixes #14472
Change-Id: If285a52749acc733476cf75a2c7ad15bc1542071
Reviewed-on: https://go-review.googlesource.com/58390
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tom Levy [Tue, 22 Aug 2017 05:10:46 +0000 (17:10 +1200)]
sort: fix mix-up between "!less" and "greater" in examples
If Less(a, b) returns true when a is less than b, the correct way to
check if a is greater than b is to use Less(b, a). It is wrong to use
!Less(a, b) because that checks if a is greater than *or equal to* b.
1. The decreasingDistance function in Example_sortKeys makes this
mistake. Fix it.
2. The documentation of multiSorter.Less says it loops along the less
functions until it finds a comparison "that is either Less or
!Less". This is nonsense, because (Less(a, b) or !Less(a, b)) is
always true. Fix the documentation to say that it finds a
comparison "that discriminates between the two items (one is less
than the other)". The implementation already does this correctly.
Change-Id: If52b79f68e4fdb0d1095edf29bdecdf154a61b8d
Reviewed-on: https://go-review.googlesource.com/57752 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Heschi Kreinick [Fri, 25 Aug 2017 16:27:15 +0000 (12:27 -0400)]
cmd/compile: bug fixes for DWARF location lists
Fix two small but serious bugs in the DWARF location list code that
should have been caught by the automated tests I didn't write.
After emitting debug information for a user variable, mark it as done
so that it doesn't get emitted again. Otherwise it would be written once
per slot it was decomposed into.
Correct a merge error in CL 44350: the location list abbreviations need
to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish.
jaredculp [Thu, 10 Aug 2017 21:00:59 +0000 (17:00 -0400)]
math: add examples for trig functions
Change-Id: Ic3ce2f3c055f2636ec8fc9cec8592e596b18dc05
Reviewed-on: https://go-review.googlesource.com/54771
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
griesemer [Mon, 21 Aug 2017 13:47:51 +0000 (15:47 +0200)]
spec: explicitly define notion of "representability" (clarification)
Throughout the spec we use the notion of a constant x being
representable by a value of type T. While intuitively clear,
at least for floating-point and complex constants types, the
concept was not well-defined. In the section on Conversions
there was an extra rule for floating-point types only and it
missed the case of floating-point values overflowing to an
infinity after rounding.
Since the concept is important to Go, and a compiler most
certainly will have a function to test "representability",
it seems warranted to define the term explicitly in the spec.
This change introduces a new entry "Representability" under
the section on "Properties of types and values", and defines
the term explicitly, together with examples.
The phrase used is "representable by" rather than "representable as"
because the former use is prevalent in the spec.
Additionally, it clarifies that a floating-point constant
that overflows to an infinity after rounding is never
representable by a value of a floating-point type, even though
infinities are valid values of IEEE floating point types.
This is required because there are not infinite value constants
in the language (like there is also no -0.0) and representability
also matters for constant conversions. This is not a language
change, and type-checkers have been following this rule before.
The change also introduces links throughout the spec to the new
section as appropriate and removes duplicate text and examples
elsewhere (Constants and Conversions sections), leading to
simplifications in the relevant paragraphs.
Fixes #15389.
Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
Reviewed-on: https://go-review.googlesource.com/57530 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
runtime: optimize storing new keys in mapassign_fastNN
Prior to this change, we use typedmemmove to write the key
value to its new location in mapassign_fast32 and mapassign_fast64.
(The use of typedmemmove was a last-minute fix in the 1.9 cycle;
see #21297 and CL 53414.)
This is significantly less inefficient than direct assignment or
calling writebarrierptr directly.
Fortunately, there aren't many cases to consider.
On systems with 32 bit pointers:
* A 32 bit AMEM value either is a single pointer or has no pointers.
* A 64 bit AMEM value may contain a pointer at the beginning,
a pointer at 32 bits, or two pointers.
On systems with 64 bit pointers:
* A 32 bit AMEM value contains no pointers.
* A 64 bit AMEM value either is a single pointer or has no pointers.
All combinations except the 32 bit pointers / 64 bit AMEM value are
cheap and easy to handle, and the problematic case is likely rare.
The most popular map keys appear to be ints and pointers.
So we handle them exhaustively. The sys.PtrSize checks are constant branches
and are eliminated by the compiler.
An alternative fix would be to return a pointer to the key,
and have the calling code do the assignment, at which point the compiler
would have full type information.
Initial tests suggest that the performance difference between these
strategies is negligible, and this fix is considerably simpler,
and has much less impact on binary size.
Keith Randall [Thu, 24 Aug 2017 20:19:40 +0000 (13:19 -0700)]
cmd/compile,math: improve code generation for math.Abs
Implement int reg <-> fp reg moves on amd64.
If we see a load to int reg followed by an int->fp move, then we can just
load to the fp reg instead. Same for stores.
Austin Clements [Thu, 24 Aug 2017 19:06:26 +0000 (15:06 -0400)]
runtime: capture runtimeInitTime after nanotime is initialized
CL 36428 changed the way nanotime works so on Darwin and Windows it
now depends on runtime.startNano, which is computed at runtime.init
time. Unfortunately, the `runtimeInitTime = nanotime()` initialization
happened *before* runtime.init, so on these platforms runtimeInitTime
is set incorrectly. The one (and only) consequence of this is that the
start time printed in gctrace lines is bogus:
gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P
To fix this, this commit moves the runtimeInitTime initialization to
shortly after runtime.init, at which point nanotime is safe to use.
This also requires changing the condition in newproc1 that currently
uses runtimeInitTime != 0 simply to detect whether or not the main M
has started. Since runtimeInitTime could genuinely be 0 now, this
introduces a separate flag to newproc1.
Fixes #21554.
Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b
Reviewed-on: https://go-review.googlesource.com/58690
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Hana Kim [Thu, 24 Aug 2017 20:32:54 +0000 (16:32 -0400)]
misc/trace: update trace-viewer
Generated with
github.com/catapult/tracing/bin/vulcanize_trace_viewer
catapult @ ab4d571fa
Renamed trace_viewer_lean.html to trace_viewer_full.html
to make it clear we are using the full version of trace viewer
(waiting for https://github.com/catapult-project/catapult/issues/2247
to be fixed).
Matthew Dempsky [Thu, 24 Aug 2017 22:36:47 +0000 (15:36 -0700)]
cmd/compile: simplify noding for struct embedding
Since golang.org/cl/31670, we've stopped using the 'embedded' function
for handling struct embeddings within package export data. Now the
only remaining use is for Go source files, which allows for some
substantial simplifications:
1. CenterDot never appears within Go source files, so that logic can
simply be removed.
2. The field name will always be declared in the local package.
Passes toolstash-check.
Change-Id: I59505f62824206dd5de0782918f98fbef6e93224
Reviewed-on: https://go-review.googlesource.com/58790
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
griesemer [Thu, 24 Aug 2017 13:20:18 +0000 (15:20 +0200)]
spec: clarify zero value for complex types
The enumeration of numeric types missed the complex types.
Clarify by removing the explicit enumeration and referring
to numeric types instead.
Fixes #21579.
Change-Id: If36c2421f8501eeec82a07f442ac2e16a35927ba
Reviewed-on: https://go-review.googlesource.com/58491 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Rob Pike <r@golang.org>
griesemer [Thu, 24 Aug 2017 13:05:53 +0000 (15:05 +0200)]
spec: clarify nil case in type switches
The old wording seemed to imply that nil is a kind of type.
Slightly reworded for clarity.
Fixes #21580.
Change-Id: I29898bf0125a10cb8dbb5c7e63ec5399ebc590ca
Reviewed-on: https://go-review.googlesource.com/58490 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org>
Tom Levy [Thu, 24 Aug 2017 01:44:04 +0000 (13:44 +1200)]
sort: fix TestAdversary
There are some major problems with TestAdversary (based on "A Killer
Adversary for Quicksort"[1] by M. D. McIlroy). See #21581 for details.
Rewrite the test to closely match the version in the paper so it can
be verified as correct by virtue of similarity.
The only major difference between this new version and the version in
the paper is that this version swaps the values directly instead of
permuting an array of indices because we don't need to recover the
original permutation.
This new version also counts the number of calls to Less() and fails
the test if there are too many.
Fixes #21581.
[1]: http://www.cs.dartmouth.edu/~doug/mdmspe.pdf
Change-Id: Ia94b5b6d288b8fa3805a5fa27661cebbc5bad9a7
Reviewed-on: https://go-review.googlesource.com/58330
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tom Levy [Fri, 25 Aug 2017 05:13:34 +0000 (17:13 +1200)]
sync/atomic: remove references to old atomic pointer hammer tests
The tests were removed in https://golang.org/cl/2311 but some
references to them were missed.
Change-Id: I163e554a0cc99401a012deead8fda813ad74dbfe
Reviewed-on: https://go-review.googlesource.com/58870 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
David du Colombier [Thu, 24 Aug 2017 23:56:50 +0000 (01:56 +0200)]
cmd/compile: don't use MOVOstore instruction on plan9/amd64
CL 54410 and CL 56250 recently added use of the MOVOstore
instruction to improve performance.
However, we can't use the MOVOstore instruction on Plan 9,
because floating point operations are not allowed in the
note handler.
This change adds a configuration flag useSSE to enable the
use of SSE instructions for non-floating point operations.
This flag is enabled by default and disabled on Plan 9.
When this flag is disabled, the MOVOstore instruction is
not used and the MOVQstoreconst instruction is used instead.
Fixes #21599
Change-Id: Ie609e5d9b82ec0092ae874bab4ce01caa5bc8fb8
Reviewed-on: https://go-review.googlesource.com/58850 Reviewed-by: Keith Randall <khr@golang.org>
Wei Congrui [Tue, 22 Aug 2017 05:36:19 +0000 (13:36 +0800)]
build: add `go env GOROOT` as default GOROOT_BOOTSTRAP value
This change also added the same check in make.bash to make.rc,
which makes sure $GOROOT_BOOTSTRAP != $GOROOT.
Fixes #14339
Change-Id: I2758f4a845bae42ace02492fc6a911f6d6247d26
Reviewed-on: https://go-review.googlesource.com/57753
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Thu, 24 Aug 2017 01:36:46 +0000 (18:36 -0700)]
archive/tar: return better WriteHeader errors
WriteHeader may fail to encode a header for any number of reasons,
which can be frustrating for the user when trying to create a tar archive.
As we validate the Header, we generate an informative error message
intended for human consumption and return that if and only if no
format can be selected.
This allows WriteHeader to return informative errors like:
tar: cannot encode header: invalid PAX record: "linkpath = \x00hello"
tar: cannot encode header: invalid PAX record: "SCHILY.xattr.foo=bar = baz"
tar: cannot encode header: Format specifies GNU; and only PAX supports Xattrs
tar: cannot encode header: Format specifies GNU; and GNU cannot encode ModTime=1969-12-31 15:59:59.0000005 -0800 PST
tar: cannot encode header: Format specifies GNU; and GNU supports sparse files only with TypeGNUSparse
tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode ModTime=292277026596-12-04 07:30:07 -0800 PST
tar: cannot encode header: Format specifies USTAR; and USTAR does not support sparse files
tar: cannot encode header: Format specifies PAX; and only GNU supports TypeGNUSparse
Updates #18710
Change-Id: I82a498d6f29d02c4e73bce47b768eb578da8499c
Reviewed-on: https://go-review.googlesource.com/58310
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith Randall [Thu, 24 Aug 2017 22:23:27 +0000 (15:23 -0700)]
cmd/compile: remove more nil ptr checks after newobject
For code like the following (where x escapes):
x := []int{1}
We're currently generating a nil check. The line above is really 3 operations:
t := new([1]int)
t[0] = 1
x := t[:]
We remove the nil check for t[0] = 1, but not for t[:].
Our current nil check removal rule is too strict about the possible
memory arguments of the nil check. Unlike zeroing or storing to the
result of runtime.newobject, the nilness of runtime.newobject is
always false, even after other stores have happened in the meantime.
Heschi Kreinick [Thu, 24 Aug 2017 18:29:13 +0000 (14:29 -0400)]
cmd/link: don't create go.info symbols for non-Go functions
In writelines the linker uses various auxiliary information about a
function to create its line table entries. (It also does some unrelated
stuff, but never mind.) There's no reason to do this for non-Go
functions, so it bails out if the symbol has no FuncInfo.
However, it does so *after* it looks up (and implicitly creates!) the
go.info symbol for the function, which doesn't make sense and risks
creating duplicate symbols for static C functions. Move the check up so
that it doesn't do that.
Since non-Go functions can't reference Go types, there shouldn't be any
relocations to type info DIEs that need to be built, so there should be
no harm not doing that.
I wanted to change the Lookup to an ROLookup but that broke the
shared-mode tests with an inscrutable error.
No test. It seems too specific to worry about, but if someone disagrees
I can figure something out.
Fixes #21566
Change-Id: I61f03b7c504a3bf1c4245a8811795b6303469e91
Reviewed-on: https://go-review.googlesource.com/58630 Reviewed-by: Ian Lance Taylor <iant@golang.org>
This eliminates a nil check of b while evaluating b.tophash,
which is in the inner loop of many hot map functions.
It also makes the code a bit clearer.
Also remove some gotos in favor of labeled breaks.
On non-x86 architectures, this change introduces a pointless reg-reg move,
although the cause is well-understood (#21572).
Ian Lance Taylor [Thu, 24 Aug 2017 00:44:51 +0000 (17:44 -0700)]
cmd/link: set correct alignment of ELF note section
Otherwise the default computation in symalign kicked in, setting the
alignment to be too high. This didn't matter with GNU ld, which put
each loadable note into a separate PT_NOTE segment, but it did matter
with gold which accumulated them all into a single PT_NOTE segment,
respecting the requested alignment. In the single PT_NOTE segment
generated by gold, the incorrect section alignment made the notes
unreadable.
Martin Möhrmann [Wed, 23 Aug 2017 07:05:29 +0000 (09:05 +0200)]
runtime: avoid infinite loop in growslice
On 386 the below code triggered an infinite loop in growslice:
x = make([]byte, 1<<30-1, 1<<30-1)
x = append(x, x...)
Check for overflow when calculating the new slice capacity
and set the new capacity to the requested capacity when an overflow
is detected to avoid an infinite loop.
No automatic test added due to requiring to allocate 1GB of memory
on a 32bit plaform before use of append is able to trigger the
overflow check.
Fixes #21441
Change-Id: Ia871cc9f88479dacf2c7044531b233f83d2fcedf
Reviewed-on: https://go-review.googlesource.com/57950
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
Dmitry Vyukov [Mon, 5 Jun 2017 08:37:37 +0000 (10:37 +0200)]
testing: parallelize tests over count
Currently all package tests are executed once
with Parallel tests executed in parallel.
Then this process is repeated count*cpu times.
Tests are not parallelized over count*cpu.
Parallelizing over cpu is not possible as
GOMAXPROCS is a global setting. But it is
possible for count.
Parallelize over count.
Brings down testing of my package with -count=100
form 10s to 0.3s.
Change-Id: I76d8322adeb8c5c6e70b99af690291fd69d6402a
Reviewed-on: https://go-review.googlesource.com/44830
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Joe Tsai [Wed, 23 Aug 2017 22:56:24 +0000 (15:56 -0700)]
archive/tar: support reporting and selecting the format
The Reader and Writer are now at feature parity,
meaning that everything that can be parsed by the Reader,
can also be composed by the Writer.
This position enables us to support selection of the format
in a backwards compatible way, since it ensures that everything
that can be read can also be round-trip written.
As such, we add the following new API:
type Format int
const FormatUnknown Format = 0 ...
type Header struct { ...; Format Format }
The new Header.Format field is populated by the Reader on the
best guess on what the format is. Note that the Reader is very liberal
in what it permits, so a hybrid TAR file using aspects of multiple
formats can still be decoded, but will be reported as FormatUnknown.
Even though Reader has full support for V7 and basic support for STAR,
it will still report those formats as unknown (and the constants for
those formats are not even exported). The reasons for this is because
the Writer has no support for V7 or STAR. Leaving it as unknown allows
the Writer to choose a format usually USTAR or GNU that can encode
the equivalent Header.
When writing, the Header.allowedFormats will take the Format field
into consideration if it is a known format.
Fixes #18710
Change-Id: I00980c475d067c6969d3414e1ff0224fdd89cd49
Reviewed-on: https://go-review.googlesource.com/58230
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Karel Pazdera [Wed, 23 Aug 2017 22:36:28 +0000 (00:36 +0200)]
encoding/xml: improve package based on the suggestions from metalinter
Existing code in encoding/xml packages contains code which breaks
various linter rules (comments, constant and variable naming, variable
shadowing, etc).
Fixes #21578
Change-Id: Id4bd9a9be6d5728ce88fb6efe33030ef943c078c
Reviewed-on: https://go-review.googlesource.com/58210 Reviewed-by: Sam Whited <sam@samwhited.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Sam Whited <sam@samwhited.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
André Carvalho [Fri, 28 Jul 2017 23:31:20 +0000 (20:31 -0300)]
reflect: handle types with unexported methods before exported ones
The method Method expects index to be an index of exported fields,
but, before this change, the index used by MethodByName could
take into account unexported fields if those happened sort
before the exported one.
Fixes #21177
Change-Id: I90bb64a47b23e2e43fdd2b8a1e0a2c9a8a63ded2
Reviewed-on: https://go-review.googlesource.com/51810 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Joe Tsai [Sat, 19 Aug 2017 01:18:38 +0000 (18:18 -0700)]
archive/tar: implement Writer support for sparse files
This CL is the second step (of two; part1 is CL/56771) for adding
sparse file support to the Writer.
There are no new identifiers exported in this CL, but this does make
use of Header.SparseHoles added in part1. If the Typeflag is set to
TypeGNUSparse or len(SparseHoles) > 0, then the Writer will emit an
sparse file, where the holes must be written by the user as zeros.
If TypeGNUSparse is set, then the output file must use the GNU format.
Otherwise, it must use the PAX format (with GNU-defined PAX keys).
A future CL may export Reader.Discard and Writer.FillZeros,
but those methods are currently unexported, and only used by the
tests for efficiency reasons.
Calling Discard or FillZeros on a hole 10GiB in size does take
time, even if it is essentially a memcopy.
Updates #13548
Change-Id: Id586d9178c227c0577f796f731ae2cbb72355601
Reviewed-on: https://go-review.googlesource.com/57212 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alexander Morozov [Wed, 23 Aug 2017 18:49:22 +0000 (11:49 -0700)]
syscall: skip some exec tests in container
For those tests there won't be enough permissions in containers.
I decided to go this way instead of just skipping os.IsPermission errors because
many of those tests were specifically written to check false positive permission
errors.
Fixes #21379
Change-Id: Ie25e1d6d47f85bb6b570352638440f3ac1e18e03
Reviewed-on: https://go-review.googlesource.com/58170 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The current code treats floating-point constant as integer
and does not treat fcmp/fcmpe as the comparison instrucitons
that requires special handling.
The fix corrects the type of immediate arguments and adds fcmp/fcmpe
in the special handing.
runtime: strength reduce key pointer calculation in mapdelete_fast*
Move the tophash checks after the equality/length checks.
For fast32/fast64, since we've done a full equality check already,
just check whether tophash is empty instead of checking tophash.
This is cheaper and allows us to skip calculating tophash.
These changes are modeled on the changes in CL 57590,
which were polished based on benchmarking.
Benchmarking directly is impeded by #21546.
Martin Möhrmann [Wed, 23 Aug 2017 11:48:05 +0000 (13:48 +0200)]
runtime: fix makemap64 function signature
During rebase of golang.org/cl/55152 the bucket argument
which was removed in golang.org/cl/56290 from makemap
was not removed from the argument list of makemap64.
This did lead to "pointer in unallocated span" errors
on 32bit platforms since the compiler did only generate
calls to makemap64 without the bucket argument.
The intent is to allow more aggressive refactoring
in the runtime without silent performance changes.
The test would be useful for many functions.
I've seeded it with the runtime functions tophash and add;
it will grow organically (or wither!) from here.
Martin Möhrmann [Mon, 14 Aug 2017 08:16:21 +0000 (10:16 +0200)]
cmd/compile: generate makemap calls with int arguments
Where possible generate calls to runtime makemap with int hint argument
during compile time instead of makemap with int64 hint argument.
This eliminates converting the hint argument for calls to makemap with
int64 hint argument for platforms where int64 values do not fit into
an argument of type int.
A similar optimization for makeslice was introduced in CL
golang.org/cl/27851.
386:
name old time/op new time/op delta
NewEmptyMap 53.5ns ± 5% 41.9ns ± 5% -21.56% (p=0.000 n=10+10)
NewSmallMap 182ns ± 1% 165ns ± 1% -8.92% (p=0.000 n=10+10)
Change-Id: Ibd2b4c57b36f171b173bf7a0602b3a59771e6e44
Reviewed-on: https://go-review.googlesource.com/55142 Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I24374accf48d43edf4bf27ea6ba2245ddca558ad
Reviewed-on: https://go-review.googlesource.com/50910 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Heschi Kreinick [Fri, 26 May 2017 19:34:56 +0000 (15:34 -0400)]
cmd/compile: emit DW_AT_decl_line
Some debuggers use the declaration line to avoid showing variables
before they're declared. Emit them for local variables and function
parameters.
DW_AT_decl_file would be nice too, but since its value is an index
into a table built by the linker, that's dramatically harder. In
practice, with inlining disabled it's safe to assume that all a
function's variables are declared in the same file, so this should still
be pretty useful.
Change-Id: I8105818c8940cd71bc5473ec98797cce2f3f9872
Reviewed-on: https://go-review.googlesource.com/44350 Reviewed-by: David Chase <drchase@google.com>
Martin Möhrmann [Mon, 7 Aug 2017 20:36:22 +0000 (22:36 +0200)]
cmd/compile: replace eqstring with memequal
eqstring is only called for strings with equal lengths.
Instead of pushing a pointer and length for each argument string
on the stack we can omit pushing one of the lengths on the stack.
Changing eqstrings signature to eqstring(*uint8, *uint8, int) bool
to implement the above optimization would make it very similar to the
existing memequal(*any, *any, uintptr) bool function.
Since string lengths are positive we can avoid code redundancy and
use memequal instead of using eqstring with an optimized signature.
go command binary size reduced by 4128 bytes on amd64.
fanzha02 [Tue, 13 Jun 2017 10:16:41 +0000 (10:16 +0000)]
cmd/internal/obj/arm64: fix assemble movk bug
The current code gets shift arguments value from prog.From3.Offset.
But prog.From3.Offset is not assigned the shift arguments value in
instructions assemble process.
The fix calls movcon() function to get the correct value.
Thomas Wanielista [Thu, 10 Aug 2017 22:39:18 +0000 (18:39 -0400)]
go/doc: classify function returning slice of T as constructor
Previously, go/doc would only consider functions that return types of
T or any number of pointers to T: *T, **T, etc. This change expands
the definition of a constructor to also include functions that return
slices of a type (or pointer to that type) in its first return.
With this change, the following return types classify a function
as a constructor of type T:
T
*T
**T (and so on)
[]T
[]*T
[]**T (and so on)
Fixes #18063.
Change-Id: I9a1a689933e13c6b8eb80b74ceec85bd4cab236d
Reviewed-on: https://go-review.googlesource.com/54971 Reviewed-by: Robert Griesemer <gri@golang.org>
Kevin Burke [Mon, 21 Aug 2017 00:27:42 +0000 (17:27 -0700)]
time: fix grammar/spelling errors in test comment
Change-Id: I159bd1313e617c929008f6ac54ec7d702293360b
Reviewed-on: https://go-review.googlesource.com/57430 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ben Shi [Wed, 16 Aug 2017 07:05:34 +0000 (07:05 +0000)]
cmd/internal/obj/arm: support BFX/BFXU instructions
BFX extracts given bits from the source register, sign extends them
to 32-bit, and writes to destination register. BFXU does the similar
operation with zero extention.
philhofer [Tue, 15 Aug 2017 04:50:43 +0000 (21:50 -0700)]
cmd/compile: omit unnecessary boolean zero extension on arm64
On arm64, all boolean-generating instructions (CSET, etc.) set the upper
63 bits of the destination register to zero, so there is no need
to zero-extend the lower 8 bits again.
Alex Brainman [Mon, 5 Jun 2017 06:56:33 +0000 (16:56 +1000)]
cmd/link: introduce and use peFile.addInitArray
Change-Id: I4377c478159129ab3f3b5ddc58d1944f8f4a4b07
Reviewed-on: https://go-review.googlesource.com/56320 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 06:10:49 +0000 (16:10 +1000)]
cmd/link: introduce and use peFile.nextSectOffset and nextFileOffset
Change-Id: Iecff99e85e2cca1127dca79747bb0d5362cd4125
Reviewed-on: https://go-review.googlesource.com/56319 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 05:53:08 +0000 (15:53 +1000)]
cmd/link: remove pensect
Change-Id: Ia4abb76a8fa9e9ab280cd9162238ebd3fba79e4d
Reviewed-on: https://go-review.googlesource.com/56318 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 05:51:26 +0000 (15:51 +1000)]
cmd/link: introduce and use peFile.textSect, dataSect and bssSect
Change-Id: I6a1d33a759deaa4788bafb1c288d9b0e2fe3b026
Reviewed-on: https://go-review.googlesource.com/56317 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 05:40:32 +0000 (15:40 +1000)]
cmd/link: introduce and use peSection.pad
Change-Id: I068e9bb6e692b5eff193ddb46af3f04785f98518
Reviewed-on: https://go-review.googlesource.com/56316 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 05:21:31 +0000 (15:21 +1000)]
cmd/link: introduce and use peSection.checkSegment
Change-Id: Idaab6516dae609e1707d4bce7bf7809ebfc8ec40
Reviewed-on: https://go-review.googlesource.com/56315 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 05:15:36 +0000 (15:15 +1000)]
cmd/link: introduce and use peSection.checkOffset
Change-Id: I093b79a8dd298bce8e8774c51a86a4873718978a
Reviewed-on: https://go-review.googlesource.com/56314 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 5 Jun 2017 04:52:31 +0000 (14:52 +1000)]
cmd/link: introduce and use peFile.addDWARFSection
Change-Id: I8b23bfb85da9ece47e337f262bafd97f303dd1d1
Reviewed-on: https://go-review.googlesource.com/56313 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Elias Naur [Sat, 19 Aug 2017 11:11:09 +0000 (13:11 +0200)]
misc/cgo/testcshared: fix tests on android
The testcshared test.bash was rewritten in Go, but the rewritten script
broke on Android. Make the tests run on Android again by:
- Restoring the LD_LIBRARY_PATH path (.).
- Restoring the Android specific C flags (-pie -fuse-ld=gold).
- Adding runExe to run test executables. All other commands must run on
the host.
Fixes #21513.
Change-Id: I3ea617a943c686b15437cc5c118e9802a913d93a
Reviewed-on: https://go-review.googlesource.com/57290
Run-TryBot: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
.github: update ISSUE_TEMPLATE to be closer to 'go bug'
Ask whether the issue reproduces with the latest release.
'go bug' places the version and system details last,
in part because they're automatically filled.
I'd like to do the same here, but I worry
that they'll get ignored.
Alex Brainman [Fri, 18 Aug 2017 06:34:44 +0000 (16:34 +1000)]
misc/cgo/testcshared: cd into work directory before running android command
Hopefully this will fix android build.
Maybe fixes #21513
Change-Id: I98f760562646f06b56e385c36927e79458465b92
Reviewed-on: https://go-review.googlesource.com/56790 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Joe Tsai [Tue, 15 Aug 2017 05:03:25 +0000 (22:03 -0700)]
archive/tar: refactor Reader support for sparse files
This CL is the first step (of two) for adding sparse file support
to the Writer. This CL only refactors the logic of sparse-file handling
in the Reader so that common logic can be easily shared by the Writer.
As a result of this CL, there are some new publicly visible API changes:
type SparseEntry struct { Offset, Length int64 }
type Header struct { ...; SparseHoles []SparseEntry }
A new type is defined to represent a sparse fragment and a new field
Header.SparseHoles is added to represent the sparse holes in a file.
The API intentionally represent sparse files using hole fragments,
rather than data fragments so that the zero value of SparseHoles
naturally represents a normal file (i.e., a file without any holes).
The Reader now populates SparseHoles for sparse files.
It is necessary to export the sparse hole information, otherwise it would
be impossible for the Writer to specify that it is trying to encode
a sparse file, and what it looks like.
Some unexported helper functions were added to common.go:
func validateSparseEntries(sp []SparseEntry, size int64) bool
func alignSparseEntries(src []SparseEntry, size int64) []SparseEntry
func invertSparseEntries(src []SparseEntry, size int64) []SparseEntry
The validation logic that used to be in newSparseFileReader is now moved
to validateSparseEntries so that the Writer can use it in the future.
alignSparseEntries is currently unused by the Reader, but will be used
by the Writer in the future. Since TAR represents sparse files by
only recording the data fragments, we add the invertSparseEntries
function to convert a list of data fragments to a normalized list
of hole fragments (and vice-versa).
Some other high-level changes:
* skipUnread is deleted, where most of it's logic is moved to the
Discard methods on regFileReader and sparseFileReader.
* readGNUSparsePAXHeaders was rewritten to be simpler.
* regFileReader and sparseFileReader were completely rewritten
in simpler and easier to understand logic.
* A bug was fixed in sparseFileReader.Read where it failed to
report an error if the logical size of the file ends before
consuming all of the underlying data.
* The tests for sparse-file support was completely rewritten.
Updates #13548
Change-Id: Ic1233ae5daf3b3f4278fe1115d34a90c4aeaf0c2
Reviewed-on: https://go-review.googlesource.com/56771
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>