This is followup of CL 228861, which remove another un-necessary nil
check for s.Pkg.
Passes toolstash-check.
Change-Id: Ide750beddd2594199af21b56ec6af734dfa55b9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/228862
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 228859 refactored detecting reflect package logic in to isReflectPkg
function. The function has un-necessary nil check for p, so remove that
check.
Passes toolstash-check.
Change-Id: I2f3f1ac967fe8d176dda3f3b4698ded08602e2fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/228861
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
A DWARF testpoint was calling t.Fatal() but should have been calling
t.Fatalf(); switch it to the correct method.
Change-Id: I996a1041adea4299cda85c147a35b513a219b970
Reviewed-on: https://go-review.googlesource.com/c/go/+/228790
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Convert all the 386 lowering rules to the typed aux form.
Passes
GOARCH=386 gotip build -toolexec 'toolstash -cmp' -a std
Change-Id: I15256f20bc4442391755e6fffb8206dcaab94830
Reviewed-on: https://go-review.googlesource.com/c/go/+/228818
Reviewed-by: Keith Randall <khr@golang.org>
Currently we only check for reflect.Value.Method. And
reflect.Value.MethodByName is covered since it calls
reflect.Value.Method internally. But it is brittle to rely on
implementation detail of the reflect package. Check for
MethodByName explicitly.
Change-Id: Ifa8920e997524003dade03abc4fb3c4e64723643
Reviewed-on: https://go-review.googlesource.com/c/go/+/228881
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
reflect.Type.Method (and MethodByName) can be used to obtain a
reference of a method by reflection. The linker needs to know
if reflect.Type.Method is called, and retain all exported methods
accordingly. This is handled by the compiler, which marks the
caller of reflect.Type.Method with REFLECTMETHOD attribute. The
current code failed to handle the reflect package itself, so the
method wrapper reflect.Type.Method is not marked. This CL fixes
it.
Fixes#38515.
Change-Id: I12904d23eda664cf1794bc3676152f3218fb762b
Reviewed-on: https://go-review.googlesource.com/c/go/+/228880
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
reflect.Value.Call, if reachable, used to bring all exported
methods live. CL 228792 fixes this, removing the check of
reflect.Value.Call. This CL adds a test.
Updates #38505.
Change-Id: Ib4cab3c3c86c9c9702d041266e59b159d0ff0a97
Reviewed-on: https://go-review.googlesource.com/c/go/+/228878
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The types used while generating code, such as Rule and File, have been
exported for a while. This is harmless for a main package, and lets us
easily differentiate types from variables and functions, as well as use
names like "If" since "if" is a keyword.
However, the fields remained unexported. This was a bit inconsistent,
and also meant that we couldn't use some intuitive names like If.else.
Export them.
Besides the capitalization, the only change is that the If type now has
the fields Then and Else, instead of stmt and alt.
Change-Id: I426ff140c6ca186fec394f17b29165861da5fd98
Reviewed-on: https://go-review.googlesource.com/c/go/+/228821
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Update the comment to be in sync with the code.
Change-Id: I19586767a37347c4da1b4d3f7c6dc6cc2292a90f
Reviewed-on: https://go-review.googlesource.com/c/go/+/228877
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In the linker's deadcode pass, we need to keep a method live if
it can be reached through reflection. We do this by marking all
exported method live if reflect.Value.Method or
reflect.Type.Method is used. Currently we also check for
reflect.Value.Call, which is unnecessary because in order to call
a method through reflection, the method must be obtained through
reflect.Value.Method or reflect.Type.Method, which we already
check.
Per discussion in https://groups.google.com/d/msg/golang-dev/eG9It63-Bxg/_bnoVy-eAwAJ
Thanks Brad, Russ, and Ian for bringing this up.
Change-Id: I8e9529a224bb898dbf5752674cc9d155db386c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/228792
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
p.literal's doc comment said it returned a value but it doesn't.
While we're here, p.newLiteral is only called from p.literal,
so simplify the code by merging the two.
Change-Id: Ia357937a99f4e7473f0f1ec837113a39eaeb83d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/222659
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Everybody was deferring a flush when main already
did that, so drop all that nonsense. (Flush was doing
the package clause stuff.) But then make sure we do
get a package clause when there is correctly no output,
as for an empty package. Do that by triggering a
package clause in allDoc and packageDoc.
Slightly tricky but way less intricate than before.
Fixes#37969.
Change-Id: Ia86828436e6c4ab46e6fdaf2c550047f37f353f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/226998
Reviewed-by: Russ Cox <rsc@golang.org>
I'm planning to modify this test in a follow-up CL, so we might
as well convert it to a script test. I don't think there's an easy
way to detect whether we have a case-insensitive file system, without
adding a new condition to the script framework, so the test is just
guessing that darwin and windows could have case-insensitive file systems.
Change-Id: I48bb36f86f19898618681515ac448c3bb4735857
Reviewed-on: https://go-review.googlesource.com/c/go/+/228783
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
At least as far as I can tell, this file never explicitly states whether
locks with higher or lower rank should be taken first. It is implied in
some comments, and clear from the code, of course.
Add an explicit comment to make things more clear and hopefully reduce
new locks being adding in the wrong spot.
Change-Id: I17c6fd5fc216954e5f3550cf91f17e25139f1587
Reviewed-on: https://go-review.googlesource.com/c/go/+/228785
Reviewed-by: Dan Scales <danscales@google.com>
When the seconds param is given, the block and mutex profile endpoints
report the difference between two measurements collected the given
seconds apart. Historically, the block and mutex profiles have reported
the cumulative counts since the process start, and it turned out they
are more useful when interpreted along with the time duration.
Note: cpu profile and trace endpoints already accept the "seconds"
parameter. With this CL, the block and mutex profile endpoints will
accept the "seconds" parameter. Providing the "seconds" parameter
to other types of profiles is an error.
This change moves runtime/pprof/internal/profile to internal/profile and
adds part of merge logic from github.com/google/pprof/profile/merge.go to
internal/profile, in order to allow both net/http/pprof and runtime/pprof
to access it.
Fixes#23401
Change-Id: Ie2486f1a63eb8ff210d7d3bc2de683e9335fd5cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/147598
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
The call does nothing when applied to an OLSH node.
It would be unnecessary anyway, since we're shifting by a small constant.
Passes toolstash-check.
Change-Id: If858711f1704f44637fa0f6a4c66cbaad6db24b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/228699
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This first pass makes the rules using the condition code mask
(CCMask) and rotate parameters (RotateParams) aux values strongly
typed. This required adding strongly typed aux handling to the
block rulegen.
More CLs like this to follow, but this is probably the most
complex.
Passes toolstash-check -all.
Change-Id: Ie513b07d527f0c1b398d7748331442dcb5f7b17d
Reviewed-on: https://go-review.googlesource.com/c/go/+/228518
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This test started failing at CL 228106 and was fixed by CL 228677.
Fixes#38496
Change-Id: I2dadcd99227347e8d28179039f5f345e728c4595
Reviewed-on: https://go-review.googlesource.com/c/go/+/228698
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
n.Bounded() is overloaded for multiple meanings based on n.Op. We
can't safely use n.Left.Bounded() without checking n.Left.Op.
Change-Id: I71fe4faa24798dfe3a5705fa3419a35ef93b0ce2
Reviewed-on: https://go-review.googlesource.com/c/go/+/228677
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
A case that I missed in CL 205239: profilealloc can be called at
program startup if GOMAXPROCS is large enough.
Fixes#38474
Change-Id: I2f089fc6ec00c376680e1c0b8a2557b62789dd7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/228420
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
These were originally introduced for the binary export format, which
required forward references to arbitrary types and later filling them
in. They're no longer needed since we switched to the indexed export
format, which only requires forward references to declared types.
Passes toolstash-check.
Change-Id: I696dc9029ec7652d01ff49fb98e658a9ed510979
Reviewed-on: https://go-review.googlesource.com/c/go/+/228579
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
These are analogous to URL.RawPath and URL.EscapedPath
and allow users fine-grained control over how the fragment
section of the URL is escaped. Some tools care about / vs %2f,
same problem as in paths.
Fixes#37776.
Change-Id: Ie6f556d86bdff750c47fe65398cbafd834152b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/227645
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
The existing implementation is not compatible with JSON
escape as it uses hex escaping.
Unicode escape, instead, is valid for both JSON and JS.
This fix avoids creating a separate escaping context for
scripts of type "application/ld+json" and it is more
future-proof in case more JSON+JS contexts get added
to the platform (e.g. import maps).
Fixes#33671Fixes#37634
Change-Id: Id6f6524b4abc52e81d9d744d46bbe5bf2e081543
Reviewed-on: https://go-review.googlesource.com/c/go/+/226097
Reviewed-by: Carl Johnson <me@carlmjohnson.net>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When a concrete type doesn't exactly implement an interface, the error
messages produced by go/types are often unhelpful. The compiler shows
the expected signature versus the one found, which is useful, so add
this behavior here.
Fixesgolang/go#38475
Change-Id: I8b780b7e1f1f433a0efe670de3b1437053f42fba
Reviewed-on: https://go-review.googlesource.com/c/go/+/228457
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
All platforms now support pushCall, hence remove the now unnecessary
pushCallSupported flag/guard.
Change-Id: I99e4be73839da68a742f3c239bae9ce2f8764624
Reviewed-on: https://go-review.googlesource.com/c/go/+/228497
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The Context object we pass to GetThreadContext on Windows must be 16
byte-aligned. We also can't allocate in the contexts where we create
these, so they must be stack-allocated. There's no great way to do
this, but this CL makes the code at least a little clearer, and makes
profilem and preemptM more consistent with each other.
Change-Id: I5ec47a27d7580ed6003030bf953e668e8cae2cef
Reviewed-on: https://go-review.googlesource.com/c/go/+/207967
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This CL adds support of call injection and async preemption on
riscv64. We also clobbered REG_TMP for the injected call. Unsafe
points related to REG_TMP access have been marked in previous commits.
Fixes#36711.
Change-Id: I1a1df5b7fc23eaafc34a6a6448fcc3c91054496e
GitHub-Last-Rev: f6110d4707
GitHub-Pull-Request: golang/go#38146
Reviewed-on: https://go-review.googlesource.com/c/go/+/226206
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently, as a result of us releasing worldsema now to allow STW events
during a mark phase, we release worldsema between starting the world and
having the goroutine block in STW mode. This inserts preemption points
which, if followed through, could lead to a deadlock. Specifically,
because user goroutine scheduling is disabled in STW mode, the goroutine
will block before properly releasing worldsema.
The fix here is to prevent preemption while releasing the worldsema.
Fixes#38404.
Updates #19812.
Change-Id: I8ed5b3aa108ab2e4680c38e77b0584fb75690e3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/228337
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
After CL 211357 (commit 499dc1c),
hasTests and numDecl were not updated properly for function
declarations with parameters, which affected the whole file
example detection logic. This caused examples like
package foo_test
func Foo(x int) {
}
func Example() {
fmt.Println("Hello, world!")
// Output: Hello, world!
}
to not be detected as whole file ones.
Change-Id: I9ebd47e52d7ee9d91eb6f8e0257511de69b2a402
GitHub-Last-Rev: cc71c31124
GitHub-Pull-Request: golang/go#37730
Reviewed-on: https://go-review.googlesource.com/c/go/+/222477
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is an attempt to distinguish between a dropped signal and
general builder slowness.
The previous attempt (increasing the settle time to 250ms) still
resulted in a timeout:
https://build.golang.org/log/dd62939f6d3b512fe3e6147074a9c6db1144113f
For #33174
Change-Id: I79027e91ba651f9f889985975f38c7b01d82f634
Reviewed-on: https://go-review.googlesource.com/c/go/+/228266
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This saves 166 KiB for a tls.Dial hello world program (5382441 to
5212356 to bytes), by permitting the linker to remove TLS server code.
Change-Id: I16610b836bb0802b7d84995ff881d79ec03b6a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/228111
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Benchmarking suggests that the combo instruction is notably slower,
at least in the places where we measure.
Updates #37955
Change-Id: I829f1975dd6edf38163128ba51d84604055512f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/228157
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
The Float.Sqrt method switches (for performance reasons) between
direct (uses Quo) and inverse (doesn't) computation, depending on the
precision, with threshold 128.
Unfortunately the implementation of recursive division in CL 172018
made Quo slightly slower exactly in the range around and below the
threshold Sqrt is using, so this strategy is no longer profitable.
The new division algorithm allocates more, and this has increased the
amount of allocations performed by Sqrt when using the direct method;
on low precisions the computation is fast, so additional allocations
have an negative impact on performance.
Interestingly, only using the inverse method doesn't just reverse the
effects of the Quo algorithm change, but it seems to make performances
better overall for small precisions:
name old time/op new time/op delta
FloatSqrt/64-4 643ns ± 1% 635ns ± 1% -1.24% (p=0.000 n=10+10)
FloatSqrt/128-4 1.44µs ± 1% 1.02µs ± 1% -29.25% (p=0.000 n=10+10)
FloatSqrt/256-4 1.49µs ± 1% 1.49µs ± 1% ~ (p=0.752 n=10+10)
FloatSqrt/1000-4 3.71µs ± 1% 3.74µs ± 1% +0.87% (p=0.001 n=10+10)
FloatSqrt/10000-4 35.3µs ± 1% 35.6µs ± 1% +0.82% (p=0.002 n=10+9)
FloatSqrt/100000-4 844µs ± 1% 844µs ± 0% ~ (p=0.549 n=10+9)
FloatSqrt/1000000-4 69.5ms ± 0% 69.6ms ± 0% ~ (p=0.222 n=9+9)
name old alloc/op new alloc/op delta
FloatSqrt/64-4 280B ± 0% 200B ± 0% -28.57% (p=0.000 n=10+10)
FloatSqrt/128-4 504B ± 0% 248B ± 0% -50.79% (p=0.000 n=10+10)
FloatSqrt/256-4 344B ± 0% 344B ± 0% ~ (all equal)
FloatSqrt/1000-4 1.30kB ± 0% 1.30kB ± 0% ~ (all equal)
FloatSqrt/10000-4 13.5kB ± 0% 13.5kB ± 0% ~ (p=0.237 n=10+10)
FloatSqrt/100000-4 123kB ± 0% 123kB ± 0% ~ (p=0.247 n=10+10)
FloatSqrt/1000000-4 1.83MB ± 1% 1.83MB ± 3% ~ (p=0.779 n=8+10)
name old allocs/op new allocs/op delta
FloatSqrt/64-4 8.00 ± 0% 5.00 ± 0% -37.50% (p=0.000 n=10+10)
FloatSqrt/128-4 11.0 ± 0% 5.0 ± 0% -54.55% (p=0.000 n=10+10)
FloatSqrt/256-4 5.00 ± 0% 5.00 ± 0% ~ (all equal)
FloatSqrt/1000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal)
FloatSqrt/10000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal)
FloatSqrt/100000-4 6.00 ± 0% 6.00 ± 0% ~ (all equal)
FloatSqrt/1000000-4 10.3 ±13% 10.3 ±13% ~ (p=1.000 n=10+10)
For example, 1.02µs for FloatSqrt/128 is actually better than what I
was getting on the same machine before the Quo changes.
The .8% slowdown on /1000 and /10000 appears to be real and it is
quite baffling (that codepath was not touched at all); it may be
caused by code alignment changes.
Change-Id: Ib03761cdc1055674bc7526d4f3a23d7a25094029
Reviewed-on: https://go-review.googlesource.com/c/go/+/228062
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This adds support support for the PCALIGN value 32. When this
directive occurs code will be aligned to 32 bytes unless
too many NOPs are needed, and then will fall back to 16
byte alignment.
On Linux the function's alignment is promoted from 16 to 32
in functions where PCALIGN 32 appears. On AIX the function's
alignment is left at 16 due to complexity with modifying its
alignment, which means code will be aligned to at least 16,
possibly 32 at times, which is still good.
Test was updated to accept new value.
Change-Id: I28e72d5f30ca472ed9ba736ddeabfea192d11797
Reviewed-on: https://go-review.googlesource.com/c/go/+/228258
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes#38304
Also change `If m > 0, y < 0, ...` to `If m != 0, y < 0, ...` since `Exp` will return `nil`
whatever `m`'s sign is.
Change-Id: I17d7337ccd1404318cea5d42a8de904ad185fd00
GitHub-Last-Rev: 2399510300
GitHub-Pull-Request: golang/go#38390
Reviewed-on: https://go-review.googlesource.com/c/go/+/228000
Reviewed-by: Robert Griesemer <gri@golang.org>
TestExtraFiles seems to be flaky on GNU/Linux systems when using cgo
because creating a new thread will call malloc which can create a new
arena which can open a file to see how many processors there are.
Try to avoid the flake by creating several new threads at process
startup time.
For #25628
Change-Id: Ie781acdbba475d993c39782fe172cf7f29a05b24
Reviewed-on: https://go-review.googlesource.com/c/go/+/228099
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Importing the time/tzdata package will embed a copy of the IANA
timezone database into the program. This will let the program work
correctly when the timezone database is not available on the system.
It will increase the size of the binary by about 800K.
You can also build a program with -tags timetzdata to embed the
timezone database in the program being built.
This is a roll forward of CL 224588 which was rolled back due to
test failures. In this version, the test is in the time package,
not the time/tzdata package. That lets us compare the zip file
to the time/tzdata package, ensuring that we are looking at similar
versions of tzdata information.
Fixes#21881Fixes#38013Fixes#38017
Change-Id: I916d9d8473abe201b897cdc2bbd9168df4ad671c
Reviewed-on: https://go-review.googlesource.com/c/go/+/228101
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
When setting the edge state in register allocation we should only
be setting each register once. It is not possible for a register
to hold multiple values at once.
This CL converts the runtime error seen in #38195 into an internal
compiler error (ICE). It is better for the compiler to fail than
generate an incorrect program.
The bug reported in #38195 is now exposed as:
./parserc.go:459:11: internal compiler error: 'yaml_parser_parse_node': R5 is already set (v1074/v1241)
[stack trace]
Updates #38195.
Change-Id: Id95842fd850b95494cbd472b6fd5a55513ecacec
Reviewed-on: https://go-review.googlesource.com/c/go/+/228060
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
