- 05 May, 2015 15 commits
-
-
Rob Pike authored
Fixes #9676. Change-Id: I32fe474cdfa09aff91daa4b10ac4df28ffdaa649 Reviewed-on: https://go-review.googlesource.com/9741Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Burcu Dogan authored
Change-Id: Ida727edb592e77918ca5511b41456786d57c97b2 Reviewed-on: https://go-review.googlesource.com/9634Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
Minux Ma authored
I just submitted the real fix for #10641. This reverts commit 3120adc2. Change-Id: I55051515f697e27ca887ed21c2ac985f0b9b062b Reviewed-on: https://go-review.googlesource.com/9720Reviewed-by:
Joel Sing <jsing@google.com>
-
Rob Pike authored
No semantic change. Fixes #8708. Change-Id: Ieda04a86a19bb69bfc2519d381a2f025e7cb8279 Reviewed-on: https://go-review.googlesource.com/9740Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
I forgot there is already a ptrSize constant. Rename field to avoid some confusion. Change-Id: I098fdcc8afc947d6c02c41c6e6de24624cc1c8ff Reviewed-on: https://go-review.googlesource.com/9700Reviewed-by:
Austin Clements <austin@google.com>
-
Rob Pike authored
The old one was inferior. Fixes #10695. Change-Id: Ia7fb88c9ceb1b10197b77a54f729865385288d98 Reviewed-on: https://go-review.googlesource.com/9709Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Rob Pike authored
When a parse error occurred, the lexing goroutine would lay idle. It's not likely a problem but if the program is for some reason accepting badly formed data repeatedly, it's wasteful. The solution is easy: Just drain the input on error. We know this will succeed because the input is always a string and is therefore guaranteed finite. With debugging prints in the package tests I've shown this is effective, shutting down 79 goroutines that would otherwise linger, out of 123 total. Fixes #10574. Change-Id: I8aa536e327b219189a7e7f604a116fa562ae1c39 Reviewed-on: https://go-review.googlesource.com/9658Reviewed-by:
Russ Cox <rsc@golang.org>
-
Keith Randall authored
Freezetheworld still has stuff to do when gomaxprocs=1. In particular, signals can come in on other Ms (like the GC M, say) and the single user M is still running. Fixes #10546 Change-Id: I2f07f17d1c81e93cf905df2cb087112d436ca7e7 Reviewed-on: https://go-review.googlesource.com/9551Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Mikio Hara authored
These a series of changes fix inconsistent errors on the package net APIs. Now almost all the APIs return OpError as a common error type except Lookup, Resolve and Parse APIs. The Lookup, Resolve and Parse APIs return more specific errors such as DNSError, AddrError or ParseError. An OpError may contain nested error information. For example, Dial may return an OpError containing a DNSError, AddrError, unexposed type/value or other package's type/value like the following: OpError{/* dial info */, Err: &DNSError{}} OpError{/* dial info */, Err: &AddrError{}} OpError{/* dial info */, Err: <unexposed type or value>} OpError{/* dial info */, Err: <other package's type or value>} and Read and Write may return an OpError containing other OpError when an application uses io.Copy or similar: OpError{/* for io.Reader */, Err: &OpError{/* for io.Writer */}} When an endpoint is created for connection-oriented byte-stream protocols, Read may return an io.EOF when the connection is closed by remote endpoint. Fixes #4856. A series of changes: - net: fix inconsistent error values on Dial, Listen partially https://go.googlesource.com/go/+/89b7c66d0d14462fd7893be4290bdfe5f9063ae1 - net: fix inconsistent error values on Read https://go.googlesource.com/go/+/ec1144423f45e010c72363fe59291d43214b6e31 - net: fix inconsistent error values on Write https://go.googlesource.com/go/+/11b5f98bf0d5eb8854f735cc332c912725070214 - net: fix inconsistent error values on Close https://go.googlesource.com/go/+/310db63c5bc121e7bfccb494c01a6b91a257e7fc - net: fix inconsistent error values on Accept https://go.googlesource.com/go/+/4540e162b1aefda8157372764ad3d290a414ef1d - net: fix inconsistent error values on File https://go.googlesource.com/go/+/885111365ba0a74421059bfbd18f4c57c1e70332 - net: fix inconsistent error values on setters https://go.googlesource.com/go/+/2173a27903897c481b0a0daf3ca3e0a0685701db - net: fix inconsistent error values on Interface https://go.googlesource.com/go/+/456cf0f22c93e1a6654980f4a48a564555f6c8a2 - net: fix inconsistent error values on Lookup https://go.googlesource.com/go/+/0fc582e87942b2e52bed751b6c56660ba99e9a7d - net: add Source field to OpError https://go.googlesource.com/go/+/afd2d2b6df3ebfe99faf347030f15adfdf422fa0 Change-Id: Id678e369088dc9fbe9073cfe7ff8a8754a57d61f Reviewed-on: https://go-review.googlesource.com/9236Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Change-Id: If84edfaec361ca2fbb75707c4ad30e4ce64f7013 Reviewed-on: https://go-review.googlesource.com/9664Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Shenghou Ma authored
When emulating ARM FSQRT instruction, the sqrt function itself should not use any floating point arithmetics, otherwise it will clobber the user software FP registers. Fortunately, the sqrt function only uses floating point instructions to test for corner cases, so it's easy to make that function does all it job using pure integer arithmetic only. I've verified that after this change, runtime.stepflt and runtime.sqrt doesn't contain any call to _sfloat. (Perhaps we should add //go:nosfloat to make the compiler enforce this?) Fixes #10641. Change-Id: Ida4742c49000fae4fea4649f28afde630ce4c576 Signed-off-by:
Shenghou Ma <minux@golang.org> Reviewed-on: https://go-review.googlesource.com/9570Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Keith Randall <khr@golang.org>
-
Nigel Tao authored
The spec at http://www.w3.org/Graphics/GIF/spec-gif89a.txt always says "color table" and not "color map". Change-Id: I4c172e3ade15618cbd616629822ce7d109a200af Reviewed-on: https://go-review.googlesource.com/9668Reviewed-by:
Rob Pike <r@golang.org>
-
Joel Sing authored
OSQRT currently produces incorrect results when used on arm with softfloat. Disable it on GOARM=5 until the actual problem is found and fixed. Updates #10641 Change-Id: Ia6f6879fbbb05cb24399c2feee93c1be21113e73 Reviewed-on: https://go-review.googlesource.com/9524Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net>
-
Shenghou Ma authored
Whenever we introduce a new GOARCH, older Go releases won't recognize them and this causes trouble for both our users and us (we need to add unnecessary build tags). Go 1.5 has introduced three new GOARCHes so far: arm64 ppc64 ppc64le, we can take the time to introduce GOARCHes for all common architectures that Go might support in the future to avoid the problem. Fixes #10165. Change-Id: Ida4f9112897cfb1e85b06538db79125955ad0f4c Reviewed-on: https://go-review.googlesource.com/9644Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Keith Randall authored
Fixes #10638 Change-Id: I7bbaad7e5a599aa94d1d158e903596231c7e9897 Reviewed-on: https://go-review.googlesource.com/9535Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com>
-
- 04 May, 2015 12 commits
-
-
Dave Cheney authored
Update #10652 This proposal deletes cmd/internal/ld.Biobuf and replaces all uses with cmd/internal/obj.Biobuf. As cmd/internal/ld already imported cmd/internal/obj there are no additional dependencies created. Notes: - ld.Boffset included more checks, so it was merged into obj.Boffset - obj.Bflush was removed in 8d16253c, so replaced all calls to ld.Bflush, with obj.Biobuf.Flush. - Almost all of this change was prepared with sed. Change-Id: I814854d52f5729a5a40c523c8188e465246b88da Reviewed-on: https://go-review.googlesource.com/9660Reviewed-by:
Keith Randall <khr@golang.org> Run-TryBot: Dave Cheney <dave@cheney.net>
-
Shenghou Ma authored
Change-Id: I3e839587626832da069d95a7d7389ea6bb2318da Reviewed-on: https://go-review.googlesource.com/9674Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
David du Colombier authored
Write should return ErrWriteAfterClose instead of ErrWriteTooLong when called after Close. Change-Id: If5ec4ef924e4c56489e0d426976f7e5fad79be9b Reviewed-on: https://go-review.googlesource.com/9259Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
This adds a field to the runtime type structure that records the size of the prefix of objects of that type containing pointers. Any data after this offset is scalar data. This is necessary for shrinking the type bitmaps to 1 bit and will help the garbage collector efficiently estimate the amount of heap that needs to be scanned. Change-Id: I1318d79e6360dca0ac980245016c562e61f52ff5 Reviewed-on: https://go-review.googlesource.com/9691Reviewed-by:
Russ Cox <rsc@golang.org> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Austin Clements authored
Move the one instance of type structure decoding in the linker that doesn't live decodesym.go in to decodesym.go. Change-Id: Ic6a23500deb72f0e9c8227ab611511e9781fac70 Reviewed-on: https://go-review.googlesource.com/9690Reviewed-by:
Russ Cox <rsc@golang.org>
-
Rob Pike authored
Fixes #10674. Change-Id: If3fae3244d87aeaa70815f499105c264394aa7ad Reviewed-on: https://go-review.googlesource.com/9657Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Rick Hudson authored
shouldtriggergc is slightly expensive due to the call overhead and the use of an atomic. This CL reduces the number of time one checks if a GC should be done from one at each allocation to once when a span is allocated. Since shouldtriggergc is an important abstraction simply hand inlining it, along with its atomic instruction would lose the abstraction. Change-Id: Ia3210655b4b3d433f77064a21ecb54e4d9d435f7 Reviewed-on: https://go-review.googlesource.com/9403Reviewed-by:
Austin Clements <austin@google.com>
-
Aymerick authored
At the end of lexInsideAction(), we return lexInsideAction: this is the default behaviour when we are still parsing an action. But some switch branches return lexInsideAction too. So let's ensure code consistency by always reaching the end of the lexInsideAction function when needed. Change-Id: I7e9d8d6e51f29ecd6db6bdd63b36017845d95368 Reviewed-on: https://go-review.googlesource.com/9441Reviewed-by:
Rob Pike <r@golang.org>
-
Keith Randall authored
We shouldn't sort the slots array, as it is used each time the test is run. Tests after the first should continue to use the unsorted ordering. Note that this doesn't fix the flaky test. Just a bug I saw while investigating. Change-Id: Ic03cca637829d569d50d3a2278d19410d4dedba9 Reviewed-on: https://go-review.googlesource.com/9637Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Nigel Tao authored
global color table. Change-Id: Ia38f75708ed5e5b430680a1eecafb4fc8047269c Reviewed-on: https://go-review.googlesource.com/9467Reviewed-by:
Rob Pike <r@golang.org>
-
David Symonds authored
The script was renamed in b3000b6f. Change-Id: I45ecafff7400e4bff14f31906278609abf2bcb9f Reviewed-on: https://go-review.googlesource.com/9667Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Shenghou Ma authored
Updates #8229. Change-Id: I3e691479d3659ed1b3ff8ebbb71b4fc03f2e67af Reviewed-on: https://go-review.googlesource.com/9680Reviewed-by:
Rob Pike <r@golang.org>
-
- 03 May, 2015 6 commits
-
-
Keith Randall authored
Noopt builds get a larger stack guard. This test must take that into account. Change-Id: I1b5cbafdbbfee8c369ae1bebd0b900524ebf0d7d Reviewed-on: https://go-review.googlesource.com/9610Reviewed-by:
Russ Cox <rsc@golang.org>
-
Shenghou Ma authored
Change-Id: Idc1aacddb79a9270265dd71fa6175539a5bed2c8 Reviewed-on: https://go-review.googlesource.com/9675Reviewed-by:
Minux Ma <minux@golang.org>
-
Shenghou Ma authored
Change-Id: Ia38256998e544d620a342dabedd9289d61fb0551 Reviewed-on: https://go-review.googlesource.com/9672Reviewed-by:
Dave Cheney <dave@cheney.net> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Rob Pike authored
Change-Id: Ie9331d102224290833c96a1535cdb96102a7fe9e Reviewed-on: https://go-review.googlesource.com/9633Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
Ideal constants in the template package are a little different from Go. This is a case that slipped through the cracks: A huge integer number was accepted as a floating-point number, but this loses precision and is confusing. Also, the code in the template package (as opposed to the parse package) wasn't expecting it. Root this out at the source: If an integer doesn't fit an int64 or uint64, complain right away. Change-Id: I375621e6f5333c4d53f053a3c84a9af051711b7a Reviewed-on: https://go-review.googlesource.com/9651Reviewed-by:
Russ Cox <rsc@golang.org>
-
Rob Pike authored
Followup to CL 9505 Change-Id: I1817b672723bd3d853283f388bc7cbaae2765acc Reviewed-on: https://go-review.googlesource.com/9652Reviewed-by:
Russ Cox <rsc@golang.org>
-
- 02 May, 2015 5 commits
-
-
Shenghou Ma authored
The siz argument to both runtime.newproc and runtime.deferproc is int32, not uintptr. This problem won't manifest on little-endian systems because that stack slot is uintptr sized anyway. However, on big-endian systems, it will make a difference. Change-Id: I2351d1ec81839abe25375cff95e327b80764c2b5 Reviewed-on: https://go-review.googlesource.com/9647 Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Didier Spezia authored
The current parser ignores obvious errors such as: {{0.1.E}} {{true.any}} {{"hello".wrong}} {{nil.E}} The common problem is that a chain is built from a literal value. It then panics at execution time. Furthermore, a double dot triggers the same behavior: {{..E}} Addresses a TODO left in Tree.operand to catch these errors at parsing time. Note that identifiers can include a '.', and pipelines could return an object which a field can be derived from (like a variable), so they are excluded from the check. Fixes #10615 Change-Id: I903706d1c17861b5a8354632c291e73c9c0bc4e1 Reviewed-on: https://go-review.googlesource.com/9621Reviewed-by:
Rob Pike <r@golang.org>
-
Dmitry Vyukov authored
There are three problems: 1. There is no CR at the end of the message. 2. The message is unconditionally printed. 3. The message is printed to stdout. Change-Id: Ib2d880eea03348e8a69720aad7752302a75bd277 Reviewed-on: https://go-review.googlesource.com/9622Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Shenghou Ma authored
Fixes #9232. Change-Id: I11a7fb7691d9e7473620db1b7fa29fec359c73d3 Reviewed-on: https://go-review.googlesource.com/9642Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
-
Alex Brainman authored
Change-Id: Ia9191bd7ecdf7bd5ee7d69ae23aa71760f379aa8 Reviewed-on: https://go-review.googlesource.com/9590Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
- 01 May, 2015 2 commits
-
-
Dave Cheney authored
This change applies CL 9365 to the copy of Biobuf in cmd/internal/obj. In the process I discovered that some of the methods that should have been checking the unget buffer before reading were not and it was probably just dumb luck that we handn't hit these issues before; Bungetc is only used in one place in cmd/internal/gc and only an unlikely code path. Change-Id: Ifa0c5c08442e9fe951a5078c6e9ec77a8a4dc2ff Reviewed-on: https://go-review.googlesource.com/9529Reviewed-by:
Daniel Morsing <daniel.morsing@gmail.com> Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Dave Cheney <dave@cheney.net> Run-TryBot: Dave Cheney <dave@cheney.net>
-
Brad Fitzpatrick authored
The test was measuring something, assuming other goroutines had already scheduled. Fixes #10427 Change-Id: I2a4d3906f9d4b5ea44b57d972e303bbe2b0b1cde Reviewed-on: https://go-review.googlesource.com/9561Reviewed-by:
David Crawshaw <crawshaw@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
-