Move the "TODO" to outside of the function so that the "Output" comment
block is the last comment block. Output is only checked when it is the
last comment block. See golang/go#48362 for this issue.
Fixes: golang/go#48494
Change-Id: I7a31d7c13710e58fa876c96240a927a9bb8273ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/350995
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: David Chase <drchase@google.com>
Extend the existing dump-to-file to also do assembly output
to make it easier to write debug-information tests that check
for line-numbering in particular orders.
Includes POC test (which is silent w/o -v):
go test -v -run TestDebugLines cmd/compile/internal/ssa
=== RUN TestDebugLines
Preserving temporary directory /var/folders/v6/xyzzy/T/debug_lines_test321
About to run (cd /var/folders/v6/xyzzy/T/debug_lines_test321; \
GOSSADIR=/var/folders/v6/xyzzy/T/debug_lines_test321 \
/Users/drchase/work/go/bin/go build -o foo.o \
'-gcflags=-N -l -d=ssa/genssa/dump=sayhi' \
/Users/drchase/work/go/src/cmd/compile/internal/ssa/testdata/sayhi.go )
Saw stmt# 8 for submatch '8' on dump line #7 = ' v107 00005 (+8) MOVQ AX, "".n(SP)'
Saw stmt# 9 for submatch '9' on dump line #9 = ' v87 00007 (+9) MOVUPS X15, ""..autotmp_2-32(SP)'
Saw stmt# 10 for submatch '10' on dump line #46 = ' v65 00044 (+10) MOVUPS X15, ""..autotmp_2-32(SP)'
Saw stmt# 11 for submatch '11' on dump line #83 = ' v131 00081 (+11) MOVQ "".wg+8(SP), AX'
--- PASS: TestDebugLines (4.95s)
PASS
ok cmd/compile/internal/ssa 5.685s
Includes a test to ensure that inlining information is printed correctly.
Updates #47880.
Change-Id: I83b596476a88687d71d5b65dbb94641a576d747e
Reviewed-on: https://go-review.googlesource.com/c/go/+/348970
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If go.mod declares 1.17 or higher, when the go command rewrites go.mod
(for example, after 'go mod tidy'), it will be more consistent about
moving requirements in two blocks, one containing only direct
requirements, and one containing only indirect requirements.
The go command will not move requirements into or out of a block with
comments. It may still update versions and "// indirect" comments, and
it may delete unneeded requirements though.
Fixes#47563Fixes#47733
Change-Id: Ia6fb3e302be53097893abf01aa7cea60ac7b069a
Reviewed-on: https://go-review.googlesource.com/c/go/+/343432
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Generate debug_info entries for types that are only referenced through
dictionaries.
Change-Id: Ic36c2e6d9588ec6746793bb213c2dc0e17a8a850
Reviewed-on: https://go-review.googlesource.com/c/go/+/350532
Run-TryBot: Alessandro Arzilli <alessandro.arzilli@gmail.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: David Chase <drchase@google.com>
This change cleans up the code, by just delaying all transforms on
generic function methods/functions until stenciling time. That way, we
don't have extra code to decide whether to delay, or an extra value for
the typecheck flag. We are already doing all possible transforms at
stencil time anyway, so no changes to the stenciling code.
transform.go includes a change for one case where we check for shape
rather than tparam, now that we only apply transforms to stenciled
functions, not generic functions. This change is to allow CONVIFACE node
to be correctly inserted (needed for dictionaries), even with this
strange code that doesn't add the CONVIFACE node if the concrete type is
NOT huge...
Change-Id: I5f1e71fab11b53385902074915b3ad85f8e753fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/350736
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>
Export the _Orig method for Named types, and rename to Origin. As
discussed in #47916, Orig is easily confused with Original, which is
not as good a name. Spelling out 'Origin' resolves the ambiguity.
Updates #47916
Change-Id: I377c73de82310d3f6aa0bd82dddcd60ee067155b
Reviewed-on: https://go-review.googlesource.com/c/go/+/350996
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>
When going to dictionary formats derived from the function
instantiations, I had broken out noder.Assignop() to deal specially with
shape types, but didn't quite get the tricky case right. We still need
to allow conversion between shape types, but if the destination is an
interface, we need to use CONVIFACE rather than CONVNOP.
Fixes#48453.
Change-Id: I8c4b39c2e628172ac34f493f1dd682cbac1e55ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/350949
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This adds the ppc64 information to the ABI doc.
Change-Id: I55ce77a59a8b50309d02e3e0de0cea3fc62ad003
Reviewed-on: https://go-review.googlesource.com/c/go/+/342869
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Ensure constant shift amounts are in the range [0-31]. When shift amounts
are out of range, bad things happen. Shift amounts out of range occur
when lowering 64-bit shifts (we take an in-range shift s in [0-63] and
calculate s-32 and 32-s, both of which might be out of [0-31]).
The constant shift operations themselves still work, but their shift
amounts get copied unmolested to operations like ORshiftLL which use only
the low 5 bits. That changes an operation like <<100 which unconditionally
produces 0, to <<4, which doesn't.
Fixes#48476
Change-Id: I87363ef2b4ceaf3b2e316426064626efdfbb8ee3
Reviewed-on: https://go-review.googlesource.com/c/go/+/350969
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add in the documentation of the new declarations and type descriptors to
support parameterized functions and types.
Change-Id: Ia21c544caa704309cc8fd639f104c192e1786b72
Reviewed-on: https://go-review.googlesource.com/c/go/+/350951
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is to keep in alignment with the naming in go/types.
Change-Id: I19ded29b39665d7b892fdbc8e92c7f15caf7ab66
Reviewed-on: https://go-review.googlesource.com/c/go/+/350950
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
a minimally invasive fix proposal for #45940. which keeps the fix for #26197.
an alternative for (#26197) could be to fail if we have both flags. adding/removing a flag without an message to the user is inconvenient.
Change-Id: I6ac2524d81ff57202fbe3032a53afd5106270a9e
GitHub-Last-Rev: edaf02fa45
GitHub-Pull-Request: golang/go#45989
Reviewed-on: https://go-review.googlesource.com/c/go/+/317569
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
As with other recent issues, the Init field of a range loop was not
being handled properly. Generally, it is much better to explicitly
import/export the Init statements, else they are incorrectly added
before the associated node, rather than as the Init value of the node.
This was causing labels to not be correctly added to the range loop that
it is immediately preceding.
Made the ORANGE handling completely similar to the OFOR handling.
Fixes#48462
Change-Id: I999530e84f9357f81deaa3dda50660061f710e7c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350911
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
CL 342350 fixed panic with dead hidden closures, by marking discarded
hidden closure as dead, and won't compile them. However, the fix is
incomplete. In case the "if" or "else" block end with panic or return
statement:
if true { return }
# All nodes starts from here are dead
the dead nodes must be processed with markHiddenClosureDead, but they
are not, causing the compiler crashes.
This CL adds that missing part.
Fixes#48459
Change-Id: Ibdd10a61fc6459d139bbf4a66b0893b523ac6b67
Reviewed-on: https://go-review.googlesource.com/c/go/+/350695
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: Keith Randall <khr@golang.org>
When registering an RPC server, the type being registered may
have additional methods that are not meant to be exposed as
RPC endpoints. Remove the warnings net/rpc produces in
this case. The functionality to report warnings is kept in the code
with a compile-time constant that can be enabled for debugging.
The documentation of net/rpc states that only methods
satisfying a set of criteria will be made available, while other
methods will be ignored.
Fixes#19957
Change-Id: I5f8a148b4be1fdfffb2cd2029871193eaf24b751
Reviewed-on: https://go-review.googlesource.com/c/go/+/350009
Reviewed-by: Daniel Lublin <daniel@lublin.se>
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Carlos Amedee <carlos@golang.org>
We used to not SSA ".this" variable, because in tail-call method
wrappers it relies on updating ".this" in place in memory, and
the tail call IR node and SSA op do not have an explicit use of
".this". It is no longer the case for the new tail call
representation. Remove the restriction.
Change-Id: I4e1ce8459adbb0d5a80c64f1ece982737bd95305
Reviewed-on: https://go-review.googlesource.com/c/go/+/350751
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 previous CL re-enables tail calls for method wrappers. But
with the changed IR and SSA representation, for stack arguments
it generates self copies. This CL makes the compiler detect the
self copies and remove them.
Change-Id: I7252572a1a47834f28b6706e45906e2356408e02
Reviewed-on: https://go-review.googlesource.com/c/go/+/350349
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>
CL 320252 reworked the time docs, but accidentally deleted the format __2
from the sentence describing the three-character day of year component.
Change-Id: I3f583733028657c2a677358a25e062ea81835ce8
GitHub-Last-Rev: 2fa9832419
GitHub-Pull-Request: golang/go#48387
Reviewed-on: https://go-review.googlesource.com/c/go/+/349929
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
If the time is in 'LMT' and has fractional minute, then
`MarshalBinary()` and `UnmarshalBinary()` will encode/decode the time
in `timeBinaryVersionV2` in which the fractional minute is at
bit 15 and 16, and presented in seconds.
Fixes#39616
Change-Id: Ib762fb5fa26f54b1a8377a5dde0b994dd5a1236a
GitHub-Last-Rev: 455d7a2496
GitHub-Pull-Request: golang/go#40293
Reviewed-on: https://go-review.googlesource.com/c/go/+/243402
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
This also requires that we sometimes delay transformSelect(), if the
assignments in the Comm part of the select have not been transformed.
Fixes#48137
Change-Id: I163aa1f999d1e63616280dca807561b12b2aa779
Reviewed-on: https://go-review.googlesource.com/c/go/+/347915
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>
For certain type of method wrappers we used to generate a tail
call. That was disabled in CL 307234 when register ABI is used,
because with the current IR it was difficult to generate a tail
call with the arguments in the right places. The problem was that
the IR does not contain a CALL-like node with arguments; instead,
it contains an OAS node that adjusts the receiver, than an
OTAILCALL node that just contains the target, but no argument
(with the assumption that the OAS node will put the adjusted
receiver in the right place). With register ABI, putting
arguments in registers are done in SSA. The assignment (OAS)
doesn't put the receiver in register.
This CL changes the IR of a tail call to take an actual OCALL
node. Specifically, a tail call is represented as
OTAILCALL (OCALL target args...)
This way, the call target and args are connected through the OCALL
node. So the call can be analyzed in SSA and the args can be passed
in the right places.
(Alternatively, we could have OTAILCALL node directly take the
target and the args, without the OCALL node. Using an OCALL node is
convenient as there are existing code that processes OCALL nodes
which do not need to be changed. Also, a tail call is similar to
ORETURN (OCALL target args...), except it doesn't preserve the
frame. I did the former but I'm open to change.)
The SSA representation is similar. Previously, the IR lowers to
a Store the receiver then a BlockRetJmp which jumps to the target
(without putting the arg in register). Now we use a TailCall op,
which takes the target and the args. The call expansion pass and
the register allocator handles TailCall pretty much like a
StaticCall, and it will do the right ABI analysis and put the args
in the right places. (Args other than the receiver are already in
the right places. For register args it generates no code for them.
For stack args currently it generates a self copy. I'll work on
optimize that out.) BlockRetJmp is still used, signaling it is a
tail call. The actual call is made in the TailCall op so
BlockRetJmp generates no code (we could use BlockExit if we like).
This slightly reduces binary size:
old new
cmd/go 14003088 13953936
cmd/link 6275552 6271456
Change-Id: I2d16d8d419fe1f17554916d317427383e17e27f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/350145
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Change so that the Init and Def fields of assignments and OSELREVC2
nodes are exported/imported properly.
A quirk of iimport.go is that it automatically converts an ODCL node to
an ODCL/OAS sequence (where the OAS is to just zero out the declared
variable). Given that the Inits are properly fixed, o.stmt needs
adjustment for the OSELRECV2 case to skip over the new OAS nodes that
are inserted only on re-import.
Change-Id: Ic38017efca4b7ca9b3952ffbbfca067380902b7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/350809
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
CL 349412 introduced a bug when Checker.subst does not return a new
signature: we were still setting the receiver to the instantiated type.
I'm not sure how this could manifest in practice (other than confusing
object strings). It's possible that I could generate a testdata-driven
test for this, but in the interest of time I just added a test to verify
object strings.
Change-Id: I29bc8e1419ddc4574755c3def52d18cb71c738eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/350143
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>
GOAMD64 is for GOARCH=amd64. Fix the GOAMD64 environment variable docs
introduced by CL 349595.
Change-Id: I794990ebe2e306d21ed275446fc52373bfe4ae7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/350534
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Most architectures currently already implement Pipe using the pipe2
syscall. Only 386, amd64 and mips{,le} still use the pipe syscall.
However, some systems (e.g. Android seccomp policies) block that
syscall, see #40828 for an example.
The pipe2 syscall was added in Linux kernel version 2.6.27. The minimum
required Linux kernel version for Go 1.18 will be changed to 2.6.32
per #45964 so it is possible to unify the implementation of Pipe using
the pipe2 syscall.
For #45964
Change-Id: I8ed6a391300c95f3107b4ec6b27d320e42fb535b
Reviewed-on: https://go-review.googlesource.com/c/go/+/350530
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
CL 210639 moved the //sysnb for Setreuid from syscall_linux_$GOARCH.go
to syscall_linux.go but forgot to remove the comment from
syscall_linux_arm64.go which leads to Setreuid being generated twice for
linux/arm64. Remove that //sysnb comment to avoid this.
Change-Id: I2c8ad95f786530ca964685b0a4fe463c64764307
Reviewed-on: https://go-review.googlesource.com/c/go/+/350531
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
There are a bunch of nodes beside ONAME and OTYPE, (such as OSTRUCTLIT
and OCOMPLIT) which can introduce a generic type that we need to mark.
So, just mark any generic type on any node in markInlBody. In this
particular issue, the type is introduced by an OSTRUCTLIT node.
Updates #48337
Change-Id: I271932518f0c1fb54d91a603e01a855c69df631d
Reviewed-on: https://go-review.googlesource.com/c/go/+/349909
Trust: Dan Scales <danscales@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Fixes#48066
Change-Id: Icd6974dfcc496c054bb096e5d70de6e135984517
Reviewed-on: https://go-review.googlesource.com/c/go/+/349774
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This test is fragile and is starting to impede others' work. This CL
disables it until I have time to either find a solution for the issues
or decide to just delete the test altogether.
Change-Id: Icefabb6d3fbedec5d16536de78be4ca20d63133c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350729
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The C code that is calling crosscall1 may depend on the GP register, which Go code
will currently clobber. Save and restore both X3 (aka GP) and X4 (aka TP) in this
code path (note that the Go code does not currently clobber X4, however there is
minimal downside to saving and restoring it here, which then also matches crosscall2).
Updates #47100
Change-Id: Icbb706d7889d5dc59de3efb2b510fa6ea2069496
Reviewed-on: https://go-review.googlesource.com/c/go/+/334870
Trust: Joel Sing <joel@sing.id.au>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
golang.org/cl/344929 broke the minimal functionality that the python
pretty printer for GDB had, this change restores it to its status prior
to that CL.
Change-Id: I4c7141d4ff726d224a074ecc533d0f896fc0052c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350529
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Than McIntosh <thanm@google.com>
Ensure that rs2 is none for various instruction encodings. Fix a couple of cases
where it should have been but is not.
Change-Id: I9f8211a0257e49643dbbc89e158e048050ebe6f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/349649
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If NoInheritHandles is passed, then we shouldn't attempt to do anything
with handle lists. Otherwise CreateProcess fails with invalid param,
because it's being told both to not inherit handles and to inherit
certain handles.
This commit fixes that by using the same logic for handle lists as it
does for enabling or disabling handle inheritance. It also adds a test
to make sure this doesn't regress again.
Fixes#48040
Change-Id: I507261baeec263091738ab90157a991d917dc92f
Reviewed-on: https://go-review.googlesource.com/c/go/+/350411
Reviewed-by: Patrik Nyblom <pnyb@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change-Id: Icbf36e1cd8311b40d18177464e7c41dd8cb1c65b
Reviewed-on: https://go-review.googlesource.com/c/go/+/340350
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Change-Id: I857b0e9aa7d933879239ef7ebc0d1a2812a74c25
Reviewed-on: https://go-review.googlesource.com/c/go/+/343533
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
Fixes#48396
Change-Id: Idd7cb66536ef513806c472d394a929bc271fc26b
Reviewed-on: https://go-review.googlesource.com/c/go/+/350159
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
The extra test just confirms that the type-checker internally
agrees with the spec with the (otherwise invisible) type given
to an untyped constant in a specific shift expression.
For #48422.
Change-Id: I6d98045f90bd20b0cc0a96a147bec9701039cb07
Reviewed-on: https://go-review.googlesource.com/c/go/+/350410
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Thanks to @bodar (Github) for finding this.
Fixes#48422.
Change-Id: I031c3d82a02db1d204e2b86b494d89784d37f073
Reviewed-on: https://go-review.googlesource.com/c/go/+/350409
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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: f83ed17204
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: c7c4905bb9
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>
