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

Jump to bottom

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
Labels
FrozenDueToAge generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.18

Comments

@rogpeppe
Copy link
Contributor

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
@rogpeppe rogpeppe added the generics Issue is related to generics label Aug 29, 2021
@griesemer griesemer added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 29, 2021
@griesemer griesemer added this to the Go1.18 milestone Aug 29, 2021
@griesemer
Copy link
Contributor

This appears to work with GOEXPERIMENT=unified.

@scott-cotton
Copy link

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

@griesemer
Copy link
Contributor

@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.

@danscales
Copy link
Contributor

@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.

@cuonglm
Copy link
Member

cuonglm commented Aug 30, 2021 •
edited

@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}
--

@randall77
Copy link
Contributor

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.

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
7 participants
@rogpeppe @danscales @cuonglm @randall77 @griesemer @gopherbot @scott-cotton