Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: wrong names during nested struct decomposition #19868

Closed
randall77 opened this issue Apr 6, 2017 · 6 comments
Closed

cmd/compile: wrong names during nested struct decomposition #19868

randall77 opened this issue Apr 6, 2017 · 6 comments

Comments

@randall77
Copy link
Contributor

import "runtime"

type T struct {
	x, y *int
}
type U struct {
	a, b T
}

func f(p *T) int {
	c := *p
	runtime.GC()
	return *c.x + *c.y
}
func g(p *U) int {
	c := *p
	runtime.GC()
	return *c.a.x + *c.b.y
}

The struct variable in f gets decomposed correctly. The generated code spills the two parts of c to stack slots named "c.x" and "c.y". We should get similar stack slots named "c.a.x" and "c.b.y" in g, but we don't. We just get autotmps.

@heschik @dr2chase @mdempsky

@randall77 randall77 added this to the Go1.9Maybe milestone Apr 6, 2017
@gopherbot
Copy link

CL https://golang.org/cl/40010 mentions this issue.

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.10 Jul 20, 2017
@heschi
Copy link
Contributor

heschi commented Oct 17, 2017

For the record, the CL for this got abandoned a little while ago.

@dr2chase
Copy link
Contributor

I am trying to revive this, I assume it would be helpful.

@heschi
Copy link
Contributor

heschi commented Oct 18, 2017

I think so. I found the problem by inspection, not by hitting it myself, so I don't know how critical it is. But it seems like anything working with small nested structs would be affected, so it seems worth fixing to me.

@gopherbot
Copy link

Change https://golang.org/cl/71731 mentions this issue: cmd/compile: provide more names for stack slots

@dr2chase
Copy link
Contributor

dr2chase commented Oct 18, 2017

The tests are very broken because of refactoring, I'm wondering how hard it would be to turn this into an end-to-end test. Seems like if it matters, there must be a way to make it be user-visible.

I've also as yet had poor luck with any of my little tests when I optimize them. Everything is always reported as <optimized out>, which may be true, but so far I haven't written anything that isn't.

@golang golang locked and limited conversation to collaborators Nov 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants