The spec defines precise numeric constants which do not overflow.
Consequently, +/-Inf and NaN values were excluded. The case was not
clear for -0.0 but they are mostly of interest to determine the sign
of infinities which don't exist.
That said, the conversion rules explicitly say that T(x) (for a numeric
x and floating-point type T) is the value after rounding per IEEE-754.
The result is constant if x is constant. Rounding per IEEE-754 can
produce a -0.0 which we cannot represent as a constant.
Thus, the spec is inconsistent. Attempt to fix the inconsistency by
adjusting the rounding rule rather than letting -0.0 into the language.
For more details, see the issue below.
Open to discussion.
Fixes#12576.
Change-Id: Ibe3c676372ab16d9229f1f9daaf316f761e074ee
Reviewed-on: https://go-review.googlesource.com/14727
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
access, connect, socket.
In Android-L, logging is done by writing the log messages to the logd
process through a unix domain socket.
Also, changed the arg types of those syscall stubs to match linux
programming APIs.
For golang/go#10743
Change-Id: I66368a03316e253561e9e76aadd180c2cd2e48f3
Reviewed-on: https://go-review.googlesource.com/15993
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Use a go:norace comment rather than having the compiler know the special
name syscall.forkAndExecInChild.
Change-Id: I69bc6aa6fc40feb2148d23f269ff32453696fb28
Reviewed-on: https://go-review.googlesource.com/16097
Reviewed-by: Minux Ma <minux@golang.org>
When I saw that it was labelled "legacy", I went looking for users of it
to see how it was still used. But there aren't any. Save the next person
the trouble.
Change-Id: I921dd6c57b60331c9816542272555153ac133c02
Reviewed-on: https://go-review.googlesource.com/16035
Reviewed-by: Dave Cheney <dave@cheney.net>
Run-TryBot: Dave Cheney <dave@cheney.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For printing, the format verb '%X' results in a capitalized
hex-representation of the formatted value. Conversely, using
'%X' in a Scanf function should scan a hex-representation
into the given interface{}. The existing implementation
however only supports '%X' for scanning hex values into
integers; strings or byte slices remain empty. On the other
hand, lower-case '%x' supports strings and byte slices just
fine. This is merely an oversight, which this commit fixes.
(Additional tests also included.)
Fixes#12940
Change-Id: I178a7f615bae950dfc014ca8c0a038448cf0452a
Reviewed-on: https://go-review.googlesource.com/15689
Reviewed-by: Andrew Gerrand <adg@golang.org>
* detect Content-Type on ReponseRecorder.Write[String] call
if header wasn't written yet, Content-Type header is not set and
Transfer-Encoding is not set.
* fix typos in serve_test.go
Updates #12986
Change-Id: Id2ed8b1994e64657370fed71eb3882d611f76b31
Reviewed-on: https://go-review.googlesource.com/16096
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is the start of wiring up the HTTP/2 Transport. It is still
disabled in this commit.
This change does two main things:
1) Transport.RegisterProtocol now permits registering "http" or
"https" (they previously paniced), and the semantics of the
registered RoundTripper have been extended to say that the new
sentinel error value (ErrSkipAltProtocol, added in this CL) means
that the Transport's RoundTrip method proceeds as if the alternate
protocol had not been registered. This gives us a place to register
an alternate "https" RoundTripper which gets first dibs on using
HTTP/2 if there's already a cached connection.
2) adds Transport.TLSNextProto, a map keyed by TLS NPN/ALPN protocol
strings, similar in feel to the existing Server.TLSNextProto map.
This map is the glue between the HTTP/1 and HTTP/2 clients, since
we don't know which protocol we're going to speak (and thus which
Transport type to use) until we've already made the TCP connection.
Updates #6891
Change-Id: I7328c7ff24f52d9fe4899facabf7ecc5dcb989f3
Reviewed-on: https://go-review.googlesource.com/16090
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
With this CL, httptest.Server now uses connection-level accounting of
outstanding requests instead of ServeHTTP-level accounting. This is
more robust and results in a non-racy shutdown.
This is much easier now that net/http.Server has the ConnState hook.
Fixes#12789Fixes#12781
Change-Id: I098cf334a6494316acb66cd07df90766df41764b
Reviewed-on: https://go-review.googlesource.com/15151
Reviewed-by: Andrew Gerrand <adg@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Just a comment change reflecting that the files were moved to the
builtin directory when the compiled was converted from C to Go.
Change-Id: I65e5340c09221684e40174feadfb69f738a9044a
Reviewed-on: https://go-review.googlesource.com/16089
Reviewed-by: Minux Ma <minux@golang.org>
This CL keeps disallowing `go get` from falling to the prompt unless
user has set GIT_TERMINAL_PROMPT env variable. If GIT_TERMINAL_PROMPT
is set, go-get will not override its value and will prompt for
username/password in the case of GIT_TERMINAL_PROMPT=1.
Fixes#12706.
Change-Id: Ibd6b1100af6b04fb8114279cdcf608943e7765be
Reviewed-on: https://go-review.googlesource.com/16091
Reviewed-by: Andrew Gerrand <adg@golang.org>
Building Go shared libraries requires that all functions that have declarations
without bodies have implementations and vice versa, so remove the
implementation of call16 and add a stub implementation of sigreturn.
Change-Id: I4d5a30c8637a5da7991054e151a536611d5bea46
Reviewed-on: https://go-review.googlesource.com/15966
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shared libraries on ppc64le will require a larger minimum stack frame (because
the ABI mandates that the TOC pointer is available at 24(R1)). Part 2b of
preparing for that is to have all the code in the linker that needs to know
this size of this call a function to find out.
Change-Id: I246363840096db22e44beabbe38b61d60c1f31ad
Reviewed-on: https://go-review.googlesource.com/15675
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only effect is register related: do not allocate R2 or R12, put function
entrypoint in R12 before indirect call.
Change-Id: I9cdd553bab022601c9cb5bb43c9dc0c368c6fb0a
Reviewed-on: https://go-review.googlesource.com/15961
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The __uint128_t type appears in darwin/arm header files processed by
cgo -godefs in http://golang.org/cl/16045.
Change-Id: I666194c65dee8ea0ae933d2f02a3abe4581c4697
Reviewed-on: https://go-review.googlesource.com/16046
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I cannot find any documentation for this, but these tests no longer run
on the device I have since upgrading to Android L. Presumably it still
works for root, but standard Android programs to not have root access.
Change-Id: I001c8fb5ce22f9ff8d7433f881d0dccbf6ab969d
Reviewed-on: https://go-review.googlesource.com/16056
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
These functions are always called together and perform logically
related state resets, so combine them in to just gcResetMarkState.
Fixes#11427.
Change-Id: I06c17ef65f66186494887a767b3993126955b5fe
Reviewed-on: https://go-review.googlesource.com/16041
Reviewed-by: Rick Hudson <rlh@golang.org>
Currently gcResetGState is called by func gcscan_m for concurrent GC
and directly by func gc for STW GC. Simplify this by consolidating
these two calls in to one call by func gc above where it splits for
concurrent and STW GC.
As a consequence, gcResetGState and gcResetMarkState are always called
together, so the next commit will consolidate these.
Change-Id: Ib62d404c7b32b28f7d3080d26ecf3966cbc4aca0
Reviewed-on: https://go-review.googlesource.com/16040
Reviewed-by: Rick Hudson <rlh@golang.org>
This work queue is no longer used (there are many reads of
work.partial, but the only write is in putpartial, which is never
called).
Fixes#11922.
Change-Id: I08b76c0c02a0867a9cdcb94783e1f7629d44249a
Reviewed-on: https://go-review.googlesource.com/15892
Reviewed-by: Rick Hudson <rlh@golang.org>
fmt docs say:
If the operand is a reflect.Value, the concrete value it
holds is printed as if it was the operand.
It implies recursive application of this rule, which is not the case.
Clarify the docs.
Change-Id: I019277c7c6439095bab83e5536aa06403638aa51
Reviewed-on: https://go-review.googlesource.com/15952
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also make PIE executables the default build mode, as PIE executables
are required as of Android L.
For #10807
Change-Id: I86b7556b9792105cd2531df1b8f3c8f7a8c5d25c
Reviewed-on: https://go-review.googlesource.com/16055
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
For #10807
Change-Id: Ied826d06cb622edf6413b6f2cdcc46987ab0b05a
Reviewed-on: https://go-review.googlesource.com/16054
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It was generating the wrong error message, always defaulting to "500
Internal Server Error", since the err variable used was always nil.
Fixes#12991
Change-Id: I94b0e516409c131ff3b878bcb91e65f0259ff077
Reviewed-on: https://go-review.googlesource.com/16060
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It appears this was made possible by commit 89f185f; before that, g was
not dereferenced above.
Change-Id: I70bc571d924b36351392fd4c13d681e938cfb573
Reviewed-on: https://go-review.googlesource.com/16033
Reviewed-by: Andrew Gerrand <adg@golang.org>
The flate library guarantees that the Reader will never read more
bytes than is necessary. This way, the underlying io.Reader will
be left exactly after the last byte of the DEFLATE stream.
Formats like gzip depend on this behavior being true.
As such, inflate conservatively reads the minimum symbol length in
huffSym leading to many individual calls to moreBits. However, if we
take advantage of the fact that every block *must* end with the EOB
symbol, we can choose to read the length of the EOB symbol.
Since the EOB symbol is also the most rare symbol (occuring exactly
once) in a block, we can hypothesize that it is almost as long as
the max symbol length, allowing huffSym to ask for more bits at the
start of every loop. This increases the probabilty that the Huffman
code is decoded on the first iteration of the outer for-loop.
benchmark old MB/s new MB/s speedup
BenchmarkDecodeDigitsSpeed1e4-4 51.05 54.31 1.06x
BenchmarkDecodeDigitsSpeed1e5-4 58.86 62.24 1.06x
BenchmarkDecodeDigitsSpeed1e6-4 59.63 63.13 1.06x
BenchmarkDecodeDigitsDefault1e4-4 51.94 54.61 1.05x
BenchmarkDecodeDigitsDefault1e5-4 63.70 69.13 1.09x
BenchmarkDecodeDigitsDefault1e6-4 66.08 71.43 1.08x
BenchmarkDecodeDigitsCompress1e4-4 52.25 54.56 1.04x
BenchmarkDecodeDigitsCompress1e5-4 63.34 68.30 1.08x
BenchmarkDecodeDigitsCompress1e6-4 66.84 70.64 1.06x
BenchmarkDecodeTwainSpeed1e4-4 50.74 53.40 1.05x
BenchmarkDecodeTwainSpeed1e5-4 60.77 67.03 1.10x
BenchmarkDecodeTwainSpeed1e6-4 62.08 69.78 1.12x
BenchmarkDecodeTwainDefault1e4-4 53.45 56.40 1.06x
BenchmarkDecodeTwainDefault1e5-4 73.54 79.05 1.07x
BenchmarkDecodeTwainDefault1e6-4 77.68 83.65 1.08x
BenchmarkDecodeTwainCompress1e4-4 53.21 56.15 1.06x
BenchmarkDecodeTwainCompress1e5-4 73.82 77.76 1.05x
BenchmarkDecodeTwainCompress1e6-4 79.23 83.30 1.05x
Change-Id: Ie194925c827988a380b8c2fdd13b13c4faa5d397
Reviewed-on: https://go-review.googlesource.com/15651
Reviewed-by: Nigel Tao <nigeltao@golang.org>
PIC code on ppc64le uses R2 as a TOC pointer and when calling a function
through a function pointer must ensure the function pointer is in R12. These
rules are easy enough to follow unconditionally in our assembly, so do that.
Change-Id: Icfc4e47ae5dfbe15f581cbdd785cdeed6e40bc32
Reviewed-on: https://go-review.googlesource.com/15526
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shared libraries on ppc64le will require a larger minimum stack frame (because
the ABI mandates that the TOC pointer is available at 24(R1)). Part 3 of that
is using a #define in the ppc64 assembly to refer to the size of the fixed
part of the stack (finding all these took me about a week!).
Change-Id: I50f22fe1c47af1ec59da1bd7ea8f84a4750df9b7
Reviewed-on: https://go-review.googlesource.com/15525
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shared libraries on ppc64le will require a larger minimum stack frame (because
the ABI mandates that the TOC pointer is available at 24(R1)). Part 2a of
preparing for that is to have all bits of arch-independent and ppc64-specific
codegen that need to know call a function to find out.
Change-Id: I55899f73037e92227813c491049a3bd6f30bd41f
Reviewed-on: https://go-review.googlesource.com/15524
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Shared libraries on ppc64le will require a larger minimum stack frame (because
the ABI mandates that the TOC pointer is available at 24(R1)). So to prepare
for this, make a constant for the fixed part of a stack and use that where
necessary.
Change-Id: I447949f4d725003bb82e7d2cf7991c1bca5aa887
Reviewed-on: https://go-review.googlesource.com/15523
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Replace the confusing game where a frame size of $-8 would suppress the
implicit setting up of a stack frame with a nice explicit flag.
The code to set up the function prologue is still a little confusing but better
than it was.
Change-Id: I1d49278ff42c6bc734ebfb079998b32bc53f8d9a
Reviewed-on: https://go-review.googlesource.com/15670
Reviewed-by: Minux Ma <minux@golang.org>
Go cannot allow lazy PLT resolution when calling between Go functions because
the lazy resolution can use more stack than is available. Lazy resolution is
disabled by passing -z now to the system linker, but unfortunately was only
passed when linking to a Go shared library. That sounds fine, but the shared
library containing the runtime is not linked to any other Go shared library but
calls main.init and main.main via a PLT, and before this fix this did use lazy
resolution. (For some reason this never caused a problem on intel, but it
breaks on ppc64le). Fortunately the fix is very simple: always pass -z now to
the system linker when dynamically linking Go.
Change-Id: I7806d40aac80dcd1e56b95864d1cfeb1c42614e2
Reviewed-on: https://go-review.googlesource.com/15870
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Current http client doesn't support Expect: 100-continue request
header(RFC2616-8/RFC7231-5.1.1). So even if the client have the header,
the head of the request body is consumed prematurely.
Those are my intentions to avoid premature consuming body in this change.
- If http.Request header contains body and Expect: 100-continue
header, it blocks sending body until it gets the first response.
- If the first status code to the request were 100, the request
starts sending body. Otherwise, sending body will be cancelled.
- Tranport.ExpectContinueTimeout specifies the amount of the time to
wait for the first response.
Fixes#3665
Change-Id: I4c04f7d88573b08cabd146c4e822061764a7cd1f
Reviewed-on: https://go-review.googlesource.com/10091
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes#7782Fixes#9554
Updates #7237 (original metabug, before we switched to specific bugs)
Updates #11932 (plan9 still doesn't have net I/O deadline support)
Change-Id: I96f311b88b1501d884ebc008fd31ad2cf1e16d75
Reviewed-on: https://go-review.googlesource.com/15941
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In net/parse.go we reimplement bytes.IndexByte and strings.IndexByte,
However those are implemented in runtime/$GOARCH_asm.s.
Using versions from runtime should provide performance advantage,
and keep the same code together.
Change-Id: I6212184bdf6aa1f2c03ce26d4b63f5b379d8ed0c
Reviewed-on: https://go-review.googlesource.com/15953
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A TODO to merge is removed from panic1.go.
The rest is appended to panic.go
Updates #12952
Change-Id: Ied4382a455abc20bc2938e34d031802e6b4baf8b
Reviewed-on: https://go-review.googlesource.com/15905
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Previously with db.maxOpen > 0, db.maxOpen+n failed connection attempts
started concurrently could result in a deadlock. DB.conn and
DB.openNewConnection did not trigger the DB.connectionOpener go routine
after a failed connection attempt. This omission could leave go routines
waiting for DB.connectionOpener forever.
In addition the logic to track the state of the pool was inconsistent.
db.numOpen was sometimes incremented optimistically and sometimes not.
This change harmonizes the logic and eliminates the db.pendingOpens
variable, making the logic easier to understand and maintain.
Fixes#10886
Change-Id: I983c4921a3dacfbd531c3d7f8d2da8a592e9922a
Reviewed-on: https://go-review.googlesource.com/14547
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
os/signal depends on a few unexported runtime functions. This removes the
assembly stubs it used to get access to these in favour of using
//go:linkname in runtime to make the functions accessible to os/signal.
This is motivated by ppc64le shared libraries, where you cannot BR to a symbol
defined in a shared library (only BL), but it seems like an improvment anyway.
Change-Id: I09361203ce38070bd3f132f6dc5ac212f2dc6f58
Reviewed-on: https://go-review.googlesource.com/15871
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Dave Cheney <dave@cheney.net>
