| Age | Commit message (Collapse) | Author |
|---|
|
This is caused by some nodes didn't carry the real line number.
Noder1 wraps these node with ir.ParenExpr. To fix this issue,
wraps this node like what noder1 does.
Change-Id: I212cad09b93b8bf1a7adfad416d229d15711918a
Reviewed-on: https://go-review.googlesource.com/c/go/+/349769
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
|
|
Arg/Load/Dereference rewriting was not using the best Pos for
translated values. I also investigated whether OpCopy processing
was losing statements, and though they flood the debugging output,
doing the "obvious" thing of moving statement marks from copi-er to
copy-ee actually makes the resulting binary score slightly worse on
statement-boundary measures.
(for -N -l, 0.9994 vs 0.9995 from "nostmt -c sqle.test")
Fixes #47793.
Change-Id: I65cb878d0e5a3ceb5da4ef679020ca5f40e9b02b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344769
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
|
|
When a LocResults is an empty list, it currently prints as ">".
Make it print "<>".
Change-Id: I0f596791b471d74cd4bbc0059e269708c80592dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/350144
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
|
|
The variable represents the microarchitecture level for which to compile.
Valid values are v1 (default), v2, v3, v4.
Updates #45453
Change-Id: I095197fc9239d79f98896d7e745e2341354daca4
GitHub-Last-Rev: f83ed17204606264073be5b9831f9d24f2f9dbc4
GitHub-Pull-Request: golang/go#48359
Reviewed-on: https://go-review.googlesource.com/c/go/+/349595
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
|
|
Replace `filepath.Split` with `filepath.Dir`. Clean paths before checking whether command line files are in same directory.
Fixes #47392
Change-Id: I259c3024e7670e78833622b02af4710bc4b68b31
GitHub-Last-Rev: c7c4905bb9c62737e95a4663813f076ee540046b
GitHub-Pull-Request: golang/go#47412
Reviewed-on: https://go-review.googlesource.com/c/go/+/337629
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Change-Id: I45575afbad364c13b7179ebe3f3dfc4ed9671d2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/336891
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
|
|
This change refactors some of the code to support skipping a run
of the seed corpus by the go command before runFuzzing occurs.
Previously, the go command would run all seed corpus for all targets
that match the provided `run` argument. This will be redundant when
fuzzing a target. Now, the seed corpus is only run by targets other than
the one that's about to be fuzzed, and the worker handles running and
reporting issues with the seed corpus.
Part of the logic that needed close inspection is what to do if a
failure occurs during a testing-only or coverage-only fail. If the input
is already in the seed corpus, the fuzzing engine shouldn't add it. If
the input is currently in the cache, then it should be written to
testdata. In all cases, if an error occurs, we need to report this to
the user with enough information for them to debug it.
This uncovered some issues with our code when fuzzing without
instrumentation, and when -run=None was provided. There are some logic
fixes in this change, and some small refactors.
Fixes golang/go#48327
Fixes golang/go#48296
Change-Id: I9ce2be0219c5b09277ddd308df8bc5a46d4558fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/349630
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Now that we are computing the dictionary format on the instantiated
functions, we can remove the early transformation code that was needed
to create the implicit CONVIFACE nodes in the generic function.
Change-Id: I1695484e7d59bccbfb757994f3e40e84288759a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/349614
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Change to computing the dictionary form on each shape-instantiated
function, rather than once on the underlying generic function/method.
The problem with computing the dictionary format on the generic function
is that we had to force early transformations to create all the
needed/implicit CONVIFACE nodes, since many of these nodes cause the
need for a dictionary entry. Also, the dictionary entries needed can
different with different instantiations of the same generic function,
especially depending on whether a type argument is a non-interface or
interface type, or a instantiated type vs. a non-instantiated type.
By computing the dictionary format on the instantiated function, we are
scanning a function where all the transformations have been done to
create implicit CONVFIFACE nodes, and we know the above relevant
information about the type params (which are shapes).
Much of the change is more mechanical changes from typeparams to shapes,
and generic functions/info to instantiated functions/info. Some of the
most important non-mechanical changes are:
- Separated out the dictionary transformations to nodes into a separate
dictPass, since we need to analyze instantiated functions after
stenciling, but before the dictionary transformations.
- Added type param index to shape types, since we need to be able
distinguish type params of an instantiation which are different but
happen to have the same shape.
- Allow the type substituter to work with shapes again (since for the
dictionary entries we need to substitute shape params to the concrete
type args).
- Support types.IdentityStrict() that does strict type comparison (no
special case for shapes). This needed for type substitution,
formatting and creating dictionaries, etc. We can maybe create better
names for this function.
- Add new information to instInfo to contain a mapping from the shape
type params to their instantiated type bound. This is needed when
doing the dictionary transformations related to type bounds.
Change-Id: I1c3ca312c5384f318c4dd7d0858dba9766396ff6
Reviewed-on: https://go-review.googlesource.com/c/go/+/349613
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
This changes the ppc64 prologue to avoid clobbering the registers
that could contain incoming argument values. This means preserving
the values in R3 - R10 and R14 - R19 for ppc64.
Instead of modifying R3, R4, R5 and R6 the registers R22, R23, R24
and R25 are used.
The argument registers that could be clobbered by the call to
morestack are saved and restored around that call.
Change-Id: If354c3dc73f2c8537ef4e513e5a4c05d7bd22866
Reviewed-on: https://go-review.googlesource.com/c/go/+/343872
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
Because of wrong case of letters, the cpu features flags were not
set properly for amd64.
Fixes #48406.
Change-Id: If19782851670e91fd31d119f4701c47373fa7e71
GitHub-Last-Rev: 91c7321ca49343c86917f071babec8a004ca5c77
GitHub-Pull-Request: golang/go#48403
Reviewed-on: https://go-review.googlesource.com/c/go/+/350151
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
A fuzz worker process should exit with fuzzWorkerExitCode (70) if it
encounters an internal error.
This should generally only happen due to an I/O error on the worker
side. I can't think of a way to write a realistic test case for
this. test_fuzz_io_error.txt triggers an I/O error on the coordinator
side, which is similar.
Change-Id: I40d2e9aaf422e5ed925debcf7a152c252c3a6984
Reviewed-on: https://go-review.googlesource.com/c/go/+/349993
Trust: Jay Conrod <jayconrod@google.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
|
|
Print the elapsed time as a nicely formatted duration, and
make small adjustments to the command line output while fuzzing.
Fixes golang/go#48132
Change-Id: Id95f84c0939171a777448c444d9b87d7af26b654
Reviewed-on: https://go-review.googlesource.com/c/go/+/349970
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Fixes golang/go#48131
Change-Id: I40ff130c849dffe38363ddc0282e93ceb74ae140
Reviewed-on: https://go-review.googlesource.com/c/go/+/349969
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
If an indirectly required module does not provide any packages needed
to build packages in the main module but is needed to disambiguate
imports, 'go mod tidy' may keep an indirect requirement on that module
to prevent it from being downgraded. This can prevent the introduction
of new ambiguities. This also ensures tidy keeps sums needed to load
all packages.
Fixes #47738
Change-Id: Ib8e33422b95394707894cda7cfbb71a4b111e0ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/344572
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
When emitting the DIE of the instantiation of a generic function also
emit one DW_TAG_typedef_type entry for each dictionary entry in use,
referencing the shape type and having a custom attribute containing the
index inside the dictionary.
When emitting the DIE of variables that have an instantiated parametric
type, instead of referencing the shape type directly go through the
DW_TAG_typedef_type entry emitted for the dictionary entry describing
the real type of the variable.
Change-Id: Ia45d157ecd4c25e2b60300469e43bbb27a663582
Reviewed-on: https://go-review.googlesource.com/c/go/+/344929
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Jeremy Faller <jeremy@golang.org>
|
|
Change DWARF generation to tag wrapper functions with the
"DW_AT_trampoline attribute". The intent is that debuggers can pick up
on this attr so as to skip through the wrapper to the eventual target.
DWARF standard allows for a couple of different possible variants of
the trampoline attr; this is the simplest variant (all it tells the
debugger is that the function is a wrapper, doesn't include a
reference to the wrapper routine).
This implementation keys off the WRAPPER LSym attribute, which is set
for method wrappers, ABI wrappers, and a selected set of runtime
assembly routines (ex: "runtime.call32").
Change-Id: Ib53e1bc56c02b86ca3ac5e7da1a541ec262726cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/347352
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jeremy Faller <jeremy@golang.org>
|
|
Make two superficial fixes to iimport.go: rename instType to
instanceType (suggested in CL 349949), and fix a stale comment.
Done in both go/internal/gcimporter and cmd/compile/internal/importer.
Change-Id: Idfdda11a59b036a35824bbb1c101cba3652aeff4
Reviewed-on: https://go-review.googlesource.com/c/go/+/350031
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This is a clean port of CL 349411 from go/types to types2.
Change-Id: Id5fa04c53f286dad263d7ba7911cb49eebf47b0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/350030
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
Clean port of CL 349410 from go/types to types2 with 2 adjustments:
using syntax.Pos instead of token.Pos, and using TypeHash instead
of typeHash.
Fixes #47887.
Change-Id: Ifd8495e4187b5e30aaf80702768d82aad5e10cf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/349995
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
This is a clean port of CL 349413 from go/types to types2.
Change-Id: I18bad5e29b1e719b30a73fb2aa32fe252538496e
Reviewed-on: https://go-review.googlesource.com/c/go/+/349992
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
Named types
This is a clean port of CL 349409 from go/types to types2.
Change-Id: I2deb9ce46e6dcda736fda2169912c02163930d7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/349991
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
Change the typeWriter to produce blank-free hashes where easily possible
if used as a type hasher, and replace remaining blanks with '#' is needed.
Exported Environment.TypeHash for use by the compiler.
Change-Id: Icbd364c207f9c139a7a1844bb695512a0c56a4e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/349990
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
When the adjustTimers function removed a timer it assumed it was
sufficient to continue the heap traversal at that position.
However, in some cases a timer will be moved to an earlier
position in the heap. If that timer is timerModifiedEarlier,
that can leave timerModifiedEarliest not correctly representing
the earlier such timer.
Fix the problem by restarting the heap traversal at the earliest
changed position.
Fixes #47762
Change-Id: I152bbe62793ee40a680baf49967bcb89b1f94764
Reviewed-on: https://go-review.googlesource.com/c/go/+/343882
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
For example, errors that started before with "go mod download: " now
start with "go: " instead.
Previously, we had a mix of errors with and without subcommand
prefixes, even in packages like modload that ostensibly aren't tied
to any specific command. This change makes usage more consistent,
which makes refactoring much easier.
These prefixes didn't add useful information: the user should know the
subcommand they just ran. But see CL 347152 for an attempt at making
the opposite change: always printing the subcommand prefix.
Note that there are a number of errors that don't start with "go: " or
any subcommand prefix. This CL doesn't affect those.
Change-Id: I16430d8c39ea3f4d0870f55a5205f06fb21943c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/349597
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This aligns with the API proposal (#47916).
Change-Id: I732e5b107e729718ed37e053ad3f434993a97ecd
Reviewed-on: https://go-review.googlesource.com/c/go/+/349413
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This CL addresses a couple TODOs related to instantiation:
- factor out resolving the best environment
- don't eagerly resolve substituted instances
Change-Id: I4a5de7ea7939b6f272991071f591d622dec04b53
Reviewed-on: https://go-review.googlesource.com/c/go/+/349429
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
In the API proposal we decided that instantiation must also instantiate
methods. This CL does that, and eliminates the special handling for lazy
instantiation in lookupMethod.
It is possible that we expand an instance before all method signatures
have been type-checked, so for simplicity we introduce a new flag on
Func, 'isIncompleteMethod', which controls whether we must fully
substitute methods before using them. We could avoid this flag by using
some convention for the structure of an incomplete method (such as the
receiver has no position), but in practice using a flag was cleaner and
didn't increase the size of the Func struct.
Updates #47916
Change-Id: I352baa6664cd07f61b06924744382897805f9d29
Reviewed-on: https://go-review.googlesource.com/c/go/+/349412
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
We no longer need to use the nilness of Named.instPos to signal whether
instance expansion has occurred, so remove it from the Named struct by
instead closing over the instantiation position in the resolver.
This means we cannot print instance markers for unexpanded instances:
instances may escape the type checking pass without being fully
expanded, and we can not check whether they have been expanded in a
concurrency-safe way without introducing a more heavy-weight
syncronization mechanism.
With this change, instantiation should be concurrency safe, modulo bugs
of course as we have little test coverage of concurrency (see #47729).
Fixes #47910
Change-Id: Ifeef6df296f00105579554b333a44d08aae113c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/349411
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Named type expansion and loading were conceptually similar: a mechanism
for lazily resolving type information in a concurrency-safe manner.
Unify them into a 'resolve' method, that delegates to a resolver func to
produce type parameters, underlying, and methods.
By leveraging the sync.Once field on Named for instance expansion, we
get closer to making instance expansion concurrency-safe, and remove the
requirement that instPos guard instantiation. This will be cleaned up
in a follow-up CL.
This also fixes #47887 by causing substituted type instances to be
expanded (in the old code, this could be fixed by setting instPos when
substituting).
For #47910
Fixes #47887
Change-Id: Ifc52a420dde76e3a46ce494fea9bd289bc8aca4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/349410
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Move ShapePkg to types, and change types.NewNamed to automatically set
IsShape/HasShape if a type is in the shapes pkg. This means that
imported shape types will automatically have the correct
IsShape/HasShape flags, even though we are not explicitly
exporting/importing those flags.
Updates #48337
Change-Id: I8b6131a663205f73f395943c9d0c8bdb2a213401
Reviewed-on: https://go-review.googlesource.com/c/go/+/349869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
|
|
Change-Id: I894ee000561a3c6afede8df697b1bce4576ceef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/349012
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Keith Randall <khr@golang.org>
|
|
In TestSegv, the t.Run closure captures the loop variable 'test'. Since
the subtest calls t.Parallel, the parent test is allowed to keep
running, changing the loop variable and thus changing the value of
'test' in the subtest.
Change-Id: I021ddc50304de08a341e6ffe486aa54e573d3b94
Reviewed-on: https://go-review.googlesource.com/c/go/+/339911
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
CL 349010 ported the fix from CL 349009, but forgot to remove the
outdated comment from old solution. This CL removes that one.
Change-Id: Ia401295e9d0984f4a088ddce5db09d306bfd89b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/349729
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
CL 201737 dropped the use of IN_KUBERNETES in tests, but it looks like
it did not catch all occurrences.
For #12815
For #34956
Change-Id: I72b89bfb850ba2890e9e6aa39b87167291ab7e9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/349789
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Likewise, reorder register numbers such that extended mnemonics which
use FPR arguments can be transparently encoded as a VSR argument for
the move to/from VSR class of instructions. Specifically, ensure the
following holds for all FPx and VRx constants: FPRx & 63 == x, and
VRx & 63 == x + 32.
This simplifies encoding machine instructions, and likewise helps
ppc64 assembly writers to avoid hokey workarounds when switching from
vector to vector-scalar register notation. Notably, many VSX
instructions are limited to vector operands due to encoding
restrictions.
Secondly, this explicitly rejects dubious usages of the m[tf]vsr
family of instructions which had previously been accepted.
* Reject two GPR arguments for non-MTVSRDD opcodes. These
have no defined behavior today, and may set RFU bits. e.g
MTVSRD R1, R2, VS1
* Reject FPR destinations for MTVSRDD, and only accept with two GPR
arguments. This copies two GPR values into either half of a VSR. e.g
MTVSRDD R1, R2, F1
MTVSRDD R1, F1
Change-Id: If13dd88c3791d1892dbd18ef0e34675a5285fff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/342929
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
|
|
This is a port of CL 349009 to typecheck importer.
Fixes #48306
Change-Id: Iec3f078089346bd85f0ab739896e079940325011
Reviewed-on: https://go-review.googlesource.com/c/go/+/349011
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
This is port of CL 349009 to go/internal/gcimporter.
Updates #48280
Change-Id: I7d40d8b67333538ca58fe012535d54e891d0ed16
Reviewed-on: https://go-review.googlesource.com/c/go/+/349010
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
|
|
The importReader always reads type parameter before declaring type stub
declaration. Thus, for recursive type, the type parameter is going to be
read twice, cause the bound more than once error.
To fix this, only read the type parameter after declaring stub obj, thus
r.doDecl can see the type was already inserted and terminate the
recursive call earlier.
Fixes #48280
Change-Id: I272e2f214f739fb8ec71a8628ba297477e1b7755
Reviewed-on: https://go-review.googlesource.com/c/go/+/349009
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
|
|
Change-Id: I519b8021fa79dccc5c0ee79134547491116fc4cc
GitHub-Last-Rev: 48869f5434c1255d33c3a14714747509235c94df
GitHub-Pull-Request: golang/go#48071
Reviewed-on: https://go-review.googlesource.com/c/go/+/346231
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Keith Randall <khr@golang.org>
|
|
This reduces the number of instructions executed for time.now by nine,
by eliminating the wrapper. Somehow BenchmarkNow is 0.2ns slower.
On the other hand BenchmarkNowUnixNano is 0.8ns faster.
name old time/op new time/op delta
AfterFunc-12 66.7µs ± 4% 67.3µs ± 2% ~ (p=0.573 n=20+18)
After-12 97.6µs ± 4% 97.4µs ± 4% ~ (p=0.758 n=20+20)
Stop-12 66.7µs ±12% 64.8µs ±10% ~ (p=0.072 n=20+20)
SimultaneousAfterFunc-12 109µs ± 0% 110µs ± 1% +1.47% (p=0.000 n=17+20)
StartStop-12 31.9µs ±15% 32.7µs ±14% ~ (p=0.799 n=20+20)
Reset-12 3.67µs ± 2% 3.68µs ± 2% ~ (p=0.132 n=20+20)
Sleep-12 132µs ± 2% 133µs ± 2% +0.70% (p=0.035 n=20+19)
Ticker-12 32.4µs ± 1% 32.3µs ± 2% ~ (p=0.270 n=20+19)
TickerReset-12 3.71µs ± 2% 3.74µs ± 2% +0.89% (p=0.012 n=20+20)
TickerResetNaive-12 65.7µs ±10% 67.2µs ±10% ~ (p=0.174 n=20+20)
Now-12 29.6ns ± 1% 29.8ns ± 0% +0.78% (p=0.000 n=17+17)
NowUnixNano-12 31.1ns ± 1% 30.3ns ± 0% -2.69% (p=0.000 n=19+18)
NowUnixMilli-12 30.9ns ± 0% 31.1ns ± 0% +0.90% (p=0.000 n=18+20)
NowUnixMicro-12 30.9ns ± 0% 31.1ns ± 1% +0.68% (p=0.000 n=20+18)
Format-12 304ns ± 1% 301ns ± 2% -0.81% (p=0.004 n=18+19)
FormatNow-12 187ns ± 2% 185ns ± 2% -0.90% (p=0.036 n=20+18)
MarshalJSON-12 267ns ± 3% 265ns ± 3% -1.00% (p=0.004 n=18+18)
MarshalText-12 267ns ± 2% 265ns ± 3% -0.87% (p=0.038 n=19+20)
Parse-12 150ns ± 1% 149ns ± 1% -0.83% (p=0.000 n=18+20)
ParseDuration-12 79.6ns ± 0% 80.1ns ± 1% +0.61% (p=0.000 n=20+20)
Hour-12 4.42ns ± 1% 4.45ns ± 0% +0.83% (p=0.000 n=20+20)
Second-12 4.42ns ± 0% 4.42ns ± 1% ~ (p=0.075 n=18+20)
Year-12 11.1ns ± 1% 11.1ns ± 1% ~ (p=0.489 n=20+19)
Day-12 14.8ns ± 1% 14.8ns ± 0% ~ (p=0.616 n=20+18)
ISOWeek-12 17.2ns ± 1% 17.2ns ± 0% ~ (p=0.179 n=20+19)
name old avg-late-ns new avg-late-ns delta
ParallelTimerLatency-12 380k ± 4% 379k ± 3% ~ (p=0.879 n=20+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-12 137k ± 3% 137k ± 2% ~ (p=0.261 n=19+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-12 106k ±16% 95k ± 8% -9.76% (p=0.003 n=19+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-12 88.6k ±22% 74.6k ± 3% -15.78% (p=0.000 n=19+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-12 76.1k ±18% 70.8k ± 5% -7.04% (p=0.020 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-12 67.3k ±27% 65.6k ±13% ~ (p=0.211 n=16+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-12 59.5k ±24% 57.3k ±32% ~ (p=0.607 n=19+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-12 41.8k ±34% 46.2k ±33% +10.54% (p=0.039 n=17+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-12 57.5k ±37% 65.6k ±46% ~ (p=0.283 n=17+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-12 118k ±60% 136k ±59% ~ (p=0.169 n=19+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-12 3.66M ±236% 2.55M ±36% ~ (p=0.158 n=16+20)
StaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-12 81.7k ± 4% 80.7k ± 5% ~ (p=0.107 n=20+19)
name old max-late-ns new max-late-ns delta
ParallelTimerLatency-12 5.88M ±124% 7.28M ±183% ~ (p=0.640 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-12 384k ±17% 371k ±11% ~ (p=0.540 n=17+17)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-12 503k ±180% 373k ±19% ~ (p=0.057 n=17+18)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-12 519k ±129% 340k ±17% -34.47% (p=0.000 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-12 491k ±141% 341k ±26% -30.52% (p=0.015 n=18+17)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-12 457k ±123% 405k ±48% ~ (p=0.786 n=17+17)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-12 491k ±85% 502k ±74% ~ (p=0.916 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-12 572k ±100% 574k ±65% ~ (p=0.858 n=18+17)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-12 1.95M ±205% 1.65M ±155% ~ (p=0.641 n=18+19)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-12 7.77M ±104% 8.72M ±103% ~ (p=0.512 n=20+20)
StaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-12 29.5M ±187% 18.5M ±43% ~ (p=0.186 n=18+20)
StaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-12 981k ±14% 1033k ±12% +5.30% (p=0.048 n=20+18)
Change-Id: Ie794a932a929b46053a6c3020b67d640b98d2335
Reviewed-on: https://go-review.googlesource.com/c/go/+/315369
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
|
This change is functionally equivalent, but reduces reliance on unsafe
features. This would allow GopherJS to avoid an additional patch to the
standard library we'd have to maintain in order to remain compatible
with Go 1.17+.
Change-Id: I4f113db0c572ec0b81ebfecf5a137145f6c8c41d
GitHub-Last-Rev: 94ebb393bac93579b6455555822691c0d69e2d42
GitHub-Pull-Request: golang/go#48346
Reviewed-on: https://go-review.googlesource.com/c/go/+/349469
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
CL 85215 added prose to provide some minimal intuition for the
definition of a "terminating statement". While the original definition
was perfectly fine, the added prose was actually incorrect: If the
terminating statement is a goto, it might jump to a labeled statement
following that goto in the same block (it could be the very next
statement), and thus a terminating statement does not in fact
"prevent execution of all statements that lexically appear after
it in the same block".
Rather than explaining the special case for gotos with targets that
are lexically following the goto in the same block, this CL opts for
a simpler approach.
Thanks to @3bodar (Github) for finding this.
Fixes #48323.
Change-Id: I8031346250341d038938a1ce6a75d3e687d32c37
Reviewed-on: https://go-review.googlesource.com/c/go/+/349172
Trust: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #48317
Change-Id: I756ae6253022870071004332dd8f49169307f7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/349013
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
|
|
For #45713
Change-Id: I16e548e6c10e58da815d08897f4ba5d71eeb17e4
GitHub-Last-Rev: 4a0c5d0cdaba94e5950effdcb0ef6b736c9556d1
GitHub-Pull-Request: golang/go#48360
Reviewed-on: https://go-review.googlesource.com/c/go/+/349599
Reviewed-by: Bryan C. Mills <bcmills@google.com>
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>
|
|
It looks like these are fixed on current tip after CL 84655
marked them to be skipped.
Fixes #23168
Change-Id: I0020e6da1042f723eb54186ef0fe925df5326230
Reviewed-on: https://go-review.googlesource.com/c/go/+/349250
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
The floating point tests were all added into the Inequalities section,
instead of separated into Equalities vs Inequalities.
Rather than separate them, add a new floating point section.
Change-Id: I3713a5aff5850dcc0caf68a754633d695a03ded9
Reviewed-on: https://go-review.googlesource.com/c/go/+/349612
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
Though the normal equality check suffices, it allocates.
Handle common, simple kinds without allocating.
For some real world types compared with DeepEqual
in the Tailscale code base, the impact of these changes:
name old time/op new time/op delta
HostInfoEqual-8 25.9µs ± 0% 14.4µs ± 0% -44.32% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
HostInfoEqual-8 18.8kB ± 0% 12.6kB ± 0% -32.58% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
HostInfoEqual-8 548 ± 0% 90 ± 0% -83.58% (p=0.008 n=5+5)
For the benchmarks added in this commit:
name old time/op new time/op delta
DeepEqual/int8-8 40.1ns ± 4% 31.3ns ± 4% -21.79% (p=0.000 n=19+20)
DeepEqual/[]int8-8 169ns ± 1% 123ns ± 1% -27.05% (p=0.000 n=17+18)
DeepEqual/int16-8 39.9ns ± 2% 30.8ns ± 4% -22.81% (p=0.000 n=17+20)
DeepEqual/[]int16-8 172ns ± 0% 122ns ± 1% -28.91% (p=0.000 n=17+18)
DeepEqual/int32-8 40.4ns ± 3% 31.1ns ± 4% -23.07% (p=0.000 n=20+20)
DeepEqual/[]int32-8 180ns ± 1% 124ns ± 1% -31.06% (p=0.000 n=20+18)
DeepEqual/int64-8 40.1ns ± 2% 31.4ns ± 4% -21.82% (p=0.000 n=20+20)
DeepEqual/[]int64-8 180ns ± 1% 124ns ± 1% -31.47% (p=0.000 n=16+19)
DeepEqual/int-8 40.1ns ± 4% 30.9ns ± 3% -22.88% (p=0.000 n=20+18)
DeepEqual/[]int-8 180ns ± 0% 123ns ± 2% -31.59% (p=0.000 n=19+20)
DeepEqual/uint8-8 39.8ns ± 3% 31.9ns ± 5% -19.72% (p=0.000 n=20+20)
DeepEqual/[]uint8-8 168ns ± 1% 114ns ± 1% -32.48% (p=0.000 n=18+19)
DeepEqual/uint16-8 40.3ns ± 4% 31.4ns ± 6% -22.14% (p=0.000 n=20+20)
DeepEqual/[]uint16-8 173ns ± 1% 124ns ± 1% -28.20% (p=0.000 n=20+16)
DeepEqual/uint32-8 40.1ns ± 3% 30.7ns ± 3% -23.48% (p=0.000 n=20+20)
DeepEqual/[]uint32-8 180ns ± 1% 123ns ± 1% -31.56% (p=0.000 n=20+18)
DeepEqual/uint64-8 40.0ns ± 4% 31.3ns ± 4% -21.80% (p=0.000 n=19+19)
DeepEqual/[]uint64-8 180ns ± 1% 124ns ± 0% -31.45% (p=0.000 n=18+18)
DeepEqual/uint-8 39.8ns ± 3% 31.1ns ± 4% -21.95% (p=0.000 n=19+20)
DeepEqual/[]uint-8 181ns ± 1% 122ns ± 1% -32.33% (p=0.000 n=17+20)
DeepEqual/uintptr-8 40.3ns ± 3% 31.2ns ± 3% -22.66% (p=0.000 n=20+18)
DeepEqual/[]uintptr-8 181ns ± 1% 124ns ± 1% -31.46% (p=0.000 n=19+16)
DeepEqual/float32-8 40.3ns ± 2% 31.2ns ± 3% -22.52% (p=0.000 n=16+20)
DeepEqual/[]float32-8 180ns ± 1% 122ns ± 1% -32.18% (p=0.000 n=17+17)
DeepEqual/float64-8 40.6ns ± 3% 30.9ns ± 5% -23.91% (p=0.000 n=19+20)
DeepEqual/[]float64-8 182ns ± 2% 121ns ± 1% -33.33% (p=0.000 n=18+20)
DeepEqual/complex64-8 43.0ns ±11% 32.1ns ± 5% -25.33% (p=0.000 n=20+18)
DeepEqual/[]complex64-8 182ns ± 1% 122ns ± 2% -32.60% (p=0.000 n=18+19)
DeepEqual/complex128-8 42.4ns ± 4% 34.2ns ± 3% -19.35% (p=0.000 n=20+19)
DeepEqual/[]complex128-8 197ns ± 1% 122ns ± 1% -38.01% (p=0.000 n=19+19)
DeepEqual/bool-8 40.3ns ± 3% 32.9ns ± 5% -18.33% (p=0.000 n=20+20)
DeepEqual/[]bool-8 169ns ± 1% 124ns ± 1% -26.90% (p=0.000 n=18+19)
DeepEqual/string-8 41.4ns ± 3% 33.7ns ± 5% -18.50% (p=0.000 n=19+20)
DeepEqual/[]string-8 216ns ± 0% 128ns ± 1% -41.05% (p=0.000 n=19+17)
DeepEqual/[]uint8#01-8 507ns ± 1% 112ns ± 2% -77.92% (p=0.000 n=20+20)
DeepEqual/[][]uint8-8 613ns ± 1% 210ns ± 1% -65.76% (p=0.000 n=18+19)
DeepEqual/[6]uint8-8 228ns ± 1% 162ns ± 1% -29.00% (p=0.000 n=20+19)
DeepEqual/[][6]uint8-8 546ns ± 2% 269ns ± 1% -50.72% (p=0.000 n=20+19)
name old alloc/op new alloc/op delta
DeepEqual/int8-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]int8-8 2.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/int16-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]int16-8 4.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/int32-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]int32-8 8.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/int64-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]int64-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/int-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]int-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/uint8-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uint8-8 2.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/uint16-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uint16-8 4.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/uint32-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uint32-8 8.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/uint64-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uint64-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/uint-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uint-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/uintptr-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]uintptr-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/float32-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]float32-8 8.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/float64-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]float64-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/complex64-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]complex64-8 16.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/complex128-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]complex128-8 32.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/bool-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]bool-8 2.00B ± 0% 0.00B -100.00% (p=0.000 n=20+20)
DeepEqual/string-8 0.00B 0.00B ~ (all equal)
DeepEqual/[]string-8 32.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/[]uint8#01-8 12.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/[][]uint8-8 12.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
DeepEqual/[6]uint8-8 0.00B 0.00B ~ (all equal)
DeepEqual/[][6]uint8-8 12.0B ± 0% 0.0B -100.00% (p=0.000 n=20+20)
name old allocs/op new allocs/op delta
DeepEqual/int8-8 0.00 0.00 ~ (all equal)
DeepEqual/[]int8-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/int16-8 0.00 0.00 ~ (all equal)
DeepEqual/[]int16-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/int32-8 0.00 0.00 ~ (all equal)
DeepEqual/[]int32-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/int64-8 0.00 0.00 ~ (all equal)
DeepEqual/[]int64-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/int-8 0.00 0.00 ~ (all equal)
DeepEqual/[]int-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uint8-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uint8-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uint16-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uint16-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uint32-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uint32-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uint64-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uint64-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uint-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uint-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/uintptr-8 0.00 0.00 ~ (all equal)
DeepEqual/[]uintptr-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/float32-8 0.00 0.00 ~ (all equal)
DeepEqual/[]float32-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/float64-8 0.00 0.00 ~ (all equal)
DeepEqual/[]float64-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/complex64-8 0.00 0.00 ~ (all equal)
DeepEqual/[]complex64-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/complex128-8 0.00 0.00 ~ (all equal)
DeepEqual/[]complex128-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/bool-8 0.00 0.00 ~ (all equal)
DeepEqual/[]bool-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/string-8 0.00 0.00 ~ (all equal)
DeepEqual/[]string-8 2.00 ± 0% 0.00 -100.00% (p=0.000 n=20+20)
DeepEqual/[]uint8#01-8 12.0 ± 0% 0.0 -100.00% (p=0.000 n=20+20)
DeepEqual/[][]uint8-8 12.0 ± 0% 0.0 -100.00% (p=0.000 n=20+20)
DeepEqual/[6]uint8-8 0.00 0.00 ~ (all equal)
DeepEqual/[][6]uint8-8 12.0 ± 0% 0.0 -100.00% (p=0.000 n=20+20)
Change-Id: Ic21f0e2305f2cf5e6674c81b9ca609120b3006d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318169
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
|
|
CL 345486 introduced an optimization to reflect's map accesses
which is not quite correct. We can't use the optimized code if the
value type is >128 bytes.
See cmd/compile/internal/walk/walk.go:mapfast
Fixes #48357
Change-Id: I8e3c7858693083dd4393a8de48ca5fa47bab66f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/349593
Trust: Keith Randall <khr@golang.org>
Trust: Joe Tsai <joetsai@digital-static.net>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
This test checks that we load the same graph regardless of the path to
the requested module in the workspace.
We currently don't. This will be fixed in a future change that redoes
workspace mode's usage of the Requirements structure.
For #45713
Change-Id: Id02cbb60a38619d840dbf1e70173ce853c0c167a
Reviewed-on: https://go-review.googlesource.com/c/go/+/348649
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
