- 29 Sep, 2014 6 commits
-
-
Adam Langley authored
RFC5280 says that the nextUpdate field is optional. Fixes #8085. R=bradfitz CC=golang-codereviews https://golang.org/cl/149770044
-
Brad Fitzpatrick authored
Fixes #8607 LGTM=r R=r CC=golang-codereviews https://golang.org/cl/146470043
-
Adam Langley authored
LGTM=bradfitz R=bradfitz CC=golang-codereviews https://golang.org/cl/138000044
-
Adam Langley authored
LGTM=bradfitz, minux R=bradfitz, minux CC=golang-codereviews https://golang.org/cl/119540043
-
Jonathan Rudenberg authored
This prevents the temporary directory from being leaked when the linker is run on a FUSE filesystem. Fixes #8684. LGTM=bradfitz R=golang-codereviews, rsc, bradfitz CC=golang-codereviews https://golang.org/cl/141840043
-
Keith Randall authored
Fixes #8816 At least, I hope it does. TBR=rsc CC=golang-codereviews https://golang.org/cl/153730043
-
- 28 Sep, 2014 1 commit
-
-
Ian Lance Taylor authored
This fixes the bug in which the linker reports "missing Go type information" when a -X option refers to a symbol that is not used. Fixes #8821. LGTM=rsc R=rsc, r CC=golang-codereviews https://golang.org/cl/151000043
-
- 27 Sep, 2014 1 commit
-
-
Rob Pike authored
LGTM=iant R=golang-codereviews, bradfitz, iant CC=golang-codereviews https://golang.org/cl/150190043
-
- 26 Sep, 2014 21 commits
-
-
Russ Cox authored
The extra-clever code in Sincos is trying to do if v&2 == 0 { mask = 0xffffffffffffffff } else { mask = 0 } It does this by turning v&2 into a float64 X0 and then using MOVSD $0.0, X3 CMPSD X0, X3, 0 That CMPSD is defined to behave like: if X0 == X3 { X3 = 0xffffffffffffffff } else { X3 = 0 } which gives the desired mask in X3. The goal in using the CMPSD was to avoid a conditional branch. This code fails when called from a PortAudio callback. In particular, the failure behavior is exactly as if the CMPSD always chose the 'true' execution. Notice that the comparison X0 == X3 is comparing as floating point values the 64-bit pattern v&2 and the actual floating point value zero. The only possible values for v&2 are 0x0000000000000000 (floating point zero) and 0x0000000000000002 (floating point 1e-323, a denormal). If they are both comparing equal to zero, I conclude that in a PortAudio callback (whatever that means), the processor is running in "denormals are zero" mode. I confirmed this by placing the processor into that mode and running the test case in the bug; it produces the incorrect output reported in the bug. In general, if a Go program changes the floating point math modes to something other than what Go expects, the math library is not going to work exactly as intended, so we might be justified in not fixing this at all. However, it seems reasonable that the client code might have expected "denormals are zero" mode to only affect actual processing of denormals. This code has produced what is in effect a gratuitous denormal by being extra clever. There is nothing about the computation being requested that fundamentally requires a denormal. It is also easy to do this computation in integer math instead: mask = ((v&2)>>1)-1 Do that. For the record, the other math tests that fail if you put the processor in "denormals are zero" mode are the tests for Frexp, Ilogb, Ldexp, Logb, Log2, and FloatMinMax, but all fail processing denormal inputs. Sincos was the only function for which that mode causes incorrect behavior on non-denormal inputs. The existing tests check that the new assembly is correct. There is no test for behavior in "denormals are zero" mode, because I don't want to add assembly to change that. Fixes #8623. LGTM=josharian R=golang-codereviews, josharian CC=golang-codereviews, iant, r https://golang.org/cl/151750043
-
Russ Cox authored
CC=golang-codereviews https://golang.org/cl/144660043
-
Russ Cox authored
go test's handling of _test.go files when the entire package's set of files has no Test functions has varied over the past few releases. There are a few interesting cases (all contain no Test functions): (1) x_test.go has syntax errors (2) x_test.go has type errors (3) x_test.go has runtime errors (say, a func init that panics) In Go 1.1, tests with (1) or (2) failed; (3) passed. In Go 1.2, tests with (1) or (2) failed; (3) passed. In Go 1.3, tests with (1) failed; (2) or (3) passed. After this CL, tests with (1), (2), or (3) all fail. This is clearly a corner case, but it seems to me that the behavior of the test should not change if you add or remove a line like func TestAlwaysPasses(t *testing.T) {} That implies that the _test.go files must always be built and always be imported into the test binary. Doing so means that (1), (2), and (3) must all fail. Fixes #8337. LGTM=iant R=golang-codereviews, iant CC=adg, golang-codereviews, r https://golang.org/cl/150980043
-
Russ Cox authored
From issue 7967 I learned: 1) yacc accepts either 'x' or "x" to mean token value 0x78 2) yacc also accepts 'xyz' and "XYZ" to mean token value 0x78 Use strconv.Unquote to simplify the handling of quoted strings and check that each has only one rune. Although this does clean things up, it makes 'x' and "x" treated as different internally (now they are stored as `'x'` and `"x"`; before they were both ` x`). Grammars that use both interchangeably will now die with an error similar to the one from issue 7967: yacc bug -- cannot have 2 different Ts with same value "+" and '+' The echoing of the quotes should make clear what is going on. The other semantic change caused by using strconv.Unquote is that '\"' and "\'" are no longer valid. Like in Go, they must be spelled without the backslash: '"' and "'". On the other hand, now yacc and Go agree about what character and string literals mean. LGTM=r R=r CC=golang-codereviews https://golang.org/cl/149110043
-
Rob Pike authored
Fixes #7779. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/147210043
-
Russ Cox authored
The one line that you can't test easily was broken. This manifested as a failure of a pre-existing test in test.bash but I didn't notice it (there are a few other long-standing failures that need to be fixed). TBR=r CC=golang-codereviews https://golang.org/cl/146340044
-
Russ Cox authored
Today, 'go build -a my/pkg' and 'go install -a my/pkg' recompile not just my/pkg and all its dependencies that you wrote but also the standard library packages. Recompiling the standard library is problematic on some systems because the installed copy is not writable. The -a behavior means that you can't use 'go install -a all' or 'go install -a my/...' to rebuild everything after a Go release - the rebuild stops early when it cannot overwrite the installed standard library. During development work, however, you do want install -a to rebuild everything, because anything might have changed. Resolve the conflict by making the behavior of -a depend on whether we are using a released copy of Go or a devel copy. In the release copies, -a no longer applies to the standard library. In the devel copies, it still does. This is the latest in a long line of refinements to the "do I build this or not" logic. It is surely not the last. Fixes #8290. LGTM=r R=golang-codereviews, r, tracey.brendan CC=adg, golang-codereviews, iant https://golang.org/cl/151730045
-
Russ Cox authored
CC=golang-codereviews https://golang.org/cl/143650043
-
Alex Brainman authored
Fixes #8130. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/143200043
-
Russ Cox authored
This fixes the test/linkx.go test, which does not run by default. (Issue 4139 is about fixing that.) Fixes #8806. LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/145420043
-
Russ Cox authored
Also rebuild doc.go; was stale, so contains extra changes. Fixes #8677. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant https://golang.org/cl/148170043
-
Russ Cox authored
While we are here, remove undocumented, meaningless test -file flag. Fixes #7724. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant https://golang.org/cl/149070043
-
Russ Cox authored
Fix by atom (from CL 89190044), comment and test by me. Fixes #6823. LGTM=crawshaw R=golang-codereviews, crawshaw CC=0xe2.0x9a.0x9b, adg, golang-codereviews, iant, r https://golang.org/cl/148180043
-
Russ Cox authored
If you say 'go get -v' you get extra information when import paths are not of the expected form. If you say 'go get -v src/rsc.io/pdf' the message says that src/rsc.io/pdf does not contain a hostname, which is incorrect. The problem is that it does not begin with a hostname. Fixes #7432. LGTM=r R=golang-codereviews, r CC=bradfitz, golang-codereviews, iant https://golang.org/cl/144650043
-
Russ Cox authored
If you do 'go get -u rsc.io/pdf' and then rsc.io/pdf's redirect changes to point somewhere else, after this CL a later 'go get -u rsc.io/pdf' will tell you that. Fixes #8548. LGTM=iant R=golang-codereviews, iant CC=adg, golang-codereviews, n13m3y3r, r https://golang.org/cl/147170043
-
Russ Cox authored
The pattern was only working if the checkout had already been done, but the code was trying to make it work even the first time. Test and fix. Fixes #8335. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant https://golang.org/cl/146310043
-
Adam Langley authored
LGTM=r R=r, adg, rsc https://golang.org/cl/148080043
-
Andrew Gerrand authored
LGTM=r R=r, rsc, iant, agl https://golang.org/cl/142650045
-
Andrew Gerrand authored
LGTM=r R=r, rsc CC=golang-codereviews https://golang.org/cl/150100044
-
Rob Pike authored
I'd rather delete the file but I doubt that will be popular. LGTM=adg R=golang-codereviews, adg CC=golang-codereviews https://golang.org/cl/150100043
-
Rob Pike authored
LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://golang.org/cl/146320043
-
- 25 Sep, 2014 11 commits
-
-
Rob Pike authored
Fixes #8084. LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://golang.org/cl/142710043
-
Rob Pike authored
LGTM=0intro R=golang-codereviews, 0intro CC=golang-codereviews https://golang.org/cl/150960043
-
Russ Cox authored
Fixes #8242. LGTM=r R=golang-codereviews, r CC=golang-codereviews, iant https://golang.org/cl/147150043
-
Robert Griesemer authored
Fixes #7834. LGTM=iant, rsc, r R=r, rsc, iant, ken CC=golang-codereviews https://golang.org/cl/148940044
-
Robert Griesemer authored
Fixes #7886. LGTM=iant, r, rsc R=r, iant, rsc, ken CC=golang-codereviews https://golang.org/cl/149010043
-
Rob Pike authored
Fixes #8672. LGTM=rsc R=golang-codereviews, rsc CC=golang-codereviews https://golang.org/cl/145390043
-
Rob Pike authored
LGTM=bradfitz, josharian, adg, rsc R=golang-codereviews, bradfitz, josharian, rsc, adg CC=golang-codereviews https://golang.org/cl/141340043
-
Russ Cox authored
Fixes #7200. LGTM=gri, iant R=golang-codereviews, gri, iant CC=golang-codereviews, r https://golang.org/cl/150020044
-
Russ Cox authored
Fixes #8311. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/146270043
-
Russ Cox authored
Fixes #8507. LGTM=iant R=golang-codereviews, iant CC=golang-codereviews, r https://golang.org/cl/144560043
-
Keith Randall authored
Need to restore the g register. Somehow this line vaporized from CL 144130043. Also cgo_topofstack -> _cgo_topofstack, that vaporized also. TBR=rsc CC=golang-codereviews https://golang.org/cl/150940044
-