Building for shared libraries requires that all functions that are declared
have an implementation and vice versa so make that so on arm64.
It would be nicer to not require the stub sigreturn (it will never be called)
but that seems a bit awkward.
Change-Id: I3cec81697161b452af81fa35939f748bd1acf7fd
Reviewed-on: https://go-review.googlesource.com/13995
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The parser tries to read as much information as possible,
issuing some errors when needed. Errors generally do not
stop the parsing.
With some pathological input, it may result in various
panics when the error message itself is built, or when the
next operand is parsed. It happens while parsing
pseudo-instructions.
For instance, the following lines all generate a panic:
TEXT
TEXT%
TEXT 1,1
TEXT $"toto", 0, $1
FUNCDATA
DATA 0
DATA(0),1
FUNCDATA(SB
GLOBL 0, 1
PCDATA 1
Added corresponding tests.
Introduced a writer in the parser to capture error messages
for testing purpose. It defaults to os.Stderr.
Added an explicit check when symbol names cannot be displayed.
Interrupted parsing early when the number of operands is wrong for
pseudo-instructions.
Note that the last point is a change of behavior, because some
operands will not get parsed anymore in case of early error.
IMO, it is acceptable, because only the first error of the line
is considered anyway. If it is not acceptable, it can probably
be improved at the price of a more verbose CL.
Fixes#11765Fixes#11760Fixes#11759
Change-Id: I9602a848132e358a1bccad794d7555e0823970dd
Reviewed-on: https://go-review.googlesource.com/13925
Reviewed-by: Rob Pike <r@golang.org>
Refine the documentation in cmd/doc and go help doc.
Fixes#12377.
Change-Id: I670c0a5cf18c9c9d5bb9bb222d8a3dd3722a3934
Reviewed-on: https://go-review.googlesource.com/14121
Reviewed-by: Andrew Gerrand <adg@golang.org>
Printing a function value is nearly useless outside of debugging, but
can occur by mistake when one forgets to call it. Diagnose this.
I did this myself just the other day and it arose in cl/14031.
Easy to fix and seems worthwhile.
Fixes#12295.
Change-Id: Ice125a84559f0394f7fa7272b5d31ae602b07f83
Reviewed-on: https://go-review.googlesource.com/14122
Reviewed-by: Andrew Gerrand <adg@golang.org>
At the moment, bootstrap.bash assumes it is called from a git working
copy. Hence, it fails to complete when running in an unpacked official
source tarball where .git and .gitignore do not exist. This fix adds a
test for existence for .git and a -f switch for the removal of
.gitignore.
Fixes#12223
Change-Id: I7f305b83b38d5115504932bd38dadb7bdeb5d487
Reviewed-on: https://go-review.googlesource.com/13770
Reviewed-by: Dave Cheney <dave@cheney.net>
Reviewed-by: Andrew Gerrand <adg@golang.org>
We could undoubtedly squeeze even more out of these loops, and in the
long term, a better compiler would be smarter with bounds checks, but in
the short term, this small change is an easy win.
benchmark old ns/op new ns/op delta
BenchmarkFillOver-8 1619470 1323192 -18.29%
BenchmarkCopyOver-8 1129369 1062787 -5.90%
BenchmarkGlyphOver-8 420070 378608 -9.87%
On github.com/golang/freetype/truetype's BenchmarkDrawString:
benchmark old ns/op new ns/op delta
BenchmarkDrawString-8 9561435 8807019 -7.89%
Change-Id: Ib1c6271ac18bced85e0fb5ebf250dd57d7747e75
Reviewed-on: https://go-review.googlesource.com/14093
Reviewed-by: Rob Pike <r@golang.org>
This may fix the flakiness on Windows/x64, assuming that it's actually
due to a variance in the connection time which slightly exceeds 100ms.
150ms + 95ms = 245ms, which is still low enough to avoid triggering
Happy Eyeballs (300ms) on non-Windows platforms.
Updates #12309
Change-Id: I816a36fbc0a3e5c90e3cf1b75a134faf0d91557c
Reviewed-on: https://go-review.googlesource.com/14120
Run-TryBot: Paul Marks <pmarks@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Update #10994
CASE and BCASE were used by 5c in switch statements, cmd/compile
does not use them.
Change-Id: I7a578c461b52b94690e35460926849b28971b770
Reviewed-on: https://go-review.googlesource.com/14009
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The hash tests generate occasional failures, quiet them some more.
In particular we can get 1 collision when the expected number is
.001 or so. That shouldn't be a dealbreaker.
Fixes#12311
Change-Id: I784e91b5d21f4f1f166dc51bde2d1cd3a7a3bfea
Reviewed-on: https://go-review.googlesource.com/13902
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Change-Id: If0d00999c58f7421e4da06e1822ba5abccf72cac
Reviewed-on: https://go-review.googlesource.com/14111
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 basic validation and should be performed early
Fixes#12412
Change-Id: I903f7eeafdc22376704985a53d649698cf9d8ef4
Reviewed-on: https://go-review.googlesource.com/14110
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#10994
CASE and BCASE were used by 7c in switch statements, cmd/compile
does not use them, cmd/assemble couldn't assemble them, and the arm64
peephole optimiser didn't know about them.
Change-Id: Id04835fcb37e207f76d211ce54a4db9c057d6112
Reviewed-on: https://go-review.googlesource.com/14100
Reviewed-by: Aram Hăvărneanu <aram@mgk.ro>
Run-TryBot: Aram Hăvărneanu <aram@mgk.ro>
TryBot-Result: Gobot Gobot <gobot@golang.org>
All implementations of File.read ensure that n >= 0. This is usually via
fixCount, except for Windows console reads, which only ever add to n.
Change-Id: Ic019d6a2da5ef1ac68d2690c908deca4fcc6b4a4
Reviewed-on: https://go-review.googlesource.com/12624
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This helps vet see a real issue:
cmd/internal/gc$ go vet
gen.go:1223: unreachable code
Fixes#12106.
Change-Id: I720868b07ae6b6d5a4dc6b238baa8c9c889da6d8
Reviewed-on: https://go-review.googlesource.com/14083
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
And clean up the mess on arm64 (the mess on arm is too confusing).
See issue #10050
Change-Id: I2ce813fe8646d4e818eb660612a7e4b2bb04de4c
Reviewed-on: https://go-review.googlesource.com/13884
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently the stack barrier stub blindly unwinds the next stack
barrier from the G's stack barrier array without checking that it's
the right stack barrier. If through some bug the stack barrier array
position gets out of sync with where we actually are on the stack,
this could return to the wrong PC, which would lead to difficult to
debug crashes. To address this, this commit adds a check to the amd64
stack barrier stub that it's unwinding the correct stack barrier.
Updates #12238.
Change-Id: If824d95191d07e2512dc5dba0d9978cfd9f54e02
Reviewed-on: https://go-review.googlesource.com/13948
Reviewed-by: Russ Cox <rsc@golang.org>
Currently enabling the debugging mode where stack barriers are
installed at every frame requires recompiling the runtime. However,
this is potentially useful for field debugging and for runtime tests,
so make this mode a GODEBUG.
Updates #12238.
Change-Id: I6fb128f598b19568ae723a612e099c0ed96917f5
Reviewed-on: https://go-review.googlesource.com/13947
Reviewed-by: Russ Cox <rsc@golang.org>
Currently the runtime can install stack barriers in any frame.
However, the frame of cgocallback_gofunc is special: it's the one
function that switches from a regular G stack to the system stack on
return. Hence, the return PC slot in its frame on the G stack is
actually used to save getg().sched.pc (so tracebacks appear to unwind
to the last Go function running on that G), and not as an actual
return PC for cgocallback_gofunc.
Because of this, if we install a stack barrier in cgocallback_gofunc's
return PC slot, when cgocallback_gofunc does return, it will move the
stack barrier stub PC in to getg().sched.pc and switch back to the
system stack. The rest of the runtime doesn't know how to deal with a
stack barrier stub in sched.pc: nothing knows how to match it up with
the G's stack barrier array and, when the runtime removes stack
barriers, it doesn't know to undo the one in sched.pc. Hence, if the C
code later returns back in to Go code, it will attempt to return
through the stack barrier saved in sched.pc, which may no longer have
correct unwinding information.
Fix this by blacklisting cgocallback_gofunc's frame so the runtime
won't install a stack barrier in it's return PC slot.
Fixes#12238.
Change-Id: I46aa2155df2fd050dd50de3434b62987dc4947b8
Reviewed-on: https://go-review.googlesource.com/13944
Reviewed-by: Russ Cox <rsc@golang.org>
https://tools.ietf.org/html/rfc7301#section-3.1 specifies that a
ProtocolName may not be empty. This change enforces this for ServerHello
messages—it's already enforced for ClientHello messages.
Change-Id: Ic5a5be6bebf07fba90a3cabd10b07ab7b4337f53
Reviewed-on: https://go-review.googlesource.com/12003
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In Go 1.5, Config.Certificates is no longer required if
Config.GetCertificate has been set. This change updated four comments to
reflect that.
Change-Id: Id72cc22fc79e931b2d645a7c3960c3241042762c
Reviewed-on: https://go-review.googlesource.com/13800
Reviewed-by: Adam Langley <agl@golang.org>
The existing implementation didn't use the CLMUL instructions for fast
and constant time binary-field multiplication. With this change, amd64
CPUs that support both AES and CLMUL instructions will use an optimised
asm implementation.
benchmark old ns/op new ns/op delta
BenchmarkAESGCMSeal8K 91723 3200 -96.51%
BenchmarkAESGCMOpen8K 91487 3324 -96.37%
BenchmarkAESGCMSeal1K 11873 546 -95.40%
BenchmarkAESGCMOpen1K 11833 594 -94.98%
benchmark old MB/s new MB/s speedup
BenchmarkAESGCMSeal8K 89.31 2559.62 28.66x
BenchmarkAESGCMOpen8K 89.54 2463.78 27.52x
BenchmarkAESGCMSeal1K 86.24 1872.49 21.71x
BenchmarkAESGCMOpen1K 86.53 1721.78 19.90x
Change-Id: Idd63233098356d8b353d16624747b74d0c3f193e
Reviewed-on: https://go-review.googlesource.com/10484
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Go 1.5 allowed TLS connections where Config.Certificates was nil as long
as the GetCertificate callback was given. However, tls.Listen wasn't
updated accordingly until this change.
Change-Id: I5f67f323f63c988ff79642f3daf8a6b2a153e6b2
Reviewed-on: https://go-review.googlesource.com/13801
Reviewed-by: Adam Langley <agl@golang.org>
Recursive types R containing slices of R's did not terminate despite the
effort in CL 10821.
For recursive types there was a competition between slice expansion by a
factor 'complexSize', and termination with probability '1/complexSize'
which lead to stack overflow as soon as a recursive struct had slices
pointing to its own type.
Fix this by shrinking the size hint as a function of recursion depth.
This has the dual effect of reducing the number of elements generated
per slice and also increasing the probability for termination.
Fixes#11148.
Change-Id: Ib61155b4f2e2de3873d508d63a1f4be759426d67
Reviewed-on: https://go-review.googlesource.com/13830
Reviewed-by: Adam Langley <agl@golang.org>
For primes which are 3 mod 4, using Tonelli-Shanks is slower
and more complicated than using the identity
a**((p+1)/4) mod p == sqrt(a)
For 2^450-2^225-1 and 2^10860-2^5430-1, which are 3 mod 4:
BenchmarkModSqrt225_TonelliTri 1000 1135375 ns/op
BenchmarkModSqrt225_3Mod4 10000 156009 ns/op
BenchmarkModSqrt5430_Tonelli 1 3448851386 ns/op
BenchmarkModSqrt5430_3Mod4 2 914616710 ns/op
~2.6x to 7x faster.
Fixes#11437 (which is a prime choice of issues to fix)
Change-Id: I813fb29454160483ec29825469e0370d517850c2
Reviewed-on: https://go-review.googlesource.com/11522
Reviewed-by: Adam Langley <agl@golang.org>
Val.Ctype used to be struct field, it's now a method.
Change-Id: I08f0b32b66dba15b2a392e84a557efb905b530cb
Reviewed-on: https://go-review.googlesource.com/14031
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The code is now in cmd/vendor/golang.org/x/arch.
Change-Id: I518d48c21b0d7fed914552b89ee41411f088456b
Reviewed-on: https://go-review.googlesource.com/14021
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For use by cmd/objdump in place of the current cmd/internal/rsc.io/... tree.
Change-Id: I7d765ddf43ab4118a3221fd755ff0a2a02daa5de
Reviewed-on: https://go-review.googlesource.com/13979
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Right now we find out implicitly if stack barriers are in place,
or defers. This change makes sure we find out about short
unwinds always.
Change-Id: Ibdde1ba9c79eb792660dcb7aa6f186e4e4d559b3
Reviewed-on: https://go-review.googlesource.com/13966
Reviewed-by: Austin Clements <austin@google.com>
Start go1.6.txt with a note that nacl ports are no longer
restricted to pepper_41 and a record of the text/template change.
Change-Id: I21dda64aec113c35caf1d565f29e3aac8171480a
Reviewed-on: https://go-review.googlesource.com/14004
Reviewed-by: Rob Pike <r@golang.org>
GetMUIStringValue tries as a convenience to resolve string values even for pathless
resource DLLs by searching the system directory (one of several paths used
by the system's standard DLL search order algorithm). This would not be
needed if regLoadMUIString searched for pathless DLLs itself, but it
doesn't, instead it needs an absolute path, otherwise it will fail.
This approach works fine for solving issue #12015 (handle localized time
zone names; for which GetMUIStringValue was created) since tzres.dll that
is used to resolve localized time zone names has no path in the registry
but is located under the system directory.
However, this approach will fail if a pathless DLL is located somewhere
else than the system directory.
Because of this limitation GetMUIStringValue may have to be revised in the
future to allow for custom paths, possibly through another version of the
function.
See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724890%28v=vs.85%29.aspxhttps://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx
Change-Id: Ida66a0ef1928e0461ce248c795827902d785e6cd
Reviewed-on: https://go-review.googlesource.com/13929
Reviewed-by: Rob Pike <r@golang.org>
