- 18 Jun, 2015 14 commits
-
-
Shenghou Ma authored
It's easy for someone who wants a time bigger than any valid time to reach for time.Unix(1<<63-1, 0), so it makes sense to explicit say such value is not valid. Fixes #10906 (again). Change-Id: If71e32472ae40d86c30e629b982406040a73c4c7 Reviewed-on: https://go-review.googlesource.com/10266Reviewed-by: Russ Cox <rsc@golang.org>
-
Davies Liu authored
The Slicing-By-8 [1] algorithm has much performance improvements than current approach. This patch only uses it for IEEE, which is the most common case in practice. There is the benchmark on Mac OS X 10.9: benchmark old MB/s new MB/s speedup BenchmarkIEEECrc1KB 349.40 353.03 1.01x BenchmarkIEEECrc4KB 351.55 934.35 2.66x BenchmarkCastagnoliCrc1KB 7037.58 7392.63 1.05x This algorithm need 8K lookup table, so it's enabled only for block larger than 4K. We can see about 2.6x improvement for IEEE. Change-Id: I7f786d20f0949245e4aa101d7921669f496ed0f7 Reviewed-on: https://go-review.googlesource.com/1863Reviewed-by: Russ Cox <rsc@golang.org>
-
Josh Bleecher Snyder authored
Fixes #11272. Change-Id: I78d666c20f4f7cb7116d37fd66b5f8b7d66c53c4 Reviewed-on: https://go-review.googlesource.com/11234Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Giulio Iotti authored
Check that if a version is declared, for example in '<?xml version="XX" ?>', version must be '1.0'. Change-Id: I16ba9f78873a5f31977dcf75ac8e671fe6c08280 Reviewed-on: https://go-review.googlesource.com/8961Reviewed-by: Russ Cox <rsc@golang.org>
-
Peter Waldschmidt authored
When the scanner receives a non-whitespace character in stateEndTop, it creates an error message and caches it to return on the next transition. nextValue() uses the scanner to sub-scan for a value inside a larger JSON structure. Since stateEndTop is triggered *after* the ending byte, whatever character immediately follows the sub-value gets pulled into the scanner's state machine as well. Even though it is not used and doesn't cause an error, it does cause the state machine to allocate an error that will never be used. The fix is to probe the state machine with whitespace after scanEndObject or scanEndArray to see if the next character would result in a scanEnd state transition. If so, we can return right away without processing the next character and avoid triggering an allocation. benchmark old ns/op new ns/op delta BenchmarkCodeEncoder 17022194 16611336 -2.41% BenchmarkCodeMarshal 18443250 18090144 -1.91% BenchmarkCodeDecoder 61502053 61010936 -0.80% BenchmarkCodeUnmarshal 61410829 60363605 -1.71% BenchmarkCodeUnmarshalReuse 59124836 58361772 -1.29% BenchmarkUnmarshalString 602 603 +0.17% BenchmarkUnmarshalFloat64 535 537 +0.37% BenchmarkUnmarshalInt64 482 482 +0.00% BenchmarkIssue10335 1206 799 -33.75% BenchmarkSkipValue 17605751 18355391 +4.26% BenchmarkEncoderEncode 612 604 -1.31% benchmark old MB/s new MB/s speedup BenchmarkCodeEncoder 114.00 116.82 1.02x BenchmarkCodeMarshal 105.21 107.27 1.02x BenchmarkCodeDecoder 31.55 31.81 1.01x BenchmarkCodeUnmarshal 31.60 32.15 1.02x BenchmarkSkipValue 111.63 107.07 0.96x benchmark old allocs new allocs delta BenchmarkIssue10335 11 4 -63.64% BenchmarkEncoderEncode 2 2 +0.00% benchmark old bytes new bytes delta BenchmarkIssue10335 376 272 -27.66% BenchmarkEncoderEncode 40 40 +0.00% Fixes #10335 Change-Id: I3d4f2b67f7a038adfb33ba48bb6b680f528baf18 Reviewed-on: https://go-review.googlesource.com/9074Reviewed-by: Russ Cox <rsc@golang.org>
-
Egon Elbre authored
Suggest running 'go help gopath' when the running 'go install .' and the folder is outside of GOPATH. Added link to 'https://golang.org/doc/code.html' in gopath help for more information. Example output: % go install . go install: no install location for directory f:\x\badmessage outside GOPATH please run 'go help gopath' for more information % go help gopath ... SNIP ... See https://golang.org/doc/code.html for an example. Fixes #8457 Change-Id: I0ef6ee3c65bb12af2168eafeb757258aa3835664 Reviewed-on: https://go-review.googlesource.com/9258Reviewed-by: Russ Cox <rsc@golang.org>
-
Shenghou Ma authored
Fixes #10734. Change-Id: I7a2c580b87749225668fbd7a005412c8eee6824d Reviewed-on: https://go-review.googlesource.com/9823Reviewed-by: Russ Cox <rsc@golang.org>
-
Michael Gehring authored
Check for errors when reading the headers following the pax headers. Fixes #11169. Change-Id: Ifec4a949ec8df8b49fa7cb7a67eb826fe2282ad8 Reviewed-on: https://go-review.googlesource.com/11031Reviewed-by: Russ Cox <rsc@golang.org>
-
Dmitry Vyukov authored
Return a meaningful message when a profile is empty. Also rename "IO blocking" to "Network blocking", currently only network blocking is captured. Fixes #11098 Change-Id: Ib6f1292b8ade4805756fcb6696ba1fca8f9f39a9 Reviewed-on: https://go-review.googlesource.com/11243Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitry Vyukov authored
There were two issues. 1. Delayed EvGoSysExit could have been emitted during TraceStart, while it had not yet emitted EvGoInSyscall. 2. Delayed EvGoSysExit could have been emitted during next tracing session. Fixes #10476 Fixes #11262 Change-Id: Iab68eb31cf38eb6eb6eee427f49c5ca0865a8c64 Reviewed-on: https://go-review.googlesource.com/9132Reviewed-by: Russ Cox <rsc@golang.org>
-
Nigel Tao authored
All the other error messages in this package are "lzw: etc". Change-Id: Ie359a8912d213f92b15f02abc953127380503048 Reviewed-on: https://go-review.googlesource.com/11228Reviewed-by: David Symonds <dsymonds@golang.org>
-
Alex Brainman authored
In preparation for rename of cgocall_errno into cgocall and asmcgocall_errno into asmcgocall in the fllowinng CL. rsc requested CL 9387 to be split into two parts. This is first part. Change-Id: I7434f0e4b44dd37017540695834bfcb1eebf0b2f Reviewed-on: https://go-review.googlesource.com/11166Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
Change-Id: Ib6d0b2947748dec98cad2e6abb6812cac46a9897 Reviewed-on: https://go-review.googlesource.com/11220Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
Work-around issue #11265 and re-enable tests for Plan9. Change-Id: I3aabb674a149b8eb936f948dd4cda5fd81454646 Reviewed-on: https://go-review.googlesource.com/11194 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 17 Jun, 2015 22 commits
-
-
Robert Griesemer authored
Replace custom solution with new (internal) library call. Change-Id: I53b26a1caf0684b9f5d8d749b10d9f3ba18a3001 Reviewed-on: https://go-review.googlesource.com/11193Reviewed-by: Damien Neil <dneil@google.com>
-
Robert Griesemer authored
Change-Id: I0e1aab2fe2340a1fbb7f377dbd7a72ea6f0477d8 Reviewed-on: https://go-review.googlesource.com/11153Reviewed-by: Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Change-Id: Ia9cbe3bfaa3e66c93d568d8beeed624b113d51a2 Reviewed-on: https://go-review.googlesource.com/11152Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
This change will brake the build. The immediately following change contains the necessary adjustments to make it work again. We're doing this in two steps to expose the manual changes applied. Change-Id: I225947da23e190b12e12cbd0c5e6e91628de7f53 Reviewed-on: https://go-review.googlesource.com/11151Reviewed-by: Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Change-Id: I376ff39594b532a5490f13e3985b7a6ff4b6761d Reviewed-on: https://go-review.googlesource.com/11191Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
-
Russ Cox authored
Change-Id: I389b2e10fe667eaa55f87b71b1e004994694d4a3 Reviewed-on: https://go-review.googlesource.com/11173Reviewed-by: Austin Clements <austin@google.com>
-
ALTree authored
Updates #11241 Change-Id: I9639c4f66cf805a57b087c9f648d3918df105d86 Reviewed-on: https://go-review.googlesource.com/11034Reviewed-by: Robert Griesemer <gri@golang.org>
-
Mikio Hara authored
Change-Id: Ia5c6d9fb114be65d7c20c7eb97ed696977051031 Reviewed-on: https://go-review.googlesource.com/11167Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
This fixes a hang during runtime.TestTraceStress. It also fixes double-scan of stacks, which leads to stack barrier installation failures. Both of these have shown up as flaky failures on the dashboard. Fixes #10941. Change-Id: Ia2a5991ce2c9f43ba06ae1c7032f7c898dc990e0 Reviewed-on: https://go-review.googlesource.com/11089Reviewed-by: Austin Clements <austin@google.com>
-
Ian Lance Taylor authored
Adjust timestamps in TestABIChecking to make sure that the library and executable are rebuilt when expected. Change-Id: I3288c254ba8201b5b4255347b0cb056fa0908657 Reviewed-on: https://go-review.googlesource.com/11128Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com> Reviewed-by: Yves Junqueira <yves.junqueira@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Change-Id: I0fcc35f43bc6059e6203af6134319cfc060c4b9a Reviewed-on: https://go-review.googlesource.com/11085Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Russ Cox authored
//go:systemstack means that the function must run on the system stack. Add one use in runtime as a demonstration. Fixes #9174. Change-Id: I8d4a509cb313541426157da703f1c022e964ace4 Reviewed-on: https://go-review.googlesource.com/10840Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
-
Yongjian Xu authored
Change-Id: I750900e0aed9ec528fea3f442c35196773e3ba5e Reviewed-on: https://go-review.googlesource.com/11163Reviewed-by: Minux Ma <minux@golang.org>
-
Mikio Hara authored
Change-Id: Ib0b0be901f2ed52e1b432ae62f0b1940eb27ecc3 Reviewed-on: https://go-review.googlesource.com/11137Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Jeremy Jackins authored
I updated some references to 6g, 6l and friends that I came across, as those programs don't exist anymore. I also fixed some echos in make.rc to match other make.* scripts while I was there. Change-Id: Ib84532cd4688cf65174dd9869e5d42af98a20a48 Reviewed-on: https://go-review.googlesource.com/11162Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Joe Tsai authored
Corrected several issues: * RFC1951 section 3.2.7 dictates that it is okay for the HDist tree to have a single code of zero bits. Furthermore, the behavior of the C zlib library permits empty trees even when there are more than one codes. * RFC1951 section 3.2.5 shows that HLit codes 286 and 287 are invalid. Thus, Go's implementation should choke on inputs using these codes. * RFC1951 section 3.2.5 and 3.2.7 are ambiguous about whether the number of HDist codes can be greater than 30. The C zlib library (which is the canonical reference implementation) performs this check here: https://github.com/madler/zlib/blob/62d6112a7981ad7c34f3b43cffdf00d4662a4f25/inflate.c#L906 In addition, a number of test cases were added to the unit tests that exercises these edge cases. The test cases listed in TestStreams will either fail or succeed in a manner matching the behaviour of the C zlib version. Given that the C zlib implementation is the reference for the world, Go's implementation should match C zlib behaviour. Fixes #11030 Change-Id: Ic24e4e40ce5832c7e1930249246e86d34bfedaa6 Reviewed-on: https://go-review.googlesource.com/11000Reviewed-by: Nigel Tao <nigeltao@golang.org>
-
Alex Brainman authored
Change-Id: If6dc3acdc023ac78f63e257974cd2d2e9f1cca10 Reviewed-on: https://go-review.googlesource.com/11161Reviewed-by: Andrew Gerrand <adg@golang.org>
-
David Chase authored
Also modified test/run.go to ignore messages prefixed <autogenerated> because those cannot be described with "// ERROR ...", and backed out patch from issue #9537 because it is no longer necessary. The reasons described in the 9537 discussion for why escape analysis cannot run late no longer hold, happily. Fixes #11053. Change-Id: Icb14eccdf2e8cde3d0f8fb8a216b765400a96385 Reviewed-on: https://go-review.googlesource.com/11088Reviewed-by: Russ Cox <rsc@golang.org> Run-TryBot: David Chase <drchase@google.com>
-
Alex Brainman authored
This change reintroduces CL 8523. CL 8523 was reverted because it broke darwin and netbsd builds. Now that this test is part of "go tool dist test" command we could skip OSes that fail. Updates #10360 Change-Id: Iaaeb5b800126492f36415a439c333a218fe4ab67 Reviewed-on: https://go-review.googlesource.com/11119Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Brainman authored
So the tests don't interfere with each other on windows. Fixes #11217 Change-Id: I4b3936bc64c95c7274298d6f137b24a28876b625 Reviewed-on: https://go-review.googlesource.com/11138Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Mikio Hara authored
This change allows LookupAddr to use getnameinfo through cgo for working together with various name services other than DNS. Fixes #7855. Change-Id: I5b3b4aefe3d1b904541c3350865734d8cbb1c1c4 Reviewed-on: https://go-review.googlesource.com/3420Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Hudson-Doyle authored
Change-Id: I854a093b9e1a62d2515ca114ee84956510925921 Reviewed-on: https://go-review.googlesource.com/10839Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 16 Jun, 2015 4 commits
-
-
Robert Griesemer authored
This flag is not needed in the std repo because we don't have tests requiring it. Remove it before it's frozen into the API. Change-Id: I18b861eea146ad67e7a3c26ee8be681d8065ef12 Reviewed-on: https://go-review.googlesource.com/11150Reviewed-by: Alan Donovan <adonovan@google.com>
-
Michael Hudson-Doyle authored
This makes the behaviour match what happens when duplicate symbols are read from regular object files and fixes errors about cgoAlwaysFalse when linking an executable that uses cgo against a shared library. Change-Id: Ibb8cd8fe3f7813cde504b7483f1e857868d7e063 Reviewed-on: https://go-review.googlesource.com/11117Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
David du Colombier authored
TestHostname was re-enabled in CL 10753. However, on Plan 9 the hostname is not obtained by executing a "hostname" command, but by reading the #c/sysname file. Change-Id: I80c0e303f4983fe39ceb300ad64e2c4a8392b695 Reviewed-on: https://go-review.googlesource.com/11033 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
Currently, when shrinkstack computes whether the halved stack allocation will have enough room for the stack, it accounts for the stack space that's actively in use but fails to leave extra room for the stack guard space. As a result, *if* the minimum stack size is small enough or the guard large enough, it may shrink the stack and leave less than enough room to run nosplit functions. If the next function called after the stack shrink is a nosplit function, it may overflow the stack without noticing and overwrite non-stack memory. We don't think this is happening under normal conditions right now. The minimum stack allocation is 2K and the guard is 640 bytes. The "worst case" stack shrink is from 4K (4048 bytes after stack barrier array reservation) to 2K (2016 bytes after stack barrier array reservation), which means the largest "used" size that will qualify for shrinking is 4048/4 - 8 = 1004 bytes. After copying, that leaves 2016 - 1004 = 1012 bytes of available stack, which is significantly more than the guard space. If we were to reduce the minimum stack size to 1K or raise the guard space above 1012 bytes, the logic in shrinkstack would no longer leave enough space. It's also possible to trigger this problem by setting firstStackBarrierOffset to 0, which puts stack barriers in a debug mode that steals away *half* of the stack for the stack barrier array reservation. Then, the largest "used" size that qualifies for shrinking is (4096/2)/4 - 8 = 504 bytes. After copying, that leaves (2096/2) - 504 = 8 bytes of available stack; much less than the required guard space. This causes failures like those in issue #11027 because func gc() shrinks its own stack and then immediately calls casgstatus (a nosplit function), which overflows the stack and overwrites a free list pointer in the neighboring span. However, since this seems to require the special debug mode, we don't think it's responsible for issue #11027. To forestall all of these subtle issues, this commit modifies shrinkstack to correctly account for the guard space when considering whether to halve the stack allocation. Change-Id: I7312584addc63b5bfe55cc384a1012f6181f1b9d Reviewed-on: https://go-review.googlesource.com/10714Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-