cmd/compile: Struct parameter leaks to return values despite copying field #80806

Activity

1. gopherbot

   added

   compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.

   on Aug 10, 2026
2. github-project-automation

   added this to Go Compiler / Runtime / Commandon Aug 10, 2026
3. gabyhelp commented on Aug 10, 2026

   

   gabyhelp

   on Aug 10, 2026

   More actions

   Related Issues

   • cmd/compile: `b.Loop` un-optimizer regression heap allocate objects passed to non-leaky functions it used to stack allocate #76482 (closed)
   • cmd/compile: escape analysis report mismatch with allocations #36083 (closed)
   • cmd/compile: unclear escape analysis #36504 (closed)
   • cmd/compile: function argument value escapes no matter the run-time condition #42781
   • cmd/compile: field access on struct-returning method copies entire struct #77720 (closed)
   • cmd/compile: escape analysis doesn't work for the function which has leaking params, level < 0 #17458 (closed)
   • cmd/compile: escape analysis does't treat reflect header correctly #39497 (closed)
   • cmd/compile: returning arguments should not cause their escape #32019 (closed)
   • cmd/compile: escape analysis miss #12588 (closed)
   • cmd/compile: improve escape analysis understanding of tree structures #14858

   _{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}
4. randall77 commented on Aug 10, 2026

   

   randall77

   on Aug 10, 2026

   Contributor

   More actions

   Unfortunately our current escape analysis is not that precise. We treat entire variables as single units, without distinguishing anything about the individual fields in a variable of compound type. So we don't know the difference between l.Val and l.RandomPtr anywhere in the code (assigning to it, or reading from it).

   This might be fixable, but would certainly take some work, and some compile time space/speed. I believe this choice was made when first doing escape analysis because it was the best bang for the buck. Maybe an analysis of both where we might still find benefits, and what the compile-time costs might be, would help decide if adding additional complexity would be worth it.
5. randall77

   added this to the Unplanned milestone on Aug 10, 2026
6. randall77

   added

   Performance

   on Aug 10, 2026
7. nicholasngai commented on Aug 11, 2026

   

   nicholasngai

   on Aug 11, 2026

   Last edited by nicholasngai

   Author

   More actions

   Thanks for the response! That’s helpful to know!

   Out of curiosity, why do *struct{}, error, and string values embedded in the struct all cause the ~r0 ← l flow, but passing int64 doesn’t? Is it because things with pointers (interfaces, pointers, and strings) all have the potential to point to the parent struct, but value types like int64 don’t?

   package main
   
   import (
   	"testing"
   )
   
   type Val struct {
   	Val       int64
   	RandomInt int64
   }
   
   type PtrVal struct {
   	Val       *int64
   	RandomInt int64
   }
   
   func BenchmarkTest(b *testing.B) {
   	for b.Loop() {
   		foo()
   	}
   }
   
   //go:noinline
   func foo() Val {
   	l := PtrVal{Val: new(int64)}
   	if l.RandomInt != 0 {
   		return Val{RandomInt: l.RandomInt}
   	}
   	return Val{Val: *l.Val}
   }

   ./main_test.go:25:22: new(int64) does not escape
   
8. randall77 commented on Aug 11, 2026

   

   randall77

   on Aug 11, 2026

   Contributor

   More actions

   Escape analysis only tracks types with pointers. Val{RandomInt: l.RandomInt} is a read from l, but it has a pointer-free type so escape analysis knows no pointers can escape via returning that type.
9. nicholasngai commented on Aug 11, 2026

   

   nicholasngai

   on Aug 11, 2026

   Last edited by nicholasngai

   Author

   More actions

   Sounds good. Sounds like the best workaround for now would just be to track these as multiple variables instead of lumping them together as a struct then?

   For context, my real code looks something like

   type Value[T] struct {
   	Val T
   	Err error
   }

   Basically a tuple of T and error, to handle error propagation and codegen more easily for a transpiler I’m writing. Writing the transpiler output errors variables is not impossible but just somewhat involved lol.
10. dr2chase

    added

    NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    on Aug 24, 2026
11. hazyhaar commented on Aug 29, 2026

    

    hazyhaar

    on Aug 29, 2026

    More actions

    Here is the exact compiler mechanism causing this unexpected heap escape, what Go 1.28 could improve, and how to avoid the allocation today.

    1. The Compiler Mechanism & Discrepancy

    The issue stems from the lack of field-sensitivity in Go's escape analysis solver (cmd/compile/internal/escape/solve.go and leaks.go):

    • When evaluating l := PtrWithPtr{Val: new(int64)}, the escape analysis builds a flow graph where new(int64) is linked to the aggregate node representing l.
    • When evaluating l.RandomPtr in return ValWithPtr{RandomPtr: l.RandomPtr}, the flow solver connects the entire aggregate l to the return value ~r0 (coarse-grained aggregate flow).
    • Because l as a whole is marked as flowing to the return, all pointer-containing fields assigned into l (including l.Val = new(int64)) transitively inherit the escape to heap (EscHeap), even though l.Val is never returned.

    2. Proposed Realignment for Go 1.28

    Introduce field-sensitive flow tracking for non-address-taken struct values in escape/solve.go. Accessing l.FieldA should only propagate flow edges from FieldA rather than collapsing all fields of l into a single escape class.

    3. Immediate Workaround Rule (Today)

    To prevent the spurious heap escape on current Go versions, avoid bundling temporary heap allocations and returned pointers in the same aggregate, or unbundle the assignment into discrete local variables before constructing the struct:

    // WORKAROUND: Keep discrete local pointer variables before constructing structs
    //go:noinline
    func foo() ValWithPtr {
        val := new(int64) // 'val' stays on stack if its dereferenced value is returned
        var randomPtr *struct{}
    
        if randomPtr != nil {
            return ValWithPtr{RandomPtr: randomPtr}
        }
        return ValWithPtr{Val: *val} // 0 allocations, 'new(int64)' does not escape
    }