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

internal/testenv: exclude GOMAXPROCS when building test program

2025-07-20T06:09:31Z

In the environment where GOMAXPROCS set explicitly, for example to 3 in shell profile, the runtime tests will fail with the following error, ---- ok regexp/syntax 0.428s --- FAIL: TestCgroupGOMAXPROCS (0.81s) crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe crash_test.go:208: built testprog in 796.664277ms --- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s) cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok cgroup_linux_test.go:63: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s) cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok cgroup_linux_test.go:85: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s) cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok cgroup_linux_test.go:105: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSRound (0.01s) --- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s) cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok cgroup_linux_test.go:232: output got "3\n" want "2\n" FAIL FAIL runtime 23.088s ---- This changes exclude the GOMAXPROCS when building program for testing so it does not affect the tests. Change-Id: I590d9eca57026539413cf4c93b37f624f179d534

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

os: revert the use of AddCleanup to close files and roots

2025-07-18T21:43:56Z

This reverts commit fdaac84480b02e600660d0ca7c15339138807107. Updates #70907 Updates #74574 Updates #74642 Reason for revert: Issue #74574 Change-Id: I7b55b85736e4210d9b6f3fd7a24050ac7bdefef9 Reviewed-on: https://go-review.googlesource.com/c/go/+/688435 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek

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

runtime: fix idle time double-counting bug

2025-07-16T20:31:59Z

This change fixes a bug in the accounting of sched.idleTime. In just the case where the GC CPU limiter needs up-to-date data, sched.idleTime is incremented in both the P-idle-time and idle-mark-work paths, but it should only be incremented in the former case. Fixes #74627. Change-Id: If41b03da102d47d25bec48ff750a9da27019b71d Reviewed-on: https://go-review.googlesource.com/c/go/+/687998 Reviewed-by: Cherry Mui LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Pratt

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

runtime: use 32-bit function index on Wasm

2025-07-16T14:15:29Z

Following CL 567896, this is one more place we used only 16 bits for the function index. Change it to load 32 bits. For #64856. Change-Id: I66a78c086e67165604053313751c097a70c50ba9 Reviewed-on: https://go-review.googlesource.com/c/go/+/609118 LUCI-TryBot-Result: Go LUCI Reviewed-by: Michael Knyszek