Patrick R. Michaud wrote:
I suspect it's an issue with register spilling, that I15 is being
reused somewhere later to represent something other than the "cutting"
value.
Please not that this has nothing to do with register spilling, where due
to a lack of registers these are stored into (and fetched from) an array
in P31. We've got a problem of a register changing it's value - or not.
After another half of a day with gdb, I've eventually tracked it down.
What happens is this: the pattern is "<ident>", which happens to be just
another Rule. So during matching the precompiled coroutine for matching
"<ident>" is entered to try this rule at various positions. But the
relevant code piece in EVAL_1 [1] looks like this:
lastpos = length target
if pos >= 0 goto try_at_pos
pos = 0
try_match:
cutting = 0
...
try_at_pos:
...
if cutting != 0 goto fail <<<< bails out at first
"pos" is already 1, therefore "cutting" get's never initialized and has
some garbage value. I've a rather lengthy typescript here, which tracks
all changes to I15 and clearly shows this reason.
I don't think that Parrot should guarantee that registers have some
predifined value on entering a subroutine. We have to NULL out PMC and
STRING registers already for GC, which is a rather costy operation.
But if folks prefer that we should clean registers, we can of course do
it. It's probably not the best idea though (for the long run and
performance-wise).
An alternative would be to fill integer and number registers with some
arbitrary and changing values (in debug builds) to simplify catching
such errors. There is further some (disabled) code in imcc/cfg.c that
tries to catch such uninitialized variables but I doubt that it would
have warned in that case, as there is one possible execution path to
initialize "cutting".
leo
[1] parrot -D20 foo.pir
creates EVAL_n (n = 1...) for each "evaled" code piece in turn. So
EVAL_1 is the precompiled "ident" rule, EVAL_2 the code for matching the
test file pattern.
