The error message for decoding a unquoted value into a struct field with
the ,string option specified has two arguments when one is needed.
Make the error message take one argument and add a test in order to cover
the case when a unquoted value is specified.
Also add error value as the missing argument for Fatalf call in test.
Fixes the following go vet reports:
decode.go:602: wrong number of args for format in Errorf call: 1 needed but 2 args
decode_test.go:1088: missing argument for Fatalf("%v"): format reads arg 1, have only 0 args
Change-Id: Id036e10c54c4a7c1ee9952f6910858ecc2b84134
Reviewed-on: https://go-review.googlesource.com/2109
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Use log.Fatalf for formatting directives instead of log.Fatal
Change-Id: Ia207b320f5795c63cdfa71f92c19ca6d05cc833f
Reviewed-on: https://go-review.googlesource.com/2160
Reviewed-by: Minux Ma <minux@golang.org>
Rename "gothrow" to "throw" now that the C version of "throw"
is no longer needed.
This change is purely mechanical except in panic.go where the
old version of "throw" has been deleted.
sed -i "" 's/[[:<:]]gothrow[[:>:]]/throw/g' runtime/*.go
Change-Id: Icf0752299c35958b92870a97111c67bcd9159dc3
Reviewed-on: https://go-review.googlesource.com/2150
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
The new test case produces the longest string representation possible and thereby uses
all of the 65 bytes in the buffer array used by the formatBits function.
Change-Id: I11320c4de56ced5ff098b7e37f1be08e456573e2
Reviewed-on: https://go-review.googlesource.com/2108
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Specify what will happen if len(dst) != len(src).
Change-Id: I66afa3730f637753b825189687418f14ddec3629
Reviewed-on: https://go-review.googlesource.com/1754
Reviewed-by: Adam Langley <agl@golang.org>
Currently we do very a complex rebalancing of runnable goroutines
between queues, which tries to preserve scheduling fairness.
Besides being complex and error-prone, it also destroys all locality
of scheduling.
This change uses simpler scheme: leave runnable goroutines where
they are, during starttheworld start all Ps with local work,
plus start one additional P in case we have excessive runnable
goroutines in local queues or in the global queue.
The schedler must be able to operate efficiently w/o the rebalancing,
because garbage collections do not have to happen frequently.
The immediate need is execution tracing support: handling of
garabage collection which does stoptheworld/starttheworld several
times becomes exceedingly complex if the current execution can
jump between Ps during starttheworld.
Change-Id: I4fdb7a6d80ca4bd08900d0c6a0a252a95b1a2c90
Reviewed-on: https://go-review.googlesource.com/1951
Reviewed-by: Rick Hudson <rlh@golang.org>
This test code is ugly. There must be a better way.
But for now, fix the build.
Change-Id: I33064145ea37f11abf040ec97caa87669be1a9fa
Reviewed-on: https://go-review.googlesource.com/2114
Reviewed-by: Ian Lance Taylor <iant@golang.org>
numCanOpen will never be larger than 0 in maybeOpenNewConnections() when this
code path is taken, so no new connections can ever be opened.
Change-Id: Id1302e8d9afb3a67be61b5e738fe07ef81d20fe0
Reviewed-on: https://go-review.googlesource.com/1550
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For Go 1.5, we can use go:linkname rather than assembly thunk for gc.
Gccgo already has support for //extern.
Change-Id: I5505aa247dd5b555112f7261ed2f192c81cf0bdf
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1888
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Move the checks for empty rotate changes
from the beginning of rotate to the callers.
Remove additional variable p used instead of existing m with same value.
Remove special casing of equal ranges (i==j) to exit early as no
work is saved vs checking (i!=j) and making a single
swapRange call if this is false.
benchmark old ns/op new ns/op delta
BenchmarkStableString1K 417195 425218 +1.92%
BenchmarkStableInt1K 126661 124498 -1.71%
BenchmarkStableInt64K 10365014 10417438 +0.51%
BenchmarkStable1e2 132151 130648 -1.14%
BenchmarkStable1e4 42027428 40812649 -2.89%
BenchmarkStable1e6 8524772364 8430192391 -1.11%
Change-Id: Ia7642e9d31408496970c700f5843d53cc3ebe817
Reviewed-on: https://go-review.googlesource.com/2100
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When go parses #cgo lines, expand ${SRCDIR} into the path to the
source directory. This allows options to be passed to the
compiler and linker that involve file paths relative to the
source code directory. Without the expansion the paths would be
invalid when the current working directory changes.
Fixes#7891Fixes#5428
Change-Id: I343a145a9771a5ccbaa958e4a1ecd1716fcae52d
Reviewed-on: https://go-review.googlesource.com/1756
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Test more stuff:
1) flagNoPointers, an incorrect value was the cause of #9425
2) Total function layout size
3) gc program
Change-Id: I73f65fe740215938fa930d2f096febd9db0a0021
Reviewed-on: https://go-review.googlesource.com/2090
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The code concerning quoted-printable encoding (RFC 2045) and its
variant for MIME headers (RFC 2047) is currently spread in
mime/multipart and net/mail. It is also not exported.
This commit is the first step to fix that issue. It moves the
quoted-printable decoding code from mime/multipart to
mime/internal/quotedprintable. The exposed API is unchanged.
Concerns #4943.
Change-Id: I11352afbb2edb4d6ef62870b9bc5c87c639eff12
Reviewed-on: https://go-review.googlesource.com/1810
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add a nil byte at the end of the itoa buffer,
before calling gostringnocopy. This prevents
gostringnocopy to read past the buffer size.
Change-Id: I87494a8dd6ea45263882536bf6c0f294eda6866d
Reviewed-on: https://go-review.googlesource.com/2033
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Originally it used r.Int63() to show "Uint32", and now we use the correct r.Uint32() method.
Fixes#9429
Change-Id: I8a1228f1ca1af93b0e3104676fc99000257c456f
Reviewed-on: https://go-review.googlesource.com/2069
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These tests were enabled as part of change 1774.
They depend on the errchk tool, which is a Perl
script. However, Perl is not available on Plan 9.
Change-Id: I82707aae16013acc9a3800d39b0084588b852b53
Reviewed-on: https://go-review.googlesource.com/2031
Reviewed-by: Minux Ma <minux@golang.org>
The freebsd-386 and freebsd-amd64 builders are timing out sometimes.
This will give them some more breathing room.
Change-Id: Ib65bd172cca046a52861759a4232d7b4b6514fa8
Reviewed-on: https://go-review.googlesource.com/1994
Reviewed-by: Ian Lance Taylor <iant@golang.org>
malloc checks kindNoPointers and if it is not set and the object
is one pointer in size, it assumes it contains a pointer. So we
must set kindNoPointers correctly; it isn't just a hint.
Fixes#9425
Change-Id: Ia43da23cc3298d6e3d6dbdf66d32e9678f0aedcf
Reviewed-on: https://go-review.googlesource.com/2055
Reviewed-by: Russ Cox <rsc@golang.org>
Replace with uses of //go:linkname in Go files, direct use of name in .s files.
The only one that really truly needs a jump is reflect.call; the jump is now
next to the runtime.reflectcall assembly implementations.
Change-Id: Ie7ff3020a8f60a8e4c8645fe236e7883a3f23f46
Reviewed-on: https://go-review.googlesource.com/1962
Reviewed-by: Austin Clements <austin@google.com>
issue9400_linux.go did not build on 386 because it used a constant
that was larger than a 32-bit int in a ... argument. Fix this by
casting the constant to uint64 (to match how the constant is being
used).
Change-Id: Ie8cb64c3910382a41c7852be7734a62f0b2d5a21
Reviewed-on: https://go-review.googlesource.com/2060
Reviewed-by: Ian Lance Taylor <iant@golang.org>
These signals are used by glibc to broadcast setuid/setgid to all
threads and to send pthread cancellations. Unlike other signals, the
Go runtime does not intercept these because they must invoke the libc
handlers (see issues #3871 and #6997). However, because 1) these
signals may be issued asynchronously by a thread running C code to
another thread running Go code and 2) glibc does not set SA_ONSTACK
for its handlers, glibc's signal handler may be run on a Go stack.
Signal frames range from 1.5K on amd64 to many kilobytes on ppc64, so
this may overflow the Go stack and corrupt heap (or other stack) data.
Fix this by ensuring that these signal handlers have the SA_ONSTACK
flag (but not otherwise taking over the handler).
This has been a problem since Go 1.1, but it's likely that people
haven't encountered it because it only affects setuid/setgid and
pthread_cancel.
Fixes#9600.
Change-Id: I6cf5f5c2d3aa48998d632f61f1ddc2778dcfd300
Reviewed-on: https://go-review.googlesource.com/1887
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently when we get a CGI or FCGI request, the remote port of the client
is hard coded to zero, despite nearly every webserver passing down the
REMOTE_PORT variable.
This was likely originally excluded because the CGI RFC (rfc3875) does not
mention anything about the remote port of the client. However every webserver
tested does pass REMOTE_PORT down. This includes Apache 2.2, Apache 2.4,
nginx and lighttpd.
Fixes#8351
Change-Id: I4c6366cb39f0ccc05e038bd31d85f93b76e8d0c8
Reviewed-on: https://go-review.googlesource.com/1750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Broken by e7173dfdfd
Fix by simply disabling the relevant tests.
* bug248 and bug345 require errchk, but we can't
rely on perl being available.
* bug369 is disabled anyway.
Change-Id: Idf73ebccb066943e3fe17c2f662b37238ec74dfe
Reviewed-on: https://go-review.googlesource.com/2052
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Calls to goproc/deferproc used to push & pop two extra arguments,
the argument size and the function to call. Now, we allocate space
for those arguments in the outargs section so we don't have to
modify the SP.
Defers now use the stack pointer (instead of the argument pointer)
to identify which frame they are associated with.
A followon CL might simplify funcspdelta and some of the stack
walking code.
Fixes issue #8641
Change-Id: I835ec2f42f0392c5dec7cb0fe6bba6f2aed1dad8
Reviewed-on: https://go-review.googlesource.com/1601
Reviewed-by: Russ Cox <rsc@golang.org>
OpenBSD 5.5 changed its kernel ABI and OpenBSD 5.6 enabled it.
This CL works on both 5.5 and 5.6.
Fixes#9102.
Change-Id: I4a295be9ab8acbc99e550d8cb7e8f8dacf3a03c5
Reviewed-on: https://go-review.googlesource.com/1932
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Gccgo creates a struct to hold the arguments for the deferred
function. In this example the struct holds a type defined in a
different package. The bug was that gccgo tried to create an equality
function for this struct, and it implemented that function by calling
the equality function for the type defined in the other package.
Since that type is not exported, the reference to the equality
function failed at link time. Normally it is impossible for a struct
to directly contain a member that is an unexported type from another
package, but in this specific case it was possible. Fixed in gccgo
with https://codereview.appspot.com/183500043 .
Change-Id: I8ec3a33631225b9ac2a4ac060cb4d10b4635e60b
Reviewed-on: https://go-review.googlesource.com/1690
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Previously, this code generated bogus section indexes for dynamic
symbols. It turns out this didn't matter, since we only emit these
when generating an executable and in an executable it only matters
whether a symbol is defined or undefined, but it leads to perplexing
code full of mysterious constants.
Unfortunately, this happens too early to put in real section indexes,
so just use section index 1 to distinguish the symbol from an
undefined symbol.
Change-Id: I0e514604bf31f21683598ebd3e020b66acf767ef
Reviewed-on: https://go-review.googlesource.com/1720
Reviewed-by: Russ Cox <rsc@golang.org>
This will be used by ppc64 to add call stubs to the .text section.
ARM needs a similar pass to generate veneers for arm->thumb
transitions.
Change-Id: Iaee74036e60643a56fab15b564718f359c5910eb
Reviewed-on: https://go-review.googlesource.com/2004
Reviewed-by: Russ Cox <rsc@golang.org>
Disabled by default, but invaluable when you need it.
Change-Id: If4a75d11d14f70b6840d339aaec4b940dc406493
Reviewed-on: https://go-review.googlesource.com/2012
Reviewed-by: Russ Cox <rsc@golang.org>
* bug248, bug345, bug369, and bug429 were ported from bash commands to run scripts. bug369 remains disabled.
* bug395 is a test for issue 1909, which is still open. It is marked as skip now and will be usable with compile with run.go when issue 1909 is fixed.
Fixes#4139
Updates #1909
Change-Id: Ibb5fbfb5cf72ddc285829245318eeacd3fb5a636
Reviewed-on: https://go-review.googlesource.com/1774
Reviewed-by: Russ Cox <rsc@golang.org>
For arm and powerpc, as well as x86 without aes instructions.
Contains a mixture of ideas from cityhash and xxhash.
Compared to our old fallback on ARM, it's ~no slower on
small objects and up to ~50% faster on large objects. More
importantly, it is a much better hash function and thus has
less chance of bad behavior.
Fixes#8737
benchmark old ns/op new ns/op delta
BenchmarkHash5 173 181 +4.62%
BenchmarkHash16 252 212 -15.87%
BenchmarkHash64 575 419 -27.13%
BenchmarkHash1024 7173 3995 -44.31%
BenchmarkHash65536 516940 313173 -39.42%
BenchmarkHashStringSpeed 300 279 -7.00%
BenchmarkHashBytesSpeed 478 424 -11.30%
BenchmarkHashInt32Speed 217 207 -4.61%
BenchmarkHashInt64Speed 262 231 -11.83%
BenchmarkHashStringArraySpeed 609 631 +3.61%
Change-Id: I0a9335028f32b10ad484966e3019987973afd3eb
Reviewed-on: https://go-review.googlesource.com/1360
Reviewed-by: Russ Cox <rsc@golang.org>
Pointers to zero-sized values may end up pointing to the next
object in memory, and possibly off the end of a span. This
can cause memory leaks and/or confuse the garbage collector.
By putting the overflow pointer at the end of the bucket, we
make sure that pointers to any zero-sized keys or values don't
accidentally point to the next object in memory.
fixes#9384
Change-Id: I5d434df176984cb0210b4d0195dd106d6eb28f73
Reviewed-on: https://go-review.googlesource.com/1869
Reviewed-by: Russ Cox <rsc@golang.org>
