- 11 Feb, 2017 1 commit
-
-
Josh Bleecher Snyder authored
When running benchmarks with -cpuprofile, the entire process gets profiled, and ReadMemStats is surprisingly expensive. Running the sort benchmarks right now with -cpuprofile shows almost half of all execution time in ReadMemStats. Since ReadMemStats is not required if the benchmark does not need allocation stats, simply skip it. This will make cpu profiles nicer to read and significantly speed up the process of running benchmarks. It might also make sense to toggle cpu profiling on/off as we begin/end individual benchmarks, but that wouldn't get us the time savings of skipping ReadMemStats, so this CL is useful in itself. Change-Id: I425197b1ee11be4bc91d22b929e2caf648ebd7c5 Reviewed-on: https://go-review.googlesource.com/36791 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
- 10 Feb, 2017 26 commits
-
-
Nigel Tao authored
The 0x10101 magic constant is a little more principled than 0x10100, as the rounding adjustment now spans the complete range [0, 0xffff] instead of [0, 0xff00]. Consider this round-tripping code: y, cb, cr := color.RGBToYCbCr(r0, g0, b0) r1, g1, b1 := color.YCbCrToRGB(y, cb, cr) Due to rounding errors both ways, we often but not always get a perfect round trip (where r0 == r1 && g0 == g1 && b0 == b1). This is true both before and after this commit. In some cases we got luckier, in others we got unluckier. For example, before this commit, (180, 135, 164) doesn't round trip perfectly (it's off by 1) but (180, 135, 165) does. After this commit, both cases are reversed: the former does and the latter doesn't (again off by 1). Over all possible (r, g, b) triples, there doesn't seem to be a big change for better or worse. There is some history in these CLs: image/color: tweak the YCbCr to RGBA conversion formula. https://go-review.googlesource.com/#/c/12220/2/src/image/color/ycbcr.go image/color: have YCbCr.RGBA work in 16-bit color, per the Color interface. https://go-review.googlesource.com/#/c/8073/2/src/image/color/ycbcr.go Change-Id: Ib25ba7039f49feab2a9d1a4141b86db17db7b3e1 Reviewed-on: https://go-review.googlesource.com/36732 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Matthew Dempsky authored
Instead we can just call needwritebarrier when constructing the SSA representation. Change-Id: I6fefaad49daada9cdb3050f112889e49dca0047b Reviewed-on: https://go-review.googlesource.com/34566Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ian Lance Taylor authored
Fixes #18975. Change-Id: I60dfb299233ecfed4b2da93750ea84e7921f1fbb Reviewed-on: https://go-review.googlesource.com/36482 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc> Reviewed-by:
Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Bryan C. Mills authored
bradfitz noted in change 36717 that the new behavior was no longer comparable with the old. This change restores comparable behavior for -cpu=1. BenchmarkMapAddSame 909 909 +0.00% BenchmarkMapAddSame-6 1309 262 -79.98% BenchmarkMapAddDifferent 2856 3030 +6.09% BenchmarkMapAddDifferent-6 3803 581 -84.72% updates #18177 Change-Id: Ifaff5a1f48be92002d86c296220313b7efdc81d6 Reviewed-on: https://go-review.googlesource.com/36723Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Mark Adams authored
The existing implementation uses v1.0 of Bitbucket's REST API. The newer version 2.0 of Bitbucket's REST API provides the same information but with support for partial responses allowing the client to request only the response fields that are relevant to their usage of the API resulting in a much smaller payload size. The partial response functionality in the Bitbucket API is documented here: https://developer.atlassian.com/bitbucket/api/2/reference/meta/partial-response The v2.0 of the Bitbucket repositories API is documented here: https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D#get Fixes #18919 Change-Id: I319947d5c51adc241cfe3a2228a667cc43fb1f56 Reviewed-on: https://go-review.googlesource.com/36219 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by:
-
Alan Donovan authored
Change-Id: Ieb0808caa24c9a5e599084183ba5ee8a6536f7d8 Reviewed-on: https://go-review.googlesource.com/36622Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Sokolov Yura authored
So it could be inlined. Using bit-tricks it could be implemented without condition (improved trick version by Minux Ma). Simple benchmark shows it is faster on i386 and x86_64, though I don't know will it be faster on other architectures? benchmark old ns/op new ns/op delta BenchmarkFastrand-3 2.79 1.48 -46.95% BenchmarkFastrandHashiter-3 25.9 24.9 -3.86% Change-Id: Ie2eb6d0f598c0bb5fac7f6ad0f8b5e3eddaa361b Reviewed-on: https://go-review.googlesource.com/34782Reviewed-by:
Minux Ma <minux@golang.org> Run-TryBot: Minux Ma <minux@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Brad Fitzpatrick authored
If the user is calling SetGCPercent(-1), they intend to disable GC. They probably don't intend to run one. If they do, they can call runtime.GC themselves. Change-Id: I40ef40dfc7e15193df9ff26159cd30e56b666f73 Reviewed-on: https://go-review.googlesource.com/34013 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Austin Clements <austin@google.com>
-
Heschi Kreinick authored
During the mark phase of garbage collection, goroutines that allocate may be recruited to assist. This change creates trace events for mark assists and displays them similarly to sweep assists in the trace viewer. Mark assists are different than sweeps in that they can be preempted, so displaying them in the trace viewer is a little tricky -- we may need to synthesize multiple slices for one mark assist. This could have been done in the parser instead, but I thought it might be preferable to keep the parser as true to the event stream as possible. Change-Id: I381dcb1027a187a354b1858537851fa68a620ea7 Reviewed-on: https://go-review.googlesource.com/36015 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Hyang-Ah Hana Kim <hyangah@gmail.com>
-
Hajime Hoshi authored
Change-Id: Ib2109ab773fbf2a35188300cf91a54735f75fc7c Reviewed-on: https://go-review.googlesource.com/36736Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Bryan C. Mills authored
The other expvar tests are already parallelized, and this will help to measure the impact of potential implementations for #18177. updates #18177 Change-Id: I0f4f1a16a0285556cbcc8339855b6459af412675 Reviewed-on: https://go-review.googlesource.com/36717Reviewed-by:
-
Michael Hudson-Doyle authored
Otherwise, calling PtrTo on the result will fail. Fixes #19003 Change-Id: I8d7d1981a5d0417d5aee52740469d71e90734963 Reviewed-on: https://go-review.googlesource.com/36731 Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David R. Jenni authored
Change code of the form `i + (j-i)/2` to `int(uint(i+j) >> 1)`. The optimized average calculation uses fewer instructions to calculate the average without overflowing at the addition. Analogous to https://golang.org/cl/36332. name old time/op new time/op delta StableString1K-4 49.6µs ± 3% 49.1µs ± 8% ~ (p=0.659 n=16+19) StableInt1K-4 160µs ±10% 148µs ± 5% -7.29% (p=0.000 n=20+16) StableInt1K_Slice-4 139µs ± 4% 136µs ± 3% -2.52% (p=0.000 n=20+16) StableInt64K-4 8.84ms ± 6% 8.57ms ± 5% -3.07% (p=0.001 n=20+19) Stable1e2-4 162µs ±19% 147µs ±16% -8.79% (p=0.002 n=20+20) Stable1e4-4 31.0ms ± 5% 30.6ms ± 5% ~ (p=0.221 n=20+20) Stable1e6-4 6.37s ± 3% 6.27s ± 2% -1.67% (p=0.000 n=19+20) Change-Id: I1cea0bcb9ace8ef7e48b8fab772e41b4b2170da9 Reviewed-on: https://go-review.googlesource.com/36570 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Ilya Tocar authored
name old time/op new time/op delta Hash8Bytes-6 913ns ± 0% 667ns ± 0% -26.91% (p=0.000 n=10+10) Hash1K-6 6.58µs ± 0% 4.23µs ± 0% -35.69% (p=0.000 n=10+9) Hash8K-6 45.9µs ± 0% 28.1µs ± 0% -38.93% (p=0.000 n=10+10) name old speed new speed delta Hash8Bytes-6 8.76MB/s ± 0% 11.99MB/s ± 0% +36.87% (p=0.000 n=10+8) Hash1K-6 156MB/s ± 0% 242MB/s ± 0% +55.49% (p=0.000 n=10+9) Hash8K-6 178MB/s ± 0% 292MB/s ± 0% +63.74% (p=0.000 n=10+10) Change-Id: Ic9211d68b02935b2195995f264ec57d6bc36f713 Reviewed-on: https://go-review.googlesource.com/36630 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
The code previously tested only whether DNS-name SANs were present in a certificate which is only approximately correct. In fact, /any/ SAN extension, including one with no DNS names, should cause the CN to be ignored. Change-Id: I3d9824918975be6d4817e7cbb48ed1b0c5a2fc8b Reviewed-on: https://go-review.googlesource.com/36696 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Michael Munday authored
The s390x port was based on the ppc64 port and, because of the way the port was done, inherited some instructions from it. ppc64 supports 3-operand (4-operand for FMADD etc.) floating point instructions but s390x doesn't (the destination register is always an input) and so these were emulated. There is a bug in the emulation of FMADD whereby if the destination register is also a source for the multiplication it will be clobbered. This doesn't break any assembly code in the std lib but could affect future work. To fix this I have gone through the floating point instructions and removed all unnecessary 3-/4-operand emulation. The compiler doesn't need it and assembly writers don't need it, it's just a source of bugs. I've also deleted the FNMADD family of emulated instructions. They aren't used anywhere. Change-Id: Ic07cedcf141a6a3b43a0c84895460f6cfbf56c04 Reviewed-on: https://go-review.googlesource.com/33350 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
Unlike the pure go implementation used by every other architecture, the amd64 asm implementation of Exp does not fail early if the argument is known to overflow. Make it fail early. Cost of the check is < 1ns (on an old Sandy Bridge machine): name old time/op new time/op delta Exp-4 18.3ns ± 1% 18.7ns ± 1% +2.08% (p=0.000 n=18+20) Fixes #14932 Fixes #18912 Change-Id: I04b3f9b4ee853822cbdc97feade726fbe2907289 Reviewed-on: https://go-review.googlesource.com/36271 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by:
-
Tuo Shan authored
Fixes #18730. Change-Id: If3ef28e62f7e449d4c8dc1dfd78f7d6f5a87ed26 Reviewed-on: https://go-review.googlesource.com/36478Reviewed-by:
-
Daniel Theophanes authored
Previously if a connection was requested but timed out during the request and when acquiring the db.Lock the connection request is fulfilled and the request is unable to be returned to the connection pool, then then driver connection would not be closed. No tests were added or modified because I was unable to determine how to trigger this situation without something invasive. Change-Id: I9d4dc680e3fdcf63d79d212174a5b8b313f363f1 Reviewed-on: https://go-review.googlesource.com/36641Reviewed-by:
-
Russ Cox authored
These are very tightly coupled, and internal/protopprof is small. There's no point to having a separate package. Change-Id: I2c8aa49c9e18a7128657bf2b05323860151b5606 Reviewed-on: https://go-review.googlesource.com/36711 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nigel Tao authored
This is a re-roll of a previous commit, a855da29, which was rolled back in 14347ee4. It was rolled back because it broke a unit test in image/gif. The image/gif code was fixed by 9ef65dbe "image/gif: fix frame-inside-image bounds checking". The original commit message: image: fix the overlap check in Rectangle.Intersect. The doc comment for Rectangle.Intersect clearly states, "If the two rectangles do not overlap then the zero rectangle will be returned." Prior to this fix, calling Intersect on adjacent but non-overlapping rectangles would return an empty but non-zero rectangle. The fix essentially changes if r.Min.X > r.Max.X || r.Min.Y > r.Max.Y { etc } to if r.Min.X >= r.Max.X || r.Min.Y >= r.Max.Y { etc } (note that the > signs have become >= signs), but changing that line to: if r.Empty() { etc } seems clearer (and equivalent). Change-Id: I2e3af1f1686064a573b2e513b39246fe60c03631 Reviewed-on: https://go-review.googlesource.com/36734Reviewed-by:
-
Josh Bleecher Snyder authored
CL 35554 taught order.go to use static variables for constants that needed to be addressable for runtime routines. However, there is one class of runtime routines that do not actually need an addressable value: fast map access routines. This CL teaches order.go to avoid using static variables for addressability in those cases. Instead, it avoids introducing a temp at all, which the backend would just have to optimize away. Fixes #19015. Change-Id: I5ef780c604fac3fb48dabb23a344435e283cb832 Reviewed-on: https://go-review.googlesource.com/36693Reviewed-by:
Keith Randall <khr@golang.org> Reviewed-by:
-
Nigel Tao authored
The semantics of the Go image.Rectangle type is that the In and Intersects methods treat empty rectangles specially. There are multiple valid representations of an empty image.Rectangle. One of them is the zero image.Rectangle but there are others. They're obviously not all equal in the == sense, so we shouldn't use != to check GIF's semantics. This change will allow us to re-roll a855da29 "image: fix the overlap check in Rectangle.Intersect" which was rolled back in 14347ee4. Change-Id: Ie1a0d092510a7bb6170e61adbf334b21361ff9e6 Reviewed-on: https://go-review.googlesource.com/36639 Run-TryBot: Nigel Tao <nigeltao@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Nathan Caza authored
The current implementation fails to produce an "IsNotExist" error on some platforms (unix) for certain situations where it would be expected. This causes downstream consumers, like FileServer, to emit 500 errors instead of a 404 for some non-existant paths on certain platforms but not others. As an example, os.Open("/index.html/foo") on a unix-type system will return syscall.ENOTDIR, which os.IsNotExist cannot return true for (because the error code is ambiguous without context). On windows, this same example would result in os.IsNotExist returning true -- since the returned error is specific. This change alters Dir.Open to look up the tree for an "IsPermission" or "IsNotExist" error to return, or a non-directory, returning os.ErrNotExist in the last case. For all other error scenarios, the original error is returned. This ensures that downstream code, like FileServer, receive errors that behave the same across all platforms. Fixes #18984 Change-Id: Id7d16591c24cd96afddb6d8ae135ac78da42ed37 Reviewed-on: https://go-review.googlesource.com/36635Reviewed-by:Yasuhiro MATSUMOTO <mattn.jp@gmail.com> Reviewed-by:
-
Robert Griesemer authored
We missed this in https://golang.org/cl/36213. Thanks to Chris Hines for pointing it out. For #18130. Change-Id: I6279ab19966c4391c4b4458b21fd2527d3f949dd Reviewed-on: https://go-review.googlesource.com/36691Reviewed-by:
-
Robert Griesemer authored
The gcCompat mode was introduced to match the new parser's node position setup exactly with the positions used by the original parser. Some of the gcCompat adjustments were required to satisfy syntax error test cases, and the rest were required to make toolstash cmp pass. This change removes the former gcCompat adjustments and instead adjusts the respective test cases as necessary. In some cases this makes the error lines consistent with the ones reported by gccgo. Where it has changed, the position associated with a given syntactic construct is the position (line/col number) of the left-most token belonging to the construct. Change-Id: I5b60c00c5999a895c4d6d6e9b383c6405ccf725c Reviewed-on: https://go-review.googlesource.com/36695 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 09 Feb, 2017 13 commits
-
-
Adam Langley authored
This change contains a very minor tidy-up to a test. Change-Id: I3a8c0168bcdcbf90cacbbac2566c8423c92129f8 Reviewed-on: https://go-review.googlesource.com/33726Reviewed-by:
Adam Langley <agl@golang.org> Reviewed-by:
-
Austin Clements authored
go:systemstack works by tweaking the stack check prologue to check against a different bound, while go:nosplit removes the stack check prologue entirely. Hence, they can't be used together. Make the build fail if they are. Change-Id: I2d180c4b1d31ff49ec193291ecdd42921d253359 Reviewed-on: https://go-review.googlesource.com/36710 Run-TryBot: Austin Clements <austin@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Paulo Flabiano Smorigo authored
Recently, a commit (85ecc51c) changed the instruction from VORL to VOR. Fixes #19014 Change-Id: I9a7e0b5771842b1abb5afc73dc41d5e7960cf390 Reviewed-on: https://go-review.googlesource.com/36625 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Bryan C. Mills authored
TestRPC writes to newServer and newServerAddr guarded with a sync.Once. TestAcceptExitAfterListenerClose was overwriting those variables, which caused the second invocation of TestRPC within a single process to fail. A second invocation can occur as a result of running the test with multiple values for the -cpu flag. fixes #19001. Change-Id: I291bacf44aefb49c2264ca0290a28248c026f80e Reviewed-on: https://go-review.googlesource.com/36624Reviewed-by:
-
Josh Bleecher Snyder authored
Pick up a few pennies: * CSE gets run twice for each function, but the set of Aux values doesn't change. Avoid populating it twice. * Don't bother populating auxmap for values that can't be CSE'd anyway. name old alloc/op new alloc/op delta Template 41.0MB ± 0% 40.7MB ± 0% -0.61% (p=0.008 n=5+5) Unicode 32.3MB ± 0% 32.3MB ± 0% -0.22% (p=0.008 n=5+5) GoTypes 122MB ± 0% 121MB ± 0% -0.55% (p=0.008 n=5+5) Compiler 482MB ± 0% 479MB ± 0% -0.58% (p=0.008 n=5+5) SSA 865MB ± 0% 862MB ± 0% -0.35% (p=0.008 n=5+5) Flate 26.5MB ± 0% 26.5MB ± 0% ~ (p=0.056 n=5+5) GoParser 32.6MB ± 0% 32.4MB ± 0% -0.58% (p=0.008 n=5+5) Reflect 84.2MB ± 0% 83.8MB ± 0% -0.57% (p=0.008 n=5+5) Tar 27.7MB ± 0% 27.6MB ± 0% -0.37% (p=0.008 n=5+5) XML 44.7MB ± 0% 44.5MB ± 0% -0.53% (p=0.008 n=5+5) name old allocs/op new allocs/op delta Template 373k ± 0% 373k ± 1% ~ (p=1.000 n=5+5) Unicode 326k ± 0% 325k ± 0% ~ (p=0.548 n=5+5) GoTypes 1.16M ± 0% 1.16M ± 0% ~ (p=0.841 n=5+5) Compiler 4.16M ± 0% 4.15M ± 0% ~ (p=0.222 n=5+5) SSA 7.57M ± 0% 7.56M ± 0% -0.22% (p=0.008 n=5+5) Flate 238k ± 1% 239k ± 1% ~ (p=0.690 n=5+5) GoParser 304k ± 0% 304k ± 0% ~ (p=1.000 n=5+5) Reflect 1.01M ± 0% 1.00M ± 0% -0.31% (p=0.016 n=4+5) Tar 245k ± 0% 245k ± 1% ~ (p=0.548 n=5+5) XML 393k ± 0% 391k ± 1% ~ (p=0.095 n=5+5) Change-Id: I78f1ffe129bd8fd590b7511717dd2bf9f5ecbd6d Reviewed-on: https://go-review.googlesource.com/36690 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Paulo Flabiano Smorigo authored
Add asm implementation for AES in order to make use of VMX cryptographic acceleration instructions for POWER8. There is a speed boost of over 10 times using those instructions: Fixes #18076 old ns/op new ns/op delta BenchmarkEncrypt-20 337 30.3 -91.00% BenchmarkDecrypt-20 347 30.5a -91.21% BenchmarkExpand-20 1180 130 -88.98% old MB/s new MB/s speedup BenchmarkEncrypt-20 47.38 527.68 11.13x BenchmarkDecrypt-20 46.05 524.45 11.38x Change-Id: Ifa4d1b508f4803cc72dcaad97acc8495d651b019 Reviewed-on: https://go-review.googlesource.com/33587 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Lynn Boger <laboger@linux.vnet.ibm.com>
-
Adam Langley authored
There's no need to hold the handshake lock across this call and it can lead to deadlocks if the net.Conn calls back into the tls.Conn. Fixes #18426. Change-Id: Ib1b2813cce385949d970f8ad2e52cfbd1390e624 Reviewed-on: https://go-review.googlesource.com/36561 Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Lynn Boger authored
Currently there are cases where an XOR with -1 followed by an AND is generanted when it could be done with just an ANDN instruction. Changes to PPC64.rules and required files allows this change in generated code. Examples of this occur in sha3 among others. Fixes: #18918 Change-Id: I647cb9b4a4aaeebb27db85f8bf75487d78f720c9 Reviewed-on: https://go-review.googlesource.com/36218 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com> Reviewed-by:
Carlos Eduardo Seo <cseo@linux.vnet.ibm.com>
-
Ian Lance Taylor authored
This ensures that SIGPROF is handled correctly when using runtime/pprof in a c-archive or c-shared library. Separate profiler handling into pre-process changes and per-thread changes. Simplify the Windows code slightly accordingly. Fixes #18220. Change-Id: I5060f7084c91ef0bbe797848978bdc527c312777 Reviewed-on: https://go-review.googlesource.com/34018 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Adam Langley authored
Change-Id: I67589cb9e728e6c7df5ef6e981189193154338d3 Reviewed-on: https://go-review.googlesource.com/36559Reviewed-by:
-
Adam Langley authored
Fixes #18899. Change-Id: I6a4bf0aad9cf1dbe6691ba4e4c478fcb33c44528 Reviewed-on: https://go-review.googlesource.com/36558Reviewed-by:
-
Adam Langley authored
Change-Id: I20f4419ca377ee9428075e42db0bad46a75d983f Reviewed-on: https://go-review.googlesource.com/36557Reviewed-by:
-
Adam Langley authored
The AuthorityKeyId value from the template was used by CreateCertificate, but that wasn't documented. Also, CreateCertificate would stash a value in the template if it needed to override it, which was wrong: template should be read-only. Fixes #18962. Change-Id: Ida15c54c341e5bbf553756e8aa65021d8085f453 Reviewed-on: https://go-review.googlesource.com/36556Reviewed-by:
-
