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: unhandled OCONV INT -> COMPLEX128 #50193

Closed
bitfield opened this issue Dec 15, 2021 · 5 comments
Closed
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@bitfield
Copy link

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

devel go1.18-b1c7703f26 Wed Dec 15 14:48:19 2021 +0000

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

Go playground (gotip mode)

What did you do?

https://go.dev/play/p/yaFqmC4e7fI?v=gotip

What did you expect to see?

(0+0i)

What did you see instead?

./prog.go:14:11: internal compiler error: 'Bunch[go.shape.complex128_0].First': unhandled OCONV INT -> COMPLEX128

./prog.go:21:21: internal compiler error: 'main': unhandled OCONV INT -> COMPLEX128

goroutine 6 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0xc99220?, 0x0?}, {0xc00033aa30, 0x1e}, {0xc0004a8390, 0x3, 0x3})
	/usr/local/go/src/cmd/compile/internal/base/print.go:227 +0x1ca
cmd/compile/internal/base.Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc00033aaa0?, {0x403d54?, 0x0?}, {0xd2a2f4, 0x18}, {0xc0004aa0a0, 0x2, 0x40e4ac?})
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:7692 +0x17d
cmd/compile/internal/ssagen.(*state).Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:953
cmd/compile/internal/ssagen.(*state).conv(0xc00001e300, {0xe91570?, 0xc0003f16d0?}, 0xe8f001?, 0xc00037e4d0, 0xc0003ed6c0)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:2547 +0x1e77
cmd/compile/internal/ssagen.(*state).exprCheckPtr(0xc00001e300, {0xe91570?, 0xc0003f16d0?}, 0x1)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:2745 +0x1cda
cmd/compile/internal/ssagen.(*state).expr(...)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:2553
cmd/compile/internal/ssagen.(*state).stmt(0xc00001e300, {0xe90c10, 0xc000579680?})
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1633 +0xb71
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1399
cmd/compile/internal/ssagen.(*state).stmt(0xc00001e300, {0xe90e68, 0xc000078bc0?})
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1422 +0x4885
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1399
cmd/compile/internal/ssagen.(*state).stmt(0xc00001e300, {0xe91c78, 0xc0003f27e0?})
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1703 +0x3c35
cmd/compile/internal/ssagen.(*state).stmtList(...)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:1399
cmd/compile/internal/ssagen.buildssa(0xc0003bf080, 0x1)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:582 +0x1eb4
cmd/compile/internal/ssagen.Compile(0xc0003bf080, 0xc00003df90?)
	/usr/local/go/src/cmd/compile/internal/ssagen/pgen.go:183 +0x4c
cmd/compile/internal/gc.compileFunctions.func4.1(0x0?)
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:153 +0x3a
cmd/compile/internal/gc.compileFunctions.func3.1()
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:140 +0x4d
created by cmd/compile/internal/gc.compileFunctions.func3
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:138 +0x78


Go build failed.
@cherrymui cherrymui added this to the Go1.18 milestone Dec 15, 2021
@cherrymui cherrymui added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels Dec 15, 2021
@cherrymui
Copy link
Member

cc @randall77 @danscales

@randall77
Copy link
Contributor

I think this boils down to the fact that you can't do this in Go:

var x int = 3
y := (complex128)(x)

In Go you'd have to do y := complex(float64(x), 0).

The special case here is that the thing being converted is a constant literal. We probably need to detect that and do the conversion of the literal at stenciling time.

@danscales
Copy link
Contributor

Yes, I guess the typechecker accepts this because it's an untyped literal and both

y := complex64(0)

and

y := complex128(0)

are allowed. I can take a look at fixing this at function instantiation time.

@randall77 randall77 self-assigned this Dec 15, 2021
@randall77
Copy link
Contributor

I have a fix that just upgrades ssagen to handle these conversions. It's a pretty simple change.

@gopherbot
Copy link

Change https://golang.org/cl/372514 mentions this issue: cmd/compile: upgrade ssa to do (int or float) -> complex

@golang golang locked and limited conversation to collaborators Jun 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

5 participants