- 25 Aug, 2017 24 commits
-
-
jaredculp authored
Change-Id: Ic3ce2f3c055f2636ec8fc9cec8592e596b18dc05 Reviewed-on: https://go-review.googlesource.com/54771 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Wei Xiao authored
Use "STP (ZR, ZR), O(R)" instead of "MOVD ZR, O(R)" to implement memory clearing. Also improve assembler supports to STP/LDP. Results (A57@2GHzx8): benchmark old ns/op new ns/op delta BenchmarkClearFat8-8 1.00 1.00 +0.00% BenchmarkClearFat12-8 1.01 1.01 +0.00% BenchmarkClearFat16-8 1.01 1.01 +0.00% BenchmarkClearFat24-8 1.52 1.52 +0.00% BenchmarkClearFat32-8 3.00 2.02 -32.67% BenchmarkClearFat40-8 3.50 2.52 -28.00% BenchmarkClearFat48-8 3.50 3.03 -13.43% BenchmarkClearFat56-8 4.00 3.50 -12.50% BenchmarkClearFat64-8 4.25 4.00 -5.88% BenchmarkClearFat128-8 8.01 8.01 +0.00% BenchmarkClearFat256-8 16.1 16.0 -0.62% BenchmarkClearFat512-8 32.1 32.0 -0.31% BenchmarkClearFat1024-8 64.1 64.1 +0.00% Change-Id: Ie5f5eac271ff685884775005825f206167a5c146 Reviewed-on: https://go-review.googlesource.com/55610 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Cherry Zhang <cherryyz@google.com>
-
Ilya Tocar authored
Sometimes (often for calls) we generate code like this: MOVQ (addr),AX MOVQ 8(addr),BX MOVQ AX,(otheraddr) MOVQ BX,8(otheraddr) Replace it with MOVUPS (addr),X0 MOVUPS X0,(otheraddr) For completeness do the same for 8,16,32-bit loads/stores too. Shaves 1% from code sections of go tool. /localdisk/itocar/golang/bin/go 10293917 go_old 10334877 [40960 bytes] read-only data = 682 bytes (0.040769%) global text (code) = 38961 bytes (1.036503%) Total difference 39643 bytes (0.674628%) Updates #6853 Change-Id: I1f0d2f60273a63a079b58927cd1c4e3429d2e7ae Reviewed-on: https://go-review.googlesource.com/57130 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
griesemer authored
Throughout the spec we use the notion of a constant x being representable by a value of type T. While intuitively clear, at least for floating-point and complex constants types, the concept was not well-defined. In the section on Conversions there was an extra rule for floating-point types only and it missed the case of floating-point values overflowing to an infinity after rounding. Since the concept is important to Go, and a compiler most certainly will have a function to test "representability", it seems warranted to define the term explicitly in the spec. This change introduces a new entry "Representability" under the section on "Properties of types and values", and defines the term explicitly, together with examples. The phrase used is "representable by" rather than "representable as" because the former use is prevalent in the spec. Additionally, it clarifies that a floating-point constant that overflows to an infinity after rounding is never representable by a value of a floating-point type, even though infinities are valid values of IEEE floating point types. This is required because there are not infinite value constants in the language (like there is also no -0.0) and representability also matters for constant conversions. This is not a language change, and type-checkers have been following this rule before. The change also introduces links throughout the spec to the new section as appropriate and removes duplicate text and examples elsewhere (Constants and Conversions sections), leading to simplifications in the relevant paragraphs. Fixes #15389. Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44 Reviewed-on: https://go-review.googlesource.com/57530Reviewed-by:
Rob Pike <r@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Josh Bleecher Snyder authored
Prior to this change, we use typedmemmove to write the key value to its new location in mapassign_fast32 and mapassign_fast64. (The use of typedmemmove was a last-minute fix in the 1.9 cycle; see #21297 and CL 53414.) This is significantly less inefficient than direct assignment or calling writebarrierptr directly. Fortunately, there aren't many cases to consider. On systems with 32 bit pointers: * A 32 bit AMEM value either is a single pointer or has no pointers. * A 64 bit AMEM value may contain a pointer at the beginning, a pointer at 32 bits, or two pointers. On systems with 64 bit pointers: * A 32 bit AMEM value contains no pointers. * A 64 bit AMEM value either is a single pointer or has no pointers. All combinations except the 32 bit pointers / 64 bit AMEM value are cheap and easy to handle, and the problematic case is likely rare. The most popular map keys appear to be ints and pointers. So we handle them exhaustively. The sys.PtrSize checks are constant branches and are eliminated by the compiler. An alternative fix would be to return a pointer to the key, and have the calling code do the assignment, at which point the compiler would have full type information. Initial tests suggest that the performance difference between these strategies is negligible, and this fix is considerably simpler, and has much less impact on binary size. Fixes #21321 Change-Id: Ib03200e89e2324dd3c76d041131447df66f22bfe Reviewed-on: https://go-review.googlesource.com/59110 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Follow-up to CL 58371. Change-Id: I3d2aaec84ee6db3ef1bd4fcfcaf46cc297c7176b Reviewed-on: https://go-review.googlesource.com/58610 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Keith Randall authored
Implement int reg <-> fp reg moves on amd64. If we see a load to int reg followed by an int->fp move, then we can just load to the fp reg instead. Same for stores. math.Abs is now: MOVQ "".x+8(SP), AX SHLQ $1, AX SHRQ $1, AX MOVQ AX, "".~r1+16(SP) math.Copysign is now: MOVQ "".x+8(SP), AX SHLQ $1, AX SHRQ $1, AX MOVQ "".y+16(SP), CX SHRQ $63, CX SHLQ $63, CX ORQ CX, AX MOVQ AX, "".~r2+24(SP) math.Float64bits is now: MOVSD "".x+8(SP), X0 MOVSD X0, "".~r1+16(SP) (it would be nicer to use a non-SSE reg for this, nothing is perfect) And due to the fix for #21440, the inlined version of these improve as well. name old time/op new time/op delta Abs 1.38ns ± 5% 0.89ns ±10% -35.54% (p=0.000 n=10+10) Copysign 1.56ns ± 7% 1.35ns ± 6% -13.77% (p=0.000 n=9+10) Fixes #13095 Change-Id: Ibd7f2792412a6668608780b0688a77062e1f1499 Reviewed-on: https://go-review.googlesource.com/58732 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com>
-
Kevin Burke authored
Make it dead simple to see visually what the function outputs in various scenarios. Change-Id: I8f6fcd72fa1515361481f0510412cde221e1d4e3 Reviewed-on: https://go-review.googlesource.com/51630 Run-TryBot: Kevin Burke <kev@inburke.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by:
Hiroshi Ioka <hirochachacha@gmail.com>
-
Austin Clements authored
CL 36428 changed the way nanotime works so on Darwin and Windows it now depends on runtime.startNano, which is computed at runtime.init time. Unfortunately, the `runtimeInitTime = nanotime()` initialization happened *before* runtime.init, so on these platforms runtimeInitTime is set incorrectly. The one (and only) consequence of this is that the start time printed in gctrace lines is bogus: gc 1 18446653480.186s 0%: 0.092+0.47+0.038 ms clock, 0.37+0.15/0.81/1.8+0.15 ms cpu, 4->4->1 MB, 5 MB goal, 8 P To fix this, this commit moves the runtimeInitTime initialization to shortly after runtime.init, at which point nanotime is safe to use. This also requires changing the condition in newproc1 that currently uses runtimeInitTime != 0 simply to detect whether or not the main M has started. Since runtimeInitTime could genuinely be 0 now, this introduces a separate flag to newproc1. Fixes #21554. Change-Id: Id874a4b912d3fa3d22f58d01b31ffb3548266d3b Reviewed-on: https://go-review.googlesource.com/58690 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Rick Hudson <rlh@golang.org> Reviewed-by:
-
Hana Kim authored
Generated with github.com/catapult/tracing/bin/vulcanize_trace_viewer catapult @ ab4d571fa Renamed trace_viewer_lean.html to trace_viewer_full.html to make it clear we are using the full version of trace viewer (waiting for https://github.com/catapult-project/catapult/issues/2247 to be fixed). Update #15302 Change-Id: Ice808bb27ab79a1dec9fc863e0c5a761027ebfbe Reviewed-on: https://go-review.googlesource.com/58750Reviewed-by:
Dmitry Vyukov <dvyukov@google.com>
-
Wei Xiao authored
Updates #21486 Change-Id: I78ca76490d8e9b52e055c1f0b8d10bdb227e3a80 Reviewed-on: https://go-review.googlesource.com/56331Reviewed-by:
-
Danny Rosseau authored
Fix debugger printing of uint that mistakenly invoked .int64() instead of .uint64() Fixes #21392 Change-Id: I107a7e87e0efbb06303c1e627dee76c369f75d1e Reviewed-on: https://go-review.googlesource.com/54750Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
-
Aliaksandr Valialkin authored
Benchmark results on GOOS=linux: GOARCH=amd64 name old time/op new time/op delta Atoi/Pos/7bit-4 20.1ns ± 2% 8.6ns ± 1% -57.34% (p=0.000 n=10+10) Atoi/Pos/26bit-4 25.8ns ± 7% 11.9ns ± 0% -53.91% (p=0.000 n=10+8) Atoi/Pos/31bit-4 27.3ns ± 2% 13.2ns ± 1% -51.56% (p=0.000 n=10+10) Atoi/Pos/56bit-4 37.2ns ± 5% 18.2ns ± 1% -51.26% (p=0.000 n=10+10) Atoi/Pos/63bit-4 38.7ns ± 1% 38.6ns ± 1% ~ (p=0.297 n=9+10) Atoi/Neg/7bit-4 17.6ns ± 1% 7.2ns ± 0% -59.22% (p=0.000 n=10+10) Atoi/Neg/26bit-4 24.4ns ± 1% 12.4ns ± 1% -49.28% (p=0.000 n=10+10) Atoi/Neg/31bit-4 26.9ns ± 0% 14.0ns ± 1% -47.88% (p=0.000 n=7+10) Atoi/Neg/56bit-4 36.2ns ± 1% 19.5ns ± 0% -46.24% (p=0.000 n=10+9) Atoi/Neg/63bit-4 38.9ns ± 1% 38.8ns ± 1% ~ (p=0.385 n=9+10) GOARCH=386 name old time/op new time/op delta Atoi/Pos/7bit-4 89.6ns ± 1% 8.2ns ± 1% -90.84% (p=0.000 n=9+10) Atoi/Pos/26bit-4 187ns ± 2% 12ns ± 1% -93.71% (p=0.000 n=10+9) Atoi/Pos/31bit-4 225ns ± 1% 225ns ± 1% ~ (p=0.995 n=10+10) Atoi/Neg/7bit-4 86.2ns ± 1% 8.5ns ± 1% -90.14% (p=0.000 n=10+10) Atoi/Neg/26bit-4 183ns ± 1% 13ns ± 1% -92.77% (p=0.000 n=9+10) Atoi/Neg/31bit-4 223ns ± 0% 223ns ± 0% ~ (p=0.247 n=8+9) Fixes #20557 Change-Id: Ib6245d88cffd4b037419e2bf8e4a71b86c6d773f Reviewed-on: https://go-review.googlesource.com/44692Reviewed-by:
Robert Griesemer <gri@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Since golang.org/cl/31670, we've stopped using the 'embedded' function for handling struct embeddings within package export data. Now the only remaining use is for Go source files, which allows for some substantial simplifications: 1. CenterDot never appears within Go source files, so that logic can simply be removed. 2. The field name will always be declared in the local package. Passes toolstash-check. Change-Id: I59505f62824206dd5de0782918f98fbef6e93224 Reviewed-on: https://go-review.googlesource.com/58790 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
griesemer authored
The enumeration of numeric types missed the complex types. Clarify by removing the explicit enumeration and referring to numeric types instead. Fixes #21579. Change-Id: If36c2421f8501eeec82a07f442ac2e16a35927ba Reviewed-on: https://go-review.googlesource.com/58491Reviewed-by:
-
Matthew Dempsky authored
Discovered while debugging CL 53644. No test case because these are purely internal conversions that should never end up resulting in compiler warnings or even generated code. Updates #19683. Change-Id: I0d9333ef2c963fa22eb9b5335bb022bcc9b25708 Reviewed-on: https://go-review.googlesource.com/58190 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
griesemer authored
The old wording seemed to imply that nil is a kind of type. Slightly reworded for clarity. Fixes #21580. Change-Id: I29898bf0125a10cb8dbb5c7e63ec5399ebc590ca Reviewed-on: https://go-review.googlesource.com/58490Reviewed-by:
-
Keith Randall authored
When we remove a nil check, add it back to the free Value pool immediately. Fixes #18732 Change-Id: I8d644faabbfb52157d3f2d071150ff0342ac28dc Reviewed-on: https://go-review.googlesource.com/58810 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Tom Levy authored
There are some major problems with TestAdversary (based on "A Killer Adversary for Quicksort"[1] by M. D. McIlroy). See #21581 for details. Rewrite the test to closely match the version in the paper so it can be verified as correct by virtue of similarity. The only major difference between this new version and the version in the paper is that this version swaps the values directly instead of permuting an array of indices because we don't need to recover the original permutation. This new version also counts the number of calls to Less() and fails the test if there are too many. Fixes #21581. [1]: http://www.cs.dartmouth.edu/~doug/mdmspe.pdf Change-Id: Ia94b5b6d288b8fa3805a5fa27661cebbc5bad9a7 Reviewed-on: https://go-review.googlesource.com/58330 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Tom Levy authored
The tests were removed in https://golang.org/cl/2311 but some references to them were missed. Change-Id: I163e554a0cc99401a012deead8fda813ad74dbfe Reviewed-on: https://go-review.googlesource.com/58870Reviewed-by:
-
David du Colombier authored
CL 54410 and CL 56250 recently added use of the MOVOstore instruction to improve performance. However, we can't use the MOVOstore instruction on Plan 9, because floating point operations are not allowed in the note handler. This change adds a configuration flag useSSE to enable the use of SSE instructions for non-floating point operations. This flag is enabled by default and disabled on Plan 9. When this flag is disabled, the MOVOstore instruction is not used and the MOVQstoreconst instruction is used instead. Fixes #21599 Change-Id: Ie609e5d9b82ec0092ae874bab4ce01caa5bc8fb8 Reviewed-on: https://go-review.googlesource.com/58850Reviewed-by:
-
Wei Congrui authored
This change also added the same check in make.bash to make.rc, which makes sure $GOROOT_BOOTSTRAP != $GOROOT. Fixes #14339 Change-Id: I2758f4a845bae42ace02492fc6a911f6d6247d26 Reviewed-on: https://go-review.googlesource.com/57753 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
WriteHeader may fail to encode a header for any number of reasons, which can be frustrating for the user when trying to create a tar archive. As we validate the Header, we generate an informative error message intended for human consumption and return that if and only if no format can be selected. This allows WriteHeader to return informative errors like: tar: cannot encode header: invalid PAX record: "linkpath = \x00hello" tar: cannot encode header: invalid PAX record: "SCHILY.xattr.foo=bar = baz" tar: cannot encode header: Format specifies GNU; and only PAX supports Xattrs tar: cannot encode header: Format specifies GNU; and GNU cannot encode ModTime=1969-12-31 15:59:59.0000005 -0800 PST tar: cannot encode header: Format specifies GNU; and GNU supports sparse files only with TypeGNUSparse tar: cannot encode header: Format specifies USTAR; and USTAR cannot encode ModTime=292277026596-12-04 07:30:07 -0800 PST tar: cannot encode header: Format specifies USTAR; and USTAR does not support sparse files tar: cannot encode header: Format specifies PAX; and only GNU supports TypeGNUSparse Updates #18710 Change-Id: I82a498d6f29d02c4e73bce47b768eb578da8499c Reviewed-on: https://go-review.googlesource.com/58310 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> Reviewed-by: -
Keith Randall authored
For code like the following (where x escapes): x := []int{1} We're currently generating a nil check. The line above is really 3 operations: t := new([1]int) t[0] = 1 x := t[:] We remove the nil check for t[0] = 1, but not for t[:]. Our current nil check removal rule is too strict about the possible memory arguments of the nil check. Unlike zeroing or storing to the result of runtime.newobject, the nilness of runtime.newobject is always false, even after other stores have happened in the meantime. Change-Id: I95fad4e3a59c27effdb37c43ea215e18f30b1e5f Reviewed-on: https://go-review.googlesource.com/58711 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 24 Aug, 2017 16 commits
-
-
Francesc Campoy Flores authored
Change-Id: I6e9b5caeca842b6bf72afefb31f5140608b86d20 Reviewed-on: https://go-review.googlesource.com/58530 Run-TryBot: Francesc Campoy Flores <campoy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Heschi Kreinick authored
In writelines the linker uses various auxiliary information about a function to create its line table entries. (It also does some unrelated stuff, but never mind.) There's no reason to do this for non-Go functions, so it bails out if the symbol has no FuncInfo. However, it does so *after* it looks up (and implicitly creates!) the go.info symbol for the function, which doesn't make sense and risks creating duplicate symbols for static C functions. Move the check up so that it doesn't do that. Since non-Go functions can't reference Go types, there shouldn't be any relocations to type info DIEs that need to be built, so there should be no harm not doing that. I wanted to change the Lookup to an ROLookup but that broke the shared-mode tests with an inscrutable error. No test. It seems too specific to worry about, but if someone disagrees I can figure something out. Fixes #21566 Change-Id: I61f03b7c504a3bf1c4245a8811795b6303469e91 Reviewed-on: https://go-review.googlesource.com/58630Reviewed-by:
-
Chris Broadfoot authored
Pre-emptive. Go 1.9 is expected to be released in August. Change-Id: I0f58c012c4110bf490022dc2c1d69c0988d73bfa Reviewed-on: https://go-review.googlesource.com/52351Reviewed-by:
-
Chris Broadfoot authored
Change-Id: I97075f24319a4b96cbeb9e3ff2e7b2056ff59e32 Reviewed-on: https://go-review.googlesource.com/58651Reviewed-by:
-
Josh Bleecher Snyder authored
This eliminates a nil check of b while evaluating b.tophash, which is in the inner loop of many hot map functions. It also makes the code a bit clearer. Also remove some gotos in favor of labeled breaks. On non-x86 architectures, this change introduces a pointless reg-reg move, although the cause is well-understood (#21572). Change-Id: Ib7ee58b59ea5463b92e1590c8b8f5c0ef87d410a Reviewed-on: https://go-review.googlesource.com/58372 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Martin Möhrmann <moehrmann@google.com> Reviewed-by:
-
Ian Lance Taylor authored
Otherwise the default computation in symalign kicked in, setting the alignment to be too high. This didn't matter with GNU ld, which put each loadable note into a separate PT_NOTE segment, but it did matter with gold which accumulated them all into a single PT_NOTE segment, respecting the requested alignment. In the single PT_NOTE segment generated by gold, the incorrect section alignment made the notes unreadable. Fixes #21564 Change-Id: I15eb408bb04a2566c9fdfb6828e14188d9ef2280 Reviewed-on: https://go-review.googlesource.com/58290Reviewed-by:
Russ Cox <rsc@golang.org>
-
Michael Munday authored
This is a crude compiler pass to eliminate stores to auto variables that are only ever written to. Eliminates an unnecessary store to x from the following code: func f() int { var x := 1 return *(&x) } Fixes #19765. Change-Id: If2c63a8ae67b8c590b6e0cc98a9610939a3eeffa Reviewed-on: https://go-review.googlesource.com/38746 Run-TryBot: Michael Munday <mike.munday@ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Josh Bleecher Snyder authored
This prevents unnecessary reg-reg moves during pointer arithmetic. This change reduces the size of the full hello world binary by 0.4%. Updates #21572 Change-Id: Ia0427021e5c94545a0dbd83a6801815806e5b12d Reviewed-on: https://go-review.googlesource.com/58371 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Martin Möhrmann <moehrmann@google.com> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: Icfe24d5660666093f3e645f82d30b7687c8077be Reviewed-on: https://go-review.googlesource.com/58370 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Martin Möhrmann authored
On 386 the below code triggered an infinite loop in growslice: x = make([]byte, 1<<30-1, 1<<30-1) x = append(x, x...) Check for overflow when calculating the new slice capacity and set the new capacity to the requested capacity when an overflow is detected to avoid an infinite loop. No automatic test added due to requiring to allocate 1GB of memory on a 32bit plaform before use of append is able to trigger the overflow check. Fixes #21441 Change-Id: Ia871cc9f88479dacf2c7044531b233f83d2fcedf Reviewed-on: https://go-review.googlesource.com/57950 Run-TryBot: Martin Möhrmann <moehrmann@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by:
-
Dmitry Vyukov authored
Currently all package tests are executed once with Parallel tests executed in parallel. Then this process is repeated count*cpu times. Tests are not parallelized over count*cpu. Parallelizing over cpu is not possible as GOMAXPROCS is a global setting. But it is possible for count. Parallelize over count. Brings down testing of my package with -count=100 form 10s to 0.3s. Change-Id: I76d8322adeb8c5c6e70b99af690291fd69d6402a Reviewed-on: https://go-review.googlesource.com/44830 Run-TryBot: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This slightly improves the generated code on x86 architectures, including on many hot paths. It is a no-op on other architectures. Change-Id: I86336fd846bc5805a27bbec572e8c73dcbd0d567 Reviewed-on: https://go-review.googlesource.com/57411 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
This is necessary when you aren't actively changing the runtime. Oops. Also, run the tests on the builders, to avoid silent failures (#17472). Change-Id: I1fc03790cdbddddb07026a772137a79919dcaac7 Reviewed-on: https://go-review.googlesource.com/58050 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Joe Tsai authored
The Reader and Writer are now at feature parity, meaning that everything that can be parsed by the Reader, can also be composed by the Writer. This position enables us to support selection of the format in a backwards compatible way, since it ensures that everything that can be read can also be round-trip written. As such, we add the following new API: type Format int const FormatUnknown Format = 0 ... type Header struct { ...; Format Format } The new Header.Format field is populated by the Reader on the best guess on what the format is. Note that the Reader is very liberal in what it permits, so a hybrid TAR file using aspects of multiple formats can still be decoded, but will be reported as FormatUnknown. Even though Reader has full support for V7 and basic support for STAR, it will still report those formats as unknown (and the constants for those formats are not even exported). The reasons for this is because the Writer has no support for V7 or STAR. Leaving it as unknown allows the Writer to choose a format usually USTAR or GNU that can encode the equivalent Header. When writing, the Header.allowedFormats will take the Format field into consideration if it is a known format. Fixes #18710 Change-Id: I00980c475d067c6969d3414e1ff0224fdd89cd49 Reviewed-on: https://go-review.googlesource.com/58230 Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Francesc Campoy authored
Fixes #19520 Change-Id: Ib0a1f0f2429172d2781c9b6fbd21f9cb8da1b8ed Reviewed-on: https://go-review.googlesource.com/43295 Run-TryBot: Francesc Campoy Flores <campoy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Joe Tsai <thebrokentoaster@gmail.com>
-
Karel Pazdera authored
Existing code in encoding/xml packages contains code which breaks various linter rules (comments, constant and variable naming, variable shadowing, etc). Fixes #21578 Change-Id: Id4bd9a9be6d5728ce88fb6efe33030ef943c078c Reviewed-on: https://go-review.googlesource.com/58210Reviewed-by:
Sam Whited <sam@samwhited.com> Reviewed-by:
-
