aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/internal/objabi
AgeCommit message (Collapse)Author
2023-12-06iter, runtime: add coroutine supportRuss Cox
The exported API is only available with GOEXPERIMENT=rangefunc. This will let Go 1.22 users who want to experiment with rangefuncs access an efficient implementation of iter.Pull and iter.Pull2. For #61897. Change-Id: I6ef5fa8f117567efe4029b7b8b0f4d9b85697fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/543319 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-12-05math/rand, math/rand/v2: use ChaCha8 for global randRuss Cox
Move ChaCha8 code into internal/chacha8rand and use it to implement runtime.rand, which is used for the unseeded global source for both math/rand and math/rand/v2. This also affects the calculation of the start point for iteration over very very large maps (when the 32-bit fastrand is not big enough). The benefit is that misuse of the global random number generators in math/rand and math/rand/v2 in contexts where non-predictable randomness is important for security reasons is no longer a security problem, removing a common mistake among programmers who are unaware of the different kinds of randomness. The cost is an extra 304 bytes per thread stored in the m struct plus 2-3ns more per random uint64 due to the more sophisticated algorithm. Using PCG looks like it would cost about the same, although I haven't benchmarked that. Before this, the math/rand and math/rand/v2 global generator was wyrand (https://github.com/wangyi-fudan/wyhash). For math/rand, using wyrand instead of the Mitchell/Reeds/Thompson ALFG was justifiable, since the latter was not any better. But for math/rand/v2, the global generator really should be at least as good as one of the well-studied, specific algorithms provided directly by the package, and it's not. (Wyrand is still reasonable for scheduling and cache decisions.) Good randomness does have a cost: about twice wyrand. Also rationalize the various runtime rand references. goos: linux goarch: amd64 pkg: math/rand/v2 cpu: AMD Ryzen 9 7950X 16-Core Processor │ bbb48afeb7.amd64 │ 5cf807d1ea.amd64 │ │ sec/op │ sec/op vs base │ ChaCha8-32 1.862n ± 2% 1.861n ± 2% ~ (p=0.825 n=20) PCG_DXSM-32 1.471n ± 1% 1.460n ± 2% ~ (p=0.153 n=20) SourceUint64-32 1.636n ± 2% 1.582n ± 1% -3.30% (p=0.000 n=20) GlobalInt64-32 2.087n ± 1% 3.663n ± 1% +75.54% (p=0.000 n=20) GlobalInt64Parallel-32 0.1042n ± 1% 0.2026n ± 1% +94.48% (p=0.000 n=20) GlobalUint64-32 2.263n ± 2% 3.724n ± 1% +64.57% (p=0.000 n=20) GlobalUint64Parallel-32 0.1019n ± 1% 0.1973n ± 1% +93.67% (p=0.000 n=20) Int64-32 1.771n ± 1% 1.774n ± 1% ~ (p=0.449 n=20) Uint64-32 1.863n ± 2% 1.866n ± 1% ~ (p=0.364 n=20) GlobalIntN1000-32 3.134n ± 3% 4.730n ± 2% +50.95% (p=0.000 n=20) IntN1000-32 2.489n ± 1% 2.489n ± 1% ~ (p=0.683 n=20) Int64N1000-32 2.521n ± 1% 2.516n ± 1% ~ (p=0.394 n=20) Int64N1e8-32 2.479n ± 1% 2.478n ± 2% ~ (p=0.743 n=20) Int64N1e9-32 2.530n ± 2% 2.514n ± 2% ~ (p=0.193 n=20) Int64N2e9-32 2.501n ± 1% 2.494n ± 1% ~ (p=0.616 n=20) Int64N1e18-32 3.227n ± 1% 3.205n ± 1% ~ (p=0.101 n=20) Int64N2e18-32 3.647n ± 1% 3.599n ± 1% ~ (p=0.019 n=20) Int64N4e18-32 5.135n ± 1% 5.069n ± 2% ~ (p=0.034 n=20) Int32N1000-32 2.657n ± 1% 2.637n ± 1% ~ (p=0.180 n=20) Int32N1e8-32 2.636n ± 1% 2.636n ± 1% ~ (p=0.763 n=20) Int32N1e9-32 2.660n ± 2% 2.638n ± 1% ~ (p=0.358 n=20) Int32N2e9-32 2.662n ± 2% 2.618n ± 2% ~ (p=0.064 n=20) Float32-32 2.272n ± 2% 2.239n ± 2% ~ (p=0.194 n=20) Float64-32 2.272n ± 1% 2.286n ± 2% ~ (p=0.763 n=20) ExpFloat64-32 3.762n ± 1% 3.744n ± 1% ~ (p=0.171 n=20) NormFloat64-32 3.706n ± 1% 3.655n ± 2% ~ (p=0.066 n=20) Perm3-32 32.93n ± 3% 34.62n ± 1% +5.13% (p=0.000 n=20) Perm30-32 202.9n ± 1% 204.0n ± 1% ~ (p=0.482 n=20) Perm30ViaShuffle-32 115.0n ± 1% 114.9n ± 1% ~ (p=0.358 n=20) ShuffleOverhead-32 112.8n ± 1% 112.7n ± 1% ~ (p=0.692 n=20) Concurrent-32 2.107n ± 0% 3.725n ± 1% +76.75% (p=0.000 n=20) goos: darwin goarch: arm64 pkg: math/rand/v2 │ bbb48afeb7.arm64 │ 5cf807d1ea.arm64 │ │ sec/op │ sec/op vs base │ ChaCha8-8 2.480n ± 0% 2.429n ± 0% -2.04% (p=0.000 n=20) PCG_DXSM-8 2.531n ± 0% 2.530n ± 0% ~ (p=0.877 n=20) SourceUint64-8 2.534n ± 0% 2.533n ± 0% ~ (p=0.732 n=20) GlobalInt64-8 2.172n ± 1% 4.794n ± 0% +120.67% (p=0.000 n=20) GlobalInt64Parallel-8 0.4320n ± 0% 0.9605n ± 0% +122.32% (p=0.000 n=20) GlobalUint64-8 2.182n ± 0% 4.770n ± 0% +118.58% (p=0.000 n=20) GlobalUint64Parallel-8 0.4307n ± 0% 0.9583n ± 0% +122.51% (p=0.000 n=20) Int64-8 4.107n ± 0% 4.104n ± 0% ~ (p=0.416 n=20) Uint64-8 4.080n ± 0% 4.080n ± 0% ~ (p=0.052 n=20) GlobalIntN1000-8 2.814n ± 2% 5.643n ± 0% +100.50% (p=0.000 n=20) IntN1000-8 4.141n ± 0% 4.139n ± 0% ~ (p=0.140 n=20) Int64N1000-8 4.140n ± 0% 4.140n ± 0% ~ (p=0.313 n=20) Int64N1e8-8 4.140n ± 0% 4.139n ± 0% ~ (p=0.103 n=20) Int64N1e9-8 4.139n ± 0% 4.140n ± 0% ~ (p=0.761 n=20) Int64N2e9-8 4.140n ± 0% 4.140n ± 0% ~ (p=0.636 n=20) Int64N1e18-8 5.266n ± 0% 5.326n ± 1% +1.14% (p=0.001 n=20) Int64N2e18-8 6.052n ± 0% 6.167n ± 0% +1.90% (p=0.000 n=20) Int64N4e18-8 8.826n ± 0% 9.051n ± 0% +2.55% (p=0.000 n=20) Int32N1000-8 4.127n ± 0% 4.132n ± 0% +0.12% (p=0.000 n=20) Int32N1e8-8 4.126n ± 0% 4.131n ± 0% +0.12% (p=0.000 n=20) Int32N1e9-8 4.127n ± 0% 4.132n ± 0% +0.12% (p=0.000 n=20) Int32N2e9-8 4.132n ± 0% 4.131n ± 0% ~ (p=0.017 n=20) Float32-8 4.109n ± 0% 4.105n ± 0% ~ (p=0.379 n=20) Float64-8 4.107n ± 0% 4.106n ± 0% ~ (p=0.867 n=20) ExpFloat64-8 5.339n ± 0% 5.383n ± 0% +0.82% (p=0.000 n=20) NormFloat64-8 5.735n ± 0% 5.737n ± 1% ~ (p=0.856 n=20) Perm3-8 26.65n ± 0% 26.80n ± 1% +0.58% (p=0.000 n=20) Perm30-8 194.8n ± 1% 197.0n ± 0% +1.18% (p=0.000 n=20) Perm30ViaShuffle-8 156.6n ± 0% 157.6n ± 1% +0.61% (p=0.000 n=20) ShuffleOverhead-8 124.9n ± 0% 125.5n ± 0% +0.52% (p=0.000 n=20) Concurrent-8 2.434n ± 3% 5.066n ± 0% +108.09% (p=0.000 n=20) goos: linux goarch: 386 pkg: math/rand/v2 cpu: AMD Ryzen 9 7950X 16-Core Processor │ bbb48afeb7.386 │ 5cf807d1ea.386 │ │ sec/op │ sec/op vs base │ ChaCha8-32 11.295n ± 1% 4.748n ± 2% -57.96% (p=0.000 n=20) PCG_DXSM-32 7.693n ± 1% 7.738n ± 2% ~ (p=0.542 n=20) SourceUint64-32 7.658n ± 2% 7.622n ± 2% ~ (p=0.344 n=20) GlobalInt64-32 3.473n ± 2% 7.526n ± 2% +116.73% (p=0.000 n=20) GlobalInt64Parallel-32 0.3198n ± 0% 0.5444n ± 0% +70.22% (p=0.000 n=20) GlobalUint64-32 3.612n ± 0% 7.575n ± 1% +109.69% (p=0.000 n=20) GlobalUint64Parallel-32 0.3168n ± 0% 0.5403n ± 0% +70.51% (p=0.000 n=20) Int64-32 7.673n ± 2% 7.789n ± 1% ~ (p=0.122 n=20) Uint64-32 7.773n ± 1% 7.827n ± 2% ~ (p=0.920 n=20) GlobalIntN1000-32 6.268n ± 1% 9.581n ± 1% +52.87% (p=0.000 n=20) IntN1000-32 10.33n ± 2% 10.45n ± 1% ~ (p=0.233 n=20) Int64N1000-32 10.98n ± 2% 11.01n ± 1% ~ (p=0.401 n=20) Int64N1e8-32 11.19n ± 2% 10.97n ± 1% ~ (p=0.033 n=20) Int64N1e9-32 11.06n ± 1% 11.08n ± 1% ~ (p=0.498 n=20) Int64N2e9-32 11.10n ± 1% 11.01n ± 2% ~ (p=0.995 n=20) Int64N1e18-32 15.23n ± 2% 15.04n ± 1% ~ (p=0.973 n=20) Int64N2e18-32 15.89n ± 1% 15.85n ± 1% ~ (p=0.409 n=20) Int64N4e18-32 18.96n ± 2% 19.34n ± 2% ~ (p=0.048 n=20) Int32N1000-32 10.46n ± 2% 10.44n ± 2% ~ (p=0.480 n=20) Int32N1e8-32 10.46n ± 2% 10.49n ± 2% ~ (p=0.951 n=20) Int32N1e9-32 10.28n ± 2% 10.26n ± 1% ~ (p=0.431 n=20) Int32N2e9-32 10.50n ± 2% 10.44n ± 2% ~ (p=0.249 n=20) Float32-32 13.80n ± 2% 13.80n ± 2% ~ (p=0.751 n=20) Float64-32 23.55n ± 2% 23.87n ± 0% ~ (p=0.408 n=20) ExpFloat64-32 15.36n ± 1% 15.29n ± 2% ~ (p=0.316 n=20) NormFloat64-32 13.57n ± 1% 13.79n ± 1% +1.66% (p=0.005 n=20) Perm3-32 45.70n ± 2% 46.99n ± 2% +2.81% (p=0.001 n=20) Perm30-32 399.0n ± 1% 403.8n ± 1% +1.19% (p=0.006 n=20) Perm30ViaShuffle-32 349.0n ± 1% 350.4n ± 1% ~ (p=0.909 n=20) ShuffleOverhead-32 322.3n ± 1% 323.8n ± 1% ~ (p=0.410 n=20) Concurrent-32 3.331n ± 1% 7.312n ± 1% +119.50% (p=0.000 n=20) For #61716. Change-Id: Ibdddeed85c34d9ae397289dc899e04d4845f9ed2 Reviewed-on: https://go-review.googlesource.com/c/go/+/516860 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-11-21cmd/internal/obj,cmd/link: access global data via GOT in -dynlink mode on ↵Guoqi Chen
loong64 Updates #58784 Change-Id: Ic98d10a512fea0c3ca321ab52693d9f6775126a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/480875 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Meidan Li <limeidan@loongson.cn> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: WANG Xuerui <git@xen0n.name>
2023-10-13cmd/internal/objabi: add inverse of PathToPrefixMichael Pratt
Add PrefixToPath, which can be used to convert a package path in a symbol name back to the original package path. For #61577. Change-Id: Ifbe8c852a7f41ff9b81ad48b92a26a0e1b046777 Reviewed-on: https://go-review.googlesource.com/c/go/+/529557 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-09-19cmd/internal/obj/riscv,cmd/link: rework riscv64 call relocationsJoel Sing
The riscv64 assembler and linker generate three types of calls. Most calls are made via a single JAL instruction, however this is limited to +/-1MB of text. In the case where a call target is unreachable (or unknown), the JAL targets an AUIPC+JALR trampoline. All other cases use AUIPC+JALR pairs, including the case where a single function exceeds 1MB in text size, potentially making it impossible to reach trampolines. Currently, the single instruction JAL call is marked with R_RISCV_CALL and the two instruction AUIPC+JALR call is marked with R_RISCV_PCREL_ITYPE, which is also used for memory load instructions. This means that we have no way to identify that the latter is a call. Switch to using R_RISCV_CALL to mark the AUIPC+JALR pair (aligning somewhat with the elf.R_RISCV_CALL, which is deprecated in favour of elf.R_RISCV_CALL_PLT). Add R_RISCV_JAL and use this to mark the single instruction JAL direct calls. This is clearer and allows us to map elf.R_RISCV_CALL_PLT to Go's R_RISCV_CALL. Add all three types to IsDirectCall, so that direct calls are correctly identified when a function exceeds 1MB of text. Fixes #62465 Change-Id: Id3eea09688a2b7d6e481eae9ed0aa0d1f9a3a48f Reviewed-on: https://go-review.googlesource.com/c/go/+/520095 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Than McIntosh <thanm@google.com>
2023-09-01cmd/internal/objabi: rename R_USEGENERICIFACEMETHOD to R_USENAMEDMETHOD.Dominique Lefevre
Now we have two cases when we want to keep methods with a specific name: calls to generic interface methods and MethodByName("Foo"). Both use the same relocation type, so let us give it a name that is not limited to the implementation of generic interfaces. Also, introduce staticdata.StrSymNoCommon(). It creates a symbol that does not appear in the final binary and only communicates arguments to the linker. Change-Id: Icc9f49febfde1f31a4455b5acb903e8838d1c0af Reviewed-on: https://go-review.googlesource.com/c/go/+/523016 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2023-08-23cmd/internal/obj/riscv,cmd/link: add support for internal cgo linking on riscv64Joel Sing
Make it possible to internally link cgo on riscv64, which also adds support for SDYNIMPORT calls without external linking being required. This reduces the time of an ./all.bash run on a Sifive Hifive Unleashed by approximately 20% (~140 minutes down to ~110 minutes). Change-Id: I43f1348de31672718ae8676cc82f6fdc1dfee054 Reviewed-on: https://go-review.googlesource.com/c/go/+/431104 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Than McIntosh <thanm@google.com>
2023-08-22cmd/internal/objabi,cmd/compile: move NoInstrumentPkgs and NoRacePkgs to ↵Austin Clements
PkgSpecials This consolidates the NoInstrumentPkgs and NoRacePkgs lists into the objabi.LookupPkgSpecial mechanism. Change-Id: I411654afdd690fb01c412e7e8b57ddfbe85415e3 Reviewed-on: https://go-review.googlesource.com/c/go/+/521702 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Austin Clements <austin@google.com>
2023-08-22cmd/internal/objabi: test runtime package listAustin Clements
This adds a test that all packages imported by runtime are marked as runtime tests by LookupPkgSpecial. We add two packages that were missing from the list. Change-Id: I2545980ab09474de0181cf546541527d8baaf2e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/521700 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-22cmd/compile,cmd/dist,cmd/go: compute -+ flag from package pathAustin Clements
As we did for the asm -compiling-runtime flag, this CL modifies the compiler to compute the -+ (compiling runtime) flag from the package path. Unlike for asm, some tests use -+ explicitly to opt in to runtime restrictions, so we leave the flag, but it's no longer passed by any build tools. This lets us eliminate cmd/go's list of "runtime packages" in favor of the unified objabi.LookupPkgSpecial. It also fixes an inconsistency with dist, which only passed -+ when compiling "runtime" itself. One consequence of this is that the compiler now ignores the -N flag when compiling runtime packages. Previously, cmd/go would strip -N when passing -+ and the compiler would fatal if it got both -N and -+, so the overall effect was that the compiler never saw -N when compiling a runtime package. Now we simply move that logic to disable -N down into the compiler. Change-Id: I4876047a1563210ed122a31b72d62798762cbcf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/521699 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2023-08-22cmd/internal/objabi: generalize "is runtime package" checkAustin Clements
There are several implementations of "is this package path a runtime package". They all have slightly different lists because they all care about slightly different properties of building the runtime. To start converging these, we replace objabi.IsRuntimePackagePath with objabi.LookupPkgSpecial, which returns a struct we can extend with various special build properties. We'll extend this with several other flags in the following CLs. Change-Id: I21959cb8c3d18a350d6060467681c72ea49af712 Reviewed-on: https://go-review.googlesource.com/c/go/+/521698 Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com>
2023-08-22cmd/asm,cmd/dist,cmd/go: remove asm -compiling-runtime flagAustin Clements
Currently, dist and go pass a -compiling-runtime flag to asm if they're compiling a runtime package. However, now that we always pass the package path to asm, it can make that determination just as well as its callers can. This CL moves that check into asm and drops the flag. This in turn makes dist's copy of IsRuntimePackagePath unnecessary, so we delete it. Change-Id: I6ecf2d50b5b83965012af34dbe5f9a973ba0778b Reviewed-on: https://go-review.googlesource.com/c/go/+/521697 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-08-10cmd/internal/objabi: add support for bisect.Matcher debug flagsMatthew Dempsky
Makes it more convenient to add new bisection targets. Change-Id: I7ac14018bac1e25751234a2267f8747a281b6088 Reviewed-on: https://go-review.googlesource.com/c/go/+/517616 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-08-03cmd/asm,cmd/internal/obj/riscv,cmd/link: improve TLS handling on riscv64Joel Sing
The existing Thread Local Storage (TLS) implementation for riscv64 uses initial-exec (IE) mode, however a MOV of a TLS symbol currently loads the thread pointer offset and not the actual address or memory location. Rework TLS on riscv64 to generate the full instruction sequence needed to load from or store to a TLS symbol. Additionally, provide support for both initial-exec (IE) and local-exec (LE) TLS - in many cases we can use LE, which is slightly more efficient and easier to support in the linker. Change-Id: I1b43f8888b3b6b10354bbb79d604771e64d92645 Reviewed-on: https://go-review.googlesource.com/c/go/+/431103 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: M Zhuo <mzh@golangcn.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Joel Sing <joel@sing.id.au>
2023-07-31runtime: refactor defer processingMatthew Dempsky
This CL refactors gopanic, Goexit, and deferreturn to share a common state machine for processing pending defers. The new state machine removes a lot of redundant code and does overall less work. It should also make it easier to implement further optimizations (e.g., TODOs added in this CL). Change-Id: I71d3cc8878a6f951d8633505424a191536c8e6b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/513837 Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-06-14all: fix spelling errorsAlexander Yastrebov
Fix spelling errors discovered using https://github.com/codespell-project/codespell. Errors in data files and vendored packages are ignored. Change-Id: I83c7818222f2eea69afbd270c15b7897678131dc GitHub-Last-Rev: 3491615b1b82832cc0064f535786546e89aa6184 GitHub-Pull-Request: golang/go#60758 Reviewed-on: https://go-review.googlesource.com/c/go/+/502576 Auto-Submit: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-05-23cmd/internal/objabi: regenerate RelocType stringsIan Lance Taylor
Change-Id: I6c9a8decb5b261be4548f148739b44e8860c5f8d Reviewed-on: https://go-review.googlesource.com/c/go/+/497595 Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-05-19cmd/compile: constant-fold loads from constant dictionaries and typesKeith Randall
Retrying the original CL with a small modification. The original CL did not handle the case of reading an itab out of a dictionary correctly. When we read an itab out of a dictionary, we must treat the type inside that itab as maybe being put in an interface. Original CL: 486895 Revert CL: 490156 Change-Id: Id2dc1699d184cd8c63dac83986a70b60b4e6cbd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/491495 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-21runtime, cmd: rationalize StackLimit and StackGuardAustin Clements
The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ia94094c5e47897e7c088d24b4a5e33f5c2768db5 Reviewed-on: https://go-review.googlesource.com/c/go/+/486976 Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-21internal/abi, runtime, cmd: merge StackSmall, StackBig consts into internal/abiAustin Clements
For #59670. Change-Id: I91448363be2fc678964ce119d85cd5fae34a14da Reviewed-on: https://go-review.googlesource.com/c/go/+/486975 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
2023-04-21internal/abi, runtime, cmd: merge PCDATA_* and FUNCDATA_* consts into ↵Austin Clements
internal/abi We also rename the constants related to unsafe-points: currently, they follow the same naming scheme as the PCDATA table indexes, but are not PCDATA table indexes. For #59670. Change-Id: I06529fecfae535be5fe7d9ac56c886b9106c74fd Reviewed-on: https://go-review.googlesource.com/c/go/+/485497 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-04-21internal/abi, runtime, cmd: merge funcFlag_* consts into internal/abiAustin Clements
For #59670. Change-Id: Ie784ba4dd2701e4f455e1abde4a6bfebee4b1387 Reviewed-on: https://go-review.googlesource.com/c/go/+/485496 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
2023-04-21internal/abi, runtime, cmd: merge funcID_* consts into internal/abiAustin Clements
For #59670. Change-Id: I517e97ea74cf232e5cfbb77b127fa8804f74d84b Reviewed-on: https://go-review.googlesource.com/c/go/+/485495 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
2023-04-20Revert "internal/abi, runtime, cmd: merge StackSmall, StackBig consts into ↵Austin Clements
internal/abi" This reverts commit CL 486379. Submitted out of order and breaks bootstrap. Change-Id: Ie20a61cc56efc79a365841293ca4e7352b02d86b Reviewed-on: https://go-review.googlesource.com/c/go/+/486917 TryBot-Bypass: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com>
2023-04-20Revert "runtime, cmd: rationalize StackLimit and StackGuard"Austin Clements
This reverts commit CL 486380. Submitted out of order and breaks bootstrap. Change-Id: I67bd225094b5c9713b97f70feba04d2c99b7da76 Reviewed-on: https://go-review.googlesource.com/c/go/+/486916 Reviewed-by: David Chase <drchase@google.com> TryBot-Bypass: Austin Clements <austin@google.com>
2023-04-20runtime, cmd: rationalize StackLimit and StackGuardAustin Clements
The current definitions of StackLimit and StackGuard only indirectly specify the NOSPLIT stack limit and duplicate a literal constant (928). Currently, they define the stack guard delta, and from there compute the NOSPLIT limit. Rationalize these by defining a new constant, abi.StackNosplitBase, which consolidates and directly specifies the NOSPLIT stack limit (in the default case). From this we then compute the stack guard delta, inverting the relationship between these two constants. While we're here, we rename StackLimit to StackNosplit to make it clearer what's being limited. This change does not affect the values of these constants in the default configuration. It does slightly change how StackGuardMultiplier values other than 1 affect the constants, but this multiplier is a pretty rough heuristic anyway. before after stackNosplit 800 800 _StackGuard 928 928 stackNosplit -race 1728 1600 _StackGuard -race 1856 1728 For #59670. Change-Id: Ibe20825ebe0076bbd7b0b7501177b16c9dbcb79e Reviewed-on: https://go-review.googlesource.com/c/go/+/486380 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-20internal/abi, runtime, cmd: merge StackSmall, StackBig consts into internal/abiAustin Clements
For #59670. Change-Id: I04a17079b351b9b4999ca252825373c17afb8a88 Reviewed-on: https://go-review.googlesource.com/c/go/+/486379 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-04-14cmd/link: establish dependable package initialization orderKeith Randall
(This is a retry of CL 462035 which was reverted at 474976. The only change from that CL is the aix fix SRODATA->SNOPTRDATA at inittask.go:141) As described here: https://github.com/golang/go/issues/31636#issuecomment-493271830 "Find the lexically earliest package that is not initialized yet, but has had all its dependencies initialized, initialize that package, and repeat." Simplify the runtime a bit, by just computing the ordering required in the linker and giving a list to the runtime. Update #31636 Fixes #57411 RELNOTE=yes Change-Id: I28c09451d6aa677d7394c179d23c2c02c503fc56 Reviewed-on: https://go-review.googlesource.com/c/go/+/478916 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-11cmd/internal/obj/loong64, cmd/internal/objabi, cmd/link: add support for ↵limeidan
--buildmode=c-shared on loong64 Updates #53301 Updates #58784 Change-Id: Ifcb40871f609531dfd8b568db9ac14da9b451742 Reviewed-on: https://go-review.googlesource.com/c/go/+/425476 Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Run-TryBot: WANG Xuerui <git@xen0n.name> Reviewed-by: abner chenc <chenguoqi@loongson.cn> Reviewed-by: WANG Xuerui <git@xen0n.name>
2023-04-05cmd/internal/obj: generate SEH aux symbols for windows/amd64qmuntal
This CL updates the Go compiler so it generate SEH unwind info [1] as a function auxiliary symbol when building for windows/amd64. A follow up CL will teach the Go linker how to assemble these codes into the PE .xdata section. Updates #57302 [1] https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64#struct-unwind_info Change-Id: I40ae0437bfee326c1a67c2b5e1496f0bf3ecea17 Reviewed-on: https://go-review.googlesource.com/c/go/+/461749 Reviewed-by: Davis Goodin <dagood@microsoft.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
2023-03-30all: add wasip1 definitionsJohan Brandhorst-Satzkorn
Add wasip1 GOOS definitions to the compiler and build definitions. Co-authored-by: Richard Musiol <neelance@gmail.com> Co-authored-by: Achille Roussel <achille.roussel@gmail.com> Co-authored-by: Julien Fabre <ju.pryz@gmail.com> Co-authored-by: Evan Phoenix <evan@phx.io> Change-Id: I087e7ff4205a34187bbca18b1693ad911ddd1219 Reviewed-on: https://go-review.googlesource.com/c/go/+/479616 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2023-03-29cmd/link,cmd/internal/objabi: support ADDR32NB relocations on windowsqmuntal
This CL updates the linker to support IMAGE_REL_[I386|AMD64|ARM|ARM64]_ADDR32NB relocations via the new R_PEIMAGEOFF relocation type. This relocation type references symbols using RVAs instead of VA, so it can use 4-byte offsets to reference symbols that would normally require 8-byte offsets. This new relocation is still not used, but will be useful when generating Structured Exception Handling (SEH) metadata, which needs to reference functions only using 4-byte addresses, thus using RVAs instead of VA is of great help. Updates #57302 Change-Id: I28d73e97d5cb78a3bc7194dc7d2fcb4a03f9f4d0 Reviewed-on: https://go-review.googlesource.com/c/go/+/461737 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> Reviewed-by: Davis Goodin <dagood@microsoft.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-09Revert "cmd/link: establish dependable package initialization order"Keith Randall
This reverts commit ce2a609909d9de3391a99a00fe140506f724f933. aka CL 462035 Reason for revert: this CL is causing some problems in some internal Google programs. Change-Id: I4476b8d8d2c3d7b5703d1d85c93baebb4b4e5d26 Reviewed-on: https://go-review.googlesource.com/c/go/+/474976 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2023-03-09Revert "cmd/internal/objabi: regenerate RelocType stringer file"Keith Randall
This reverts commit 99914db5eea927c7694276169585f1fff9e614c8. aka CL 473875 Reason for revert: init order change that required this CL is causing some problems in some internal Google programs. Change-Id: I801e278ab58d542c05c0332a9f1977b9588b6151 Reviewed-on: https://go-review.googlesource.com/c/go/+/474975 Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
2023-03-07cmd/internal/objabi: regenerate RelocType stringer fileqmuntal
reloctype_strings.go is out-of-date since CL 462035, regenerate it. Found while working on CL 461737. Change-Id: I5cf910ab14c3618d6653c87861a4d53d3c91feff Reviewed-on: https://go-review.googlesource.com/c/go/+/473875 Auto-Submit: Quim Muntal <quimmuntal@gmail.com> Run-TryBot: Quim Muntal <quimmuntal@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2023-03-03cmd/link: establish dependable package initialization orderKeith Randall
As described here: https://github.com/golang/go/issues/31636#issuecomment-493271830 "Find the lexically earliest package that is not initialized yet, but has had all its dependencies initialized, initialize that package, and repeat." Simplify the runtime a bit, by just computing the ordering required in the linker and giving a list to the runtime. Update #31636 Fixes #57411 RELNOTE=yes Change-Id: I1e4d3878ebe6e8953527aedb730824971d722cac Reviewed-on: https://go-review.googlesource.com/c/go/+/462035 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-01-17cmd/dist: make toolchain build reproducibleRuss Cox
- Build cmd with CGO_ENABLED=0. Doing so removes the C compiler toolchain from the reproducibility perimeter and also results in cmd/go and cmd/pprof binaries that are statically linked, so that they will run on a wider variety of systems. In particular the Linux versions will run on Alpine and NixOS without needing a simulation of libc.so.6. The potential downside of disabling cgo is that cmd/go and cmd/pprof use the pure Go network resolver instead of the host resolver on Unix systems. This means they will not be able to use non-DNS resolver mechanisms that may be specified in /etc/resolv.conf, such as mDNS. Neither program seems likely to need non-DNS names like those, however. macOS and Windows systems still use the host resolver, which they access without cgo. - Build cmd with -trimpath when building a release. Doing so removes $GOPATH from the file name prefixes stored in the binary, so that the build directory does not leak into the final artifacts. - When CC and CXX are empty, do not pick values to hard-code into the source tree and binaries. Instead, emit code that makes the right decision at runtime. In addition to reproducibility, this makes cross-compiled toolchains work better. A macOS toolchain cross-compiled on Linux will now correctly look for clang, instead of looking for gcc because it was built on Linux. - Convert \ to / in file names stored in .a files. These are converted to / in the final binaries, but the hashes of the .a files affect the final build ID of the binaries. Without this change, builds of a Windows toolchain on Windows and non-Windows machines produce identical binaries except for the input hash part of the build ID. - Due to the conversion of \ to / in .a files, convert back when reading inline bodies on Windows to preserve output file names in error messages. Combined, these four changes (along with Go 1.20's removal of installed pkg/**.a files and conversion of macOS net away from cgo) make the output of make.bash fully reproducible, even when cross-compiling: a released macOS toolchain built on Linux or Windows will contain exactly the same bits as a released macOS toolchain built on macOS. The word "released" in the previous sentence is important. For the build IDs in the binaries to work out the same on both systems, a VERSION file must exist to provide a consistent compiler build ID (instead of using a content hash of the binary). For #24904. Fixes #57007. Change-Id: I665e1ef4ff207d6ff469452347dca5bfc81050e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/454836 Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Russ Cox <rsc@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-18runtime,cmd/link: increase stack guard space when building with -raceKeith Randall
More stuff to do = more stack needed. Bump up the guard space when building with the race detector. Fixes #54291 Change-Id: I701bc8800507921bed568047d35b8f49c26e7df7 Reviewed-on: https://go-review.googlesource.com/c/go/+/451217 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-11-11all: fix problematic commentscui fliter
Change-Id: Ib6ea1bd04d9b06542ed2b0f453c718115417c62c Reviewed-on: https://go-review.googlesource.com/c/go/+/449755 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com>
2022-11-03cmd/link: support PPC64 prefixed relocations for power10Paul E. Murphy
Handle emitting (to ld) or resolving commonly used ELFv2 1.5 relocations. The new ISA provides PC relative addressing with 34 bit signed addresses, and many other relocations which can replace addis + d-form type relocations with a single prefixed instruction. Updates #44549 Change-Id: I7d4f4314d1082daa3938f4353826739be35b0e81 Reviewed-on: https://go-review.googlesource.com/c/go/+/355149 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Paul Murphy <murp@ibm.com>
2022-10-31cmd/compile: add ability to indicate 'concurrentOk' for debug flagsDavid Chase
Also removes no-longer-needed "Any" field from compiler's DebugFlags. Test/use case for this is the fmahash CL. Change-Id: I214f02c91f30fc2ce53caf75fa5e2b905dd33429 Reviewed-on: https://go-review.googlesource.com/c/go/+/445495 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: David Chase <drchase@google.com>
2022-10-28cmd/internal/obj/arm64: optimize ADRP+ADD+LD/ST to ADRP+LD/ST(offset)eric fang
This CL optimizes the sequence of instructions ADRP+ADD+LD/ST to the sequence of ADRP+LD/ST(offset). This saves an ADD instruction. The test result of compilecmp: name old text-bytes new text-bytes delta HelloSize 763kB ± 0% 755kB ± 0% -1.06% (p=0.000 n=20+20) name old data-bytes new data-bytes delta HelloSize 13.5kB ± 0% 13.5kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 227kB ± 0% 227kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.33MB ± 0% 1.33MB ± 0% -0.02% (p=0.000 n=20+20) file before after Δ % addr2line 3760392 3759504 -888 -0.024% api 5361511 5295351 -66160 -1.234% asm 5014157 4948674 -65483 -1.306% buildid 2579949 2579485 -464 -0.018% cgo 4492817 4491737 -1080 -0.024% compile 23359229 23156074 -203155 -0.870% cover 4823337 4756937 -66400 -1.377% dist 3332850 3331794 -1056 -0.032% doc 3902649 3836745 -65904 -1.689% fix 3269708 3268828 -880 -0.027% link 6510760 6443496 -67264 -1.033% nm 3670740 3604348 -66392 -1.809% objdump 4069599 4068967 -632 -0.016% pack 2374824 2374208 -616 -0.026% pprof 13874860 13805700 -69160 -0.498% test2json 2599210 2598530 -680 -0.026% trace 13231640 13162872 -68768 -0.520% vet 7360899 7292267 -68632 -0.932% total 113589131 112775517 -813614 -0.716% Change-Id: Ie1cf277e149ddd3f352d05fa0753d0ced7e0b894 Reviewed-on: https://go-review.googlesource.com/c/go/+/444715 Run-TryBot: Eric Fang <eric.fang@arm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
2022-09-27cmd/compile,cmd/link: hooks for identifying coverage countersThan McIntosh
Add a new "coverage counter" classification for variables to be used for storing code coverage counter values (somewhat in the same way that we identify fuzzer counters). Tagging such variables allows us to aggregate them in the linker, and to treat updates specially. Updates #51430. Change-Id: Ib49fb05736ffece98bcc2f7a7c37e991b7f67bbb Reviewed-on: https://go-review.googlesource.com/c/go/+/401235 Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-20all: replace package ioutil with os and io in srcAndy Pan
For #45557 Change-Id: I56824135d86452603dd4ed4bab0e24c201bb0683 Reviewed-on: https://go-review.googlesource.com/c/go/+/426257 Run-TryBot: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Andy Pan <panjf2000@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-09-16cmd/internal/objabi: record GO$GOARCH setting in object headerRuss Cox
The object header string is meant to record the relevant toolchain configuration, so that we don't import or link object files that are incompatible with each other. One important part of compatibility is the sub-architecture version (GOARM for GOARCH=arm, and so on). Add the sub-architecture info to the object header line so that binaries cannot be built that have inconsistent sub-architecture configurations across the build. This check is only important when the build system makes a mistake. Builds using the go command don't make this kind of mistake anymore, but we just debugged a difficult problem inside Google where a custom build system had built part of a program with GOARM=5 and part of a program with GOARM=7, resulting in corrupted execution when signal-based preemption was attempted. Updating the check will avoid this kind of problem in the future, in any custom build system, or if the go command makes a mistake. After this change: % sed 3q pkg/darwin_amd64/runtime.a !<arch> __.PKGDEF 0 0 0 644 30525 ` go object darwin amd64 devel go1.20-102ebe10b7 Wed Aug 17 14:31:01 2022 -0400 GOAMD64=v1 X:regabiwrappers,regabiargs % Change-Id: I901e0758f1002dd2c58292dc65e2d06da86e4495 Reviewed-on: https://go-review.googlesource.com/c/go/+/427174 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-09-13cmd/internal/objabi: declare HeadType String on a non-pointer receiverJoel Sing
objabi.HeadType is typically used as a non-pointer type, however the String function is declared on a pointer receiver. This means that in most cases its integer value is printed, rather than the value from the String function. Change-Id: I3d28d9680e88a714bc1152ed5e1df4ac43d7a33f Reviewed-on: https://go-review.googlesource.com/c/go/+/430556 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Jenny Rakoczy <jenny@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Jenny Rakoczy <jenny@golang.org>
2022-09-01cmd/internal/objabi: use strings.Builderhopehook
Since when go1.17 is now used for bootstraping. Change-Id: I5ee65aff72500a04e243238cffeae92ea659627b Reviewed-on: https://go-review.googlesource.com/c/go/+/427555 Auto-Submit: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: hopehook <hopehook@golangcn.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
2022-08-05cmd/dist: force stackGuardMultiplierDefault to 1Russ Cox
Nothing seems to break, not even the noopt builder. For #51256 (the conversation there is headed toward additional changes). Change-Id: Icb7ca451159a74f351c25d2cefb32c773b9bb017 Reviewed-on: https://go-review.googlesource.com/c/go/+/416859 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-20cmd/compile, cmd/link: use libFuzzer 8-bit instead of extra countersKhaled Yakdan
By using libFuzzer’s 8-bit counters instead of extra counters, the coverage instrumentation in libFuzzer mode is improved in three ways: 1- 8-bit counters are supported on all platforms, including macOS and Windows, with all relevant versions of libFuzzer, whereas extra counters are a Linux-only feature that only recently received support on Windows. 2- Newly covered blocks are now properly reported as new coverage by libFuzzer, not only as new features. 3- The NeverZero strategy is used to ensure that coverage counters never become 0 again after having been positive once. This resolves issues encountered when fuzzing loops with iteration counts that are multiples of 256 (e.g., larger powers of two). Change-Id: I9021210d7fbffd07c891ad08750402ee91cb3df5 GitHub-Last-Rev: 9057e4b21d146ce9ffb3993982bfb84b96705989 GitHub-Pull-Request: golang/go#51318 Reviewed-on: https://go-review.googlesource.com/c/go/+/387334 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org>
2022-05-02cmd/internal/objabi: define Go relocation types for loong64Xiaodong Liu
Contributors to the loong64 port are: Weining Lu <luweining@loongson.cn> Lei Wang <wanglei@loongson.cn> Lingqin Gong <gonglingqin@loongson.cn> Xiaolin Zhao <zhaoxiaolin@loongson.cn> Meidan Li <limeidan@loongson.cn> Xiaojuan Zhai <zhaixiaojuan@loongson.cn> Qiyuan Pu <puqiyuan@loongson.cn> Guoqi Chen <chenguoqi@loongson.cn> This port has been updated to Go 1.15.6: https://github.com/loongson/go Updates #46229 Change-Id: I8d31b3cd827325aa0ff748ca8c0c0da6df6ed99f Reviewed-on: https://go-review.googlesource.com/c/go/+/396734 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>