-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: ICE: "must have bodyReader for type..hash.[type]" #58572
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
Comments
Further minimized: https://go.dev/play/p/fkRXZrXwIfe?v=gotip |
Since CL 436961 isn't essential, I'm leaning towards reverting it for now and adding the regress test case; and then we can try that CL again but without breaking the test case. |
Change https://go.dev/cl/468880 mentions this issue: |
Change https://go.dev/cl/468879 mentions this issue: |
This reverts commit 25f5d9d. Causes ICE on valid code. Updates #58572. Change-Id: Ib276c87d9b0362bbd2a760ac2a242f82d4e20400 Reviewed-on: https://go-review.googlesource.com/c/go/+/468879 Reviewed-by: Cuong Manh Le <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Auto-Submit: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
@mdempsky seems that we should relax the check in bodyReaderFor to assert only in case of local functions and imported generic functions? Previously, the type hash functions is generated during local package compilation, but they are from pseudo package |
I think it would be a reasonable short-term solution to exempt the synthetic hash and eq functions, but I wouldn't want to more broadly relax that assert. The inliner is able to gracefully fallback when an inline body is missing, but that's not really intended operation, and it degrades the quality of the inliner's cost heuristics. I think a better solution would be to change inline.CanInline to recognize these functions, and mark them as non-inlineable. Longer term, if there's a reason we do want to be able to inline these eq/hash functions, then maybe we need to integrate the code generation into the unified frontend's "synthetic" function mechanism. |
Change https://go.dev/cl/469017 mentions this issue: |
Change https://go.dev/cl/469018 mentions this issue: |
This reverts commit 25f5d9d. Causes ICE on valid code. Updates golang#58572. Change-Id: Ib276c87d9b0362bbd2a760ac2a242f82d4e20400 Reviewed-on: https://go-review.googlesource.com/c/go/+/468879 Reviewed-by: Cuong Manh Le <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Auto-Submit: Matthew Dempsky <[email protected]> Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
Fixes golang#58572. Change-Id: I75fa432afefc3e036ed9a6a9002a29d7b23105ee Reviewed-on: https://go-review.googlesource.com/c/go/+/468880 Reviewed-by: Keith Randall <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Cuong Manh Le <[email protected]> Run-TryBot: Matthew Dempsky <[email protected]> Auto-Submit: Matthew Dempsky <[email protected]>
The compiler used to generate ONAME node with nil Func for them, so the inliner can still analyze, but could not generate inline call for them anyway. CL 436961 attempts to create ONAME node with non-nil Func, causing the inliner complains about missing body reader. This CL makes inliner recognize type eq/hash functions, and mark them as non-inlineable. Longer term, if we do want to inline these functions, we need to integrate the code generation into Unified IR frontend. Updates #58572 Change-Id: Icdd4dda03711929faa3d48fe2d9886568471f0bc Reviewed-on: https://go-review.googlesource.com/c/go/+/469017 TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> Reviewed-by: Keith Randall <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Keith Randall <[email protected]>
This reverts CL 468879 CL 469017 marked type eq/hash functions as non-inlineable, so this change won't cause ICE anymore. Updates #58572 Change-Id: I3e6ec9ba2217102693acd1848a0eba0886dc9fda Reviewed-on: https://go-review.googlesource.com/c/go/+/469018 Auto-Submit: Cuong Manh Le <[email protected]> Reviewed-by: Bryan Mills <[email protected]> Run-TryBot: Cuong Manh Le <[email protected]> Reviewed-by: Matthew Dempsky <[email protected]> TryBot-Result: Gopher Robot <[email protected]>
We have a Google-internal package that's failing to build since 25f5d9d (https://go.googlesource.com/go/+/25f5d9d, /cc @cuonglm).
Mostly minified test case here: https://go.dev/play/p/jddWxVs4sf0?v=gotip
The text was updated successfully, but these errors were encountered: