- 16 Jun, 2014 1 commit
-
-
Rob Pike authored
Printf("%x", "abc") was "0x610x620x63"; is now "0x616263", which is surely better. Printf("% #x", "abc") is still "0x61 0x62 0x63". Fixes #8080. LGTM=bradfitz, gri R=golang-codereviews, bradfitz, gri CC=golang-codereviews https://golang.org/cl/106990043
-
- 14 Jun, 2014 3 commits
-
-
Alex Brainman authored
Fixes build. LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/105140047
-
Alan Shreve authored
Also added a test to verify os.Getppid() works across all platforms LGTM=alex.brainman R=golang-codereviews, alex.brainman, shreveal, iant CC=golang-codereviews https://golang.org/cl/102320044
-
Ian Lance Taylor authored
Generated by addca. R=gobot CC=golang-codereviews https://golang.org/cl/102410044
-
- 13 Jun, 2014 11 commits
-
-
Ian Lance Taylor authored
Reportedly in the Linux 3.16 kernel the VDSO will not have section headers or a normal symbol table. Too late for 1.3 but perhaps for 1.3.1, if there is one. Fixes #8197. LGTM=rsc R=golang-codereviews, mattn.jp, rsc CC=golang-codereviews https://golang.org/cl/101260044
-
Nigel Tao authored
algorithm. See https://golang.org/cl/105750045/ for an implementation of TIFF's LZW. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/102940043
-
Nigel Tao authored
bufio.Scanner.Scan returns whether the scan succeeded, not whether it is done, so the test was mistakenly breaking early. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/93670045
-
Andrew Gerrand authored
LGTM=minux R=golang-codereviews, minux CC=golang-codereviews https://golang.org/cl/102340044
-
Russ Cox authored
makes windows-amd64-race benchmarks slower ««« original CL description testing: make benchmarking faster Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice. Using the default benchtime, this CL reduces wall clock time to run benchmarks: net/http 49s -> 37s (-24%) runtime 8m31s -> 5m55s (-30%) bytes 2m37s -> 1m29s (-43%) encoding/json 29s -> 21s (-27%) strings 1m16s -> 53s (-30%) LGTM=crawshaw R=golang-codereviews, crawshaw CC=golang-codereviews https://golang.org/cl/101970047 »»» TBR=josharian CC=golang-codereviews https://golang.org/cl/105950044
-
Andrew Gerrand authored
LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/101270043
-
Russ Cox authored
It appears that something about Go on Windows cannot handle the fault cause by a jump to address 0. The way Go represents and calls functions, this never happened at all, until CL 105140044. This CL changes the code added in CL 105140044 to make jump to 0 impossible once again. Fixes #8047. (again, on Windows) TBR=bradfitz R=golang-codereviews, dave CC=adg, golang-codereviews, iant, r https://golang.org/cl/105120044
-
Rob Pike authored
R=rsc CC=golang-codereviews https://golang.org/cl/105930043
-
Russ Cox authored
LGTM=r R=r CC=golang-codereviews https://golang.org/cl/108950046
-
Russ Cox authored
CC=golang-codereviews https://golang.org/cl/103340046
-
Rob Pike authored
'u' is not micro, µ (U+00B5) is. LGTM=gri, bradfitz R=golang-codereviews, bradfitz, gri CC=golang-codereviews https://golang.org/cl/105030046
-
- 12 Jun, 2014 15 commits
-
-
Russ Cox authored
Rob asked for this change to make maintaining go1.4.txt easier. If you are not sure of a change, it is still okay to send for review. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/109880044
-
Russ Cox authored
jmpdefer modifies PC, SP, and LR, and not atomically, so walking past jmpdefer will often end up in a state where the three are not a consistent execution snapshot. This was causing warning messages a few frames later when the traceback realized it was confused, but given the right memory it could easily crash instead. Update #8153 LGTM=minux, iant R=golang-codereviews, minux, iant CC=golang-codereviews, r https://golang.org/cl/107970043
-
Russ Cox authored
Fixes #8047. LGTM=r, iant R=golang-codereviews, r, iant CC=dvyukov, golang-codereviews, khr https://golang.org/cl/105140044
-
Rob Pike authored
The test requires that timerproc runs, but busy loops and starves the scheduler so that, with high probability, timerproc doesn't run. Avoid the issue by expecting the test to succeed; if not, a major outside timeout will kill it and let us know. As you can see from the diffs, there have been several attempts to fix this with chicanery, but none has worked. Don't bother trying any more. Fixes #8136. LGTM=rsc R=rsc, josharian CC=golang-codereviews https://golang.org/cl/105140043
-
Brad Fitzpatrick authored
It should've been removed in https://golang.org/cl/9365044 Thanks to Jacek Masiulaniec for noticing. LGTM=ruiu R=ruiu CC=golang-codereviews https://golang.org/cl/109880043
-
Josh Bleecher Snyder authored
Allow the number of benchmark iterations to grow faster for fast benchmarks, and don't round up twice. Using the default benchtime, this CL reduces wall clock time to run benchmarks: net/http 49s -> 37s (-24%) runtime 8m31s -> 5m55s (-30%) bytes 2m37s -> 1m29s (-43%) encoding/json 29s -> 21s (-27%) strings 1m16s -> 53s (-30%) LGTM=crawshaw R=golang-codereviews, crawshaw CC=golang-codereviews https://golang.org/cl/101970047
-
Alan Donovan authored
Contains a link to /lib/godoc/analysis/help.html which is not yet live. LGTM=r R=r, adg CC=golang-codereviews https://golang.org/cl/88560044
-
Rui Ueyama authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/105890044
-
Rui Ueyama authored
Optimize IP.String, IPMask.String and ParseIP. benchmark old ns/op new ns/op delta BenchmarkParseIP 2216 1849 -16.56% BenchmarkIPString 7828 2486 -68.24% BenchmarkIPMaskString 3872 659 -82.98% LGTM=mikioh.mikioh, dave, bradfitz R=golang-codereviews, mikioh.mikioh, dave, bradfitz CC=golang-codereviews https://golang.org/cl/95750043
-
Rui Ueyama authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/104080043
-
Andrew Gerrand authored
Fixes #8168. TBR=bradfitz R=golang-codereviews CC=golang-codereviews https://golang.org/cl/107950043
-
Andrew Gerrand authored
TBR=bradfitz R=golang-codereviews CC=golang-codereviews https://golang.org/cl/104090044
-
Rui Ueyama authored
Call copy with as large buffer as possible to reduce the number of function calls. benchmark old ns/op new ns/op delta BenchmarkBytesRepeat 540 162 -70.00% BenchmarkStringsRepeat 563 177 -68.56% LGTM=josharian R=golang-codereviews, josharian, dave, dvyukov CC=golang-codereviews https://golang.org/cl/90550043
-
Rui Ueyama authored
Remove unnecessary blank line. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/105040045
-
Keith Randall authored
Make sure stack copier doesn't barf on a nil defer. Bug was fixed in https://golang.org/cl/101800043 This change just adds a test. Fixes #8047 LGTM=dvyukov, rsc R=dvyukov, rsc CC=golang-codereviews https://golang.org/cl/108840043
-
- 11 Jun, 2014 7 commits
-
-
Robert Griesemer authored
LGTM=adonovan R=rsc, adonovan CC=golang-codereviews https://golang.org/cl/104050045
-
Rui Ueyama authored
Previously, an input string was stripped of newline characters at the beginning of DecodeString and then passed to Decode. Decode again tried to strip newline characters. That's waste of time. benchmark old MB/s new MB/s speedup BenchmarkDecodeString 38.37 65.20 1.70x LGTM=dave, bradfitz R=golang-codereviews, dave, bradfitz CC=golang-codereviews https://golang.org/cl/91770051
-
Russ Cox authored
There is a hierarchy of location defined by loop depth: -1 = the heap 0 = function results 1 = local variables (and parameters) 2 = local variable declared inside a loop 3 = local variable declared inside a loop inside a loop etc In general if an address from loopdepth n is assigned to something in loop depth m < n, that indicates an extended lifetime of some form that requires a heap allocation. Function results can be local variables too, though, and so they don't actually fit into the hierarchy very well. Treat the address of a function result as level 1 so that if it is written back into a result, the address is treated as escaping. Fixes #8185. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108870044
-
Robert Griesemer authored
Pending CL 101750048. For submission after the 1.3 release. Fixes #8065. LGTM=adonovan R=adonovan CC=golang-codereviews https://golang.org/cl/93550043
-
Robert Griesemer authored
Provide Nextafter64 as alias to Nextafter. For submission after the 1.3 release. Fixes #8117. LGTM=adonovan R=adonovan CC=golang-codereviews https://golang.org/cl/101750048
-
Russ Cox authored
The analysis for &x was using the loop depth on x set during x's declaration. A type switch creates a list of implicit declarations that were not getting initialized with loop depths. Fixes #8176. LGTM=iant R=iant CC=golang-codereviews https://golang.org/cl/108860043
-
Shenghou Ma authored
LGTM=rsc R=dave, rsc CC=golang-codereviews https://golang.org/cl/105030043
-
- 10 Jun, 2014 3 commits
-
-
Brad Fitzpatrick authored
Fixes #8180 LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/105040043
-
Ian Lance Taylor authored
The putpclcdelta function set the DWARF line number PC to s->value + pcline->pc, which is correct, but the code then set the local variable pc to epc, which can be a different value. This caused the next delta in the DWARF table to be wrong. Fixes #8098. LGTM=rsc R=rsc CC=golang-codereviews https://golang.org/cl/104950045
-
Rob Pike authored
Fixes #8156. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/108840045
-