An io.Reader does not guarantee that it will read in the entire buffer.
To ensure that property, io.ReadFull should be used instead.
Change-Id: I0b863135ab9abc40e813f9dac07bfb2a76199950
Reviewed-on: https://go-review.googlesource.com/37403
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The loop-A-encloses-loop-C code did not properly handle the
case where really C was already known to be enclosed by B,
and A was nearest-outer to B, not C.
Fixes#19217.
Change-Id: I755dd768e823cb707abdc5302fed39c11cdb34d4
Reviewed-on: https://go-review.googlesource.com/37340
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Avoid printing a second error message when a field of an undefined
variable is accessed.
Fixes#8440.
Change-Id: I3fe0b11fa3423cec3871cb01b5951efa8ea7451a
Reviewed-on: https://go-review.googlesource.com/36751
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The existing CPU profiling buffer is a slice of uintptr, but we want to
start including profiling label data in the profiles, and those labels need
to be pointers in order to let them describe rich information.
This CL implements a new profBuf type that holds both a slice of uint64
for data and a slice of unsafe.Pointer for profiling labels (aka tags).
Making the runtime use these buffers will happen in followup CLs.
Change-Id: I9ff16b532d8edaf4ce0cbba1098229a561834efc
Reviewed-on: https://go-review.googlesource.com/36713
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
xdg-open's man page says:
> xdg-open is for use inside a desktop session only.
Use the DISPLAY environment variable to detect this.
Updates #19131.
Change-Id: I3926b3e1042393939b2ec6aacd9b63ac8192df3b
Reviewed-on: https://go-review.googlesource.com/37390
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When running on the host platform,
the standard library has almost certainly already been built.
However, all other platforms will probably need building.
Use the new -dolinkobj=false flag to cmd/compile
to only build the export data instead of doing a full compile.
Having partial object files could be confusing for people
doing subsequent cross-compiles, depending on what happens with #18369.
However, cmd/vet/all will mainly be run by builders
and core developers, who are probably fairly well-placed
to handle any such confusion.
This reduces the time on my machine for a cold run of
'go run main.go -all' by almost half:
benchmark old ns/op new ns/op delta
BenchmarkVetAll 240670814551 130784517074 -45.66%
Change-Id: Ieb866ffb2cb714b361b0a6104077652f8eacd166
Reviewed-on: https://go-review.googlesource.com/37385
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When set to false, the -dolinkobj flag instructs the compiler
not to generate or emit linker information.
This is handy when you need the compiler's export data,
e.g. for use with go/importer,
but you want to avoid the cost of full compilation.
This must be used with care, since the resulting
files are unusable for linking.
This CL interacts with #18369,
where adding gcflags and ldflags to buildid has been mooted.
On the one hand, adding gcflags would make safe use of this
flag easier, since if the full object files were needed,
a simple 'go install' would fix it.
On the other hand, this would mean that
'go install -gcflags=-dolinkobj=false' would rebuild the object files,
although any existing object files would probably suffice.
Change-Id: I8dc75ab5a40095c785c1a4d2260aeb63c4d10f73
Reviewed-on: https://go-review.googlesource.com/37384
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Replaces pairs of shifts with sign/zero extension where possible.
For example:
(uint64(x) << 32) >> 32 -> uint64(uint32(x))
Reduces the execution time of the following code by ~4.5% on s390x:
for i := 0; i < N; i++ {
x += (uint64(i)<<32)>>32
}
Change-Id: Idb2d56f27e80a2e1366bc995922ad3fd958c51a7
Reviewed-on: https://go-review.googlesource.com/37292
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
ExampleSliceStable echoes the sort.Slice example, to demonstrate sorting
on two fields together preserving order between sorts.
Change-Id: I8afc20c0203991bfd57260431eda73913c165355
Reviewed-on: https://go-review.googlesource.com/37196
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fix the encoding of the SH field for rldimi.
The SH field of rldimi is 6-bit wide and it is not contiguous in the instruction.
Bits 0-4 are placed in bit fields 16-20 in the instruction, while bit 5 is
placed in bit field 30. The current implementation does not consider this and,
therefore, any SH field between 32 and 63 are encoded wrongly in the instruciton.
Change-Id: I4d25a0a70f4219569be0e18160dea5505bd7fff0
Reviewed-on: https://go-review.googlesource.com/37350
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Describe the difference from String encoding when len(ip) is zero.
Change-Id: Ia9b36b405d4fec3fee9a77498a839b6d90c2ec0d
Reviewed-on: https://go-review.googlesource.com/37379
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Removes init function from the math package.
Allows stripping of arrays with pre-computed values
used for Pow10 from binaries if Pow10 is not used.
cmd/go shrinks by 128 bytes.
Fixed small values like 10**-323 being 0 instead of 1e-323.
Overall precision is increased but still not as good as
predefined constants for some inputs.
Samples:
Pow10(208)
before: 1.0000000000000006662e+208
after: 1.0000000000000000959e+208
Pow10(202)
before 1.0000000000000009895e+202
after 1.0000000000000001193e+202
Pow10(60)
before 1.0000000000000001278e+60
after 0.9999999999999999494e+60
Pow10(-100)
before 0.99999999999999938551e-100
after 0.99999999999999989309e-100
Pow10(-200)
before 0.9999999999999988218e-200
after 1.0000000000000001271e-200
name old time/op new time/op delta
Pow10Pos-4 44.6ns ± 2% 1.2ns ± 1% -97.39% (p=0.000 n=19+17)
Pow10Neg-4 50.8ns ± 1% 4.1ns ± 2% -92.02% (p=0.000 n=17+19)
Change-Id: If094034286b8ac64be3a95fd9e8ffa3d4ad39b31
Reviewed-on: https://go-review.googlesource.com/36331
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
std and race bench tests fail to check against t.runRxWant, so what
should be negative filters act as positive filters.
Fixes#19239
Change-Id: Icf02b2192bcd806a162fca9fb0af68a27ccfc936
Reviewed-on: https://go-review.googlesource.com/37336
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#19012.
Fallback to return signatures without detailed types.
These error message will be of the form of issue:
* https://golang.org/issues/4215
* https://golang.org/issues/6750
So:
func f(x int, y uint) {
return x > y
}
f(10, "a" < 3)
will give errors:
too many errors to return
too many arguments in call to f
instead of:
too many errors to return
have (<T>)
want ()
too many arguments in call to f
have (number, <T>)
want (number, number)
Change-Id: I680abc7cdd8444400e234caddf3ff49c2d69f53d
Reviewed-on: https://go-review.googlesource.com/36806
Reviewed-by: Robert Griesemer <gri@golang.org>
Test finite negative x with Y0(-1), Y1(-1), Yn(2,-1), Yn(-3,-1).
Also test the special case Yn(0,0).
Fixes#19130.
Change-Id: I95f05a72e1c455ed8ddf202c56f4266f03f370fd
Reviewed-on: https://go-review.googlesource.com/37310
Reviewed-by: Robert Griesemer <gri@golang.org>
It could have been defined the other way, but since the behavior has
been unspecified, this is the conservative approach for people writing
different implementations of the Context interface.
Change-Id: I7334a4c674bc2330cca6874f7cac1eb0eaea3cff
Reviewed-on: https://go-review.googlesource.com/37375
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Sameer Ajmani <sameer@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This updates the testcase to display the timestamps for the
runtime.a, it dependent packages atomic.a and sys.a, and
source files.
Change-Id: Id2901b4e8aa8eb9775c4f404ac01cc07b394ba91
Reviewed-on: https://go-review.googlesource.com/37332
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Keith pointed out that these rules should zero extend during the review
of CL 36845. In practice the generic rules are responsible for eliminating
most load-hit-stores and they do not have this problem. When the s390x
rules are triggered any cast following the elided load-hit-store is
kept because of the sequence the rules are applied in (i.e. the load is
removed before the zero extension gets a chance to be merged into the load).
It is therefore not clear that this issue results in any functional bugs.
This CL includes a test, but it only tests the generic rules currently.
Change-Id: Idbc43c782097a3fb159be293ec3138c5b36858ad
Reviewed-on: https://go-review.googlesource.com/37154
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Added a flag to generic and various architectures' atomic
operations that are judged to have observable side effects
and thus cannot be dead-code-eliminated.
Test requires GOMAXPROCS > 1 without preemption in loop.
Fixes#19182.
Change-Id: Id2230031abd2cca0bbb32fd68fc8a58fb912070f
Reviewed-on: https://go-review.googlesource.com/37333
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The gcdata field only records ptrdata entries, not size entries.
Also fix an obsolete comment: the enforced limit on pointer maps is
now 2048 bytes, not 16 bytes.
I wasn't able to contruct a test case for this. It would require
building a type whose size is greater than 64 bytes but less than 128
bytes, with at least one pointer in first 64 bytes but no pointers
after the first 64 bytes, such that the linker arranges for the one
byte gcbits value to be immediately followed by a non-zero byte.
Change-Id: I9118d3e4ec6f07fd18b72f621c1e5f4fdfe5f80b
Reviewed-on: https://go-review.googlesource.com/37142
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
The definition of writeBarrier in the runtime was changed in CL 22855
to include padding. Update the definition built in to the compiler to match.
This doesn't affect the generated code, as the compiler sets the type
to use anyhow, but having them be different seems clearly wrong.
Change-Id: I8eac05bf70a424a0b2338ba5e9e41af231316de0
Reviewed-on: https://go-review.googlesource.com/37377
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#19223.
Change-Id: I4cc8e81559a1313e1477ee36902e1b653155a888
Reviewed-on: https://go-review.googlesource.com/37374
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
For compatibility with math/bits uint operations.
When math/big was written originally, the Go compiler used 32bit
int/uint values even on a 64bit machine. uintptr was the type that
represented the machine register size. Now, the int/uint types are
sized to the native machine register size, so they are the natural
machine Word type.
On most machines, the size of int/uint correspond to the size of
uintptr. On platforms where uint and uintptr have different sizes,
this change may lead to performance differences (e.g., amd64p32).
Change-Id: Ief249c160b707b6441848f20041e32e9e9d8d8ca
Reviewed-on: https://go-review.googlesource.com/37372
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The type of the OffPtr should be consistent with the type of the
following load. Before this CL it was typed as a pointer to the
struct.
Fixes#19164.
Change-Id: Ibcdec4411c6f719702f76f8dba3cce8691bfbe0c
Reviewed-on: https://go-review.googlesource.com/37254
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
doEncryptKeyAsm is tail-called from other assembly routines.
Give it a proper prototype so that vet can check it.
Adjust one assembly FP reference accordingly.
Change-Id: I263fcb0191529214b16e6bd67330fadee492eef4
Reviewed-on: https://go-review.googlesource.com/37305
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A last-minute rollback of a change left some
unreachable code that we don't want to remove.
Change-Id: Ida0af5b18ed1a2e13ef66c303694afcc49d7bff4
Reviewed-on: https://go-review.googlesource.com/37304
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cmd/vet has a known deficiency in its handling of fmt.Formatters.
This causes a spurious printf error only for non-host platforms.
Since cmd/vet/all may get run on any given platform,
whitelists cannot help here.
Work around the issue by skipping printf tests entirely
for non-host platforms.
Work around the one known acceptable false positive from vet
by whitelisting the file that contains it.
Change-Id: Id74b3d4db0519cf9a670a065683715f856266e45
Reviewed-on: https://go-review.googlesource.com/36936
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Stop reporting errors from cmd.Process.Kill; they don't matter for
purposes of this test, and they can occur if the process exits quickly.
Fixes#19211.
Fixes#19213.
Change-Id: I1a0bb9170220ca69199abb8e8811b1dde43e1897
Reviewed-on: https://go-review.googlesource.com/37309
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
storeOrder visits values in DFS order. It should "break" after
pushing one argument to stack, instead of "continue".
Fixes#19179.
Change-Id: I561afb44213df40ebf8bf7d28e0fd00f22a81ac0
Reviewed-on: https://go-review.googlesource.com/37250
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
No functional changes.
For #10776.
Change-Id: If9a5ef832af116c5802b06a38e0c050d7363f2d5
Reviewed-on: https://go-review.googlesource.com/36981
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dwarf writing code assumes that dwarf sections follow
.data and .bss, not .ctors. Make pe section writing code
match that assumption.
For #10776.
Change-Id: I128c3ad125f7d0db19e922f165704a054b2af7ba
Reviewed-on: https://go-review.googlesource.com/36980
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The symbols get in a way when using external linker. They are
not associated with a section. And linker fails when
generating relocations for them.
__image_base__ and _image_base__ have been added long time ago.
I do not think they are needed anymore. If I delete them, all
tests still PASS. I tried going back to the commit that added
them to see if I can reproduce original error, but I cannot
build it. I don't have hg version of go repo, and my gcc is
complaining about cc source code.
I wasted too much time with this, so I decided to leave them only
for internal linker. That is what they were originally added for.
For #10776.
Change-Id: Ibb72b04f3864947c782f964a7badc69f4b074e25
Reviewed-on: https://go-review.googlesource.com/36979
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dwarf relocations refer to dwarf section symbols, so dwarf
section symbols must be present in pe symbol table before we
write dwarf relocations.
.ctors pe section already refer to .text symbol.
Write all pe section name symbols into symbol table, so we
can use them whenever we need them.
This CL also simplified some code.
For #10776.
Change-Id: I9b8c680ea75904af90c797a06bbb1f4df19e34b6
Reviewed-on: https://go-review.googlesource.com/36978
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Introduce a slice that keeps long pe section names as we add them.
It will be used later to output pe symbol table and dwarf relocations.
For #10776.
Change-Id: I02f808a456393659db2354031baf1d4f9e0b2d61
Reviewed-on: https://go-review.googlesource.com/36977
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is what gcc does when it generates object files.
And pecoff.doc says: "for simplicity, compilers should
set this to zero". It is easier to count everything,
when it starts from 0. Make go linker do the same.
For #10776.
Change-Id: Iffa4b3ad86160624ed34adf1c6ba13feba34c658
Reviewed-on: https://go-review.googlesource.com/36976
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Change list https://golang.org/cl/37015/ moved the optimization
of division by constants to the generic ssa backend.
This removes the old now unused code that was used
for this optimization outside of the ssa backend.
Change-Id: I86223e56742e48dbb372ba8d779681e66448c513
Reviewed-on: https://go-review.googlesource.com/37198
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>