On Thu, Jul 28, 2005 at 03:39:33PM -0400, Andy Dougherty wrote:
> On Thu, 28 Jul 2005, Will Coleda wrote:
>
> > Applying your patch to a pristine build yields only the backtrack.t failure:
> > #2 eats 100% of the CPU until I kill it: it doesn't behave that way in
> > svn-head.
>
> I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say
> what other tests may have changed; the script I had running the comparison
> got stuck at backtrack.t and never finished.
Just to add to the picture -- I also tried applying df.patch to a fresh
checkout of parrot/trunk (r8727), and also observed the same problem
of getting stuck on test #2 in t/p6rules/backtrack.t . (FWIW, I'm running
Fedora Core 4.)
Some additional investigation reveals that with df.patch applied it's
the PIR compiler that is getting stuck. I'm able to reproduce this
with the code below, which doesn't do anything useful other than
demonstrate that the compiler gets stuck when one tries to compile:
$ cat x4.pir
.sub foo
print "started\n"
bsr R1
goto end
R1:
goto R2
if $I0 goto R2
bsr R2
R2:
ret
end:
.end
$ parrot -t -v -o x4.pbc x4.pir
debug = 0x0
Reading x4.pir
using optimization '0' (0)
Starting parse...
at which point the process is stuck until interrupted somehow.
The problem seems to be with the exact goto/if/bsr sequence given in R1 --
remove any of them or reorder them and the code successfully compiles.
I completely grant that the specific sequence of statements that
trigger this problem is bizarre -- it only occurred in PGE because
of a missing optimization in PGE's code generator. The cut operator
(for backtracking control) generated a "goto R2" statement to
handle the cut, but then also generated the code that would've
performed the backtracking had the cut not been present. Note that
having the extra code after the goto doesn't change the syntactic
or semantic correctness at all -- it just causes the compiler to choke
somehow (when df.patch is applied).
I'll definitely fix PGE to not generate the unnecessary code
following the "goto", but it seems to me that the compiler should
not hang on something like this in any case.
I'll be very happy to add the above PIR segment to the imcc test
suite if someone can tell me which imcc/t/*/*.t file it should go in.
Then I'll fix PGE to not generate the code it should not have
been generating in the first place. :-)
Hope this helps!
Pm
