summaryrefslogtreecommitdiffstats
path: root/tl.vim
diff options
context:
space:
mode:
authorKaz Kylheku <kaz@kylheku.com>2018-04-01 23:10:01 -0700
committerKaz Kylheku <kaz@kylheku.com>2018-04-01 23:10:01 -0700
commit370821a0c8ef107e8cdc2eb7b648e48a958a59c8 (patch)
treed90244b1cda0ef65436902b7349e0e42a4d3b25d /tl.vim
parent6f30c1dc672c453b82794b621049ea6a3ae4c656 (diff)
downloadtxr-370821a0c8ef107e8cdc2eb7b648e48a958a59c8.tar.gz
txr-370821a0c8ef107e8cdc2eb7b648e48a958a59c8.tar.bz2
txr-370821a0c8ef107e8cdc2eb7b648e48a958a59c8.zip
compiler: big oreg-related bugfix
There is a smattering of incorrect logic affecting a number of the compiler's special form sub-compilers. Basically the issue is that a compiler routine cannot arbitrarily use the oreg that it is given. If it generates multiple instructions which clobber a destination, only the last clobber may target oreg. The reason is that oreg is not necessarily a fresh temporary that can be used arbitrarily. It can be a variable which is evaluated by the forms that are compiled by the sub-compiler. Prematurely storing a value into oreg can affect the behavior and result value of not-yet executed code. The recent "indirect function calls" fix addressed just one case of this; the problem is more wide-spread. * share/txr/stdlib/compiler.tl (compiler (maybe-alloc-treg, maybe-free-treg)): New methods. (compiler (comp-if, comp-switch, comp-unwind-protect, comp-block, comp-handler-bind, comp-catch, comp-let, comp-progn, comp-and-or, comp-prog1, comp-for, comp-call, comp-tree-case): Do not carelessly use oreg for intermediate computations; allocate one or more temporary registers for that purpose, and either only move the final value into oreg, or else indicate a temporary register as the returned frag's output register.
Diffstat (limited to 'tl.vim')
0 files changed, 0 insertions, 0 deletions