- 05 Oct, 2016 9 commits
-
-
Brad Fitzpatrick authored
Change-Id: I9783d8023d453a72c4605a308064bef98168bcb8 Reviewed-on: https://go-review.googlesource.com/30360Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Aliaksandr Valialkin authored
Fixes #17006 Change-Id: I3c2060ca5384a4b9782a7d804305d2cf4388dd5a Reviewed-on: https://go-review.googlesource.com/29014 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
Calling cgocallback from a signal handler can fail when using the race detector. Calling cgocallback will lead to a call to newextram which will call oneNewExtraM which will call racegostart. The racegostart function will set up some race detector data structures, and doing that will sometimes call the C memory allocator. If we are running the signal handler from a signal that interrupted the C memory allocator, we will crash or hang. Instead, change the signal handler code to call needm and dropm. The needm function will grab allocated m and g structures and initialize the g to use the current stack--the signal stack. That is all we need to safely call code that allocates memory and checks whether it needs to split the stack. This may temporarily leave us with no m available to run a cgo callback, but that is OK in this case since the code we call will quickly either crash or call dropm to return the m. Implementing this required changing some of the setSignalstackSP functions to avoid a write barrier. These functions never need a write barrier but in some cases generated one anyhow because on some systems the ss_sp field is a pointer. Change-Id: I3893f47c3a66278f85eab7f94c1ab11d4f3be133 Reviewed-on: https://go-review.googlesource.com/30218 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
-
Ian Lance Taylor authored
Change-Id: I56de359a5ccdc0a10925cd372fa86534353c6ca0 Reviewed-on: https://go-review.googlesource.com/30358 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Benchmarks broken off from https://golang.org/cl/24723 and modified to allocate less in the places we're not trying to measure. Updates #16791 Change-Id: I508e4cfeac60322d56f1d71ff1912f6a6f183a63 Reviewed-on: https://go-review.googlesource.com/30357 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Jeff R. Allen authored
All the prefixes of the testGIF produce errors today, but they differ wildly in which errors: some are io.EOF, others are io.ErrUnexpectedEOF, and others are gif-specific. Make them all gif-specific to explain context, and make any complaining about EOF be sure to mention the EOF is unexpected. Fixes #11390. Change-Id: I742c39c88591649276268327ea314e68d1de1845 Reviewed-on: https://go-review.googlesource.com/17493 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Russ Cox authored
Fixes #11441. Test tables generated by package main import ( "bytes" "fmt" "log" "os/exec" "strconv" "strings" ) var inputs = []float64{ 0.5, 1.5, 2.5, 3.5, -0.5, -1.5, -2.5, -3.5, 0.1, 0.01, 1e-8, 1e-16, 1e-3, 1e-16, 1e-308, 5.6e-309, 5.5e-309, 1e-309, 1e-323, 5e-324, -0.1, -0.01, -1e-8, -1e-16, -1e-3, -1e-16, -1e-308, -5.6e-309, -5.5e-309, -1e-300 / 1e9, -1e-300 / 1e23, -5e-300 / 1e24, -0.9999999999999999, -1.0000000000000002, -1.9999999999999998, -2.0000000000000004, -100.00000000000001, -99.999999999999986, 17, 171, 171.6, 171.624, 171.625, 172, 2000, -100.5, -160.5, -170.5, -171.5, -176.5, -177.5, -178.5, -179.5, -201.0001, -202.9999, -1000.5, -1000000000.3, -4503599627370495.5, -63.349078729022985, -127.45117632943295, } func main() { var buf bytes.Buffer for _, v := range inputs { fmt.Fprintf(&buf, "gamma(%.1000g)\n", v) } cmd := exec.Command("gp", "-q") cmd.Stdin = &buf out, err := cmd.CombinedOutput() if err != nil { log.Fatalf("gp: %v", err) } f := strings.Split(string(out), "\n") if len(f) > 0 && f[len(f)-1] == "" { f = f[:len(f)-1] } if len(f) != len(inputs) { log.Fatalf("gp: wrong output count\n%s\n", out) } for i, g := range f { gf, err := strconv.ParseFloat(strings.Replace(g, " E", "e", -1), 64) if err != nil { if strings.Contains(err.Error(), "value out of range") { if strings.HasPrefix(g, "-") { fmt.Printf("\t{%g, Inf(-1)},\n", inputs[i]) } else { fmt.Printf("\t{%g, Inf(1)},\n", inputs[i]) } continue } log.Fatal(err) } if gf == 0 && strings.HasPrefix(g, "-") { fmt.Printf("\t{%g, Copysign(0, -1)},\n", inputs[i]) continue } fmt.Printf("\t{%g, %g},\n", inputs[i], gf) } } Change-Id: Ie98c7751d92b8ffb40e8313f5ea10df0890e2feb Reviewed-on: https://go-review.googlesource.com/30146 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org>
-
Russ Cox authored
The 387 implementation is less accurate and slower. name old time/op new time/op delta Exp-8 29.7ns ± 2% 24.0ns ± 2% -19.08% (p=0.000 n=10+10) This makes Gamma more accurate too. Change-Id: Iad33b9cce0b087ccbce3e08ba7a6d285c4999d02 Reviewed-on: https://go-review.googlesource.com/30230 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Quentin Smith <quentin@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Joe Tsai authored
The documentation for doc says: > Doc prints the documentation comments associated with the item identified by its > arguments (a package, const, func, type, var, or method) followed by a one-line > summary of each of the first-level items "under" that item (package-level > declarations for a package, methods for a type, etc.). Certain variables (and constants, functions, and types) have value specifications that are multiple lines long. Prior to this change, doc would print out all of the lines necessary to display the value. This is inconsistent with the documented behavior, which guarantees a one-line summary for all first-level items. We fix this here by writing a general oneLineNode method that always returns a one-line summary (guaranteed!) of any input node. Packages like image/color/palette and unicode now become much more readable since large slices are now a single line. $ go doc image/color/palette <<< // Before: var Plan9 = []color.Color{ color.RGBA{0x00, 0x00, 0x00, 0xff}, color.RGBA{0x00, 0x00, 0x44, 0xff}, color.RGBA{0x00, 0x00, 0x88, 0xff}, ... // Hundreds of more lines! } var WebSafe = []color.Color{ color.RGBA{0x00, 0x00, 0x00, 0xff}, color.RGBA{0x00, 0x00, 0x33, 0xff}, color.RGBA{0x00, 0x00, 0x66, 0xff}, ... // Hundreds of more lines! } // After: var Plan9 = []color.Color{ ... } var WebSafe = []color.Color{ ... } >>> In order to test this, I ran `go doc` and `go doc -u` on all of the standard library packages and diff'd the output with and without the change to ensure that all differences were intended. Fixes #13072 Change-Id: Ida10b7796b7e4e174a929b55c60813a9eb7158fe Reviewed-on: https://go-review.googlesource.com/25420 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
- 04 Oct, 2016 27 commits
-
-
Kevin Burke authored
Change-Id: I3f13488605ab62eba5d3c59d5e9df1bcf69dd571 Reviewed-on: https://go-review.googlesource.com/30355Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
For #16339 Change-Id: I8927f40e0fd166795f41c784ad92449743f73af5 Reviewed-on: https://go-review.googlesource.com/30213Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For #16339. Change-Id: Ie2e3338b87e84f45cda0868213bbcd2dae9ab6e3 Reviewed-on: https://go-review.googlesource.com/30212Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For now, we also accept "type p = p.T" (using = instead of =>, for type aliases only), so we can experiment with an approach that only uses type aliases. This concession is implemened in the parser. For #16339 Change-Id: I88b5522a8b6cfc2e97ca146ede8b32af340220f8 Reviewed-on: https://go-review.googlesource.com/30211Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Robert Griesemer authored
For #16339. Change-Id: I0f83e46f13b5c8801aacf48fc8b690049edbbbff Reviewed-on: https://go-review.googlesource.com/30210Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Carl Mastrangelo authored
Also add a benchmark that shows off the new behavior. The existing benchmarks reuse the same slice, and thus don't ever have to clear memory. Running the Append|Grow benchmarks in runtime: name old time/op new time/op delta AppendSliceLarge/1024Bytes-12 265ns ± 1% 265ns ± 3% ~ (p=0.524 n=17+20) AppendSliceLarge/4096Bytes-12 807ns ± 3% 772ns ± 1% -4.38% (p=0.000 n=20+20) AppendSliceLarge/16384Bytes-12 3.20µs ± 4% 2.82µs ± 4% -11.93% (p=0.000 n=19+20) AppendSliceLarge/65536Bytes-12 13.0µs ± 4% 11.0µs ± 3% -15.22% (p=0.000 n=20+20) AppendSliceLarge/262144Bytes-12 62.7µs ± 1% 51.6µs ± 1% -17.67% (p=0.000 n=19+20) AppendSliceLarge/1048576Bytes-12 337µs ± 3% 289µs ± 3% -14.36% (p=0.000 n=20+20) GrowSliceBytes-12 31.2ns ± 4% 31.4ns ±11% ~ (p=0.308 n=19+18) GrowSliceInts-12 53.4ns ±14% 45.0ns ± 6% -15.74% (p=0.000 n=20+19) GrowSlicePtr-12 87.0ns ± 3% 83.3ns ± 3% -4.26% (p=0.000 n=18+17) GrowSliceStruct24Bytes-12 88.9ns ± 5% 77.8ns ± 2% -12.45% (p=0.000 n=20+19) Append-12 17.2ns ± 1% 17.3ns ± 2% ~ (p=0.464 n=18+17) AppendGrowByte-12 2.28ms ± 1% 1.92ms ± 2% -15.65% (p=0.000 n=20+18) AppendGrowString-12 255ms ± 3% 253ms ± 4% ~ (p=0.065 n=19+19) AppendSlice/1Bytes-12 3.13ns ± 0% 3.11ns ± 1% -0.65% (p=0.000 n=17+18) AppendSlice/4Bytes-12 3.02ns ± 2% 3.11ns ± 1% +3.27% (p=0.000 n=18+17) AppendSlice/7Bytes-12 4.14ns ± 3% 4.13ns ± 2% ~ (p=0.380 n=19+18) AppendSlice/8Bytes-12 3.74ns ± 3% 3.68ns ± 1% -1.76% (p=0.000 n=19+18) AppendSlice/15Bytes-12 4.03ns ± 2% 4.04ns ± 2% ~ (p=0.261 n=19+20) AppendSlice/16Bytes-12 4.03ns ± 2% 4.03ns ± 0% ~ (p=0.062 n=18+17) AppendSlice/32Bytes-12 3.23ns ± 4% 3.43ns ± 1% +6.10% (p=0.000 n=17+18) AppendStr/1Bytes-12 3.51ns ± 1% 3.52ns ± 1% ~ (p=0.321 n=18+19) AppendStr/4Bytes-12 3.46ns ± 1% 3.46ns ± 1% ~ (p=0.977 n=18+20) AppendStr/8Bytes-12 3.18ns ± 1% 3.19ns ± 1% ~ (p=0.650 n=16+17) AppendStr/16Bytes-12 6.08ns ±27% 5.52ns ± 3% -9.16% (p=0.002 n=18+19) AppendStr/32Bytes-12 3.71ns ± 1% 3.53ns ± 1% -4.73% (p=0.000 n=20+19) AppendSpecialCase-12 17.7ns ± 1% 17.8ns ± 3% +0.86% (p=0.045 n=17+18) AppendInPlace/NoGrow/Byte-12 375ns ± 1% 376ns ± 1% +0.35% (p=0.021 n=20+18) AppendInPlace/NoGrow/1Ptr-12 1.01µs ± 1% 1.10µs ± 1% +9.28% (p=0.000 n=18+20) AppendInPlace/NoGrow/2Ptr-12 1.85µs ± 2% 1.71µs ± 1% -7.51% (p=0.000 n=19+18) AppendInPlace/NoGrow/3Ptr-12 2.57µs ± 2% 2.44µs ± 1% -5.08% (p=0.000 n=19+19) AppendInPlace/NoGrow/4Ptr-12 3.52µs ± 2% 3.35µs ± 2% -4.70% (p=0.000 n=20+19) AppendInPlace/Grow/Byte-12 212ns ± 1% 217ns ± 8% +2.57% (p=0.000 n=20+20) AppendInPlace/Grow/1Ptr-12 214ns ± 2% 217ns ± 3% +1.23% (p=0.001 n=18+19) AppendInPlace/Grow/2Ptr-12 298ns ± 2% 300ns ± 2% +0.55% (p=0.038 n=19+20) AppendInPlace/Grow/3Ptr-12 367ns ± 2% 366ns ± 2% ~ (p=0.452 n=20+18) AppendInPlace/Grow/4Ptr-12 416ns ± 2% 411ns ± 2% -1.18% (p=0.000 n=20+19) StackGrowth-12 43.4ns ± 1% 43.4ns ± 0% ~ (p=1.000 n=16+16) StackGrowthDeep-12 11.4µs ± 4% 10.3µs ± 4% -9.65% (p=0.000 n=20+19) Change-Id: I69a8afbd942c787c591d95b9d9439bd6db4d1e49 Reviewed-on: https://go-review.googlesource.com/30192Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Matthew Dempsky authored
BlockCall was removed in golang.org/cl/28950. Change-Id: Ib8d9f3111bf3dc01956dd776afeb345ede8bc933 Reviewed-on: https://go-review.googlesource.com/30353Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Oleg Vakheta authored
Change-Id: Ie7b869892816a171d8c71612998cc32a190aeff9 Reviewed-on: https://go-review.googlesource.com/17227 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Passes toolstash/buildall. Change-Id: I928a2ef39fb10091957f35bb3f1564498f6f1b83 Reviewed-on: https://go-review.googlesource.com/30312 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Quentin Renard authored
Remove the use of io.ReadAll in http.parsePostForm to avoid converting the whole input from []byte to string and not performing well space-allocated-wise. Instead a new function called parsePostFormURLEncoded is used and is fed directly an io.Reader that is parsed using a bufio.Reader. Benchmark: name old time/op new time/op delta PostQuery-4 2.90µs ± 6% 2.82µs ± 4% ~ (p=0.094 n=9+9) name old alloc/op new alloc/op delta PostQuery-4 1.05kB ± 0% 0.90kB ± 0% -14.49% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PostQuery-4 6.00 ± 0% 7.00 ± 0% +16.67% (p=0.000 n=10+10) Fixes #14655 Change-Id: I112c263d4221d959ed6153cfe88bc57a2aa8ea73 Reviewed-on: https://go-review.googlesource.com/20301Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
Todd originally set cmpDepth to 4. Quoting: I picked a depth of 4 by timing tests of `go tool compile arithConst_ssa.go` and `go test -c net/http`. 3.89 / 3.92 CL w/cmpDepth = 1 3.78 / 3.92 CL w/cmpDepth = 2 3.44 / 3.96 CL w/cmpDepth = 3 3.29 / 3.9 CL w/cmpDepth = 4 3.3 / 3.93 CL w/cmpDepth = 5 3.29 / 3.92 CL w/cmpDepth = 10 I don't see the same behavior now, differences in those two benchmarks are in the noise (between 1 and 4). In issue 17127, CSE takes a really long time. Lowering cmpDepth from 4 to 1 lowers compile time from 8 minutes to 1 minute. Fixes #17127 Change-Id: I6dc544bbcf2a9dca73637d0182d3de1a5ae6c944 Reviewed-on: https://go-review.googlesource.com/30257 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
-
Daniel Theophanes authored
Missed one in the prior CL. Change-Id: I6f6d84d52fe4d902a985971a402701fb3b1eed86 Reviewed-on: https://go-review.googlesource.com/30255Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Robert Griesemer authored
Implementation of spec change https://golang.org/cl/24190/. For #16085. Change-Id: Ib7cb513354269282dfad663c7d2c6e624149f3cd Reviewed-on: https://go-review.googlesource.com/30191Reviewed-by: David Crawshaw <crawshaw@golang.org>
-
Robert Griesemer authored
Implementation of spec change https://golang.org/cl/24190/. For #16085. Change-Id: I17bbbce38d98a169bc64e84983a7ebfe7142f6e9 Reviewed-on: https://go-review.googlesource.com/30190Reviewed-by: Alan Donovan <adonovan@google.com>
-
Robert Griesemer authored
Implementation of spec change https://golang.org/cl/24190/. For #16085. Change-Id: Id71ef29af5031b073e8be163f578d1bb768ff97a Reviewed-on: https://go-review.googlesource.com/30169Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
Matthew Dempsky authored
Does not pass toolstash, but only because it causes ATYPE instructions to be emitted in a different order, and it avoids emitting type metadata for unused variables. Change-Id: I3ec8f66a40b5af9213e0d6e852b267a8dd995838 Reviewed-on: https://go-review.googlesource.com/30217 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Robert Griesemer authored
This is a backwards-compatible language change. Per the proposal (#16085), the rules for conversions are relaxed such that struct tags in any of the structs involved in the conversion are ignored (recursively). Because this is loosening the existing rules, code that compiled so far will continue to compile. For #16085. Fixes #6858. Change-Id: I0feef651582db5f23046a2331fc3f179ae577c45 Reviewed-on: https://go-review.googlesource.com/24190Reviewed-by: Russ Cox <rsc@golang.org>
-
Matthew Dempsky authored
Identify live stack variables during SSA and compute the stack frame layout earlier so that we can emit instructions with the correct offsets upfront. Passes toolstash/buildall. Change-Id: I191100dba274f1e364a15bdcfdc1d1466cdd1db5 Reviewed-on: https://go-review.googlesource.com/30216 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Keith Randall authored
Probably a holdover from linked list vs. slice. Change-Id: Ib2540b08ef0ae48707d44a5d57bc23f8d65c760d Reviewed-on: https://go-review.googlesource.com/30256 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dhananjay Nakrani authored
Currently, it separates comments from rest of the AST. This causes problems when long counter increment statements are added before compiler directives. See Issue #17315. This change moves comments handling into AST Visitor so that when printer prints code from AST, position of compiler directives relative to the associated function is preserved. Tested with https://gist.github.com/dhananjay92/837df6bc1f171b1350f85d7a7d59ca1e and unit test. Fixes #17315 Change-Id: I61a80332fc1923de6fc59ff63b953671598071fa Reviewed-on: https://go-review.googlesource.com/30161Reviewed-by: Rob Pike <r@golang.org>
-
Keith Randall authored
Fold MOVDaddr ops into MOVXstorezero ops. Also fold ADDconst into MOVDaddr so we're sure there isn't (MOVDstorezero (ADDconst (MOVDaddr ..))) Without this CL, we get: v1 = MOVDaddr {s} v2 = VARDEF {s} v3 = MOVDstorezero v1 v2 The liveness pass thinks the MOVDaddr is a read of s, so s is incorrectly thought to be live at the start of the function. Fixes #17194 Change-Id: I2b4a2f13b12aa5b072941ee1c7b89f3793650cdc Reviewed-on: https://go-review.googlesource.com/30086 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Michael Munday <munday@ca.ibm.com>
-
Brad Fitzpatrick authored
Wasn't convenient enough. Change-Id: I78270dc22cdb2e264641148e50029a9e4de953cd Reviewed-on: https://go-review.googlesource.com/30251 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Nick Craig-Wood authored
Change-Id: I8fd271066925734c3f7196f64db04f27c4ce27cb Reviewed-on: https://go-review.googlesource.com/30274Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Filippo Valsorda authored
The aim is to make the decrypt() timing profile constant, irrespective of the CBC padding length or correctness. The old algorithm, on valid padding, would only MAC bytes up to the padding length threshold, making CBC ciphersuites vulnerable to plaintext recovery attacks as presented in the "Lucky Thirteen" paper. The new algorithm Write()s to the MAC all supposed payload, performs a constant time Sum()---which required implementing a constant time Sum() in crypto/sha1, see the "Lucky Microseconds" paper---and then Write()s the rest of the data. This is performed whether the padding is good or not. This should have no explicit secret-dependent timings, but it does NOT attempt to normalize memory accesses to prevent cache timing leaks. Updates #13385 Change-Id: I15d91dc3cc6eefc1d44f317f72ff8feb0a9888f7 Reviewed-on: https://go-review.googlesource.com/18130 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
-
Brad Fitzpatrick authored
I avoided anywhere in the compiler or things which might be used by the compiler in the future, since they need to build with Go 1.4. I also avoided anywhere where there was no benefit to changing it. I probably missed some. Updates #16721 Change-Id: Ib3c895ff475c6dec2d4322393faaf8cb6a6d4956 Reviewed-on: https://go-review.googlesource.com/30250 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Mikio Hara authored
Fixes #7177. Change-Id: Iba6063905f4f9c6acef8aba76b55d996f186d835 Reviewed-on: https://go-review.googlesource.com/29892Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
-
Mikio Hara authored
golang.org/x/net/lif becomes vendor/golang_org/x/net/lif. At git rev 9f0e377 (golang.org/cl/29893) Updates #7177. Change-Id: Id838fcc234e71f735bb2609073f4c2214b48a970 Reviewed-on: https://go-review.googlesource.com/29891Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
- 03 Oct, 2016 4 commits
-
-
Mikio Hara authored
This change switches the use of socket implementation from the conventional SUS-based one to the latest POSIX-based one to make socket control message work correctly on Solaris. It looks like those two implementations, Socket over TLI/XTI and Socket, have different semantics in details but it wouldn't hurt the existing applications because the exposed syscall API doesn't support socket properties related to such a protocol independent application framework. Fixes #7402. Change-Id: I45a4e782d606bfbebe1404086c50a8c69af53461 Reviewed-on: https://go-review.googlesource.com/30171Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Munday authored
Reversed, indexed and multi-register stores/loads cannot accept SB inputs. Therefore if one of these Ops is an input to a rule any pointer that is an argument to that Op cannot be OpSB. Change-Id: Ib8048362d1c6277122afec0d13a1c905290d69cb Reviewed-on: https://go-review.googlesource.com/30131 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
-
Austin Clements authored
Change-Id: I422708d50c3c727246e7991039877660ca034dc9 Reviewed-on: https://go-review.googlesource.com/30144 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
In particular, it wasn't obvious that some values are special (unless you also found those special values), so document that it isn't necessarily a hash value. Change-Id: Iff292822b44408239e26cd882dc07be6df2c1d38 Reviewed-on: https://go-review.googlesource.com/30143 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-