-
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: Unified IR exports table is binary unstable in presence of generics #59571
Comments
Repro case:
|
Further minimized:
|
Assuming the fix is a trivial change like a strategically placed call to sort.Sort, we should backport the fix to Go 1.20. |
@rsc Agreed. I've narrowed down the cause; just figuring out the best way to fix it. @gopherbot Please backport to Go 1.20. |
Backport issue(s) opened: #59585 (for 1.20). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
Change https://go.dev/cl/484155 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes (tested on go 1.20.3)
go1.19.8 works fine even with unified IR enabled
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Internally we use extensive caching of precompiled go packages, but we started seeing
fingerprint mismatch
issue after switching to 1.20.The problem seems to be the following: starting with go 1.20 packages are binary unstable: the fingerprint changes from build to build (of the exactly same code) in presence of generics. The code (as reported by objdump) and the names (as reported by nm) are identical. In our environment we see some shuffling in export table strings related to generic instantiations (the total size of table remains the same). In more generic environment I see wider changes, but I still expect to see none.
Looking at the code of
cmd/compile/internal/noder/unified.go
and
internal/pkgbits/encoder.go
We see that fingerprint is exactly hash of the exports table.
--
The problem is not specific to the project below, but can be reproduced on it:
checkout https://github.com/urfave/cli, than do the following:
What did you expect to see?
Binary exact packages (as with 1.19). At the very least difference that does not affect package fingerprint.
What did you see instead?
According to source code
The text was updated successfully, but these errors were encountered: