This causes a problem in the test sometimes. With a mapping like:
00400000-00411000 r--p 00000000 fe:01 4459044 /tmp/go-build1710804385/b001/pprof.test
00411000-00645000 r-xp 00011000 fe:01 4459044 /tmp/go-build1710804385/b001/pprof.test
The removed code would make the first mapping 0x400000-0x645000. Tests
then grab the first few addresses to use as PCs, thinking they are in
an executable range. But those addresses are really not in an
executable range, causing the tests to fail.
Change-Id: I5a69d0259d1fd70ff9745df1cbad4d54c5898e7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/424295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
JoinPath would fail to remove relative elements from the start of
the path when the first path element is "".
In addition, JoinPath would return the original path unmodified
when provided with no elements to join, violating the documented
behavior of always cleaning the resulting path.
Correct both these cases.
JoinPath("http://go.dev", "../go")
// before: http://go.dev/../go
// after: http://go.dev/go
JoinPath("http://go.dev/../go")
// before: http://go.dev/../go
// after: http://go.dev/goFixes#54385.
Change-Id: I6d22cd160d097c50703dd96e4f453c6c118fd5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/423514
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Detect rotate instructions while still in architecture-independent form.
It's easier to do here, and we don't need to repeat it in each
architecture file.
Change-Id: I9396954b3f3b3bfb96c160d064a02002309935bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/421195
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Ruinan Sun <Ruinan.Sun@arm.com>
Run-TryBot: Keith Randall <khr@golang.org>
From the append docs in the builtin package:
As a special case, it is legal to append a string to a byte slice, like this:
slice = append([]byte("hello "), "world"...)
Change-Id: Ib14039a7476873b12a3aefccd8863e8d628b9249
Reviewed-on: https://go-review.googlesource.com/c/go/+/425102
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
No debug/plan9obj test case because the problem can only happen for
invalid data. Let the fuzzer find cases like this.
For #47653Fixes#54585
Change-Id: I8d3e15725b9bc09dd0e6f2750769987021f5e982
Reviewed-on: https://go-review.googlesource.com/c/go/+/425115
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
If narch is very large we would allocate a lot of memory for seenArches.
In practice we aren't going to see many different architectures so
don't bother to specify a size for the seenArches map.
No debug/macho test case because the problem can only happen for
invalid data. Let the fuzzer find cases like this.
For #47653
For #52523
Change-Id: I5a3b0e3aa6172ddffd6f44d9ae513c39a00d8764
Reviewed-on: https://go-review.googlesource.com/c/go/+/425114
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
When one has a []byte on hand, but desires to call the Parse functions,
the conversion from []byte to string would allocate.
var b []byte = ...
v, err := strconv.ParseXXX(string(b), ...)
This changes it such that the input string never escapes from
any of the Parse functions. Together with the compiler optimization
where the compiler stack allocates any string smaller than 32B
this makes most valid inputs for strconv.ParseXXX(string(b), ...)
not require an allocation for the input string.
For example, the longest int64 or uint64 encoded in decimal is 20B.
Also, the longest decimal formatting of a float64 in appendix B
of RFC 8785 is 25B.
Previously, this was not possible since the input leaked to the error,
which causes the prover to give up and instead heap copy the []byte.
We fix this by copying the input string in the error case.
The advantage of this change is that you can now call strconv.ParseXXX
with a []byte without allocations (most times) in the non-error case.
The detriment is that the error-case now has an extra allocation.
We should optimize for the non-error path, rather than the error path.
The effects of this change is transitively seen through packages
that must use strconv.ParseXXX on a []byte such as "encoding/json":
name old time/op new time/op delta
UnmarshalFloat64 186ns 157ns -15.89% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
UnmarshalFloat64 148B 144B -2.70% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
UnmarshalFloat64 2.00 1.00 -50.00% (p=0.000 n=10+10)
In order for "encoding/json" to benefit, there needs to be a
small change made to how "encoding/json" calls strconv.ParseXXX.
That will be a future change.
Credit goes to Jeff Wendling for a similar patch.
Fixes#42429
Change-Id: I512d6927f965f82e95bd7ec14a28a587f23b7203
Reviewed-on: https://go-review.googlesource.com/c/go/+/345488
Reviewed-by: Martin Möhrmann <martin@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Use explicit name pdNil for nil semaphore of a pollDesc to make it self-explanatory like pdReady and pdWait.
Change-Id: Ibfb246e14419d366edadbccac4d3717f0c135cb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/424923
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
This is both simpler and more performant.
Change-Id: I66ef8e49c059a722932392ee3ecfb951d9b8e121
Reviewed-on: https://go-review.googlesource.com/c/go/+/412339
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Some code paths in the runtime (cgo, heapdump) request heap bits
without first checking that the span is !noscan. Instead of trying
to find and work around all those cases, just set the pointer bits
of noscan spans correctly. It's somewhat safer than ensuring we
caught all the possible cases.
Fixes#54557Fixes#54558
Change-Id: Ibd476e6cdea77c962e4d15aad26f29df66fd94e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/425194
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Normally, when moving Go values of type T from one location to another,
we don't need to worry about partial overlaps. The two Ts must either be
in disjoint (nonoverlapping) memory or in exactly the same location.
There are 2 cases where this isn't true:
1) Using unsafe you can arrange partial overlaps.
2) Since Go 1.17, you can use a cast from a slice to a ptr-to-array.
https://go.dev/ref/spec#Conversions_from_slice_to_array_pointer
This feature can be used to construct partial overlaps of array types.
var a [3]int
p := (*[2]int)(a[:])
q := (*[2]int)(a[1:])
*p = *q
We don't care about solving 1. Or at least, we haven't historically
and no one has complained.
For 2, we need to ensure that if there might be partial overlap,
then we can't use OpMove; we must use memmove instead.
(memmove handles partial overlap by copying in the correct
direction. OpMove does not.)
Note that we have to be careful here not to introduce a call when
we're marshaling arguments to a call or unmarshaling results from a call.
Fixes#54467
Change-Id: I1ca6aba8041576849c1d85f1fa33ae61b80a373d
Reviewed-on: https://go-review.googlesource.com/c/go/+/425076
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
This reverts CL 424854.
Reason for revert: broke misc/cgo/stdio.TestTestRun on several builders.
Will re-land after CL 421879 is submitted.
Change-Id: I2548c70d33d7c178cc71c1d491cd81c22660348f
Reviewed-on: https://go-review.googlesource.com/c/go/+/425214
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
R0 needs to be cleared at startup as it may not always be cleared
by the kernel on newer kernels.
Fixes#54547
Change-Id: Id7055699aaa8d8b193b7e3e784f075ce29ac3f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/424927
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
None of cgo, "go test", nor srcimporter make use of go/ast's object
resolution via go/ast.Object. As such, we can skip that work during
parse time, which should save some CPU time.
We don't have any benchmark numbers, as none of the three packages have
any usable benchmarks, but we measured gofmt to be about 5% faster
thanks to this tweak in https://go.dev/cl/401454.
These three packages are quite different to gofmt, but one can expect
similar speed-ups in the 1-5% range.
Two notable exceptions, which do make use of go/ast.Object, are cmd/fix
and cmd/doc - we do not modify those here.
See #46485.
Change-Id: Ie3e65600d4790641c4e4d6f1c379be477fa02cee
Reviewed-on: https://go-review.googlesource.com/c/go/+/401455
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Flush can not check for unclosed elements, as more data might be encoded
after Flush is called. Close implicitly calls Flush and also checks that
all opened elements are closed as well.
Fixes#53346
Change-Id: I889b9f5ae54e5dfabb9e6948d96c5ed7bc1110f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/424777
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
These two functions together duplicated much of the functionality of
modload.Lookup. Use that instead in modcmd.vendorPkg, and reduce the
modload surface area.
Updates #42504
Updates #40775
For #26904
Change-Id: Ib8aaac495d090178dd56971aef9e5aa44ffa818b
Reviewed-on: https://go-review.googlesource.com/c/go/+/332571
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
In CL 424734, I implemented pointer shaping for unified IR. Evidently
though, we didn't have any test cases that check that uses of
pointer-shaped expressions were handled correctly.
In the reported test case, the struct field "children items[*node[T]]"
gets shaped to "children items[go.shape.*uint8]" (underlying type
"[]go.shape.*uint8"); and so the expression "n.children[i]" has type
"go.shape.*uint8" and the ".items" field selection expression fails.
The fix implemented in this CL is that any expression of derived type
now gets an explicit "reshape" operation applied to it, to ensure it
has the appropriate type for its context. E.g., the "n.children[i]"
OINDEX expression above gets "reshaped" from "go.shape.*uint8" to
"*node[go.shape.int]", allowing the field selection to succeed.
This CL also adds a "-d=reshape" compiler debugging flag, because I
anticipate debugging reshaping operations will be something to come up
again in the future.
Fixes#54535.
Change-Id: Id847bd8f51300d2491d679505ee4d2e974ca972a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424936
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: hopehook <hopehook@qq.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
During walk, we sometimes desugar OEQ nodes into multiple "untyped
bool" expressions, and then use typecheck.Conv to convert back to the
original OEQ node's type.
However, typecheck.Conv had a short-circuit path that if the type is
already identical to the target type according to types.Identical,
then we skipped the conversion. This short-circuit is normally fine;
but with generic code and shape types, it considers "untyped bool" and
"go.shape.bool" to be identical types. And we could end up leaving an
expression of "untyped bool", which then fails an internal consistency
check later.
The simple fix is to change Conv to use types.IdenticalStrict, so that
we ensure "untyped bool" gets converted to "go.shape.bool". And for
good measure, make the same change to ConvNop.
This issue was discovered and reported against unified IR, but the
issue was latent within the non-unified frontend too.
Fixes#54537.
Change-Id: I7559a346b063349b35749e8a2da704be18e51654
Reviewed-on: https://go-review.googlesource.com/c/go/+/424937
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
To disambiguate local types, we append a "·N" suffix to their name and
then trim it off again when producing their runtime type descriptors.
However, if a local type is generic, then we were further appending
the type arguments after this suffix, and the code in types/fmt.go
responsible for trimming didn't know to handle this.
We could extend the types/fmt.go code to look for the "·N" suffix
elsewhere in the type name, but this is risky because it could
legitimately (albeit unlikely) appear in struct field tags.
Instead, the most robust solution is to just change the mangling logic
to keep the "·N" suffix at the end, where types/fmt.go can easily and
reliably trim it.
Note: the "·N" suffix is still visible within the type arguments
list (e.g., the "·3" suffixes in nested.out), because we currently use
the link strings in the type arguments list.
Fixes#54456.
Change-Id: Ie9beaf7e5330982f539bff57b8d48868a3674a37
Reviewed-on: https://go-review.googlesource.com/c/go/+/424901
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When handling a type declaration like:
```
type B A
```
unified IR has been writing out that B's underlying type is A, rather
than the underlying type of A.
This is a bit awkward to implement and adds complexity to importers,
who need to handle resolving the underlying type themselves. But it
was necessary to handle when A was declared like:
```
//go:notinheap
type A int
```
Because we expected A's not-in-heap'ness to be conferred to B, which
required knowing that A was on the path from B to its actual
underlying type int.
However, since #46731 was accepted, we no longer need to support this
case. Instead we can write out B's actual underlying type.
One stumbling point though is the existing code for exporting
interfaces doesn't work for the underlying type of `comparable`, which
is now needed to implement `type C comparable`. As a bit of a hack, we
we instead export its underlying type as `interface{ comparable }`.
Fixes#54512.
Change-Id: I0fb892068d656f1e87bb8ef97da27756051126d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/424854
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The hours, minutes, and seconds fields for time zones
should not have any plus or minus signs.
Use getnum instead of atoi since the latter implicitly
handles leading signs, while the former does not.
Fixes#54570
Change-Id: If9600170af3af999739c27d81958e3649946913a
Reviewed-on: https://go-review.googlesource.com/c/go/+/425038
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Rob Pike <r@golang.org>
The error return value of the seconds field is overwritten
and not checked in the presence of a fractional second.
Perform an explicit check for errors.
Fixes#54569
Change-Id: I1204c8bdcd5a5a09b773d9e44748141ed1e5cb20
Reviewed-on: https://go-review.googlesource.com/c/go/+/425036
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Rob Pike <r@golang.org>
This modifies the code to match the comment such that
the behavior truly is identical to stdSecond case.
Also, it modifies the behavior to match the documented
behavior where:
Fractional seconds are truncated to nanosecond precision.
Fixes#54567
Updates #48685
Change-Id: Ie64549e4372ab51624c105ad8ab4cc99b9b5a0b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/425037
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
This lock is acquired under trace.lock, which as of CL 418956
(6c2e327e35) must be acquired on the system stack, so this lock must
be, too.
Fixes#54553.
Change-Id: I4fb0c0c2dfc3cb94b76673e842ad416305a31238
Reviewed-on: https://go-review.googlesource.com/c/go/+/425097
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Previously we convert $0 to the ZR register for some reasons, which causes
two problems:
1. Confusion, the special case of the ZR register needs to be considered
when dealing with constants. For encoding, some places we encode ZR, and
some places we encode $0, although we have converted $0 to ZR.
2. Unexpected instruction format. All instructions that support ZR register
operands can be replaced by $0.
This patch removes this conversion. Note that this patch may cause previously
unintendedly supported instruction formats to no longer be supported.
Change-Id: I3d8d2c06711b7614a38191397da7776417f1861c
Reviewed-on: https://go-review.googlesource.com/c/go/+/404316
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: I50e5609ff9c5f2b216b93cec7fb5214d196cae90
Reviewed-on: https://go-review.googlesource.com/c/go/+/412537
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This is both simpler and more performant.
Change-Id: I398de29230e578fb7caf1765df7b8fe84d4e8876
Reviewed-on: https://go-review.googlesource.com/c/go/+/412336
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Ian Lance Taylor <iant@google.com>
We don't need compression enabled here, because we only set one question in the dns message. So there is nothing to compress. Also it reduces 8 allocs per LookupHost.
Change-Id: I0968f837011daf6d7a7b22d9af4a8cc5b2878f4c
GitHub-Last-Rev: 7eb3362bca
GitHub-Pull-Request: golang/go#54576
Reviewed-on: https://go-review.googlesource.com/c/go/+/425043
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
On ARM64 we use two separate instructions to compute the hi and lo
results of a 64x64->128 multiplication. Lower to two separate ops
so if only one result is needed we can deadcode the other.
Fixes#54607.
Change-Id: Ib023e77eb2b2b0bcf467b45471cb8a294bce6f90
Reviewed-on: https://go-review.googlesource.com/c/go/+/425101
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
There is already a skip in case of a later failure in the same test on
these platforms. Skip the failure if it occurs earlier too.
For #43120.
Change-Id: Id530370caa6a7df8cae593f6fdcb66871b86b125
Reviewed-on: https://go-review.googlesource.com/c/go/+/425096
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Use OpVarDef only when the variable being defined has pointers in it.
VarDef markers are only used for liveness analysis, and that only
runs on pointer-ful variables.
Fixes#53810
Change-Id: I09b0ef7ed31e72528916fe79325f80bbe69ff9b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/419320
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Neither are currently used. These concepts only need to exist
in the ssa backend (as ssa.OpVarDef and ssa.OpVarLive).
Change-Id: I8d6bd14aa7967b2156e5e9a103b95146e5552f36
Reviewed-on: https://go-review.googlesource.com/c/go/+/419319
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
os/exec.Cmd.Wait closes the read end of os/exec.Cmd.StdoutPipe, meaning
that io.ReadAll can return fs.ErrClosed if the child exits too early,
allowing Wait to complete. The StdoutPipe docs already note this sharp
edge.
Move cmd.Wait until after we finish waiting on stdout. If the child
crashes for some reason, the write end of the pipe will implicitly close
causing io.ReadAll to return as well, so we won't get stuck.
Fixes#52725.
Change-Id: Ifae5745d86206879af2f1523a664236972e07252
Reviewed-on: https://go-review.googlesource.com/c/go/+/420597
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The existing decode() method offers the ability to keep just one
frame of the GIF image, however it will read and decompress all
subsequent frames regardless.
Fixes#41142
Change-Id: I0c3c11f9c11cd487b6c365e9a8b98e617d555db0
GitHub-Last-Rev: 03ebc8ee7b
GitHub-Pull-Request: golang/go#46813
Reviewed-on: https://go-review.googlesource.com/c/go/+/329329
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Paul Tyng <paul@paultyng.net>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Nigel Tao (INACTIVE; USE @golang.org INSTEAD) <nigeltao@google.com>
Check for malformed data when reading the number of aux
symbols associated with a symbol table entry.
Fixes#54584.
Change-Id: Ic2a8d4d6a1d481d585a065b8182de86294c3d3d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/425049
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
I was profiling the cpu usage of go/printer's only benchmark,
and found that token.File.Unpack was one of the top offenders.
It was mainly the deferred unlock that took a big chunk of time,
and to my surprise, reoving the use of defer helped significantly:
name old time/op new time/op delta
Print-16 5.61ms ± 2% 5.38ms ± 1% -4.04% (p=0.000 n=10+8)
name old speed new speed delta
Print-16 9.27MB/s ± 2% 9.64MB/s ± 1% +4.03% (p=0.000 n=9+8)
name old alloc/op new alloc/op delta
Print-16 332kB ± 0% 332kB ± 0% ~ (p=0.363 n=10+10)
name old allocs/op new allocs/op delta
Print-16 3.45k ± 0% 3.45k ± 0% ~ (all equal)
It seems like #38471 is to blame, as the defer prevents Unlock from
being inlined. Add a TODO as a reminder to come back here once the
compiler issue is fixed.
Change-Id: I5a1c6d36a8e8357435a305a1bc0970ee0358b08a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424920
Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
ReadData follows the error semantics of io.ReadFull for small sizes,
it should do so as well for large sizes.
Change-Id: I6a11b00d903ac5332e1dda074473790dcf21f32a
Reviewed-on: https://go-review.googlesource.com/c/go/+/424919
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Joseph Tsai <joetsai@digital-static.net>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
We don't have a good musl detection mechanism, so we detect Alpine (the
most common user of musl) instead.
For #39857.
For #19938.
Change-Id: I2fa39248682aed75884476374fe2212be4427347
Reviewed-on: https://go-review.googlesource.com/c/go/+/425001
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
