Will Coleda wrote:
But it looks like the PMC args are getting *switched* somehow. looking
at the stack trace below starting just before the tailcall:
I've now located the problem, but I can't fix it right now. It is a bit
non-trivial. The bug isn't related to tailcalls at all, which mislead me
a long time. We have e.g
.sub foo
.param pmc argv :slurpy
...
bar(argv)
.end
You would of course expect that argv is passed on unaltered, actually
the param passing code in the call to "bar" flattens "argv".
Why? This is deeply buried in imcc symbols handling.
.param pmc argv :slurpy
defines the identifier 'argv' with mk_ident() and sets the slurpy bit
after the symbol is created.
When 'argv' is now reused, just the same symbols is used (which is
correct - both get the same Parrot register) but as the ADV_SLURPY bit
is also associate with the symbol - the call to bar also get's the
ADV_SLURPY, which for a call just means :flatten.
Until there is a fix, the following workaround works (use different
symbols for slurpy args that are passed on elsewhere):
.sub foo
.param pmc argv_sl :slurpy
.local pmc argv
argv = argv_sl
bar(argv)
.end
I'm leading towards Braga (YAPC::EU) tomorrow early in the morning and
will probably not have much time to fix it there. Takers welcome.
I think, moving the 'paramtype_list' flags from the symbol into the call
structure 'pcc_sub' to an appropriate 'arg_flags[i]' or 'ret_flags[i]'
shouldn't be too hard - see also add_pcc_param() and friends.
leo
