-
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: internal compiler error: panic during prove while compiling: unexpected induction with too many parents #63955
Comments
/cc @golang/compiler |
@Jorropo That error is from your CL from July. Not sure it is the culprit, but looks likely, as there's not much else that has changed about prove lately. |
I'll take a look thx. |
After a quick 2 step bisection, I confirm that bac4e2f is the faulty commit. |
I think this is a latent bug in See right here: if b.Kind != BlockIf || len(b.Preds) != 2 { // it tries to only match blocks with 2 preds
continue
}
var ind *Value // induction variable
var init *Value // starting value
var limit *Value // ending value
// Check that the control if it either ind </<= limit or limit </<= ind.
// TODO: Handle unsigned comparisons?
c := b.Controls[0]
inclusive := false
switch c.Op {
case OpLeq64, OpLeq32, OpLeq16, OpLeq8:
inclusive = true
fallthrough
case OpLess64, OpLess32, OpLess16, OpLess8:
ind, limit = c.Args[0], c.Args[1]
default:
continue
} It then extract However consider that this wouldn't be true if there are blocks between
Here b17:
v150 = Eq64 <bool> v149 v146
- If v150 -> b20 b18
+ If v150 -> b20 b22
- b18:
- v153 = Eq64 <bool> v152 v146
- If v153 -> b20 b22
b20:
v157 = Less64 <bool> v270 v156
If v157 -> b23 b22 This changes nothing in term of loop semantics, I removed an After a quick review of I'll submit a patch later, if I didn't in a few days feel free to revert. |
Update: func parseIndVar(ind *Value) (min, inc, nxt *Value) {
if ind.Op != OpPhi {
return
}
if n := ind.Args[0]; (n.Op == OpAdd64 || n.Op == OpAdd32 || n.Op == OpAdd16 || n.Op == OpAdd8) && (n.Args[0] == ind || n.Args[1] == ind) {
min, nxt = ind.Args[1], n
} else if n := ind.Args[1]; (n.Op == OpAdd64 || n.Op == OpAdd32 || n.Op == OpAdd16 || n.Op == OpAdd8) && (n.Args[0] == ind || n.Args[1] == ind) {
min, nxt = ind.Args[0], n
} else {
// Not a recognized induction variable.
return
}
if nxt.Args[0] == ind { // nxt = ind + inc
inc = nxt.Args[1]
} else if nxt.Args[1] == ind { // nxt = inc + ind
inc = nxt.Args[0]
} else {
panic("unreachable") // one of the cases must be true from the above.
}
return
} If this were safe it should iterate over |
Change https://go.dev/cl/539977 mentions this issue: |
@randall77 I don't think the particular code pattern required is likely to be seen in the wild. |
@gopherbot please open backport issues. I agree that if this could cause a miscompilation we should backport. |
Backport issue(s) opened: #63983 (for 1.20), #63984 (for 1.21). 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/560975 mentions this issue: |
I wrote theses checks because I got bad panics on some innocent functions, turns out I was working around #63955 but I was not aware of that at the time. The proper fix was included in CL 539977 this is now doing nothing. Change-Id: I89329329933527b6f3cb817dc1e039a38f58da9a Reviewed-on: https://go-review.googlesource.com/c/go/+/560975 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
It does not reproduce with the 1.21 release, only with the 1.22 development version.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I tried to compile a minimal program using the
oto
library with the devel version of Go 1.22 on Darwin:What did you expect to see?
Successful compilation as with Go 1.21.
What did you see instead?
An internal compiler error:
The text was updated successfully, but these errors were encountered: