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: panic during prove while compiling: unexpected induction with too many parents [1.20 backport] #63983

Closed
gopherbot opened this issue Nov 7, 2023 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@gopherbot
Copy link
Contributor

@randall77 requested issue #63955 to be considered for backport to the next 1.20 minor release.

@gopherbot please open backport issues.

I agree that if this could cause a miscompilation we should backport.
It does seem exceedingly rare though.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Nov 7, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Nov 7, 2023
@gopherbot gopherbot added this to the Go1.20.11 milestone Nov 7, 2023
@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/539936 mentions this issue: cmd/compile: fix findIndVar so it does not match disjointed loop headers

@gopherbot gopherbot modified the milestones: Go1.20.11, Go1.20.12 Nov 7, 2023
@heschi heschi added the CherryPickApproved Used during the release process for point releases label Nov 15, 2023
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Nov 15, 2023
@gopherbot
Copy link
Contributor Author

Closed by merging d77307f to release-branch.go1.20.

gopherbot pushed a commit that referenced this issue Nov 28, 2023
…tch disjointed loop headers

Fix #63983

parseIndVar, prove and maybe more are on the assumption that the loop header
is a single block. This can be wrong, ensure we don't match theses cases we
don't know how to handle.

In the future we could update them so that they know how to handle such cases
but theses cases seems rare so I don't think the value would be really high.
We could also run a loop canonicalization pass first which could handle this.

The repro case looks weird because I massaged it so it would crash with the
previous compiler.

Change-Id: I4aa8afae9e90a17fa1085832250fc1139c97faa6
Reviewed-on: https://go-review.googlesource.com/c/go/+/539977
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 8b4e125)
Reviewed-on: https://go-review.googlesource.com/c/go/+/539936
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Jorropo <jorropo.pgm@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

2 participants