cmd/compile: autotmp_* variables make the compiler crash

[randall77]

package main
func f(autotmp_foo int) int {
    return autotmp_foo
}

The compiler fails with:

internal compiler error: Treating auto as if it were arg, func f, node autotmp_foo, value v7

We should really keep track of which variables are autos with PAUTO, not with the name.

[dr2chase]

The test could also be removed; if you let it through, it causes a mystifying crash in the register allocator, so the only purpose of this check was to remove mystery. P(crash happening again) I think is relatively low, since we haven't to my knowledge run into this again since inserting the earlier check.

[mdempsky]

Do we have to use "autotmp_" as the prefix for compiler-generated temporaries? Can we use some impossible prefix instead? E.g., "autotmp."?

We could use something shorter, and it would probably reduce object file / DWARF info sizes. GCC uses ".L" for generated labels in assembly output.

[randall77]

There are a few other cases of strings.HasPrefix(..., "autotmp_") in the compiler, not just the one that caused this ICE. We should probably fix them all.

[odeke-em]

@randall77, I can't seem to reproduce the crash on tip 0e7f970

$ go run main.go && cat main.go 
package main
func f(autotmp_foo int) int {
    return autotmp_foo
}
func main() {
}

I was looking at fixing all the strings.HasPrefix(..., "autotmp_") calls but can't reproduce the crash.

[josharian]

Related / possible duplicate: #7923

[randall77]

Yes, my particular example seems to have fixed itself.
The general issue stands though, we shouldn't use variable names to affect behavior. But fixing it using Matthew's suggestion (an impossible prefix) would be ok, I guess.

[dr2chase]

I'm looking at using Than's abandoned change, for this and for #17644

[gopherbot]

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

[gopherbot]

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