Updates golang/go#37595
Change-Id: I7568e7416d5504e9dc67061c79f66e3a0d597dee
Reviewed-on: https://go-review.googlesource.com/c/go/+/351470
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Change-Id: I9921ba5c29ada6ff06d147f6d9b46a29101c449c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350694
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Change-Id: Ic0a97fd7bb89865448e436e5c092415a29d8badf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352009
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: David Chase <drchase@google.com>
Cribbed and modified from arm64, verify each transformation
rewrites a too-far conditional branch as expected.
Change-Id: I87d35085158ed7d7478aa9725b273401fcd0bd01
Reviewed-on: https://go-review.googlesource.com/c/go/+/347049
Trust: David Chase <drchase@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
This adds the changes for the register ABI in the runtime
functions for ppc64x:
- Add spill functions used by runtime
- Add ABIInternal to functions
Some changes were needed to the stubs files
due to vet issues when compiling for linux/ppc64.
Change-Id: I010ddbc774ed4f22e1f9d77833bd55b919d95c99
Reviewed-on: https://go-review.googlesource.com/c/go/+/351590
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>
This should have been part of https://golang.org/cl/340049 but I
overlooked it. That commit added fast path code when the destination
image was *not* an *image.RGBA. This commit edits func drawRGBA.
name old time/op new time/op delta
RGBA1-4 5.11ms ± 1% 1.12ms ± 1% -78.01% (p=0.008 n=5+5)
RGBA2-4 8.69ms ± 1% 2.98ms ± 1% -65.77% (p=0.008 n=5+5)
Updates #44808.
Updates #46395.
Change-Id: I899d46d985634fc81ea47ff4f0d436630e8a961c
Reviewed-on: https://go-review.googlesource.com/c/go/+/351852
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In CL 349613,we have supported types.IdentityStrict() that does strict
type comparison.
Therefore, OCONVNOP becomes a possible case in call.X.Op().
Fixes#48604
Change-Id: Ibab27ffcf09656e3380314662f05f38294c1c6ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/351857
Trust: Dan Scales <danscales@google.com>
Trust: David Chase <drchase@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For #48617
Change-Id: I6c00b7912c441ac323a0adede63b7d4a9ae6f92d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351858
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
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>
In CL 349614. we removed the early transformation code that
was needed to create the implicit CONVIFACE nodes.
Because the transformCall function is not called when translating OFUNCINST.
So we add in needed CONVIFACE nodes via typecheckaste().
Fixes#48598
Change-Id: If9dc7040cdc38ef2e52fdbb08c840095651426f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/351856
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Dan Scales <danscales@google.com>
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>
Deal correctly with a blank local variable with type param type. This is
a special case, because a blank local variable is not in the fn.Dcl
list. In this case, we must explicitly create a new blank node with the
correct substituted type, so we have correct types if the blank local
variable has an initializing assignment.
Fixes#48602
Change-Id: I903ea44b29934e180404e32800773b7309bf297b
Reviewed-on: https://go-review.googlesource.com/c/go/+/352117
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: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Dan Scales <danscales@google.com>
Based on comments in CL 348469.
Note that with this change, F.Fuzz no longer calls
runtime.Goexit. This simplifies our logic and makes F.Fuzz more
predictable.
Change-Id: I6c3c65b0e8e8f261621cbe2f17375e8164ef60a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/351316
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>
gofmt is pretty heavily CPU-bound, since parsing and formatting 1MiB
of Go code takes much longer than reading that amount of bytes from
disk. However, parsing and manipulating a large Go source file is very
difficult to parallelize, so we continue to process each file in its
own goroutine.
A Go module may contain a large number of Go source files, so we need
to bound the amount of work in flight. However, because the
distribution of sizes for Go source files varies widely — from tiny
doc.go files containing a single package comment all the way up to
massive API wrappers generated by automated tools — the amount of
time, work, and memory overhead needed to process each file also
varies. To account for this variability, we limit the in-flight work
by bytes of input rather than by number of files. That allows us to
make progress on many small files while we wait for work on a handful
of large files to complete.
The gofmt tool has a well-defined output format on stdout, which was
previously deterministic. We keep it deterministic by printing the
results of each file in order, using a lazily-synchronized io.Writer
(loosly inspired by Haskell's IO monad). After a file has been
formatted in memory, we keep it in memory (again, limited by the
corresponding number of input bytes) until the output for all previous
files has been flushed. This adds a bit of latency compared to
emitting the output in nondeterministic order, but a little extra
latency seems worth the cost to preserve output stability.
This change is based on Daniel Martí's work in CL 284139, but using a
weighted semaphore and ephemeral goroutines instead of a worker pool
and batches. Benchmark results are similar, and I find the concurrency
in this approach a bit easier to reason about.
In the batching-based approach, the batch size allows us to "look
ahead" to find large files and start processing them early. To keep
the CPUs saturated and prevent stragglers, we would need to tune the
batch size to be about the same as the largest input files. If the
batch size is set too high, a large batch of small files could turn
into a straggler, but if the batch size is set too low, the largest
files in the data set won't be started early enough and we'll end up
with a large-file straggler.
One possible alternative would be to sort by file size instead of
batching: identify all of the files to be processed, sort from largest
to smallest, and then process the largest files first so that the
"tail" of processing covers the smallest files. However, that approach
would still fail to saturate available CPU when disk latency is high,
would require buffering an arbitrary amount of metadata in order to
sort by size, and (perhaps most importantly!) would not allow the
`gofmt` binary to preserve the same (deterministic) output order that
it has today.
In contrast, with a semaphore we can produce the same deterministic
output as ever using only one tuning parameter: the memory footprint,
expressed as a rough lower bound on the amount of RAM available per
thread. While we're below the memory limit, we can run arbitrarily
many disk operations arbitrarily far ahead, and process the results of
those operations whenever they become avaliable. Then it's up to the
kernel (not us) to schedule the disk operations for throughput and
latency, and it's up to the runtime (not us) to schedule the
goroutines so that they complete quickly.
In practice, even a modest assumption of a few megabytes per thread
seems to provide a nice speedup, and it should scale reasonably even
to machines with vastly different ratios of CPU to disk. (In practice,
I expect that most 'gofmt' invocations will work with files on at most
one physical disk, so the CPU:disk ratio should vary more-or-less
directly with the thread count, whereas the CPU:memory ratio is
more-or-less independent of thread count.)
name \ time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 11.9s ± 2% 2.7s ± 3% 2.8s ± 5%
name \ user-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 13.5s ± 2% 14.4s ± 1% 14.7s ± 1%
name \ sys-time/op baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 465ms ± 8% 229ms ±28% 232ms ±31%
name \ peak-RSS-bytes baseline.txt 284139.txt simplified.txt
GofmtGorootCmd 77.7MB ± 4% 162.2MB ±10% 192.9MB ±15%
For #43566
Change-Id: I4ba251eb4d188a3bd1901039086be57f0b341910
Reviewed-on: https://go-review.googlesource.com/c/go/+/317975
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
'go mod why -m' works by listing modules matching command line
arguments, then loading "all" packages and finding which of the listed
modules provide packages imported by the main module.
If go.mod is inconsistent (that is, a requirement has a lower version
than MVS would select when the module graph is loaded) and pruned
(that is, the module graph is only loaded when necessary), then
modload.ListModules may return modules with different versions than
would be selected in modload.LoadPackages.
'go mod why -m' was too strict about this, mapping module paths and
versions to packages. With this fix, it maps module paths without
versions to packages.
Fixes#48613
Change-Id: I836c46289bb647d6c46ec65e7589531da532d5e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/352115
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>
The delayTransform only checks whether ir.CurFunc is generic function or
not. but when compiling a non-generic closure inside a generic function,
we also want to delay the transformation, which delayTransform fails to
detect, since when ir.CurFunc is the closure, not the top level function.
Instead, we must rely on irgen.topFuncIsGeneric field to decide whether
to delay the transformation, the same logic with what is being done for
not adding closure inside a generic function to g.target.Decls list.
Fixes#48609
Change-Id: I5bf5592027d112fe8b19c92eb906add424c46507
Reviewed-on: https://go-review.googlesource.com/c/go/+/351855
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>
So next CL will make delayTransform to become irgen's method, because
the delay transform logic also depends on irgen.topFuncIsGeneric field.
For #48609
Change-Id: I660ed19856bd06c3b6f4279a9184db96175dea2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351854
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>
In markType() in crawler.go, mark the type of a unexported field if it
is a fully-instantiated type, since we create and instantiate the
methods of any fully-instantiated type that we see during import. As
before, we still do not mark the type of an unexported field if that
type is not generic. Fixes#48454 and most recent issue described in
48337. The included test is similar to the case in 48454.
Fixes#48454Fixes#48337
Change-Id: I77a2a62b9e2647876facfa6f004201e8f699c905
Reviewed-on: https://go-review.googlesource.com/c/go/+/351315
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
When I separate out the dictionary transformations to dictPass, I missed
duplicating a conditional that deals with OMETHVALUE nodes that are
actually called. We create the OMETHVALUE when transforming bounds
function reference (before we know whether that reference will be
called), and we need to call transformDot() again to convert the
OMETHVALUE to ODOTMETH if the reference is actually called (the usual
case). Without this change, we leave the OMETHVALUE in, and extra *-fm
are created and used unncessarily.
Also, fixed a few places where we were missing ir.MarkFunc(), which sets
the class of a function node properly.
Change-Id: I6b02613039b16b507b44525faa2cd7031afb6982
Reviewed-on: https://go-review.googlesource.com/c/go/+/352069
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Subcommands may now set the global flag modload.ExplicitWriteGoMod
instead of calling {Allow,Disallow}WriteGoMod.
When ExplicitWriteGoMod is false (default), modload.LoadPackages and
ListModules will either update go.mod and go.sum or report an error if
they need to be updated, depending on cfg.BuildMod.
When ExplicitWriteGoMod is true, commands must explicitly call
modload.WriteGoMod to update go.mod and go.sum or report an
error. Commands that perform some operation after loading the build
list (like downloading zips or building packages) and commands that
load packages multiple times should set this. For now, only 'go get'
and 'go mod download' set this.
This CL is a pure refactor: no change in behavior is expected.
There are some other minor changes in here, too: commitRequirements no
longer sets the global requirements: that should be done separately first.
Change-Id: I69942a808bb177faf7904a53aaf2d4ac68500e82
Reviewed-on: https://go-review.googlesource.com/c/go/+/349600
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
They should also not report an error if these files need to be
updated. These commands are used for debugging, so it's important that
they still work when go.mod and go.sum are incomplete.
For #40775
Change-Id: I1b731599e5a4510f47827b9812525636a7402bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/351468
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
m.vdsoSP should be set to the SP of the caller of nanotime1,
instead of the SP of nanotime1 itself, which matches m.vdsoPC.
Otherwise the unmatched vdsoPC and vdsoSP would make the stack
trace look like recursive.
We already do it correctly on AMD64, 386, and RISCV64. This CL
fixes the rest.
Fixes#47324.
Change-Id: I98b6fcfbe9fc6bdd28b8fe2a1299b7c505371dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/337590
Trust: Cherry Mui <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Instructions with immediates can be precomputed when operating on a
constant - do so for SLTI/SLTIU, SLLI/SRLI/SRAI, NEG/NEGW, ANDI, ORI
and ADDI. Additionally, optimise ANDI and ORI when the immediate is
all ones or all zeroes.
In particular, the RISCV64 logical left and right shift rules
(Lsh*x*/Rsh*Ux*) produce sequences that check if the shift amount
exceeds 64 and if so returns zero. When the shift amount is a
constant we can precompute and eliminate the filter entirely.
Likewise the arithmetic right shift rules produce sequences that
check if the shift amount exceeds 64 and if so, ensures that the
lower six bits of the shift are all ones. When the shift amount
is a constant we can precompute the shift value.
Arithmetic right shift sequences like:
117fc: 00100513 li a0,1
11800: 04053593 sltiu a1,a0,64
11804: fff58593 addi a1,a1,-1
11808: 0015e593 ori a1,a1,1
1180c: 40b45433 sra s0,s0,a1
Are now a single srai instruction:
117fc: 40145413 srai s0,s0,0x1
Likewise for logical left shift (and logical right shift):
1d560: 01100413 li s0,17
1d564: 04043413 sltiu s0,s0,64
1d568: 40800433 neg s0,s0
1d56c: 01131493 slli s1,t1,0x11
1d570: 0084f433 and s0,s1,s0
Which are now a single slli (or srli) instruction:
1d120: 01131413 slli s0,t1,0x11
This removes more than 30,000 instructions from the Go binary and
should improve performance in a variety of areas - of note
runtime.makemap_small drops from 48 to 36 instructions. Similar
gains exist in at least other parts of runtime and math/bits.
Change-Id: I33f6f3d1fd36d9ff1bda706997162bfe4bb859b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/350689
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Munday <mike.munday@lowrisc.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Add tests for shift by constant, masked shifts and bounded shifts. While here,
sort tests by architecture and keep order of tests consistent (lsh, rshU, rsh).
Change-Id: I512d64196f34df9cb2884e8c0f6adcf9dd88b0fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/351289
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Munday <mike.munday@lowrisc.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
So after constructing "args" variable, "gcflags" is not used anywhere.
It makes the code easier to maintain, and prevent subtle bug like #48490.
Change-Id: I41653536480880a8a6f9fbf6cfa8a461b6fb3208
Reviewed-on: https://go-review.googlesource.com/c/go/+/351849
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Also: improve some error message prints in testSyntaxErrors.
Change-Id: Iaa1d642398fa82975fefb4bde54f476dd5229eb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/351791
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a clean port of CL 351969 from types2 to go/types
with a minor adjustment for error handling (provide an error
code).
For #46461.
Change-Id: I493dde12d8ccf86aa33f4913ac6e82f2eb459088
Reviewed-on: https://go-review.googlesource.com/c/go/+/351971
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The constraint packages defined a set of useful constraints to be used
with type parameters.
Fixes#45458
Change-Id: Id4f4e6c55debb90e6b10ea0dbe2319be1e888746
Reviewed-on: https://go-review.googlesource.com/c/go/+/349709
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We cannot determine the underlying type right when parsing
a union term since it may lead to types that are not yet
fully set up.
Fixes#46461.
Change-Id: I1fcadb1dcef2160be2f088a4a34e99dbab01da67
Reviewed-on: https://go-review.googlesource.com/c/go/+/351969
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>
The test checks that two packages aren't non-test dependencies.
There's a copy-paste typo, however.
When net/http is unexpectedly found as a dependendency,
we instead mention the other package in the error message.
Change-Id: I3232c6252255c839e08efa048f2232c192d0fb85
Reviewed-on: https://go-review.googlesource.com/c/go/+/351372
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The cmd/go bug this worked around should be fixed as of CL 351329.
Fixes#43938Fixes#48550
Change-Id: Ida930e7ee33d44d89556b9b8bbc3c26bb53697b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/351529
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For #33232.
Change-Id: Id95a92bfdad91e3ccde9f5654c3b1b02ca95f6ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/351731
Trust: Robert Griesemer <gri@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Agressively mark all LHS variables in assignments as used if there
is any error in the (entire) assignment. This reduces the number of
spurious "declared but not used" errors in programs that are invalid
in the first place. This behavior is closer to the behavior of the
compiler's original type checker (types1) and lets us remove lines
of the form "_ = variable" just to satisfy test cases. It also makes
more important errors visible by not crowding them out.
Remove the Checker.useLHS function and use Checker.use instead:
useLHS didn't evaluate top-level variables, but we actually want
them to be evaluated in an error scenario so that they are getting
used (and thus we don't get the "declared but not used" error).
Fixes#42937.
Change-Id: Idda460f6b81c66735bf9fd597c54188949bf12b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/351730
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 partial port of CL 351669 from types2 to go/types; it
only copies the fix for variable usage.
Eventually we may want to use the compiler error messages for assignment
errors everywhere, but that doesn't need to happen now.
Change-Id: I62b024b1b29cc27c29d919de3de44f944f6e2b4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/351670
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 used with the compiler, types2 will report assignment error
messages that closely match what the compiler type checker (types1)
produces.
Also, mark lhs variables as used in invalid variable initializations
to avoid a class of follow-on errors.
Fixes#48558.
Change-Id: I92d1de006c66b3a2364bb1bea773a312963afe75
Reviewed-on: https://go-review.googlesource.com/c/go/+/351669
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 reverts commit abbfec2829.
Reason to revert: breaks darwin builders.
Updates #48319
Change-Id: I50c957a6a3f46ffcdaf972bdbb0574867ddc9486
Reviewed-on: https://go-review.googlesource.com/c/go/+/351851
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Checker.validType was not considering Unions when looking for illegal
cycles.
Fixes#48582
Change-Id: I11ad0279eeaaa56bb6d5731b0572c1c3a0c459eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/351829
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>
For architectures without a specialized implementation (e.g. arm),
the generic implementation allocates because it does:
var block = blockGeneric
which causes the compiler to give up trying to analyze block
even though it is technically only ever one implementation.
Instead of a variable, declare a function that wraps blockGeneric.
We apply this fix to md5, sha1, and sha256,
while sha512 already had the equivalent change.
We add a test to all hashing packages to ensure no allocations.
Credit goes to Cuong Manh Le for more specifically identifying
the problem and Keith Randal for suggesting a concrete solution.
Fixes#48055
Change-Id: I1a6a2e028038e051c83fd72b10a8bf4d210df57d
Reviewed-on: https://go-review.googlesource.com/c/go/+/346209
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
While reading the help text for #48576,
I noticed that the output was misaligned.
Turns out it's because two lines have space indentation,
while the rest use tab indentation. Fix that.
Change-Id: Ie7c473d892ca13852fa2134f3cdef21e9210e02e
Reviewed-on: https://go-review.googlesource.com/c/go/+/351750
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This adds support for duffcopy on ppc64x and updates the
ssa/config.go file to enable register args and recognize
the duffDevice is available on ppc64x.
Change-Id: Ifc472cc9cc19c9a80e468fb52078c75f7dd44d36
Reviewed-on: https://go-review.googlesource.com/c/go/+/351490
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
There are some absolute paths in the object file of the packages include C files. The path in C objects file can't be rewritten by linker. The goroot must be used as input for the hash when the packages include C files. So that the debug_info of the binary is correctly.
Fixes#48319
Change-Id: I659a3d6d71c4e49fff83f5bcf53a0a417e552a93
Reviewed-on: https://go-review.googlesource.com/c/go/+/348991
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Trust: Jay Conrod <jayconrod@google.com>
Break and continue for range loops was accepted as a proposal in June 2017.
It was implemented in CL 66410 (Oct 2017)
but then rolled back in CL 92155 (Feb 2018)
because html/template changes had not been implemented.
This CL reimplements break and continue in text/template
and then adds support for them in html/template as well.
Fixes#20531.
Change-Id: I05330482a976f1c078b4b49c2287bd9031bb7616
Reviewed-on: https://go-review.googlesource.com/c/go/+/321491
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Like other builtin functions, unsafe.Add's len operand is allowed to
be variable sized. However, unlike other builtins, it doesn't get
lowered to a runtime function call, so we never end up coercing it to
a specific type. As a result, we could end up constructing an OpAddPtr
value but with a less-than-ptr-sized addend operand.
This CL fixes this by always coercing the second operand to uintptr
during SSA construction.
Theoretically, we could do this during walk instead, but the frontend
doesn't allow converting negative constants to uintptr.
Fixes#48536.
Change-Id: Ib0619ea79df58b256b250fec967a6d3c8afea631
Reviewed-on: https://go-review.googlesource.com/c/go/+/351592
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Create constant LocalDictName for the pname/refix for dictionary
parameters or local variables, and constant GlobalDictPrefix for the
prefix for names of global dictionaries. I wanted to make sure these
constants were set up as we add more reference to dictionaries for
debugging, etc.
Change-Id: Ide801f842383300a2699c96943ec06decaecc358
Reviewed-on: https://go-review.googlesource.com/c/go/+/351450
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>
Reviewed-by: Than McIntosh <thanm@google.com>
In go test vet=x, x should be off, all, or one of the analyses supported
by vet. All other flags should not be passed to vet. This CL maintains a
list of supported vet analyzers by running go tool vet -flags and
parsing the flag info to figure out the names of the supported analyzers
and their aliases.
Fixes#47309
Change-Id: I16ade8024301ad4aee5ad45aa92cf63b63dbc2d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/341334
Trust: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Zvonimir Pavlinovic <zpavlinovic@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Allow the CALL ops to take variable number of arguments.
Change-Id: I6753c2fcb434ce2ebbce51dd595fbcbb39a60bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/351589
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Change-Id: Ie23a9f1300a803d9c713e82b0d892dd90333ca7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/351371
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
