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: internal compiler error: not lowered: v22, StructMake0 STRUCT #48049

Closed
rogpeppe opened this issue Aug 29, 2021 · 7 comments
Closed

cmd/compile: internal compiler error: not lowered: v22, StructMake0 STRUCT #48049

rogpeppe opened this issue Aug 29, 2021 · 7 comments

Comments

@rogpeppe
Copy link
Contributor

@rogpeppe rogpeppe commented Aug 29, 2021

What version of Go are you using (go version)?

$ go version
go version devel go1.18-f4cd001b57 Sat Aug 28 18:48:37 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

yes

What did you do?

Compiled this code:

package main

func main() {
	Fooer2[byte]()
}

type Fooer[T any] interface {
	Foo(p T)
}

type fooer1[T any] struct{}

func (fooer1[T]) Foo(T) {}

type fooer2[T any] struct {
	r []Fooer[T]
}

func (mr fooer2[T]) Foo(p T){
	mr.r[0] = fooer1[T]{}
	return
}

func Fooer2[T any]() Fooer[T] {
	return fooer2[T]{}
}

I see the following panic:

# github.com/rogpeppe/generic/bug-2021-08-29
<autogenerated>:1: internal compiler error: '(*fooer2[uint8]).Foo': not lowered: v22, StructMake0 STRUCT

goroutine 1 [running]:
runtime/debug.Stack()
	/home/rogpeppe/go-dev/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0xc73500, 0x0}, {0xc00008d8e0, 0x8}, {0xc00042a860, 0x2, 0x2})
	/home/rogpeppe/go-dev/src/cmd/compile/internal/base/print.go:227 +0x154
cmd/compile/internal/base.Fatalf(...)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0x8, {0x367b75b8, 0x7f4a}, {0xce9c12, 0x2}, {0xc0000727e0, 0x1, 0x5})
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssagen/ssa.go:7477 +0x17d
cmd/compile/internal/ssa.(*Func).Fatalf(0xc0004301c0, {0xce9c12, 0x2}, {0xc0000727e0, 0x1, 0x1})
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssa/func.go:773 +0x27f
cmd/compile/internal/ssa.checkLower(0xc0004301c0)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssa/lower.go:41 +0x409
cmd/compile/internal/ssa.Compile(0xc0004301c0)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssa/compile.go:96 +0x9e7
cmd/compile/internal/ssagen.buildssa(0xc00011ec60, 0x0)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssagen/ssa.go:584 +0x1e30
cmd/compile/internal/ssagen.Compile(0xc00011ec60, 0xc00042a6a0)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/ssagen/pgen.go:183 +0x4c
cmd/compile/internal/gc.compileFunctions.func4.1(0xc0000abb01)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/gc/compile.go:153 +0x3a
cmd/compile/internal/gc.compileFunctions.func2(0xc0000001a0)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/gc/compile.go:125 +0x1e
cmd/compile/internal/gc.compileFunctions.func4({0xc00042e2c0, 0x7, 0x8})
	/home/rogpeppe/go-dev/src/cmd/compile/internal/gc/compile.go:152 +0x53
cmd/compile/internal/gc.compileFunctions()
	/home/rogpeppe/go-dev/src/cmd/compile/internal/gc/compile.go:163 +0x162
cmd/compile/internal/gc.Main(0xd21740)
	/home/rogpeppe/go-dev/src/cmd/compile/internal/gc/main.go:302 +0xfb6
main.main()
	/home/rogpeppe/go-dev/src/cmd/compile/main.go:55 +0xdd

@griesemer @ianlancetaylor

@griesemer
Copy link
Contributor

@griesemer griesemer commented Aug 29, 2021

This appears to work with GOEXPERIMENT=unified.

Loading

@scott-cotton
Copy link

@scott-cotton scott-cotton commented Aug 29, 2021

I am curious, is GOEXPERIMENT=unified planned for 1.18?

Loading

@griesemer
Copy link
Contributor

@griesemer griesemer commented Aug 29, 2021

@scott-cotton Let's not speculate on implementation approach and schedule. But in the interest of the best possible user experience it seems reasonable (to me) to select the most stable and feature-complete implementation approach when the time comes, whichever that is. Thanks.

Loading

@danscales
Copy link

@danscales danscales commented Aug 30, 2021

@randall77 Do you want to take a look. I don't immediately know why the lowering is not happening properly. If you add //go:noinline in front of method "mr fooer2[T]) Foo(p T)", then it seems easier to debug, since then the error occurs on that function (the instantiation 'fooer2[.shape.uint8].Foo'), rather than on a wrapper (which inlines that method)

The problem seems to be with the STRUCTLIT in that function - somehow the final lowering is not happening. It could possibly be related to the fact that the type of the STRUCTLIT is a shape type (e.g. fooer1[.shape.uint8] ), but I haven't look far enough into the SSA code.

Loading

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Aug 30, 2021

@randall77 @danscales While investigating this, I notice that:

GOSSAFUNC='fooer2[.shape.uint8].Foo' go tool compile p.go

produce ssa.html with no source code in the sources section.:

<br class="Apple-interchange-newline">

sources   main.go
--

Unified IR can properly show:

<br class="Apple-interchange-newline">

sources  20212223 /Users/cuonglm/p.gofunc (mr fooer2[T]) Foo(p T){	mr.r[0] = fooer1[T]{}	return}
--

Loading

@randall77
Copy link
Contributor

@randall77 randall77 commented Aug 30, 2021

There is a missing OCONVIFACE. This assignment:

	mr.r[0] = fooer1[T]{}

Implicitly converts the concrete type on the RHS to an interface type on the LHS.
The immediate problem is easy, in stencil.go:929, we need to assign the results of lhs[0] and rhs[0] back to as.X and as.Y. (The OCONVIFACE is made in transformAssign, we just lose it by not assigning back to the source.)
But then we end up with a OCONVIFACE introduced late, too late to convert the OCONVIFACE to using the dictionary. Have to think a bit more about how to make that work.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 7, 2021

Change https://golang.org/cl/347914 mentions this issue: cmd/compile: add CONVIFACE nodes needed in generic code due to assignments

Loading

@gopherbot gopherbot closed this in 3fff213 Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants