1. 07 Feb, 2017 26 commits
    • Cherry Zhang's avatar
      cmd/compile: do not use statictmp for zeroing · a8334858
      Cherry Zhang authored
      Also fixes #18687.
      
      Change-Id: I7c6d47c71e632adf4c16937a29074621f771844c
      Reviewed-on: https://go-review.googlesource.com/35261
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      a8334858
    • Matthew Dempsky's avatar
      cmd/compile/internal/ssa: use *obj.LSym in ExternSymbol · 8cf17669
      Matthew Dempsky authored
      Change-Id: I713120f90fd1d2df6698c40622ccac6eae907919
      Reviewed-on: https://go-review.googlesource.com/36423
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      8cf17669
    • Matthew Dempsky's avatar
      cmd/internal/dwarf: use []*Var instead of linked lists · 1a7582f5
      Matthew Dempsky authored
      Passes toolstash -cmp.
      
      Change-Id: I202b29495ca1aaf3c52879fa99fdc0a4b86703af
      Reviewed-on: https://go-review.googlesource.com/36419
      Run-TryBot: Matthew Dempsky <mdempsky@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarJosh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      1a7582f5
    • Jaana Burcu Dogan's avatar
      runtime/pprof: clarify CPU profile's captured during the lifetime of the prog · 6cf7918e
      Jaana Burcu Dogan authored
      Fixes #18504.
      
      Change-Id: I3716fc58fc98472eea15ce3617aee3890670c276
      Reviewed-on: https://go-review.googlesource.com/36430Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      6cf7918e
    • Sameer Ajmani's avatar
      time: delete incorrect docs about day-of-month checks. · 67c3d4da
      Sameer Ajmani authored
      Documentation was introduced by CL https://golang.org/cl/14123
      but that behavior was changed later by CL https://golang.org/cl/17710.
      This CL deletes the stale paragraph.
      
      Fixes #18980
      
      Change-Id: Ib434f1eac6fc814fde1be112a8f52afe6e3e0fcc
      Reviewed-on: https://go-review.googlesource.com/36532Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      67c3d4da
    • Russ Cox's avatar
      cmd/go, go/build: better defenses against GOPATH=GOROOT · 57d06fff
      Russ Cox authored
      Fixes #18863.
      
      Change-Id: I0723563cd23728b0d43ebcc25979bf8d21e2a72c
      Reviewed-on: https://go-review.googlesource.com/36427
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      57d06fff
    • Austin Clements's avatar
      runtime: fix confusion between _MaxMem and _MaxArena32 · 4af6b81d
      Austin Clements authored
      Currently both _MaxMem and _MaxArena32 represent the maximum arena
      size on 32-bit hosts (except on MIPS32 where _MaxMem is confusingly
      smaller than _MaxArena32).
      
      Clean up sysAlloc so that it always uses _MaxMem, which is the maximum
      arena size on both 32- and 64-bit architectures and is the arena size
      we allocate auxiliary structures for. This lets us simplify and unify
      some code paths and eliminate _MaxArena32.
      
      Fixes #18651. mheap.sysAlloc currently assumes that if the arena is
      small, we must be on a 32-bit machine and can therefore grow the arena
      to _MaxArena32. This breaks down on darwin/arm64, where _MaxMem is
      only 2 GB. As a result, on darwin/arm64, we only reserve spans and
      bitmap space for a 2 GB heap, and if the application tries to allocate
      beyond that, sysAlloc takes the 32-bit path, tries to grow the arena
      beyond 2 GB, and panics when it tries to grow the spans array
      allocation past its reserved size. This has probably been a problem
      for several releases now, but was only noticed recently because
      mapSpans didn't check the bounds on the span reservation until
      recently. Most likely it corrupted the bitmap before. By using _MaxMem
      consistently, we avoid thinking that we can grow the arena larger than
      we have auxiliary structures for.
      
      Change-Id: Ifef28cb746a3ead4b31c1d7348495c2242fef520
      Reviewed-on: https://go-review.googlesource.com/35253Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      Reviewed-by: default avatarElias Naur <elias.naur@gmail.com>
      Run-TryBot: Austin Clements <austin@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      4af6b81d
    • Austin Clements's avatar
      runtime: simplify and cleanup mallocinit · 1cc24690
      Austin Clements authored
      mallocinit has evolved organically. Make a pass to clean it up in
      various ways:
      
      1. Merge the computation of spansSize and bitmapSize. These were
         computed on every loop iteration of two different loops, but always
         have the same value, which can be derived directly from _MaxMem.
         This also avoids over-reserving these on MIPS, were _MaxArena32 is
         larger than _MaxMem.
      
      2. Remove the ulimit -v logic. It's been disabled for many releases
         and the dead code paths to support it are even more wrong now than
         they were when it was first disabled, since now we *must* reserve
         spans and bitmaps for the full address space.
      
      3. Make it clear that we're using a simple linear allocation to lay
         out the spans, bitmap, and arena spaces. Previously there were a
         lot of redundant pointer computations. Now we just bump p1 up as we
         reserve the spaces.
      
      In preparation for #18651.
      
      Updates #5049 (respect ulimit).
      
      Change-Id: Icbe66570d3a7a17bea227dc54fb3c4978b52a3af
      Reviewed-on: https://go-review.googlesource.com/35252Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      1cc24690
    • Austin Clements's avatar
      runtime: make _MaxMem an untyped constant · efb5eae3
      Austin Clements authored
      Currently _MaxMem is a uintptr, which is going to complicate some
      further changes. Make it untyped so we'll be able to do untyped math
      on it before truncating it to a uintptr.
      
      The runtime assembly is identical before and after this change on
      {linux,windows}/{amd64,386}.
      
      Updates #18651.
      
      Change-Id: I0f64511faa9e0aa25179a556ab9f185ebf8c9cf8
      Reviewed-on: https://go-review.googlesource.com/35251
      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 avatarDavid Crawshaw <crawshaw@golang.org>
      efb5eae3
    • Josh Bleecher Snyder's avatar
      cmd/compile: cmd/internal/obj: cull dead code · 46085c4b
      Josh Bleecher Snyder authored
      This code is dead as a result of
      
      * removing the Follow pass
      * moving rotation detection from walk to ssa
      
      Change-Id: I14599c85bedb4e3148347b547e724187920182c4
      Reviewed-on: https://go-review.googlesource.com/36484
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      Reviewed-by: default avatarCherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      46085c4b
    • Cherry Zhang's avatar
      cmd/compile: do not use "oaslit" for global · 160914e3
      Cherry Zhang authored
      The compiler did not emit write barrier for assigning global with
      struct literal, like global = T{} where T contains pointer.
      
      The relevant code path is:
      walkexpr OAS var_ OSTRUCTLIT
          oaslit
              anylit OSTRUCTLIT
                  walkexpr OAS var_ nil
                  return without adding write barrier
          return true
      break (without adding write barrier)
      
      This CL makes oaslit not apply to globals. See also CL
      https://go-review.googlesource.com/c/36355/ for an alternative
      fix.
      
      The downside of this is that it generates static data for zeroing
      struct now. Also this only covers global. If there is any lurking
      bug with implicit zeroing other than globals, this doesn't fix.
      
      Fixes #18956.
      
      Change-Id: Ibcd27e4fae3aa38390ffa94a32a9dd7a802e4b37
      Reviewed-on: https://go-review.googlesource.com/36410Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      160914e3
    • Russ Cox's avatar
      crypto/x509: check for new tls-ca-bundle.pem last · 1ead0bd1
      Russ Cox authored
      We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
      to the list in response to #17549 - not being able to find any certs otherwise.
      
      Now we have #18813, where CentOS 6 apparently has both that file
      and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while
      the former is not.
      
      Moving the new CentOS 7 file to the bottom of the list should fix both
      problems: the CentOS 7 system that didn't have any of the other files
      in the list will still find the new one, and existing systems will still
      keep using what they were using instead of preferring the new path
      that may or may not be complete on some systems.
      
      Fixes #18813.
      
      Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba
      Reviewed-on: https://go-review.googlesource.com/36429
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: default avatarAdam Langley <agl@golang.org>
      1ead0bd1
    • Daniel Martí's avatar
      cmd/link, crypto/tls: don't use append loops · 99df7c9c
      Daniel Martí authored
      Change-Id: Ib47e295e8646b769c30fd81e5c7f20f964df163e
      Reviewed-on: https://go-review.googlesource.com/36335Reviewed-by: default avatarFilippo Valsorda <hi@filippo.io>
      Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      99df7c9c
    • Robert Griesemer's avatar
      spec: clarify alignment of arrays · e62aab12
      Robert Griesemer authored
      Fixes #18950.
      
      Change-Id: I9f94748f36a896bcadc96f0642eb1f3bff387950
      Reviewed-on: https://go-review.googlesource.com/36481Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      e62aab12
    • Daniel Martí's avatar
      testing: clarify T.Parallel() godoc wording · 3e366ec6
      Daniel Martí authored
      Fixes #18914.
      
      Change-Id: Iec90d6aaa62595983db28b17794429f3c9a3dc36
      Reviewed-on: https://go-review.googlesource.com/36272Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      3e366ec6
    • Russ Cox's avatar
      Revert "image: fix the overlap check in Rectangle.Intersect." · 14347ee4
      Russ Cox authored
      This reverts commit a855da29.
      
      Change-Id: I23c0351b0708877e0b3d1b44a2bc2799cee52cd1
      Reviewed-on: https://go-review.googlesource.com/36426Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      14347ee4
    • Seth Vargo's avatar
      text/template: remove duplicate logic in conditional · 50c7783f
      Seth Vargo authored
      It looks like this conditional may have been refactored at some point,
      but the logic was still very confusing. The outer conditional checks if
      the function is variadic, so there's no need to verify that in the
      result. Additionally, since the function isn't variadic, there is no
      reason to permit the function call if the number of input arguments is
      less than the function signature requires.
      
      Change-Id: Ia957cf83d1c900c08dd66384efcb74f0c368422e
      Reviewed-on: https://go-review.googlesource.com/35491
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      50c7783f
    • Cherry Zhang's avatar
      cmd/internal/obj: remove Follow pass · bed8129e
      Cherry Zhang authored
      The Follow pass in the assembler backend reorders and copies
      instructions. This even applies to hand-written assembly code,
      which in many cases don't want to be reordered. Now that the
      SSA compiler does a good job for laying out instructions, the
      benefit of this pass is very little:
      
      AMD64: (old = with Follow, new = without Follow)
      name                      old time/op    new time/op    delta
      BinaryTree17-12              2.78s ± 1%     2.79s ± 1%  +0.44%  (p=0.000 n=20+19)
      Fannkuch11-12                3.11s ± 0%     3.31s ± 1%  +6.16%  (p=0.000 n=19+19)
      FmtFprintfEmpty-12          50.9ns ± 1%    51.6ns ± 3%  +1.40%  (p=0.000 n=17+20)
      FmtFprintfString-12          127ns ± 0%     128ns ± 1%  +0.88%  (p=0.000 n=17+17)
      FmtFprintfInt-12             122ns ± 0%     123ns ± 1%  +0.76%  (p=0.000 n=20+19)
      FmtFprintfIntInt-12          185ns ± 1%     186ns ± 1%  +0.65%  (p=0.000 n=20+19)
      FmtFprintfPrefixedInt-12     192ns ± 1%     202ns ± 1%  +4.99%  (p=0.000 n=20+19)
      FmtFprintfFloat-12           284ns ± 0%     288ns ± 0%  +1.33%  (p=0.000 n=15+19)
      FmtManyArgs-12               807ns ± 0%     804ns ± 0%  -0.44%  (p=0.000 n=16+18)
      GobDecode-12                7.23ms ± 1%    7.21ms ± 1%    ~     (p=0.052 n=20+20)
      GobEncode-12                6.09ms ± 1%    6.12ms ± 1%  +0.41%  (p=0.002 n=19+19)
      Gzip-12                      253ms ± 1%     255ms ± 1%  +0.95%  (p=0.000 n=18+20)
      Gunzip-12                   38.4ms ± 0%    38.5ms ± 0%  +0.34%  (p=0.000 n=17+17)
      HTTPClientServer-12         95.4µs ± 2%    96.1µs ± 1%  +0.78%  (p=0.002 n=19+19)
      JSONEncode-12               16.5ms ± 1%    16.6ms ± 1%  +1.17%  (p=0.000 n=19+19)
      JSONDecode-12               54.6ms ± 1%    55.3ms ± 1%  +1.23%  (p=0.000 n=18+18)
      Mandelbrot200-12            4.47ms ± 0%    4.47ms ± 0%  +0.06%  (p=0.000 n=18+18)
      GoParse-12                  3.47ms ± 1%    3.47ms ± 1%    ~     (p=0.583 n=20+20)
      RegexpMatchEasy0_32-12      84.8ns ± 1%    85.2ns ± 2%  +0.51%  (p=0.022 n=20+20)
      RegexpMatchEasy0_1K-12       206ns ± 1%     206ns ± 1%    ~     (p=0.770 n=20+20)
      RegexpMatchEasy1_32-12      82.8ns ± 1%    83.4ns ± 1%  +0.64%  (p=0.000 n=20+19)
      RegexpMatchEasy1_1K-12       363ns ± 1%     361ns ± 1%  -0.48%  (p=0.007 n=20+20)
      RegexpMatchMedium_32-12      126ns ± 1%     126ns ± 0%  +0.72%  (p=0.000 n=20+20)
      RegexpMatchMedium_1K-12     39.1µs ± 1%    39.8µs ± 0%  +1.73%  (p=0.000 n=19+19)
      RegexpMatchHard_32-12       1.97µs ± 0%    1.98µs ± 1%  +0.29%  (p=0.005 n=18+20)
      RegexpMatchHard_1K-12       59.5µs ± 1%    59.8µs ± 1%  +0.36%  (p=0.000 n=18+20)
      Revcomp-12                   442ms ± 1%     445ms ± 2%  +0.67%  (p=0.000 n=19+20)
      Template-12                 58.0ms ± 1%    57.5ms ± 1%  -0.85%  (p=0.000 n=19+19)
      TimeParse-12                 311ns ± 0%     314ns ± 0%  +0.94%  (p=0.000 n=20+18)
      TimeFormat-12                350ns ± 3%     346ns ± 0%    ~     (p=0.076 n=20+19)
      [Geo mean]                  55.9µs         56.4µs       +0.80%
      
      ARM32:
      name                     old time/op    new time/op    delta
      BinaryTree17-4              30.4s ± 0%     30.1s ± 0%  -1.14%  (p=0.000 n=10+8)
      Fannkuch11-4                13.7s ± 0%     13.6s ± 0%  -0.75%  (p=0.000 n=10+10)
      FmtFprintfEmpty-4           664ns ± 1%     651ns ± 1%  -1.96%  (p=0.000 n=7+8)
      FmtFprintfString-4         1.83µs ± 2%    1.77µs ± 2%  -3.21%  (p=0.000 n=10+10)
      FmtFprintfInt-4            1.57µs ± 2%    1.54µs ± 2%  -2.25%  (p=0.007 n=10+10)
      FmtFprintfIntInt-4         2.37µs ± 2%    2.31µs ± 1%  -2.68%  (p=0.000 n=10+10)
      FmtFprintfPrefixedInt-4    2.14µs ± 2%    2.10µs ± 1%  -1.83%  (p=0.006 n=10+10)
      FmtFprintfFloat-4          3.69µs ± 2%    3.74µs ± 1%  +1.60%  (p=0.000 n=10+10)
      FmtManyArgs-4              9.43µs ± 1%    9.17µs ± 1%  -2.70%  (p=0.000 n=10+10)
      GobDecode-4                76.3ms ± 1%    75.5ms ± 1%  -1.14%  (p=0.003 n=10+10)
      GobEncode-4                70.7ms ± 2%    69.0ms ± 1%  -2.36%  (p=0.000 n=10+10)
      Gzip-4                      2.64s ± 1%     2.65s ± 0%  +0.59%  (p=0.002 n=10+10)
      Gunzip-4                    402ms ± 0%     398ms ± 0%  -1.11%  (p=0.000 n=10+9)
      HTTPClientServer-4          458µs ± 0%     457µs ± 0%    ~     (p=0.247 n=10+10)
      JSONEncode-4                171ms ± 0%     172ms ± 0%  +0.56%  (p=0.000 n=10+10)
      JSONDecode-4                672ms ± 1%     668ms ± 1%    ~     (p=0.105 n=10+10)
      Mandelbrot200-4            33.5ms ± 0%    33.5ms ± 0%    ~     (p=0.156 n=9+10)
      GoParse-4                  33.9ms ± 0%    34.0ms ± 0%  +0.36%  (p=0.031 n=9+9)
      RegexpMatchEasy0_32-4       823ns ± 1%     835ns ± 1%  +1.49%  (p=0.000 n=8+8)
      RegexpMatchEasy0_1K-4      3.99µs ± 0%    4.02µs ± 1%  +0.92%  (p=0.000 n=8+10)
      RegexpMatchEasy1_32-4       877ns ± 3%     904ns ± 2%  +3.07%  (p=0.012 n=10+10)
      RegexpMatchEasy1_1K-4      5.99µs ± 0%    5.97µs ± 1%  -0.38%  (p=0.023 n=8+8)
      RegexpMatchMedium_32-4     1.40µs ± 2%    1.40µs ± 2%    ~     (p=0.590 n=10+9)
      RegexpMatchMedium_1K-4      357µs ± 0%     355µs ± 1%  -0.72%  (p=0.000 n=7+8)
      RegexpMatchHard_32-4       22.3µs ± 0%    22.1µs ± 0%  -0.49%  (p=0.000 n=8+7)
      RegexpMatchHard_1K-4        661µs ± 0%     658µs ± 0%  -0.42%  (p=0.000 n=8+7)
      Revcomp-4                  46.3ms ± 0%    46.3ms ± 0%    ~     (p=0.393 n=10+10)
      Template-4                  753ms ± 1%     750ms ± 0%    ~     (p=0.211 n=10+9)
      TimeParse-4                4.28µs ± 1%    4.22µs ± 1%  -1.34%  (p=0.000 n=8+10)
      TimeFormat-4               9.00µs ± 0%    9.05µs ± 0%  +0.59%  (p=0.000 n=10+10)
      [Geo mean]                  538µs          535µs       -0.55%
      
      ARM64:
      name                     old time/op    new time/op    delta
      BinaryTree17-8              8.39s ± 0%     8.39s ± 0%    ~     (p=0.684 n=10+10)
      Fannkuch11-8                5.95s ± 0%     5.99s ± 0%  +0.63%  (p=0.000 n=10+10)
      FmtFprintfEmpty-8           116ns ± 0%     116ns ± 0%    ~     (all equal)
      FmtFprintfString-8          361ns ± 0%     360ns ± 0%  -0.31%  (p=0.003 n=8+6)
      FmtFprintfInt-8             290ns ± 0%     290ns ± 0%    ~     (p=0.620 n=9+9)
      FmtFprintfIntInt-8          476ns ± 1%     469ns ± 0%  -1.47%  (p=0.000 n=10+6)
      FmtFprintfPrefixedInt-8     412ns ± 2%     417ns ± 2%  +1.39%  (p=0.006 n=9+10)
      FmtFprintfFloat-8           652ns ± 1%     652ns ± 0%    ~     (p=0.161 n=10+8)
      FmtManyArgs-8              1.94µs ± 0%    1.94µs ± 2%    ~     (p=0.781 n=10+10)
      GobDecode-8                17.7ms ± 1%    17.7ms ± 0%    ~     (p=0.962 n=10+7)
      GobEncode-8                15.6ms ± 0%    15.6ms ± 1%    ~     (p=0.063 n=10+10)
      Gzip-8                      786ms ± 0%     787ms ± 0%    ~     (p=0.356 n=10+9)
      Gunzip-8                    127ms ± 0%     127ms ± 0%  +0.08%  (p=0.028 n=10+9)
      HTTPClientServer-8          198µs ± 6%     198µs ± 7%    ~     (p=0.796 n=10+10)
      JSONEncode-8               42.5ms ± 0%    42.2ms ± 0%  -0.73%  (p=0.000 n=9+8)
      JSONDecode-8                158ms ± 1%     162ms ± 0%  +2.28%  (p=0.000 n=10+9)
      Mandelbrot200-8            10.1ms ± 0%    10.1ms ± 0%  -0.01%  (p=0.000 n=10+9)
      GoParse-8                  8.54ms ± 1%    8.63ms ± 1%  +1.06%  (p=0.000 n=10+9)
      RegexpMatchEasy0_32-8       231ns ± 1%     225ns ± 0%  -2.52%  (p=0.000 n=9+10)
      RegexpMatchEasy0_1K-8      1.63µs ± 0%    1.63µs ± 0%    ~     (p=0.170 n=10+10)
      RegexpMatchEasy1_32-8       253ns ± 0%     249ns ± 0%  -1.41%  (p=0.000 n=9+10)
      RegexpMatchEasy1_1K-8      2.08µs ± 0%    2.08µs ± 0%  -0.32%  (p=0.000 n=9+10)
      RegexpMatchMedium_32-8      355ns ± 1%     351ns ± 0%  -1.04%  (p=0.007 n=10+7)
      RegexpMatchMedium_1K-8      104µs ± 0%     104µs ± 0%    ~     (p=0.148 n=10+10)
      RegexpMatchHard_32-8       5.79µs ± 0%    5.79µs ± 0%    ~     (p=0.578 n=10+10)
      RegexpMatchHard_1K-8        176µs ± 0%     176µs ± 0%    ~     (p=0.137 n=10+10)
      Revcomp-8                   1.37s ± 1%     1.36s ± 1%  -0.26%  (p=0.023 n=10+10)
      Template-8                  151ms ± 1%     154ms ± 1%  +2.14%  (p=0.000 n=9+10)
      TimeParse-8                 723ns ± 2%     721ns ± 1%    ~     (p=0.592 n=10+10)
      TimeFormat-8                804ns ± 2%     798ns ± 3%    ~     (p=0.344 n=10+10)
      [Geo mean]                  154µs          154µs       -0.02%
      
      Therefore remove this pass. Also reduce text size by 0.5~2%.
      
      Comment out some dead code in runtime/sys_nacl_amd64p32.s
      which contains undefined symbols.
      
      Change-Id: I1473986fe5b18b3d2554ce96cdc6f0999b8d955d
      Reviewed-on: https://go-review.googlesource.com/36205
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      bed8129e
    • Mura Li's avatar
      crypto/des: improve the throughput of DES and 3DES · 76d42744
      Mura Li authored
      For detailed explanation of the adopted (Eric Young's) algorithm,
      see http://ftp.nluug.nl/security/coast/libs/libdes/ALGORITHM
      
      benchmark                   old ns/op     new ns/op     delta
      BenchmarkEncrypt-16         649           164           -74.73%
      BenchmarkDecrypt-16         546           156           -71.43%
      BenchmarkTDESEncrypt-16     1651          385           -76.68%
      BenchmarkTDESDecrypt-16     1645          378           -77.02%
      
      benchmark                   old MB/s     new MB/s     speedup
      BenchmarkEncrypt-16         12.31        48.76        3.96x
      BenchmarkDecrypt-16         14.64        51.03        3.49x
      BenchmarkTDESEncrypt-16     4.84         20.74        4.29x
      BenchmarkTDESDecrypt-16     4.86         21.16        4.35x
      
      Change-Id: Ic3e1fe3340419ec5a0e6379434911eb41e0246f6
      Reviewed-on: https://go-review.googlesource.com/36490
      Run-TryBot: Minux Ma <minux@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      76d42744
    • Alan Donovan's avatar
      go/types: permit f(nil...) for variadic arguments · 08bb7ccb
      Alan Donovan authored
      This code may be pointless, but it is legal.
      
      Fixes golang/go#18268
      
      Change-Id: Ibacae583606e1a6fdf0c0f01abe2e22e9e608393
      Reviewed-on: https://go-review.googlesource.com/34194Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      08bb7ccb
    • Nigel Tao's avatar
      image: fix the overlap check in Rectangle.Intersect. · a855da29
      Nigel Tao authored
      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: Ia654e4b9dc805978db3e94d7a9718b6366005360
      Reviewed-on: https://go-review.googlesource.com/34853Reviewed-by: default avatarDavid Crawshaw <crawshaw@golang.org>
      a855da29
    • Michael Matloob's avatar
      runtime/pprof: symbolize proto profiles · cbef450d
      Michael Matloob authored
      When generating pprof profiles in proto format, symbolize the profiles.
      
      Change-Id: I2471ed7f919483e5828868306418a63e41aff5c5
      Reviewed-on: https://go-review.googlesource.com/34192
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      cbef450d
    • Shintaro Kaneko's avatar
      test: improve output format of issue10607a.go test · 936749ef
      Shintaro Kaneko authored
      Change-Id: Iad5ff820a95f5082b75aa5260e40c33c7b0ecf22
      Reviewed-on: https://go-review.googlesource.com/35990Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      936749ef
    • Robert Griesemer's avatar
      cmd/compile/internal/syntax: avoid follow-up error for incorrect if statement · 53c6ac54
      Robert Griesemer authored
      This is a follow-up on https://go-review.googlesource.com/36470
      and leads to a more stable fix. The above CL relied on filtering
      of multiple errors on the same line to avoid more than one error
      for an `if` statement of the form `if a := 10 {}`. This CL avoids
      the secondary error ("missing condition in if statement") in the
      first place.
      
      For #18915.
      
      Change-Id: I8517f485cc2305965276c17d8f8797d61ef9e999
      Reviewed-on: https://go-review.googlesource.com/36479
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      53c6ac54
    • Quentin Smith's avatar
      testing: print extra labels on benchmarks · 6b742b2f
      Quentin Smith authored
      When running benchmarks, print "goos", "goarch", and "pkg"
      labels. This makes it easier to refer to benchmark logs and understand
      how they were generated. "pkg" is printed only for benchmarks located
      in GOPATH.
      
      Change-Id: I397cbdd57b9fe8cbabbb354ec7bfba59f5625c42
      Reviewed-on: https://go-review.googlesource.com/36356
      Run-TryBot: Quentin Smith <quentin@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      6b742b2f
    • Robert Griesemer's avatar
      spec: pick up a few corrections missed in prior commit · c0bd4f33
      Robert Griesemer authored
      This CL picks up a couple of minor fixes that were present
      in https://go-review.googlesource.com/#/c/36213/6..5 but
      accidentally got dropped in https://go-review.googlesource.com/#/c/36213/
      because I submitted from the wrong client.
      
      Change-Id: I3ad0d20457152ea9a116cbb65a23eb0dc3a8525e
      Reviewed-on: https://go-review.googlesource.com/36471Reviewed-by: default avatarMatthew Dempsky <mdempsky@google.com>
      c0bd4f33
  2. 06 Feb, 2017 14 commits