-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: large variable not initialized to 0 #42054
Comments
I think this is actually a linker issue. Looking at go/src/cmd/internal/obj/objfile.go Line 334 in 9499a2e
but that code was newly merged from the dev.link branch, and the issue reproduces identically under Go 1.15 (including the compiler's /cc @cherrymui @thanm |
Go 1.15 has the same code as well (in a different place). Go 1.14 rejects it.
We never supported symbol larger than 2GB (issue #9862), so the object file uses 32-bit for symbol size. I'll add a check before truncation. |
It looks that gc 1.15.3 rejects [edit]: it looks 31 is the only rejected number. And it is ok when x is declared locally. |
Change https://golang.org/cl/263641 mentions this issue: |
What is the difficulty to declare very large sized arrays? |
It looks the fix makes the old code "var x [1<<31]byte" fail to compile now. An incompatibility? |
Sorry, I forgot "var x [1<<31]byte" doesn't compile before. ;) |
What version of Go are you using (
go version
)?Initially spotted on playground (1.14.9), but also reproduces with 1.15.2 and:
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Create a large array and print the first few elements of it:
https://play.golang.org/p/66eTJdT8Ctu
What did you expect to see?
Either a slice of 0s, or a compilation error. (I was originally trying to demonstrate an error that can be reported by
dowidth
. An error does occur when the size of the array is greater than 2e9 but less than 1<<32, but it originates elsewhere.)What did you see instead?
[1 1 0 0 0 0 0 0 0 0 0 1 0 0 0 1 1 1 0 1]
, with other apparently random combinations of 1s and 0s for other sizes. Testing locally, I also see different combinations on the same size between my (slightly dated) copy of tip and 1.15.2.The text was updated successfully, but these errors were encountered: