Type values being comparable implies that Type is a valid map key type.
As previously written, they sound unrelated.
Change-Id: I8e2235275d62898bfb47de850e8257b51ab5cbd6
Reviewed-on: https://go-review.googlesource.com/87021
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Don't suggest that it's always necessary to disable optimizations.
(The text can be misread that way, even if it's not what was meant.)
Change-Id: I9a2dff6a75ce4a3f9210cdf4f5bad6aaaeae9b29
Reviewed-on: https://go-review.googlesource.com/87018
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We were not being consistent.
Standardize on toolchain.
Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c
Reviewed-on: https://go-review.googlesource.com/87017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Suppose you build the Go toolchain in directory A,
move the whole thing to directory B, and then use
it from B to build a new program hello.exe, and then
run hello.exe, and hello.exe crashes with a stack
trace into the standard library.
Long ago, you'd have seen hello.exe print file names
in the A directory tree, even though the files had moved
to the B directory tree. About two years ago we changed
the compiler to write down these files with the name
"$GOROOT" (that literal string) instead of A, so that the
final link from B could replace "$GOROOT" with B,
so that hello.exe's crash would show the correct source
file paths in the stack trace. (golang.org/cl/18200)
Now suppose that you do the same thing but hello.exe
doesn't crash: it prints fmt.Println(runtime.GOROOT()).
And you run hello.exe after clearing $GOROOT from the
environment.
Long ago, you'd have seen hello.exe print A instead of B.
Before this CL, you'd still see hello.exe print A instead of B.
This case is the one instance where a moved toolchain
still divulges its origin. Not anymore. After this CL, hello.exe
will print B, because the linker sets runtime/internal/sys.DefaultGoroot
with the effective GOROOT from link time.
This makes the default result of runtime.GOROOT once again
match the file names recorded in the binary, after two years
of divergence.
With that cleared up, we can reintroduce GOROOT into the
link action ID and also reenable TestExecutableGOROOT/RelocatedExe.
When $GOROOT_FINAL is set during link, it is used
in preference to $GOROOT, as always, but it was easier
to explain the behavior above without introducing that
complication.
Fixes#22155.
Fixes#20284.
Fixes#22475.
Change-Id: Ifdaeb77fd4678fdb337cf59ee25b2cd873ec1016
Reviewed-on: https://go-review.googlesource.com/86835
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The linker has been applying -X options before loading symbols,
meaning that when it sees -X y=z it creates a symbol named y
and initializes its string data to z. The symbol named y is marked
"DUPOK" so that when the actual packages are loaded, no error is
emitted when the real y is seen. The predefined y's data is used
instead of whatever the real y says.
If we define -X y=z and we never load y, then the predefined symbol
is dropped during dead code elimination, but not in shared library
builds. Shared library builds must include all symbols, so we have to
be more careful about not defining symbols that wouldn't have
appeared anyway.
To be more careful, save the -X settings until after all the symbols
are loaded from the packages, and then apply the string changes
to whatever symbols are known (but ignore the ones that were not
loaded at all). This ends up being simpler anyway, since it doesn't
depend on DUPOK magic.
Makes CL 86835 safe.
Fixes#23273.
Change-Id: Ib4c9b2d5eafa97c5a8114401dbec0134c76be54f
Reviewed-on: https://go-review.googlesource.com/86915
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts commit cd0a5f0829, which
unnecessarily restricts the use of AddParseTree.
Change-Id: I1155214a20ba08981d604404e79fff54874fd8e4
Reviewed-on: https://go-review.googlesource.com/83919
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
When benchmarks run, they print lines like:
BenchmarkGenericNoMatch-8 3000000 385 ns/op
The first field, padded by spaces and followed by a tab,
is printed when the benchmark begins running.
The rest of the line is printed when the benchmark ends.
Tools and people can watch the timing of these prints
to see which benchmark is running.
To allow tools consuming json output to continue to be
able to see which benchmark is running, this CL adds a
special case to the usual "line at a time" behavior to flush
the benchmark name if it is observed separately from the
rest of the line.
Fixes#23352.
Change-Id: I7b6410698d78034eec18745d7f57b7d8e9575dbb
Reviewed-on: https://go-review.googlesource.com/86695
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Apple changed the format of its support page, so we need to
restructure the HTML parser. The HTML table is now parsed using
regular expressions, and certificates are then found in macOS
trust store by their fingerprint.
Fixes#22181
Change-Id: I29e7a40d37770bb005d728f1832299c528691f7e
Reviewed-on: https://go-review.googlesource.com/77252
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
No longer needs to be done.
Updates #23009
Updates #21255
Change-Id: I78e9e29a923dc03dea89ff3a5bf60f2e0bd0c0aa
Reviewed-on: https://go-review.googlesource.com/86476
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This just adds support on ELF systems, which is OK for now since that
is all that gccgo works on.
For the archive file generated by the compiler we add a new file
_buildid.o that has a section .go.buildid containing the build ID.
Using a new file lets us set the SHF_EXCLUDE bit in the section header,
so the linker will discard the section. It would be nicer to use
`objcopy --add-section`, but objcopy doesn't support setting the
SHF_EXCLUDE bit.
For an executable we just use an ordinary GNU build ID. Doing this
required modifying cmd/internal/buildid to look for a GNU build ID,
and use it if there is no other Go-specific note.
This CL fixes a minor bug in gccgoTOolchain.link: it was using .Target
instead of .built, so it failed for a cached file.
This CL fixes a bug reading note segments: the notes are aligned as
reported by the PT_NOTE's alignment field.
Updates #22472
Change-Id: I4d9e9978ef060bafc5b9574d9af16d97c13f3102
Reviewed-on: https://go-review.googlesource.com/85555
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If a benchmark calls b.Log without failing (without b.Error/b.Fatal/b.FailNow)
then that turns into output very much like a test passing,
except it says BENCH instead of PASS.
Benchmarks failing say FAIL just like tests failing.
Fixes#23346.
Change-Id: Ib188e695952da78057ab4a13f90d49937aa3c232
Reviewed-on: https://go-review.googlesource.com/86396
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is natural for tools to take a large string concatenation like
"1" + "1" + "1" + ... + "1"
and translate that into a sequence of go/constant calls:
x := constant.MakeString("1")
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
x = constant.BinaryOp(x, token.ADD, constant.MakeString("1"))
...
If the underlying representation of a string constant is a Go string,
then this leads to O(N²) memory for the concatenation of N strings,
allocating memory for "1", "11", "111", "1111", and so on.
This makes go/types and in particular cmd/vet run out of memory
(or at least use far too much) on machine-generated string concatenations,
such as those generated by go-bindata.
This CL allows code like the above to operate efficiently, by delaying
the evaluation of the actual string constant value until it is needed.
Now the representation of a string constant is either a string or an
explicit addition expression. The addition expression is turned into
a string the first time it is requested and then cached for future use.
This slows down the use of single strings, but analyses are likely not
dominated by that use anyway. It speeds up string concatenations,
especially large ones, significantly.
On my Mac running 32-bit code:
name old time/op new time/op delta
StringAdd/1-8 160ns ± 2% 183ns ± 1% +13.98% (p=0.000 n=10+10)
StringAdd/4-8 650ns ± 1% 927ns ± 4% +42.73% (p=0.000 n=10+10)
StringAdd/16-8 3.93µs ± 1% 2.78µs ± 2% -29.12% (p=0.000 n=8+9)
StringAdd/64-8 37.3µs ± 9% 10.1µs ± 5% -73.06% (p=0.000 n=10+10)
StringAdd/256-8 513µs ± 5% 38µs ± 1% -92.63% (p=0.000 n=10+10)
StringAdd/1024-8 5.67ms ± 4% 0.14ms ± 2% -97.45% (p=0.000 n=8+10)
StringAdd/4096-8 77.1ms ± 9% 0.7ms ± 2% -99.10% (p=0.000 n=10+9)
StringAdd/16384-8 1.33s ± 7% 0.00s ±10% -99.64% (p=0.000 n=10+10)
StringAdd/65536-8 21.5s ± 4% 0.0s ± 8% -99.89% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
StringAdd/1-8 232B ± 0% 256B ± 0% +10.34% (p=0.000 n=10+10)
StringAdd/4-8 1.20kB ± 0% 1.24kB ± 0% +3.33% (p=0.000 n=10+10)
StringAdd/16-8 14.7kB ± 0% 4.6kB ± 0% -68.87% (p=0.000 n=10+10)
StringAdd/64-8 223kB ± 0% 16kB ± 0% -92.66% (p=0.000 n=10+10)
StringAdd/256-8 3.48MB ± 0% 0.07MB ± 0% -98.07% (p=0.000 n=10+10)
StringAdd/1024-8 55.7MB ± 0% 0.3MB ± 0% -99.53% (p=0.000 n=10+10)
StringAdd/4096-8 855MB ± 0% 1MB ± 0% -99.88% (p=0.000 n=10+10)
StringAdd/16384-8 13.5GB ± 0% 0.0GB ± 0% -99.97% (p=0.000 n=9+10)
StringAdd/65536-8 215GB ± 0% 0GB ± 0% -99.99% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
StringAdd/1-8 3.00 ± 0% 3.00 ± 0% ~ (all equal)
StringAdd/4-8 9.00 ± 0% 11.00 ± 0% +22.22% (p=0.000 n=10+10)
StringAdd/16-8 33.0 ± 0% 25.0 ± 0% -24.24% (p=0.000 n=10+10)
StringAdd/64-8 129 ± 0% 75 ± 0% -41.86% (p=0.000 n=10+10)
StringAdd/256-8 513 ± 0% 269 ± 0% -47.56% (p=0.000 n=10+10)
StringAdd/1024-8 2.05k ± 0% 1.04k ± 0% -49.29% (p=0.000 n=10+10)
StringAdd/4096-8 8.19k ± 0% 4.12k ± 0% -49.77% (p=0.000 n=10+10)
StringAdd/16384-8 32.8k ± 0% 16.4k ± 0% -49.97% (p=0.000 n=9+10)
StringAdd/65536-8 131k ± 0% 66k ± 0% -50.11% (p=0.000 n=10+10)
https://perf.golang.org/search?q=upload:20180105.2Fixes#23348 (originally reported as cmd/vet failures in comments on #23222).
This makes constant.Values of Kind String no longer meaningful for ==, which
required fixes in go/types. While there, also fix go/types handling of constant.Values
of Kind Int (for uint64), Float, and Complex.
Change-Id: I80867bc9c4232c5c9b213443ff16645434a68b36
Reviewed-on: https://go-review.googlesource.com/86395
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
I marked every test that takes more than 0.5 seconds on my machine
as something to run only when not in -short mode, or in -short mode
on the beefy linux/amd64, windows/amd64, and darwin/amd64 builders.
I also shortened a few needlessly-expensive tests where possible.
Cuts the time for go test -short cmd/go from 45s to 15s on my machine.
Should help even more on some of our builders and slower user machines.
Fixes#23287.
Change-Id: I0e36003ef947b0ebe4224a1373731f9fa9216843
Reviewed-on: https://go-review.googlesource.com/86252
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Also vendors x/net/http git rev 42fe2e1c for:
http2: don't check WriteHeader status if we've already sent the header
https://golang.org/cl/86255Fixes#23010
Change-Id: I4f3dd63acb52d5a34a0350aaf847a7a376d6968f
Reviewed-on: https://go-review.googlesource.com/86275
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The docs were too specific. Make it vaguer. There are conditions for
which the Transport will try to reuse a connection anyway, even if the
Response Body isn't read to EOF or closed, but we don't need to get
into all the details in the docs.
Fixes#22954
Change-Id: I3b8ae32aeb1a61b396d0026e129552afbfecceec
Reviewed-on: https://go-review.googlesource.com/86276
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 84735 strengthened the -x test to make sure commands succeed,
using set -e, but the gcc flag tests can fail. Change them to say || true.
Fixes#23337.
Change-Id: I01e4017cb36ceb147b56935c2636de52ce7bdfdb
Reviewed-on: https://go-review.googlesource.com/86239
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.
fixes#8549
Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
In the comment of seedPost, the word: condiiton was changed to: condition
Change-Id: I8967cc0e9f5d37776bada96cc1443c8bf46e1117
Reviewed-on: https://go-review.googlesource.com/86156
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The spec refers to a map's key and element types; thus the respective
values are "keys" and "elements". Also, a map value is the value of
the entire map.
Similar fix for channels, where appropriate.
Fixes#23254.
Change-Id: I6f03ea6d86586c7b0b3e84f0c2e9446b8109fa53
Reviewed-on: https://go-review.googlesource.com/85999
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
If test case framing appears in ordinary test output,
then test2json can get confused. If the fake framing is being
saved with t.Logf/t.Errorf/etc then we can already
distinguish it from real framing, and the code did.
It just forgot to write that framing as output (1-line fix).
If the fake framing is being generated by printing directly
to stdout/stderr, then test2json will simply get confused.
There's not a lot to do at that point (maybe it's even a feature).
Fixes#23036.
Change-Id: I29449c7ace304172b89d8babe23de507c0500455
Reviewed-on: https://go-review.googlesource.com/86238
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
go test -json was inadvertently disabling caching. Fix that.
Fixes#22984.
Change-Id: Ic933a8c8ac00ce8253e934766954b1ccc6ac0cec
Reviewed-on: https://go-review.googlesource.com/84075
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If you have a package p1 with an xtest (package p1_test)
that imports p2, where p2 itself imports p1, then when
trying to do coverage for p1 we need to make sure to
recompile p2. The problem was that the overall package
import graph looked like:
main -> p1_test -> p2 -> p1
Since we were recompiling p1 with coverage, we correctly
figured out that because p2 depends on a package being
recompiled due to coverage, p2 also needs to be split (forked) to
insert the dependency on the modified p1. But then we used
the same logic to split p1_test and main, with the effect that
the changes to p2 and p1_test and main were lost, since the
caller was still holding on to the original main, not the split version.
Change the code to treat main and p1_test as "already split"
and just update them in place.
Fixes#23314.
Change-Id: If7edeca6e39cdaeb5b9380d00b0c7d8c5891f086
Reviewed-on: https://go-review.googlesource.com/86237
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
findrunnable loops over allp to check run queues *after* it has
dropped its own P. This is unsafe because allp can change when nothing
is blocking safe-points. Hence, procresize could change allp
concurrently with findrunnable's loop. Beyond generally violating Go's
memory model, in the best case this could findrunnable to observe a
nil P pointer if allp has been grown but the new slots not yet
initialized. In the worst case, the reads of allp could tear, causing
findrunnable to read a word that isn't even a valid *P pointer.
Fix this by taking a snapshot of the allp slice header (but not the
backing store) before findrunnable drops its P and iterating over this
snapshot. The actual contents of allp are immutable up to len(allp),
so this fixes the race.
Updates #23098 (may fix).
Change-Id: I556ae2dbfffe9fe4a1bf43126e930b9e5c240ea8
Reviewed-on: https://go-review.googlesource.com/86215
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update rewrite algorithm by coping code from
go/internal/work/buildid:updateBuildID.
Probably, this is not the best option. We could provide high-level API
in cmd/internal/buildid in the future.
Fixes#23181
Change-Id: I336a7c50426ab39bc9998b55c372af61a4fb21a7
Reviewed-on: https://go-review.googlesource.com/84735
Reviewed-by: Russ Cox <rsc@golang.org>
After 1.10, gcflags apply to only the immediate target.
Change-Id: I3bf331c76041e7b533076cb2f3274e44aafff58a
Reviewed-on: https://go-review.googlesource.com/84775
Reviewed-by: Heschi Kreinick <heschi@google.com>
In func TestXxxx(*testing.T) the Xxxx can be anything that can appear
in an identifier, but can't start with a lowercase letter. Clarify the docs.
Fixes#23322
Change-Id: I5c297916981f7e3890ee955d12bc7422a75488e2
Reviewed-on: https://go-review.googlesource.com/86001
Reviewed-by: Rob Pike <r@golang.org>
CL 78735 description:
time: add space padding layout strings(using underscore) for not only day but others
As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.
Updates #22802 (maybe fixes it)
Revert this CL because it breaks currently working formats that happen
to use underscores.
Fixes#23259
Change-Id: I64acaaca9b5b74785ee0f0be7910574e87daa649
Reviewed-on: https://go-review.googlesource.com/85998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
I don't know why these errors occur. Ignore them to avoid breaking the
build.
Updates #22019
Change-Id: Ia048e6d9b928e8e237b311ff3a364e7a23af4aa4
Reviewed-on: https://go-review.googlesource.com/86000
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We retrieve an error using getsockopt with SO_ERROR. We were reporting
the error as coming from "getsockopt", but really it is coming from
"connect". It is not getsockopt that failed.
Fixes#19302
Change-Id: I510ab76e4b04c70cd9dfdfc46d9a410bf653d017
Reviewed-on: https://go-review.googlesource.com/85997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Commit c2c07c7989 (CL 49331) changed the linker and runtime to always
use 2MB stacks on 64-bit Windows. This is the corresponding change to
make 32-bit Windows always use large (1MB) stacks because it's
difficult to detect when Windows applications will call into arbitrary
C code that may expect a large stack.
This is done as a separate change because it's possible this will
cause too much address space pressure for a 32-bit address space. On
the other hand, cgo binaries on Windows already use 1MB stacks and
there haven't been complaints.
Updates #20975.
Change-Id: I8ce583f07cb52254fb4bd47250f1ef2b789bc490
Reviewed-on: https://go-review.googlesource.com/49610
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
During the refactor in 1126d1483f I
introduced a logical error within one withLock function that used
the result of the call before checking for the error. Change
the order so that the error is checked before the result is used.
None of the other withLock uses have similar issues.
Fixes#23208
Change-Id: I6c5dcf262e36bad4369c850f1e0131066360a82e
Reviewed-on: https://go-review.googlesource.com/85175
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A Select Op could produce a value with upper 32 bits NOT zeroed,
for example, Div32 is lowered to (Select0 (DIVL x y)).
In theory, we could look into the argument of a Select to decide
whether the upper bits are zeroed. As it is late in release cycle,
just disable this optimization for Select for now.
Fixes#23305.
Change-Id: Icf665a2af9ccb0a7ba0ae00c683c9e349638bf85
Reviewed-on: https://go-review.googlesource.com/85736
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ilya Tocar <ilya.tocar@intel.com>
Modify the regex in TestLinuxSendfile to not match the parameters of
the syscall, just its name and the opening parenthesis. This is enough
to recognize that the syscall was invoked.
This fixes the TestLinuxSendfile test when running in Clear Linux,
where strace always execute with -yy implied, having output with extra
information in the parameters:
[pid 5336] sendfile(6<TCP:[127.0.0.1:35007->127.0.0.1:55170]>, 8</home/c/src/go/src/net/http/testdata/index.html>, NULL, 22) = 22
Change-Id: If7639b785d5fdf65fae8e6149a97a57b06ea981c
Reviewed-on: https://go-review.googlesource.com/85657
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Fixes#23224
The previous Pow code had an optimization for
powers equal to ±0.5 that used Sqrt for
increased accuracy/speed. This caused special
cases involving powers of ±0.5 to disagree with
the Pow spec. This change places the Sqrt optimization
after all of the special case handling.
Change-Id: I6bf757f6248256b29cc21725a84e27705d855369
Reviewed-on: https://go-review.googlesource.com/85660
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
