For now this is simply a mechanical combination without any
relevant logic changes. This will make it easier to review
subsequent changes.
Change-Id: Ic2e2ae32b031d2dda0f69a08a5cc2349748bd25d
Reviewed-on: https://go-review.googlesource.com/c/go/+/472675
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
After CL 235820 all references to FD.rtimedout and FD.wtimedout
are guarded by mutexes. Therefore they can safely be changed
from type atomic.Bool to bool.
Change-Id: I7ab921d1ad5c7ccc147feb2b0fba58a66b031261
Reviewed-on: https://go-review.googlesource.com/c/go/+/472435
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Go programs can now use the //go:wasmimport module_name function_name
directive to import functions from the WebAssembly runtime.
For now, the directive is restricted to the runtime and syscall/js
packages.
* Derived from CL 350737
* Original work modified to work with changes to the IR conversion code.
* Modification of CL 350737 changes to fully exist in Unified IR path (emp)
* Original work modified to work with changes to the ABI configuration code.
* Fixes#38248
Co-authored-by: Vedant Roy <vroy101@gmail.com>
Co-authored-by: Richard Musiol <mail@richard-musiol.de>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Change-Id: I740719735d91c306ac718a435a78e1ee9686bc16
Reviewed-on: https://go-review.googlesource.com/c/go/+/463018
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Change-Id: I18bb87bfdea8b6d7994091ced5134aa2549f221e
Reviewed-on: https://go-review.googlesource.com/c/go/+/472476
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
This simplifies the use of missingMethod and also opens the door to
further missingMethod-internal simplifications.
Change-Id: I74d9694b6fca67c4103aea04d08916a69ad0e3c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/472495
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This CL allows missingMethod (and with it the assertableTo methods)
to provide an error cause without an extra external (and messy) call
of missingMethodCause. This latter function is now only called by
missingMethod and can be eliminated eventually in favor of more
precise error causes generated directly by missingMethod.
The change requires that missingMethod (and the assertableTo methods)
accept general types for both relevant argument types (rather than a
Type and a *Interface) so that error causes can report the appropriate
(possibly defined) type rather than the underlying interface type.
Change-Id: Ic31508073fa138dd5fa27285b06cf232ee638685
Reviewed-on: https://go-review.googlesource.com/c/go/+/472395
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
An inferred type argument must implement its type parameter's constraint's
methods whether or not a core type exists. This allows us to infer type
parameters used in method signatures.
Fixes#51593.
Change-Id: I1fddb05a71d442641b4311d8e30a13ea9bdb4db5
Reviewed-on: https://go-review.googlesource.com/c/go/+/472298
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This allows us to use missingMethod with different type comparers,
such as the global Identical predicate, or a unifier.
Preparation for the next CL.
Change-Id: I237fd9dd7feb3708847ae6d9a112bcdd0aa1ecb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/472297
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
This simply moves the special handling for unbound type parameters
into the switch (which already looks for type parameters).
Change-Id: I2d6d22f3fdffc443065c3681a442288cd1d375ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/472115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Because we rename type parameters to avoid problems with self-recursive
function calls, there's no need anymore for special (and hard to follow)
logic for pointer-identical types. If they are identical, we have a
match. Simplify the code accordingly.
Change-Id: I2e1838a43e90fa4abfae3ab9e4f7da6463508966
Reviewed-on: https://go-review.googlesource.com/c/go/+/471018
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Adjust imports but no other code changes otherwise.
Change-Id: Iffbd7f9b1786676a42b68d91ee6cc7df07d776bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/471015
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The primary change is that type inference now always reports
an error if a unification step fails (rather than ignoring that
case, see infer2.go). This brings the implementation closely to
the description in #58650; but the implementation is more direct
by always maintaining a simple (type parameter => type) mapping.
To make this work, there are two small but subtle changes in the
unifier:
1) When deciding whether to proceed with the underlying type of
a defined type, we also use the underlying type if the other
type is a basic type (switch from !hasName(x) to isTypeLit(x)
in unifier.go). This makes the case in issue #53650 work out.
See the comment in the code for a detailed explanation of this
change.
2) When we unify against an unbound type parameter, we always
proceed with its core type (if any).
Again, see the comment in the code for a detailed explanation
of this change.
The remaining changes are comment and test adjustments. Because
the new logic now results in failing type inference where it
succeeded before or vice versa, and then instatiation or parameter
passing failed, a handful of error messages changed.
As desired, we still have the same number of errors for the same
programs.
Also, because type inference now produces different results, we
cannot easily compare against infer1 anymore (also infer1 won't
work correctly anymore due to the changes in the unifier). This
comparison (together with infer1) is now disabled.
Because some errors and their positions have changed, we need a
slightly larger error position tolerance for types2 (which produces
less accurate error positions than go/types). Hence the change in
types2/check_test.go.
Finally, because type inference is now slightly more relaxed,
issue #51139 doesn't produce a type unification failure anymore
for a (previously correctly) inferred type argument.
Fixes#51139.
Change-Id: Id796eea42f1b706a248843ad855d9d429d077bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/470916
Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
The assertion here was to make sure the newly constructed and
typechecked expression selected the same receiver-qualified method,
but in the case of anonymous receiver types we can actually end up
with separate types.Field instances corresponding to each types.Type
instance. In that case, the assertion spuriously failed.
The fix here is to relax and assertion and just compare the method's
name and type (including receiver type).
Fixes#58563.
Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886
Reviewed-on: https://go-review.googlesource.com/c/go/+/471676
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since we can't gate tests on the macOS version on normal machines,
restrict TestIssue51759 to only run on builders, where we have a way to
do this.
Change-Id: I70fc83c587689b499b6a38864973a77bb3e52596
Reviewed-on: https://go-review.googlesource.com/c/go/+/472619
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The -T flag actually means the start address of text symbols, not
the text sections, which may differ by the header size. It has
been behaving like this since at least 2009. Make it clear in the
documentation.
Also remove the -D flag from the doc. The flag doesn't actually
exist in the implementation.
Fixes#58727.
Change-Id: Ic5b7e93adca3f1ff9f0de33dbb6089f46cdf4738
Reviewed-on: https://go-review.googlesource.com/c/go/+/472356
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Convert TestUnknownAuthorityError to use subtests, avoiding continuing
the test after an unrecoverable failure.
Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the
behavior we were testing for.
Updates #58791Fixes#58812
Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f
Reviewed-on: https://go-review.googlesource.com/c/go/+/472496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The existing runtime/coverage API set includes a "ClearCounters()"
function that zeros out the counter values in a running process so as
enable capturing of a coverage profile from a specific execution time
segment. Calling this function is only permitted if the program is
built with "-covermode=atomic", due (in part) to concerns about
processors with relaxed memory models in which normal stores can be
reordered.
In the bug in question, a test that stresses a different set of
counter-related APIs was hitting an invalid counter segment when
running on a machine (ppc64) which does indeed have a relaxed memory
consistency model.
From a post-mortem examination of the counter array for the harness
from the ppc64 test run, it was clear that the thread reading values
from the counter array was seeing the sort of inconsistency that could
result from stores being reordered (specifically the prolog
"packageID" and "number-of-counters" stores).
To preclude the possibility of future similar problems, this patch
extends the "atomic mode only" restriction from ClearCounters to the
other APIs that deal with counters (WriteCounters, WriteCountersDir).
Fixes#56197.
Change-Id: Idb85d67a84d69ead508e0902ab46ab4dc82af466
Reviewed-on: https://go-review.googlesource.com/c/go/+/463695
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
All amd64 OSes already make use of the NOFRAME flag wherever is
required, so we can remove the frameless nosplit functions heuristic
code path.
Updates #58378
Change-Id: I966970693ba07f8c66da0aca83c23caad7cbbfe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/466458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
A build constraint reports whether the test binary was compiled with
cgo enabled, but that doesn't necessarily imply that cgo can be used
in the environment in which the test binary is run.
In particular, cross-compiled builders (such as Android) may compile
the test binaries on the host with CGO enabled but not provide a C
toolchain on the device that runs the test.
For #58775.
Change-Id: Ibf2f44c9e956cd3fa898c3de67af4449e8ef2dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/472215
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This CL marks some plan9 assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Updates #58378
Change-Id: Ic8c9ab5c1a0897bebc6c1419ddc903a7492a1b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466457
TryBot-Bypass: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL removes some NOFRAME flags on Windows assembly files
for several reasons:
- windows/386 does not use a frame pointer
- Leaf frameless functions already skip the frame pointer
- Some non-leaf functions do not contain enough dragons to justify
not using the frame pointer
Updates #58378
Change-Id: I31e71bf7f769e1957a4adba91778da5af66ce1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/466835
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.
Fixes#58791
Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
In the past, we planned to implement asynchronous preemption using
precise register pointer maps. In this strategy, conversions between
unsafe.Pointer and uintptr would need to be marked as unsafe points,
as if a pointer value is temporarily converted to uintptr (and not
live otherwise), the GC would not be able to see it when scanning
the stack (and registers).
But now we actually implemented asynchronous preemption with inner
frame conservative scan. So even if a pointer value lives as an
integer the GC can still see it. There is no need to mark the
conversion as unsafe points. This allows more places to be
preempted, as well as for debugger to inject a call.
Fixes#57719.
Change-Id: I375ab820d8d74d122b565cf72ecc7cdb225dbc01
Reviewed-on: https://go-review.googlesource.com/c/go/+/461696
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This was noticed while testing hash-search debugging
of the loopvar experiment.
The change is incomplete -- it only addresses local
variables, not parameters. The code to log/search
changes in loop variable semantics depends on this,
so that will be the test.
Change-Id: I0f84ab7696c6cab43486242cacaba6a0bfc45475
Reviewed-on: https://go-review.googlesource.com/c/go/+/464315
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
After CL 436435 chain, the only case left where we create an ONAME node
with nil Func is interface method from imported package.
Change-Id: I9d9144916d01712283f2b116973f88965715fea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/468816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Some folks working on the Go project may have a go.work file in
GOROOT/src in order to test changes in x repos. 'go test cmd/go'
should not fail if that is the case.
For #58767.
Change-Id: I0e57b15fb1d3e4abc4903c177434626c9f125cae
Reviewed-on: https://go-review.googlesource.com/c/go/+/471601
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Workspace mode is specifically for working with modules;
it doesn't make sense in GOPATH mode.
This also fixes a panic in (*modload.MainModuleSet).GoVersion
when go.work is present in GOPATH mode.
For #58767.
Change-Id: Ic6924352afb486fecc18e009e6b517f078e81094
Reviewed-on: https://go-review.googlesource.com/c/go/+/471600
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#58754
Change-Id: Ic3ef58b204b946f8bff80310d4c8dfcbb2939a1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/471678
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Because "CopyN" will read one more byte, which will cause us
to overflow when calling "Reader.ReadForm(math.MaxInt64)".
So we should check if the parameter exceeds "math.MaxInt64"
to avoid returning no data.
Fixes#58384.
Change-Id: I30088ce6468176b21e4a9a0b8b6080f2986dda23
Reviewed-on: https://go-review.googlesource.com/c/go/+/467557
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: hopehook <hopehook@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The compiler used to generate ONAME node with nil Func for them, so the
inliner can still analyze, but could not generate inline call for them
anyway.
CL 436961 attempts to create ONAME node with non-nil Func, causing the
inliner complains about missing body reader.
This CL makes inliner recognize type eq/hash functions, and mark them as
non-inlineable. Longer term, if we do want to inline these functions, we
need to integrate the code generation into Unified IR frontend.
Updates #58572
Change-Id: Icdd4dda03711929faa3d48fe2d9886568471f0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/469017
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Go 1.19 introduced doc links (https://go.dev/doc/comment#doclinks).
It will be convenient when we can directly jump to the suggested
function when the original function is deprecated.
Change-Id: I6172a5265f3b47aefec53179bca60f9904606b3f
GitHub-Last-Rev: b2aa85bf1b
GitHub-Pull-Request: golang/go#58779
Reviewed-on: https://go-review.googlesource.com/c/go/+/471915
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
testGo is currently only configured if testenv.HasGoBuild returns
true, which implies that a complete toolchain is present.
Since setting up testGo now only uses the test binary itself, it does
not actually require 'go build', but fixing that will be a bit more
involved. For now, just skip the test when it isn't set up.
Fixes#58775.
Change-Id: I6487b47b44c87aa139ae11cfa44ce6f0f5f84bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/472095
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
As background, Power10 adds prefixed load, store, and add immediate
instructions which encode 34b signed displacements. Likewise, they
also give the option to compute addresses against the PC. This enables
using simpler PC relative (PC-rel) relocations instead of maintaining a
dedicated pointer (the TOC) to the code/data blob on PPC64/linux.
Similary, there are several Go opcodes where it can be advantageous to
use prefixed instructions instead of composite sequences like oris/ori/add
to implement "MOVD <big const>, Rx" or "ADD <big const>, Rx, Ry", or
large offset load/stores like "MOVD <big constant>(Rx), Ry" using the same
framework which dynamically configures optab.
When selecting prefixed instruction forms, the assembler must also use
new relocations. These new relocations are always PC-rel by design, thus
code assembled as such has no implicit requirement to maintain a TOC
pointer when assembling shared objects. Thus, we can safely avoid
situations where some Go objects use a TOC pointer, and some do not. This
greatly simplifies linking Go objects. For more details about the
challenges of linking TOC and PC-rel compiled code, see the PPC64 ELFv2
ABI.
The TOC pointer in R2 is still maintained in those build configurations
which previously required it (e.x buildmode=pie). However, Go code built
with PC-rel relocations does not require the TOC pointer. A future
change could remove the overhead of maintaining a TOC pointer in those
build configurations.
This is enabled only for power10/ppc64le/linux.
A final noteworthy difference between the prefixed and regular load/store
instruction forms is the removal of the DS/DQ form restrictions. That
is, the immediate operand does not need to be aligned.
Updates #44549
Change-Id: If59c216d203c3eed963bfa08855e21771e6ed669
Reviewed-on: https://go-review.googlesource.com/c/go/+/355150
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#58755
Change-Id: I5b95a21f47ec306ad90cd6221f0566c6f8b6c3ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/471835
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
According to the ARM Architecture Reference Manual, LDADDx-like
instructions can take rt as zr when the encode A bit is 0. They
are used by the alias STADDx-like instructions. The current
assembler adds incorrect constraints for them, which is rt can't
be zr when field.enc A is 0. This patch removes it.
Add test cases.
Reported by Matt Horsnell <matt.horsnell@arm.com>
The reference:
https://developer.arm.com/documentation/ddi0602/2022-12/Base-Instructions
Change-Id: Ia2487a5e3900e32994fc14edaf03deeb245e70c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/462295
Reviewed-by: Matt Horsnell <matthew.horsnell@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ica8d5e5799a4de532764ae86cdb623508d3a8e18
GitHub-Last-Rev: 3e97cca9de
GitHub-Pull-Request: golang/go#58689
Reviewed-on: https://go-review.googlesource.com/c/go/+/471021
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
On Arm64, all 32-bit instructions will ignore the upper 32 bits and
clear them to zero for the result. No need to do an unsign extend before
a 32 bit op.
This CL removes the redundant unsign extension only for the existing
32-bit opcodes, and also omits the sign extension when the upper bit of
the result can be predicted.
Fixes#42162
Change-Id: I61e6670bfb8982572430e67a4fa61134a3ea240a
CustomizedGitHooks: yes
Reviewed-on: https://go-review.googlesource.com/c/go/+/427454
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Eric Fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
