| commit | 6eb755deadbfd2df3e1f54c891e8ef331f176076 | |
| author | Alastair Bridgewater <alastair.bridgewater@gmail.com> | |
| Wed, 20 Dec 2017 03:37:32 +0000 (19 22:37 -0500) | ||
| committer | Alastair Bridgewater <alastair.bridgewater@gmail.com> | |
| Wed, 20 Dec 2017 03:44:37 +0000 (19 22:44 -0500) | ||
| tree | c419d04b3ce2fabd4c7c827be98dbf2c3d2a1227 | treesnapshot (tar.gz zip) |
| parent | c3a13d3569b12d594be9259776db966e1926fa4a | commitdiff |
Fix STACK analysis for lp#1739308
* Reported by Paul F. Dietz, it's Yet Another STACK Analysis Bug.
Probably my fault, too.
* Essentially, there was a failure to properly compute the live
sets protected by a DX LVAR when the only path from USE to DEST
of that LVAR passes through a non-local entry. Fix, by deeming
non-local-entry blocks to have their "allocating" block as one of
their predecessor blocks (really, their only predecessor block).
* I suspect the following: that part of this fix works more by
coincidence than by design, and that there are still more bugs to
be found in STACK analysis. Maybe involving TAGBODY, BLOCK, or
UNWIND-PROTECT?
* Reported by Paul F. Dietz, it's Yet Another STACK Analysis Bug.
Probably my fault, too.
* Essentially, there was a failure to properly compute the live
sets protected by a DX LVAR when the only path from USE to DEST
of that LVAR passes through a non-local entry. Fix, by deeming
non-local-entry blocks to have their "allocating" block as one of
their predecessor blocks (really, their only predecessor block).
* I suspect the following: that part of this fix works more by
coincidence than by design, and that there are still more bugs to
be found in STACK analysis. Maybe involving TAGBODY, BLOCK, or
UNWIND-PROTECT?
| src/compiler/stack.lisp | diffblobblamehistory | |
| tests/dynamic-extent.impure.lisp | diffblobblamehistory |