diff options
author | Kaz Kylheku <kaz@kylheku.com> | 2023-04-08 17:03:04 -0700 |
---|---|---|
committer | Kaz Kylheku <kaz@kylheku.com> | 2023-04-08 17:03:04 -0700 |
commit | f88f74ad3043a496f8945d6e139e3b3eb51c36aa (patch) | |
tree | bf9dbf47d6b3fc6dc2d9d44dc565749ce240c13f /args.c | |
parent | eb6e492d47b14254f4e1d4ba912ca959bda4a43b (diff) | |
download | txr-f88f74ad3043a496f8945d6e139e3b3eb51c36aa.tar.gz txr-f88f74ad3043a496f8945d6e139e3b3eb51c36aa.tar.bz2 txr-f88f74ad3043a496f8945d6e139e3b3eb51c36aa.zip |
compiler: bugfix: eval order of variables.
We have the following problem: when function call argument
expressions mutate some of the variables that are being
passed as arguments, the left-to-right semantics isn't
obeyed. The problem is that the funcction call simply refers
to the registers that hold the variables, rather than to
the evaluated values. For instance (fun a (inc a)) will
translate to something like (gcall <n> (v 3) (v 3))
which is incorrect: both argument positions refer to the
current value of a, whereas we need the left argument
to refer to the value before the increment.
* stdlib/compiler.tl (compiler comp-var): Do not assert the
variable as the output register, with null code. Indicate
that the value is in the caller's output register, and
if necessary generate the move.
(compiler comp-setq): When compiling the right-hand-side,
use the original output register, so that we don't end
up reporting the variable as the result location.
Diffstat (limited to 'args.c')
0 files changed, 0 insertions, 0 deletions