Skip to content

cmd/compile: internal compiler error: untyped type mismatch, have: untyped float, want: untyped int #41680

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.

Sign up for GitHub

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
Closed
ianlancetaylor opened this issue Sep 28, 2020 · 7 comments
Closed

cmd/compile: internal compiler error: untyped type mismatch, have: untyped float, want: untyped int #41680

ianlancetaylor opened this issue Sep 28, 2020 · 7 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone
Go1.16

Comments

@ianlancetaylor
Copy link
Member

On current tip (874b313, CL 247477) this valid code gets an incorrect compilation error.

I believe this is due to CL 255217. CC @cuonglm @mdempsky

package p

func F(s string) bool {
	const m = 16
	const n = 1e5
	_ = make([]int, n)
	return len(s) < n*m
}
@ianlancetaylor ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Sep 28, 2020
@ianlancetaylor ianlancetaylor added this to the Go1.16 milestone Sep 28, 2020
@ianlancetaylor
Copy link
Member Author

Sorry, I forgot to include the compilation error.

foo.go:7:19: internal compiler error: untyped type mismatch, have: untyped float, want: untyped int

goroutine 1 [running]:
runtime/debug.Stack(0xd6b500, 0xc0000ba008, 0x0)
	/home/iant/go/src/runtime/debug/stack.go:24 +0x9f
cmd/compile/internal/gc.Fatalf(0xc73811, 0x29, 0xc0000cc620, 0x2, 0x2)
	/home/iant/go/src/cmd/compile/internal/gc/subr.go:199 +0x1b0
cmd/compile/internal/gc.setconst(0xc0003b6000, 0xc3bec0, 0xc0000a1ad0)
	/home/iant/go/src/cmd/compile/internal/gc/const.go:981 +0x35c
cmd/compile/internal/gc.evconst(0xc0003b6000)
	/home/iant/go/src/cmd/compile/internal/gc/const.go:581 +0x785
cmd/compile/internal/gc.typecheck1(0xc0003b6000, 0x2, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:2099 +0x2c5
cmd/compile/internal/gc.typecheck(0xc0003b6000, 0x2, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:300 +0x735
cmd/compile/internal/gc.typecheck1(0xc0003b6080, 0x12, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:593 +0x2c1c
cmd/compile/internal/gc.typecheck(0xc0003b6080, 0x12, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:300 +0x735
cmd/compile/internal/gc.typecheckslice(0xc0000ba448, 0x1, 0x1, 0x12)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:118 +0x51
cmd/compile/internal/gc.typecheckargs(0xc0003b6100)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:2140 +0x96
cmd/compile/internal/gc.typecheck1(0xc0003b6100, 0x1, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:2036 +0xa94e
cmd/compile/internal/gc.typecheck(0xc0003b6100, 0x1, 0x0)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:300 +0x735
cmd/compile/internal/gc.typecheckslice(0xc0003a1a80, 0x4, 0x4, 0x1)
	/home/iant/go/src/cmd/compile/internal/gc/typecheck.go:118 +0x51
cmd/compile/internal/gc.Main(0xc81008)
	/home/iant/go/src/cmd/compile/internal/gc/main.go:624 +0x2cb0
main.main()
	/home/iant/go/src/cmd/compile/main.go:52 +0xb1

@mdempsky mdempsky self-assigned this Sep 28, 2020
@mdempsky
Copy link
Contributor

mdempsky commented Sep 28, 2020 •
edited
Loading

Thanks. Looks like this is related to a pre-existing type-checking bug related to make. For example, this program is valid and type checks with gccgo and go/types, but not with Go 1.15:

package main

func main() {
	const n = 1e5
	_ = make([]int, n)
	f := n
	var _ float64 = f
}

Edit: Go 1.15's error message is:

x.go:7:6: cannot use f (type int) as type float64 in assignment

(Positively, it successfully compiles at tip, likely thanks to CL 255217.)

@cuonglm
Copy link
Member

cuonglm commented Sep 28, 2020

@mdempsky Is it normal that const n = 1e5 is untyped float, but the n.Val().Ctype() is CTINT?

@mdempsky
Copy link
Contributor

@cuonglm No, that's the issue. If a Node has type Idealfloat, then it should have value CTFLT.

@cuonglm
Copy link
Member

cuonglm commented Sep 28, 2020

@cuonglm No, that's the issue. If a Node has type Idealfloat, then it should have value CTFLT.

So I think that's the bug here. I can't find where we currently set that information. This bug does exists before CL 255217, it just works because we assign the value to n instead of doing assertion.

@mdempsky
Copy link
Contributor

@cuonglm That's my assessment too. I have a fix. Will upload shortly.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/257966 mentions this issue: cmd/compile: fix type checking of "make" arguments

@golang golang locked and limited conversation to collaborators Sep 28, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Milestone
Go1.16
Development

No branches or pull requests
4 participants
@mdempsky @ianlancetaylor @cuonglm @gopherbot