go/src/cmd, branch fix-runtime-test-GOMAXPROCS

cmd/internal/obj: enable got pcrel itype in fips140 for riscv64

2025-07-20T04:15:12Z

This CL enable R_RISCV_GOT_PCREL_ITYPE in fips140 Fixes #74662 Change-Id: Ic189c4e352517ae74034f207a5f944b610f2eb73 Reviewed-on: https://go-review.googlesource.com/c/go/+/688635 Reviewed-by: Mark Ryan Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Carlos Amedee Reviewed-by: Julian Zhu

cmd/compile/internal/ssa: restrict architectures for TestDebugLines_74576

2025-07-19T12:33:40Z

CL 687815 recently added TestDebugLines_74576. The pre-existing debug_lines_test.go file generally restricts the tested architectures and contains multiple warnings that the testing approach is useful but fragile, such as: "These files must all be short because this is super-fragile." Despite that, initially I wanted to see what happened on the different architectures on the trybots in case it might show something surprising, and I let TestDebugLines_74576 run on all architectures. That seemed to initially work, but the test is now failing on a linux/risc64 builder (#74669), so it is likely more prudent to be more conservative and restrict the platforms like many of the other pre-existing tests, which is what this CL now does. Fixes #74669 Change-Id: I9e5a7d3ee901f58253cf72e03c2239df338479e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/688856 Auto-Submit: Keith Randall Reviewed-by: Keith Randall LUCI-TryBot-Result: Go LUCI Reviewed-by: Keith Randall Reviewed-by: David Chase

go/types: infer correct type for y in append(bytes, y...)

2025-07-18T18:13:45Z

The type-checking logic for append has a special case for append(bytes, s...) where the typeset for s contains string. However, this case was triggering even when the typeset contained only []byte, causing the creation of Signature types of the form func([]byte, Y) []byte, with the variadic flag set, where Y is the type of Y (e.g. a type parameter constrained to ~[]byte). This is an illegal combination: a variadic signature's last parameter must be a slice, or its typeset must contain string. This caused x/tools/go/ssa to crash. This CL narrows the special case to only typesets that contain string, and adds a test for the inferred signature. (There's little point in testing that a subsequent NewSignatureType call would succeed, because the inferred type plainly has no free type parameters.) Fixes #73871 Change-Id: Id7641104133371dd6b0077f281cdaa9db84cc1c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/688815 Reviewed-by: Mark Freeman LUCI-TryBot-Result: Go LUCI

cmd/compile/internal/escape: improve DWARF .debug_line numbering for literal rewriting optimizations

2025-07-17T10:41:36Z

The literal rewriting optimizations to reduce user allocations that were implemented in CL 649079 and related CLs like CL 684116 could produce .debug_line tables such that the line numbers sometimes jumped back to a variable's declaration. This CL adjusts the positions of the IR nodes to avoid this. For the first test added here in i74576a.go: 11 func main() { 12 a := 1 13 runtime.Breakpoint() 14 sink = a 15 } Without this fix, the test reports debug lines of 12, 13, 13, 12, 14. Note it goes backwards from 13 to a second 12. With this fix, the test reports debug lines of 12, 13, 13, 14 without going backwards. The test added in i74576b.go creates a slice via make with a non-constant argument, which similarly shows debug lines going backwards before this fix but not after. To address the slice make case, we create a new BasicLit node to then set its position. There were some related allocation optimizations for struct literals such as CL 649555 during the Go 1.25 dev cycle, but at least in some basic test cases, those optimizations did not seem to produce debug line issues. The struct literal interface conversion test added in i74576c.go has the same behavior before and after this change. Finally, running 'go test ./...' in the delve repo root (4a2a6e1aeb) seems to have many failures with go1.25rc2, but seems to pass with this CL. Fixes #74576 Updates #71359 Change-Id: I31faf5fe4bb352fdcd06bdc8606dbdbc4bbd65f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/687815 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase Reviewed-by: Alessandro Arzilli Reviewed-by: Keith Randall

cmd/compile/internal/escape: speed up analyzing some functions with many closures

2025-07-16T15:52:56Z

Escape analysis examines functions in batches. In some cases, closures are in the same batch as their parent function, but in other cases, the closures are in different batches. This can mean the per-batch ir.ReassignOracle cache is not as effective. For example, #74615 has 4,000 closures in a single function that are all in different batches. For that example, these caches had an ~80% hit rate. This CL makes the ir.ReassignOracle cache more broadly scoped, instead of per batch. This speeds up escape analysis when a function has many closures that end up in different batches, including this resolves #74615. For that example, this cache now has a ~100% hit rate. In addition, in (*batch).rewriteWithLiterals, we also slightly delay checking the ir.ReassignOracle cache, which is more natural to do now compared to when rewriteWithLiterals was first merged. This means we can avoid consulting or populating the cache in more cases. (We also leave a new type-related TODO there. If we were to also implement that TODO, a quick test suggests we could independently resolve the specific example in #74615 even without making the cache more broadly scoped, though other conceivable examples would not be helped; the scoping of the cache is the more fundamental improvement.) If we look at cumulative time spent via pprof for the #74615 example using this CL, the work of ir.ReassignOracle escape analysis cache now typically shows zero cpu samples. This CL passes "go build -toolexec 'toolstash -cmp' -a std cmd". Fixes #74615 Change-Id: I3c17c527fbb546ffb8a4fa52cd61e41ff3cdb869 Reviewed-on: https://go-review.googlesource.com/c/go/+/688075 Auto-Submit: Keith Randall Reviewed-by: Cherry Mui Reviewed-by: Keith Randall Reviewed-by: Keith Randall LUCI-TryBot-Result: Go LUCI

cmd/link, runtime: on Wasm, put only function index in method table and func table

2025-07-16T14:15:42Z

In the type descriptor's method table, it contains relative PCs of the methods (relative to the start of the text section) stored as 32-bit offsets. On Wasm, a PC is PC_F<<16 + PC_B, where PC_F is the function index, and PC_B is the block index. When there are more than 65536 functions, the PC will not fit into 32-bit (and relative to the section start doesn't help). Since there are no more bits for the function index, and the method table always targets the entry of a method, we put just the PC_F there, and rewrite back to a full PC at run time when we need the PC. This way we can have more than 65536 functions. The func table also contains 32-bit relative PCs, and it also always points to function entries. Do the same there, as well as other places where we use relative text offsets. Also add the relocation type in the relocation overflow error message. Also add check for function too big on Wasm. If a function has more than 65536 blocks, PC_B will overflow and PC = PC_F<<16 + PC_B will points to the wrong function. Fixes #64856. Change-Id: If9c307e9fb1641f367a5f19c39f88f455805d0bb Reviewed-on: https://go-review.googlesource.com/c/go/+/552835 Reviewed-by: Than McIntosh Reviewed-by: Dmitri Shuralyov LUCI-TryBot-Result: Go LUCI

cmd/internal/obj/wasm: use 64-bit instructions for indirect calls

2025-07-16T14:14:59Z

Currently, on Wasm, an indirect call is compiled to // function index = PC>>16, PC is already on stack I32WrapI64 I32Const $16 ShrU // set PC_B to 0 ... // actual call CallIndirect Specifically, the function index is extracted from bits 16-31 of the "PC". When there are more than 65536 functions, this will overflow and wrap around, causing wrong function being called. This CL changes it to use 64-bit operations to extract the function index from the "PC", so there are enough bits to for it. For #64856. Change-Id: I83c11db4b78cf66250e88ac02a82bd13730a8914 Reviewed-on: https://go-review.googlesource.com/c/go/+/567896 LUCI-TryBot-Result: Go LUCI Reviewed-by: Than McIntosh Reviewed-by: Dmitri Shuralyov

cmd/internal/doc: upgrade godoc pkgsite to 01b046e

2025-07-15T21:51:11Z

Increase the dependency on the doc tool to bring in the fixes to CL 687918 and CL 687976. Fixes golang/go#74459 Change-Id: I9cdefdfd9792a142ad14bae3d4f7bb9d8256a246 Reviewed-on: https://go-review.googlesource.com/c/go/+/687997 Reviewed-by: Jonathan Amsterdam LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Matloob

cmd/link: do size fixups after symbol references are loaded

2025-07-11T14:32:16Z

When we do a size fixup, we need to clone the symbol to an external symbol so we can modify it. This includes cloning the relocations, which includes resolving the relocations. If the symbol being fixed has a relocation referencing a non-Go symbol, that symbol has not yet been created, it will be resolved to an empty symbol. Load the references first, so the referenced symbol, even if it is a non-Go symbol, exists. Fixes #74537. Change-Id: I81525bd7c3e232b80eefeb0f18e13ba5331e1510 Reviewed-on: https://go-review.googlesource.com/c/go/+/687315 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase

cmd/go: disable support for multiple vcs in one module

2025-07-08T18:30:38Z

Removes the somewhat redundant vcs.FromDir, "allowNesting" argument, which was always enabled, and disallow multiple VCS metadata folders being present in a single directory. This makes VCS injection attacks much more difficult. Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior. Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue. Fixes #74380 Fixes CVE-2025-4674 Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789 Reviewed-on: https://go-review.googlesource.com/c/go/+/686515 LUCI-TryBot-Result: Go LUCI Reviewed-by: David Chase Commit-Queue: Carlos Amedee Reviewed-by: Carlos Amedee