1. 25 Aug, 2017 28 commits
    • Borja Clemente's avatar
      bytes: Add missing examples to functions · 394f6a5a
      Borja Clemente authored
      Fixes #21570
      
      Change-Id: Ia0734929a04fbce8fdd5fbcb1b7baff9a8bbe39e
      Reviewed-on: https://go-review.googlesource.com/58030Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      Reviewed-by: default avatarJoe Tsai <thebrokentoaster@gmail.com>
      Run-TryBot: Robert Griesemer <gri@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      394f6a5a
    • Tom Levy's avatar
      sort: fix mix-up between "!less" and "greater" in examples · 2bba2671
      Tom Levy authored
      If Less(a, b) returns true when a is less than b, the correct way to
      check if a is greater than b is to use Less(b, a). It is wrong to use
      !Less(a, b) because that checks if a is greater than *or equal to* b.
      
      1. The decreasingDistance function in Example_sortKeys makes this
         mistake. Fix it.
      
      2. The documentation of multiSorter.Less says it loops along the less
         functions until it finds a comparison "that is either Less or
         !Less". This is nonsense, because (Less(a, b) or !Less(a, b)) is
         always true. Fix the documentation to say that it finds a
         comparison "that discriminates between the two items (one is less
         than the other)". The implementation already does this correctly.
      
      Change-Id: If52b79f68e4fdb0d1095edf29bdecdf154a61b8d
      Reviewed-on: https://go-review.googlesource.com/57752Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      2bba2671
    • fanzha02's avatar
      cmd/internal/obj/arm64: fix assemble fcsels/fcseld bug · aea286b4
      fanzha02 authored
      The current code treats the type of SIMD&FP register as C_REG incorrectly.
      
      The fix code converts C_REG type into C_FREG type.
      
      Uncomment fcsels/fcseld test cases.
      
      Fixes #21582
      Change-Id: I754c51f72a0418bd352cbc0f7740f14cc599c72d
      Reviewed-on: https://go-review.googlesource.com/58350Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      aea286b4
    • Heschi Kreinick's avatar
      cmd/compile: bug fixes for DWARF location lists · 38bd725b
      Heschi Kreinick authored
      Fix two small but serious bugs in the DWARF location list code that
      should have been caught by the automated tests I didn't write.
      
      After emitting debug information for a user variable, mark it as done
      so that it doesn't get emitted again. Otherwise it would be written once
      per slot it was decomposed into.
      
      Correct a merge error in CL 44350: the location list abbreviations need
      to have DW_AT_decl_line too, otherwise the resulting DWARF is gibberish.
      
      Change-Id: I6ab4b8b32b7870981dac80eadf0ebfc4015ccb01
      Reviewed-on: https://go-review.googlesource.com/59070
      Run-TryBot: Heschi Kreinick <heschi@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarDavid Chase <drchase@google.com>
      38bd725b
    • jaredculp's avatar
      math: add examples for trig functions · dc42ffff
      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: default avatarIan Lance Taylor <iant@golang.org>
      dc42ffff
    • Wei Xiao's avatar
      cmd/compile: memory clearing optimization for arm64 · c02fc160
      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: default avatarCherry Zhang <cherryyz@google.com>
      c02fc160
    • Ilya Tocar's avatar
      cmd/compile/internal/ssa: combine consecutive loads and stores on amd64 · 9c99512d
      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: default avatarKeith Randall <khr@golang.org>
      9c99512d
    • griesemer's avatar
      spec: explicitly define notion of "representability" (clarification) · b40831b1
      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: default avatarRob Pike <r@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      b40831b1
    • Josh Bleecher Snyder's avatar
      runtime: optimize storing new keys in mapassign_fastNN · 25bbb695
      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: default avatarAustin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      25bbb695
    • Josh Bleecher Snyder's avatar
      cmd/compile: enforce that MOVXconvert is a no-op on 386 and amd64 · a45d6859
      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: default avatarKeith Randall <khr@golang.org>
      a45d6859
    • Keith Randall's avatar
      cmd/compile,math: improve code generation for math.Abs · fb05948d
      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: default avatarCherry Zhang <cherryyz@google.com>
      Reviewed-by: default avatarIlya Tocar <ilya.tocar@intel.com>
      fb05948d
    • Kevin Burke's avatar
      path/filepath: add example for Ext · e11fd006
      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: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarHiroshi Ioka <hirochachacha@gmail.com>
      e11fd006
    • Austin Clements's avatar
      runtime: capture runtimeInitTime after nanotime is initialized · 9d17e175
      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: default avatarRick Hudson <rlh@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      9d17e175
    • Hana Kim's avatar
      misc/trace: update trace-viewer · 05ff6bfe
      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: default avatarDmitry Vyukov <dvyukov@google.com>
      05ff6bfe
    • Wei Xiao's avatar
      cmd/vendor/golang.org/x/arch: pull latest updates from x repo (commit edaf650) · 1708122b
      Wei Xiao authored
      Updates #21486
      
      Change-Id: I78ca76490d8e9b52e055c1f0b8d10bdb227e3a80
      Reviewed-on: https://go-review.googlesource.com/56331Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      1708122b
    • Danny Rosseau's avatar
      encoding/gob: fix Debug to properly print uint · 9515610a
      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: default avatarEmmanuel Odeke <emm.odeke@gmail.com>
      Reviewed-by: default avatarRob Pike <r@golang.org>
      Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      9515610a
    • Aliaksandr Valialkin's avatar
      strconv: optimize Atoi for common case · 46aa9f54
      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: default avatarRobert Griesemer <gri@golang.org>
      Reviewed-by: default avatarKeith Randall <khr@golang.org>
      46aa9f54
    • Matthew Dempsky's avatar
      cmd/compile: simplify noding for struct embedding · 180bfc4b
      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: default avatarRobert Griesemer <gri@golang.org>
      180bfc4b
    • griesemer's avatar
      spec: clarify zero value for complex types · a9f832a6
      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: default avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarRob Pike <r@golang.org>
      a9f832a6
    • Matthew Dempsky's avatar
      cmd/compile: fix node position for imported constants · b976859b
      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: default avatarRobert Griesemer <gri@golang.org>
      b976859b
    • griesemer's avatar
      spec: clarify nil case in type switches · 84ac90eb
      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: default avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      Reviewed-by: default avatarRob Pike <r@golang.org>
      84ac90eb
    • Keith Randall's avatar
      cmd/compile: free value earlier in nilcheck · 770d8d82
      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: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      770d8d82
    • Tom Levy's avatar
      sort: fix TestAdversary · 3723d080
      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: default avatarIan Lance Taylor <iant@golang.org>
      3723d080
    • Tom Levy's avatar
      sync/atomic: remove references to old atomic pointer hammer tests · b0ba0b49
      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: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      b0ba0b49
    • David du Colombier's avatar
      cmd/compile: don't use MOVOstore instruction on plan9/amd64 · 14cb4158
      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: default avatarKeith Randall <khr@golang.org>
      14cb4158
    • Wei Congrui's avatar
      build: add `go env GOROOT` as default GOROOT_BOOTSTRAP value · a164a2f5
      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: default avatarIan Lance Taylor <iant@golang.org>
      a164a2f5
    • Joe Tsai's avatar
      archive/tar: return better WriteHeader errors · 3d62000a
      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: default avatarIan Lance Taylor <iant@golang.org>
      3d62000a
    • Keith Randall's avatar
      cmd/compile: remove more nil ptr checks after newobject · f1517ec6
      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: default avatarCherry Zhang <cherryyz@google.com>
      f1517ec6
  2. 24 Aug, 2017 12 commits