-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
fix #15704 #15597 wrong VM register was freed #15705
Conversation
5ab8b8c
to
28c198a
Compare
This needs to be backported all the way down to 1.0.x, @narimiran |
PTAL:
can you explain the added |
Not anymore but I did review the entire VM codegen looking for register allocator leaks. Apparently my work wasn't good enough. ;-) |
cba8c75
to
e78a62c
Compare
e78a62c
to
89d4143
Compare
lib/system.nim
Outdated
@@ -2106,7 +2106,7 @@ const | |||
## is the minor number of Nim's version. | |||
## Odd for devel, even for releases. | |||
|
|||
NimPatch* {.intdefine.}: int = 1 | |||
NimPatch* {.intdefine.}: int = 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What the heck? That should not be part of this PR!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that was so code could branch on this bugfix, as explained in #14124 (comment) and it was useful in some PR's to branch on that.
It also makes nim -v
a little more helpful to show, instead of just a hash + fixed 1.5.1 it shows hash + 1.5.x so it's immediately clearer in bug reports how recent was the nim version used.
Finally, it makes pre-releases / nightly builds easier to distinguish via nim -v
I'm not aware of negative consequences in bumping NimPatch, it's a common practice to bump patch on bug fixes. I'm not suggesting to do it on each commit (nim isn't following standard semver anyways), but bumping patch somewhat regularly between 2 stable releases is IMO a good thing.
Sorry, I took over a bit as we want to release 1.2.8 this morning. :-) |
no problem. too bad #15724 couldn't make the cut for 1.2.8 |
* fix #15704 #15597 wrong VM register was freed * same treatment for nkCheckedFieldExpr * note concerning HighRegisterPressure * bump NimPatch * Update lib/system.nim Co-authored-by: Andreas Rumpf <[email protected]> (cherry picked from commit d4c2e2c)
…ng#15705) * fix nim-lang#15704 nim-lang#15597 wrong VM register was freed * same treatment for nkCheckedFieldExpr * note concerning HighRegisterPressure * bump NimPatch * Update lib/system.nim Co-authored-by: Andreas Rumpf <[email protected]>
…ng#15705) * fix nim-lang#15704 nim-lang#15597 wrong VM register was freed * same treatment for nkCheckedFieldExpr * note concerning HighRegisterPressure * bump NimPatch * Update lib/system.nim Co-authored-by: Andreas Rumpf <[email protected]>
…ng#15705) * fix nim-lang#15704 nim-lang#15597 wrong VM register was freed * same treatment for nkCheckedFieldExpr * note concerning HighRegisterPressure * bump NimPatch * Update lib/system.nim Co-authored-by: Andreas Rumpf <[email protected]>
fix #15704
fix #15597
(regressions caused by #12485)
This was painful to track down, we should improve debug-ability of nim vm; I used
-d:nimVMDebug
for that but-d:nimVMDebug
should be further improved-d:nimVMDebug
by showing more contextual informationCI failure unrelated
=> flaky timotheecour#352
future work
freeTemp
from VM: fixes most ran-out-registers problems [backport] #12485see also: fix #15704 #15597 wrong VM register was freed #15705 (comment) (some
dest
registers being freed)HighRegisterPressure = 40
; will allow for eg lowering it to find more bugs easily, or increasing it for temporary workarounds when there's a similar bug; at least useful for debugging (it was for me in this PR)