Roland Shoemaker [Fri, 8 May 2020 22:57:25 +0000 (15:57 -0700)]
crypto/x509: prioritize potential parents in chain building
When building a x509 chain the algorithm currently looks for parents
that have a subject key identifier (SKID) that matches the child
authority key identifier (AKID), if it is present, and returns all
matches. If the child doesn't have an AKID, or there are no parents
with matching SKID it will instead return all parents that have a
subject DN matching the child's issuer DN. Prioritizing AKID/SKID
matches over issuer/subject matches means that later in buildChains we
have to throw away any pairs where these DNs do not match. This also
prevents validation when a child has a SKID with two possible parents,
one with matching AKID but mismatching subject DN, and one with a
matching subject but missing AKID. In this case the former will be
chosen and the latter ignored, meaning a valid chain cannot be built.
This change alters how possible parents are chosen. Instead of doing a
two step search it instead only consults the CertPool.byName subject DN
map, avoiding issues where possible parents may be shadowed by parents
that have SKID but bad subject DNs. Additionally it orders the list of
possible parents by the likelihood that they are in fact a match. This
ordering follows this pattern:
* AKID and SKID match
* AKID present, SKID missing / AKID missing, SKID present
* AKID and SKID don't match
In an ideal world this should save a handful of cycles when there are
multiple possible matching parents by prioritizing parents that have
the highest likelihood. This does diverge from past behavior in that
it also means there are cases where _more_ parents will be considered
than in the past. Another version of this change could just retain the
past behavior, and only consider parents where both the subject and
issuer DNs match, and if both parent and child have SKID and AKID also
compare those, without any prioritization of the candidate parents.
This change removes an existing test case as it assumes that the
CertPool will return a possible candidate where the issuer/subject DNs
do not match.
Fixes #30079
Change-Id: I629f579cabb0b3d0c8cae5ad0429cc5a536b3e58
Reviewed-on: https://go-review.googlesource.com/c/go/+/232993
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Currently, in the linker's deadcode pass, when an interface type
is live, the linker thinks all its methods are live, and uses
them to match methods on concrete types. The interface method may
never be used, though.
This CL changes it to only keep used interface methods, for
matching concrete type methods. To do that, when an interface
method is used, the compiler generates a mark relocation. The
linker uses the marker relocations to mark used interface
methods, and only the used ones.
cmd/link, runtime: use a sentinel value for unreachable method
In the method table, the method's code pointer is stored as an
offset from the start of the text section. Currently, for an
unreachable method, the offset is left as 0, which resolves to
the start of the text section at run time. It is possible that
there is valid code there. If an unreachable method is ever
reached (due to a compiler or linker bug), the execution will
jump to a wrong location but may continue to run for a while,
until it fails with a seemingly unrelated error.
This CL changes it to use -1 for unreachable method instead. At
run time this will resolve to an invalid address, which makes it
fail immediately if it is ever reached.
A test that checks if "tls.(*Conn)" appears in any symbol's name.
tls.Conn is a type, so the string "tls.(*Conn)" can only appear
in the name of a method of Conn. But the test code doesn't use
any of the methods. Not sure why this needs to be live. In
particular, the linker is now able to prune all methods of Conn.
Remove this requirement. In fact, just drop the only_conn test
case, as simply allocating a type doesn't necessarily bring
anything live.
Daniel Martí [Sat, 26 Sep 2020 20:00:37 +0000 (21:00 +0100)]
cmd/go: fix doc math for build cache hashing
The function takes five 24-bit chunks from the hash, resulting in 120
bits. When base-64 encoded, this results in a 20-byte output string,
which is confirmed by "var dst [chunks * 4]byte".
It seems like the documented math could have been written for a previous
implementation with shorter hashes, using 4 chunks instead of 5, as then
the math checks out.
Since this code has been working correctly for over three years, let's
fix the documentation to reflect the code.
Change-Id: I9e908e6bafb5dcc1e3c23915e2b6c8843ed444d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/257646
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
NetBSD does not supply AT_HWCAP, however we still need to initialise
cpu.HWCaps. For now specify the bare minimum until we add some form of
capabilities detection. See
https://golang.org/issue/30824#issuecomment-494901591
Follows CL 174129 which did the same for openbsd/arm64.
Updates #30824
Change-Id: I43a86b583bc60d259a66772703de06970124bb7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/257998
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
cmd/link: consider interface conversions only in reachable code
The linker prunes methods that are not directly reachable if the
receiver type is never converted to interface. Currently, this
"never" is too strong: it is invalidated even if the interface
conversion is in an unreachable function. This CL improves it by
only considering interface conversions in reachable code. To do
that, we introduce a marker relocation R_USEIFACE, which marks
the target symbol as UsedInIface if the source symbol is reached.
Matthew Dempsky [Mon, 28 Sep 2020 19:19:56 +0000 (12:19 -0700)]
cmd/compile: fix type checking of "make" arguments
As part of type checking make's arguments, we were converting untyped
float and complex constant arguments to integers. However, we were
doing this without concern for whether the argument was a declared
constant. Thus a call like "make([]T, n)" could change n from an
untyped float or untyped complex to an untyped integer.
The fix here is to simply change checkmake to not call SetVal, which
will be handled by defaultlit anyway. However, we also need to
properly return the defaultlit result value to the caller, so
checkmake's *Node parameter is also changed to **Node.
Fixes #41680.
Change-Id: I858927a052f384ec38684570d37b10a6906961f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/257966
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Roland Shoemaker [Mon, 28 Sep 2020 15:59:13 +0000 (08:59 -0700)]
crypto/x509: hardcode RSA PSS parameters rather than generating them
Rather than generating the three possible RSA PSS parameters each time
they are needed just hardcode them and pick the required one based on
the hash function.
Fixes #41407
Change-Id: Id43bdaf40b3ca82c4c04c6588e3b643f63107657
Reviewed-on: https://go-review.googlesource.com/c/go/+/258037
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org>
Alberto Donizetti [Sat, 26 Sep 2020 07:42:59 +0000 (09:42 +0200)]
cmd/compile: fix escape reason for MAKESLICE with no cap
When explaining why the slice from a make() call escapes for the -m -m
message, we print "non-const size" if any one of Isconst(n.Left) and
Isconst(n.Right) return false; but for OMAKESLICE nodes with no cap,
n.Right is nil, so Isconst(n.Right, CTINT) will be always false.
Only call Isconst on n.Right if it's not nil.
Fixes #41635
Change-Id: I8729801a9b234b68ae40adad64d66fa7653adf09
Reviewed-on: https://go-review.googlesource.com/c/go/+/257641 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
os: remove ENOTSUP special case in Getwd on darwin
ENOTSUP was used as a signaling error in the custom implementation of
syscall.Getwd to fall back to the slow algorithm. Since CL 257637 Getwd
directly calls the respective function from libSystem.dylib which can no
longer return ENOTSUP.
Change-Id: I8e65e42b3ea069bf78969a29f2af1c55552e2949
Reviewed-on: https://go-review.googlesource.com/c/go/+/257644
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Changkun Ou [Thu, 24 Sep 2020 06:57:00 +0000 (08:57 +0200)]
os: document and emphasize a potential misuse of File.Fd
This CL revises the document of File.Fd that explicitly points
its user to runtime.SetFinalizer where contains the information
that a file descriptor could be closed in a finalizer and therefore
causes a failure in syscall.Write if runtime.KeepAlive is not invoked.
The CL also suggests an alternative of File.Fd towards File.SyscallConn.
Fixes #41505
Change-Id: I6816f0157add48b649bf1fb793cf19dcea6894b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/256899 Reviewed-by: Rob Pike <r@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
David Chase [Fri, 25 Sep 2020 17:30:51 +0000 (13:30 -0400)]
cmd/compile: fix logopt log directory naming for windows
Allow Windows absolute paths, also fixed URI decoding on Windows.
Added a test, reorganized to make the test cleaner.
Also put some doc comments on exported functions that did not have them.
Fixes #41614.
Change-Id: I2871be0e5183fbd53ffb309896d6fe56c15a7727
Reviewed-on: https://go-review.googlesource.com/c/go/+/257677
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
On netbsd/arm64 `uname -m` reports `evbarm` which is mapped to
gohostarch=arm. Fix this by checking for "aarch64" in `uname -p` output
to fix self-hosted build on netbsd/arm64.
Alberto Donizetti [Tue, 22 Sep 2020 13:31:43 +0000 (15:31 +0200)]
cmd/compile: more amd64 typed rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I2621f9ab48199204cf6116941b19b6df4170d0e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/256497
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
syscall: implement Getwd using getcwd from libSystem on darwin
Directly wrap the getcwd implementation provided by libSystem.dylib on
darwin and use it to implement Getwd like on the BSDs. This allows to
drop the custom implementation using getAttrList and to merge the
implementation of Getwd for darwin and the BSDs in syscall_bsd.go.
Same as CL 257497 did for golang.org/x/sys/unix
Change-Id: If30390c4c17cd463bb8fdcb5465f40d6fa11f391
Reviewed-on: https://go-review.googlesource.com/c/go/+/257637
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Direct syscalls using syscall numbers are no longer supported on darwin
since Go 1.12, see https://golang.org/doc/go1.12#darwin. Also,
/usr/include/sys/syscall.h is no longer available on recent macOS
versions, so remove the generating script.
Change-Id: I8e2579c3d0e94a61fc041d06280149ec6ccf13e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/257638
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
vendor, cmd/vendor: update vendored x/sys and x/net
Pick up GOOS=ios changes.
This is done by
cd $GOROOT/src
go get -d golang.org/x/net@latest
go mod tidy
go mod vendor
go get -d golang.org/x/sys@latest
go mod tidy
go mod vendor
cd $GOROOT/src/cmd
go get -d golang.org/x/sys@latest
go mod tidy
go mod vendor
Michael Pratt [Fri, 11 Sep 2020 16:14:06 +0000 (12:14 -0400)]
runtime: drop nosplit from primary lockrank functions
acquireLockRank and releaseLockRank are called from nosplit context, and
thus must be nosplit.
lockWithRank, unlockWithRank, and lockWithRankMayAcquire are called from
spittable context, and thus don't strictly need to be nosplit.
The stated reasoning for making these functions nosplit is to avoid
re-entrant calls due to a stack split on function entry taking a lock.
There are two potential issues at play here:
1. A stack split on function entry adds a new lock ordering edge before
we (a) take lock l, or (b) release lock l.
2. A stack split in a child call (such as to lock2) introduces a new
lock ordering edge _in the wrong order_ because e.g., in the case of
lockWithRank, we've noted that l is taken, but the stack split in
lock2 actually takes stack split locks _before_ l is actually locked.
(1) is indeed avoided by marking these functions nosplit, but this is
really just a bit of duct tape that generally has no effect overall. Any
earlier call can have a stack split and introduce the same new edge.
This includes lock/unlock which are not nosplit!
I began this CL as a change to extend nosplit to lock and unlock to try
to make this mitigation more effective, but I've realized that as long
as there is a _single_ nosplit call between a lock and unlock, we can
end up with the edge. There seems to be few enough cases without any
calls that is does not seem worth the extra cognitive load to extend
nosplit throughout all of the locking functions.
(2) is a real issue which would cause incorrect ordering, but it is
already handled by switching to the system stack before recording the
lock ordering. Adding / removing nosplit has no effect on this issue.
Change-Id: I94fbd21b2bf928dbf1bf71aabb6788fc0a012829
Reviewed-on: https://go-review.googlesource.com/c/go/+/254367
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dan Scales <danscales@google.com>
Trust: Michael Pratt <mpratt@google.com>
The rules for go:notinheap were recently tweaked to disallow stack
allocation (CL 249917). This CL updates the documentation about
go:notinheap in runtime/HACKING.md.
Keith Randall [Fri, 25 Sep 2020 02:26:33 +0000 (19:26 -0700)]
runtime: use old capacity to decide on append growth regime
We grow the backing store on append by 2x for small sizes and 1.25x
for large sizes. The threshold we use for picking the growth factor
used to depend on the old length, not the old capacity. That's kind of
unfortunate, because then doing append(s, 0, 0) and append(append(s,
0), 0) do different things. (If s has one more spot available, then
the former expression chooses its growth based on len(s) and the
latter on len(s)+1.) If we instead use the old capacity, we get more
consistent behavior. (Both expressions use len(s)+1 == cap(s) to
decide.)
Fixes #41239
Change-Id: I40686471d256edd72ec92aef973a89b52e235d4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/257338
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
cmd/asm: fix the issue of moving 128-bit integers to vector registers on arm64
The CL 249758 added `FMOVQ $vcon, Vd` instruction and assembler used
128-bit simd literal-loading to load `$vcon` from pool into 128-bit vector
register `Vd`. Because Go does not have 128-bit integers for now, the
assembler will report an error of `immediate out of range` when
assembleing `FMOVQ $0x123456789abcdef0123456789abcdef, V0` instruction.
This patch lets 128-bit integers take two 64-bit operands, for the high
and low parts separately and adds `VMOVQ $hi, $lo, Vd` instruction to
move `$hi<<64+$lo' into 128-bit register `Vd`.
In addition, this patch renames `FMOVQ/FMOVD/FMOVS` ops to 'VMOVQ/VMOVD/VMOVS'
and uses them to move 128-bit, 64-bit and 32-bit constants into vector
registers, respectively
Keith Randall [Thu, 24 Sep 2020 21:25:21 +0000 (14:25 -0700)]
cmd/compile: prevent 387+float32+pie from clobbering registers
The 387 port needs to load a floating-point control word from a
global location to implement float32 arithmetic.
When compiling with -pie, loading that control word clobbers an
integer register. If that register had something important in it, boom.
Fix by using LEAL to materialize the address of the global location
first. LEAL with -pie works because the destination register is
used as the scratch register.
387 support is about to go away (#40255), so this will need to be
backported to have any effect.
No test. I have one, but it requires building with -pie, which
requires cgo. Our testing infrastructure doesn't make that easy.
Not worth it for a port which is about to vanish.
Fixes #41503
Change-Id: I140f9fc8fdce4e74a52c2c046e2bd30ae476d295
Reviewed-on: https://go-review.googlesource.com/c/go/+/257277
Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Than McIntosh [Thu, 24 Sep 2020 20:11:43 +0000 (16:11 -0400)]
cmd/compile,cmd/asm: fix buglet in -S=2 output
In CL 255718 the -S=2 assembly output was enhanced to dump symbol
ABIs. This patch fixes a bug in that CL: when dumping the relocations
on a symbol, we were dumping the symbol's ABI as opposed to the
relocation target symbol's ABI.
Change-Id: I134128687757f549fa37b998cff1290765889140
Reviewed-on: https://go-review.googlesource.com/c/go/+/257202
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Robert Griesemer [Thu, 24 Sep 2020 19:44:19 +0000 (12:44 -0700)]
spec: better variable name for operator example
Suggested by @yaxinlx.
Fixes #41612.
Change-Id: I98b9968a95d090ee3c67ff02678e1874e6d98c33
Reviewed-on: https://go-review.googlesource.com/c/go/+/257159
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Daniel Martí [Fri, 12 Jun 2020 14:14:42 +0000 (15:14 +0100)]
cmd/go: error when -c or -i are used with unknown flags
Other test flags passed to the test binary, such as -run or -count, are
equally pointless when -c or -i are used, since the test binary is never
run. However, custom flags in that scenario are far more likely to be
due to human error, such as:
# note the "ldflags" typo, which silently did nothing
go test -c -lflags=-w
Instead, make this scenario error. It seems unlikely that anyone is
using -c along with intended custom-defined test flags, and if they are,
removing those extra flags that do nothing is probably a good idea
anyway.
We don't add this restriction for the flags defined in 'go help
testflag', since they are far less likely to be typos or unintended
mistakes. Another reason not to do that change is that other commands
similarly silently ignore no-op flags, such as:
# -d disables the build, so -ldflags is never used
go get -d -ldflags=-w
Fixes #39484.
Change-Id: I6ba2f6866562fe8f8fceaf4cd862d874bf5cd978
Reviewed-on: https://go-review.googlesource.com/c/go/+/237697
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
Changkun Ou [Sat, 19 Sep 2020 21:32:12 +0000 (23:32 +0200)]
testing: send t.signal only if there is no panic
If a signal is sent to t.signal before the panic is triggered,
a panicking test may end up with "warning: no tests to run" because
the tRunner that invokes the test in t.Run calls runtime.Goexit on
panic, which causes the panicking test not be recorded in runTests.
Send the signal if and only if there is no panic.
Fixes #41479
Change-Id: I812f1303bfe02c443a1902732e68d21620d6672e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256098
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Emmanuel Odeke <emm.odeke@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Sean Liao [Thu, 21 May 2020 15:52:33 +0000 (17:52 +0200)]
encoding/json: allow semicolon in field key / struct tag
Allow ';' as a valid character for json field keys and struct tags.
Fixes #39189
Change-Id: I4b602a1b0674ff028db07623682f0d1e8e9fd6c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/234818
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Alberto Donizetti [Thu, 24 Sep 2020 12:36:34 +0000 (14:36 +0200)]
cmd/compile: more amd64 typed aux rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: Id9da1240ca810fe07f23c56b36900b6e35a10a6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/257037
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
CL 250357 exported net.ErrClosed to allow more reliable detection
of closed network connection errors. Use that error in crypto/tls
as well.
The error message is changed from "tls: use of closed connection"
to "use of closed network connection", so the code that detected such
errors by looking for that text in the error message will need to be
updated to use errors.Is(err, net.ErrClosed) instead.
Fixes #41066
Change-Id: Ic05c0ed6a4f57af2a0302d53b00851a59200be2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/256897 Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sat, 29 Aug 2020 09:10:50 +0000 (11:10 +0200)]
cmd/compile: enforce strongly typed rules for ARM (GOARM)
Toolstash-check successful for remaining rules using GOARM value.
Change-Id: I254f80d17839ef4957c1b7afbdb4db363a3b9367
Reviewed-on: https://go-review.googlesource.com/c/go/+/240997
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
SparrowLii [Tue, 25 Aug 2020 08:33:50 +0000 (16:33 +0800)]
math/big: replace division with multiplication by reciprocal word
Division is much slower than multiplication. And the method of using
multiplication by multiplying reciprocal and replacing division with it
can increase the speed of divWVW algorithm by three times,and at the
same time increase the speed of nats division.
Change-Id: I049f1196562b20800e6ef8a6493fd147f93ad830
Reviewed-on: https://go-review.googlesource.com/c/go/+/250417
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Alberto Donizetti [Wed, 23 Sep 2020 12:41:33 +0000 (14:41 +0200)]
cmd/compile: switch to typed for amd64 flag const rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I5a322c9a3922107aa3bfcddfae732dcd6e15ac3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/256738
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
The IndexString implementation in the bytealg package requires that
the string passed into it be in the range '2 <= len(s) <= MaxLen'
where MaxLen may be any value (including 0).
CL 156998 added calls to bytealg.IndexString where MaxLen was not
first checked. This led to an illegal instruction on s390x with
the vector facility disabled.
This CL guards the calls to bytealg.IndexString with a MaxLen check.
If the check fails then the code now falls back to the pre CL 156998
implementation (a loop over the runes in the string).
Since the MaxLen check is now in place the generic implementation is
no longer called so I have returned it to its original unimplemented
state.
In future we may want to drop MaxLen to prevent this kind of
confusion.
Fixes #41552.
Change-Id: Ibeb3f08720444a05c08d719ed97f6cef2423bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/256717
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Munday <mike.munday@ibm.com> Reviewed-by: Keith Randall <khr@golang.org>
Constantin Konstantinidis [Sat, 4 Jul 2020 09:01:29 +0000 (11:01 +0200)]
cmd/compile: enforce strongly typed rules for ARM (8)
add type casting to int32: L148-L156, L774-L778
Toolstash-check successful
Change-Id: Ib6544c1d7853c2811def5b18786e1fc5c18086ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/256097 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Change-Id: I69e8e9f964c1f35615e4e19401c3f661e1e64a3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256100 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Change-Id: I80f90716477f269a227be28b14bf913b78ef375d
Reviewed-on: https://go-review.googlesource.com/c/go/+/228824
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Introduce GOOS=ios for iOS systems. GOOS=ios matches "darwin"
build tag, like GOOS=android matches "linux" and GOOS=illumos
matches "solaris". Only ios/arm64 is supported (ios/amd64 is
not).
GOOS=ios and GOOS=darwin remain essentially the same at this
point. They will diverge at later time, to differentiate macOS
and iOS.
Uses of GOOS=="darwin" are changed to (GOOS=="darwin" || GOOS=="ios"),
except if it clearly means macOS (e.g. GOOS=="darwin" && GOARCH=="amd64"),
it remains GOOS=="darwin".
The instructions have already been updated in greater
detail in "Step 2: Configure git authentication", but
the overview needs updated to reflect the new workflow.
Change-Id: I6f411a3dc500a9058036a4a828403c0153e4220a
Reviewed-on: https://go-review.googlesource.com/c/go/+/256857
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sat, 4 Jul 2020 09:29:40 +0000 (11:29 +0200)]
cmd/compile: enforce strongly typed rules for ARM (4)
"mul by constant" until "div by constant"
L547-L609
Change-Id: I19ebb5694e383878f505d34df2591a51fe38431a
Reviewed-on: https://go-review.googlesource.com/c/go/+/254662 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Alberto Donizetti [Sun, 20 Sep 2020 07:15:29 +0000 (09:15 +0200)]
cmd/compile: switch to typed aux in more amd64 rules
Passes
gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I9acda12d24f85d0b12d0cbbedbf9df3b4afcb31b
Reviewed-on: https://go-review.googlesource.com/c/go/+/256099
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Change-Id: I5b6ef0da5052e3381ee9c714bbff541c11ed0259
Reviewed-on: https://go-review.googlesource.com/c/go/+/246837
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Constantin Konstantinidis [Fri, 15 May 2020 18:35:00 +0000 (20:35 +0200)]
cmd/compile: enforce strongly typed rules for ARM (6)
End of "constant folding in *shift ops" until EOF
(L1070-)
Toolstash-check is successful.
Change-Id: I55846a459aca5238f831750f04132e13a0baeed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/234198 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Thu, 14 May 2020 05:43:01 +0000 (07:43 +0200)]
cmd/compile: enforce strongly typed rules for ARM (5)
From "absorb InvertFlags" until "constant folding in *shift ops"
L666-L1011
Toolstash-check is successful.
Change-Id: Ieed7d4643dc3dc2b3649477e87aebd22c81d1322
Reviewed-on: https://go-review.googlesource.com/c/go/+/234197 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sun, 10 May 2020 19:55:55 +0000 (21:55 +0200)]
cmd/compile: enforce strongly typed rules for ARM (3)
Toolstash-check successful from L270 until L543.
Change-Id: Ic39ab86c80f970bfb21e318284f6bb3e8a994220
Reviewed-on: https://go-review.googlesource.com/c/go/+/233439 Reviewed-by: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Constantin Konstantinidis [Sun, 10 May 2020 06:10:47 +0000 (08:10 +0200)]
cmd/compile: enforce strongly typed rules for ARM (2)
Toolstash-check successful from L0 until L268
Change-Id: Ifc55ea1e4177c21107c521fc72da2da7b507b8ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/232811 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
QueryPackage was a wrapper around QueryPattern with extra validation,
called only once from within the same package. Most of that validation
was already performed much earlier, in (*loader).Load. Inline the
remaining validation and remove the needless indirection.
For #36460
Change-Id: I108a01d416197db8f886889554e07b29f0c37f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/256057
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Change-Id: I3989bcb051ae57dd2d8f89759d241d4cdce49659
Reviewed-on: https://go-review.googlesource.com/c/go/+/255969
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
cmd/go: add a '-e' flag to 'mod tidy' and 'mod vendor'
This flag, like the -e flag to 'go list', instructs the command to
make a best effort to continue in spite of errors for specific packages.
Fixes #26603
Change-Id: I5ee2f50c71870ae8ef3f9b3e5b045474adcca525
Reviewed-on: https://go-review.googlesource.com/c/go/+/255960
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
This change replaces ImportPaths, ImportPathsQuiet, LoadALL, and
LoadVendor with a single LoadPackages function, with a LoadOpts struct
that more clearly documents the variations in behavior.
It also eliminates the cmd/go/internal/load.ImportPaths function,
which was undocumented and had only one call site (within its own
package).
The modload.LoadTests global variable is subsumed by a field in the
new LoadOpts struct, and is no longer needed for callers that invoke
LoadPackages directly. It has been (temporarily) replaced with a
similar global variable, load.ModResolveTests, which can itself be
converted to an explicit, local argument.
For #37438
For #36460
Updates #40775
Fixes #26977
Change-Id: I4fb6086c01b04de829d98875db19cf0118d40f8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255938
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
Michael Pratt [Fri, 21 Aug 2020 15:51:25 +0000 (11:51 -0400)]
runtime: add sched.lock assertions
Functions that require holding sched.lock now have an assertion.
A few places with missing locks have been fixed in this CL:
Additionally, locking is added around the call to procresize in
schedinit. This doesn't technically need a lock since the program is
still starting (thus no concurrency) when this is called, but lock held
checking doesn't know that.
Updates #40677
Change-Id: I198d3cbaa727f7088e4d55ba8fa989cf1ee8f9cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/250261
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Pratt [Fri, 21 Aug 2020 15:49:56 +0000 (11:49 -0400)]
runtime: check held locks with staticlockranking
When lock ranking is enabled, we can now assert that lock preconditions
are met by checking that the caller holds required locks on function
entry.
This change adds the infrastructure to add assertions. Actual assertions
will be added for various locks in subsequent changes.
Some functions are protected by locks that are not directly accessible
in the function. In that case, we can use assertRankHeld to check that
any lock with the rank is held. This is less precise, but it avoids
requiring passing the lock into the functions.
Updates #40677
Change-Id: I843c6874867f975e90a063f087b6e2ffc147877b
Reviewed-on: https://go-review.googlesource.com/c/go/+/245484
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Dmitri Shuralyov [Thu, 17 Sep 2020 16:32:24 +0000 (12:32 -0400)]
all: update vendored dependencies during Go 1.16 development
The Go 1.16 development cycle has started. This is the time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Those versions have already gone through code review, and now they
will undergo additional testing during the development period.
If there are new issues in these dependencies discovered, we have
development period to deal with that. We will do this update once
more at the end of the development cycle, by the code freeze, and
so doing it now will make that update smaller and safer.
Overall, this change will help us build confidence that the
Go 1.16 release and its selected dependencies will be robust.
Also increment the Go language version to 1.16 in standard library
go.mod files.
This change was created with a program from CL 256357 patch set 1
(which updates golang.org/x modules only) and the bundle tool at
CL 255053 patch set 1:
$ updatestd -goroot=$HOME/gotip -branch=master
> go version
go version devel +eda1d40544 Mon Sep 21 16:50:07 2020 +0000 darwin/amd64
> go env GOROOT
/Users/dmitshur/gotip
> go version -m /Users/dmitshur/go/bin/bundle
/Users/dmitshur/go/bin/bundle: go1.15.2
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools (devel) # CL 255053 PS 1
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
debug/dwarf: speed up SkipChildren for compilation units
For a common pattern of iterating only over top-level compilation units (CU)
Reader.SkipChildren has decode and meterialize all CU subentries just
to skip them, because DW_TAG_compile_unit does not have DW_AT_sibling.
However, CUs have total size encoded before the unit and we already parse them
and know all unit sizes.
Optimize Reader.SkipChildren to use that size when skipping CUs children.
This speeds up iteration over a 1.3GB object file from 7.5s to 0.73s.
Change-Id: I2a8f00955159b4bd13571409f4817805f934cb69
Reviewed-on: https://go-review.googlesource.com/c/go/+/256217
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Than McIntosh <thanm@google.com>
Michael Pratt [Fri, 18 Sep 2020 21:53:12 +0000 (17:53 -0400)]
runtime: expand gopark documentation
unlockf is called after the G is put into _Gwaiting, meaning another G
may have readied this one before unlockf is called.
This is implied by the current doc, but add additional notes to call out
this behavior, as it can be quite surprising.
Updates #40641
Change-Id: I60b1ccc6a4dd9ced8ad2aa1f729cb2e973100b59
Reviewed-on: https://go-review.googlesource.com/c/go/+/256058
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Michael Anthony Knyszek [Mon, 10 Aug 2020 20:02:22 +0000 (20:02 +0000)]
runtime: disable stack shrinking in activeStackChans race window
Currently activeStackChans is set before a goroutine blocks on a channel
operation in an unlockf passed to gopark. The trouble is that the
unlockf is called *after* the G's status is changed, and the G's status
is what is used by a concurrent mark worker (calling suspendG) to
determine that a G has successfully been suspended. In this window
between the status change and unlockf, the mark worker could try to
shrink the G's stack, and in particular observe that activeStackChans is
false. This observation will cause the mark worker to *not* synchronize
with concurrent channel operations when it should, and so updating
pointers in the sudog for the blocked goroutine (which may point to the
goroutine's stack) races with channel operations which may also
manipulate the pointer (read it, dereference it, update it, etc.).
Fix the problem by adding a new atomically-updated flag to the g struct
called parkingOnChan, which is non-zero in the race window above. Then,
in isShrinkStackSafe, check if parkingOnChan is zero. The race is
resolved like so:
* Blocking G sets parkingOnChan, then changes status in gopark.
* Mark worker successfully suspends blocking G.
* If the mark worker observes parkingOnChan is non-zero when checking
isShrinkStackSafe, then it's not safe to shrink (we're in the race
window).
* If the mark worker observes parkingOnChan as zero, then because
the mark worker observed the G status change, it can be sure that
gopark's unlockf completed, and gp.activeStackChans will be correct.
The risk of this change is low, since although it reduces the number of
places that stack shrinking is allowed, the window here is incredibly
small. Essentially, every place that it might crash now is replaced with
no shrink.
This change adds a test, but the race window is so small that it's hard
to trigger without a well-placed sleep in park_m. Also, this change
fixes stackGrowRecursive in proc_test.go to actually allocate a 128-byte
stack frame. It turns out the compiler was destructuring the "pad" field
and only allocating one uint64 on the stack.
Fixes #40641.
Change-Id: I7dfbe7d460f6972b8956116b137bc13bc24464e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/247050
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
runtime: improve error messages after allocating a stack that is too big
In the current implementation, we can observe crashes after calling
debug.SetMaxStack and allocating a stack larger than 4GB since
stackalloc works with 32-bit sizes. To avoid this, we define an upper
limit as the largest feasible point we can grow a stack to and provide a
better error message when we get a stack overflow.
Fixes #41228
Change-Id: I55fb0a824f47ed9fb1fcc2445a4dfd57da9ef8d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/255997
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com> Reviewed-by: Keith Randall <khr@golang.org>
unicode/utf8: document the handling of runes out of range in EncodeRune
Document the way EncodeRune currently handles runes which are
out of range. Also add an example showing that behaviour.
Change-Id: I0f8e7645ae053474ec319085a2bb6d7f73bc137c
Reviewed-on: https://go-review.googlesource.com/c/go/+/255998 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Giovanni Bajo <rasky@develer.com>
Trust: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
surechen [Wed, 6 May 2020 12:04:35 +0000 (20:04 +0800)]
math: Remove redundant local variable Ln2
Use the const variable Ln2 in math/const.go for function acosh.
Change-Id: I5381d03dd3142c227ae5773ece9be6c8f377615e
Reviewed-on: https://go-review.googlesource.com/c/go/+/232517 Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Jay Lee [Fri, 18 Sep 2020 05:49:09 +0000 (05:49 +0000)]
time: support colon at start of TZ value
According to POSIX, there are three formats for TZ variable. When
it refers to timezone file, it should starts with a colon. This commit
removes the colon if it exists, so that it keeps compatible with both
the spec and the old behavior.
Change-Id: I30cfeaea530d24e174de309952338cb1146694a5
GitHub-Last-Rev: 11d83d11ca2eca9d542036cf5e23559388fd323e
GitHub-Pull-Request: golang/go#27570
Reviewed-on: https://go-review.googlesource.com/c/go/+/134217
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I61a13f7d6410e4931efaa20307bdf1cc0037afc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/255200
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Change-Id: I2233a6a157ec8feffaefd6a8ee65b1c38778c1cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/255238 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Giovanni Bajo <rasky@develer.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Keith Randall [Fri, 18 Sep 2020 21:19:22 +0000 (14:19 -0700)]
reflect: use zero buffer to back the Value returned by Zero
In the common case (<1KB types), no allocation is required
by reflect.Zero.
Also use memclr instead of memmove in Set when the source
is known to be zero.
Fixes #33136
Change-Id: Ic66871930fbb53328032e587153ebd12995ccf55
Reviewed-on: https://go-review.googlesource.com/c/go/+/192331
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Martin Möhrmann <moehrmann@google.com>
cmd/link: don't mark a symbol's GoType reachable when -linkshared
In CL 231397, we stopped marking symbols' GoType reachable in
general, but not when -linkshared. It was left as a TODO. This CL
addresses it.
The problem was that the type names are mangled in the shared
library, so we need to mangle the name consistently in the
executable as well (regardless of whether the symbol is reachable
or not), so that the GCProg generation code can find the
corresponding symbol from the shared library.
Change-Id: I1040747402929a983ec581109f1681a77893682e
Reviewed-on: https://go-review.googlesource.com/c/go/+/255964
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Keith Randall [Thu, 20 Aug 2020 21:22:30 +0000 (14:22 -0700)]
runtime/debug: provide Addr method for errors from SetPanicOnFault
When we're building a panic that's triggered by a memory fault when
SetPanicOnFault has been called, include an Addr method. This
method reports the address at which the fault occurred.
Fixes #37023
RELNOTE=yes
Change-Id: Idff144587d6b75070fdc861a36efec76f4ec7384
Reviewed-on: https://go-review.googlesource.com/c/go/+/249677
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
David Chase [Wed, 15 Jul 2020 13:07:00 +0000 (09:07 -0400)]
cmd/compile: generate late-lowering static calls
This is testing for the limited case of zero or one SSA-able results.
One regression is that the later expansion of "Dereference" into
Move into argument slots thwarts the
MOVE A -> B, MOVE B -> C
replaced-by
MOVE A -> B, MOVE A -> C
optimization; the second move is written instead as a Dereference at the
phase where the optimization occurs, and because the target of the
dereference is not visible in the dereference, it's not possible to verify
that A and B or A and C don't overlap in some peculiar way (and for results
fed to args, they can).
Regression is repaired in a later CL by changing when calls are expanded.
Change-Id: Ia0f48a9d483d5a54a99657a24b12b25b8edde55f
Reviewed-on: https://go-review.googlesource.com/c/go/+/242782
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>