Folks,
There seems to be some problems with -O1 when instructions are optimised
at the end of functions. For instance, take
sub main
func ()
end
sub func
$I0 += 1
end
which translates to
main:
@pcc_sub_call_0:
set I0, 1
set I1, 0
set I2, 0
set I3, 0
set I4, 0
set S1, ""
set_p_pc P0, func
invokecc
null I0
null I3
returncc
func:
add I30, 1
null I0
null I3
returncc
When optimised with -O1 you instead get
main:
@pcc_sub_call_0:
set I0, 1
set I1, 0
set I2, 0
set I3, 0
set I4, 0
set S1, ""
set_p_pc P0, func
invokecc
null I0
null I3
returncc
func:
inc I30
where the tail of func is lost after the instruction has been
substituted (and as such core dumps for me as control goes past the end
of the bytecode).
In what is semi-related to this, if a deleted instruction (e.g. $I0+=0)
is at the end of a function, you get a core dump in imcc/optimiser.c in
this line (because ins is NULL):
ins = ins->prev ? ins->prev : unit->instructions;
If no ones picked this up in the next couple of days, I'll hopefully
have time to get my teeth into it...
Cheers,
Nick
Fixed, thanks for testing.
> In what is semi-related to this, if a deleted instruction (e.g. $I0+=0)
> is at the end of a function, you get a core dump in imcc/optimiser.c in
> this line (because ins is NULL):
>
> ins = ins->prev ? ins->prev : unit->instructions;
Fixed too rev 8227
> Cheers,
>
> Nick
leo
> Nick Glencross wrote:
>
>> (I'm reposting this because I'm not sure what happened to the one that
>> I sent to parrotbugs; forgive me if two eventually appear)
>>
>> Folks,
>>
>> There seems to be some problems with -O1 when instructions are
>> optimised at the end of functions.
>
>
> Fixed, thanks for testing.
Hmmm... Not seeing any improvement at my end ...
>> In what is semi-related to this, if a deleted instruction (e.g.
>> $I0+=0) is at the end of a function, you get a core dump in
>> imcc/optimiser.c in this line (because ins is NULL):
>>
>> ins = ins->prev ? ins->prev : unit->instructions;
>
>
> Fixed too rev 8227
That ones certainly much happier! Brilliant.
Nick
>> Fixed, thanks for testing.
>
> Hmmm... Not seeing any improvement at my end ...
I don't see any indication that it is still broken. I ran "make test" on
two different boxes w/o failures (the 2 cases are
imcc/t/imcpasm/opt1_71.pir and _72.pir).
What is still failing? What says gdb/$DEBUGGER? Which paltform/OS?
leo
At the moment I'm on Windows/cygwin, and don't have access to Linux.
$ svn update
At revision 8234.
make clean & rebuild
$ perl -Ilib imcc/t/imcpasm/opt1.t
1..72
ok 1 - branch opt if
ok 2 - branch opt gt
...
ok 69 - constant add big nums
ok 70 # skip constant concat N/Y
not ok 71 - segv - last ins changed
# Failed test (imcc/t/imcpasm/opt1.t at line 1038)
# '# IMCC does produce b0rken PASM files
# # see http://gu...@rt.perl.org/rt3/Ticket/Display.html?id=32392
# main:
# @pcc_sub_call_0:
# set I0, 1
# set I1, 0
# set I2, 0
# set I3, 0
# set I4, 0
# set S1, ""
# set_p_pc P0, func
# invokecc
# end
# func:
# inc I30
# '
# doesn't match '/func:
# inc I\d+
# null I0
# null I3
# returncc
# /
# '
ok 72 - segv - last ins deleted
# Looks like you failed 1 test of 72.
It's doing the same from the command-line. Was the fix for opt1_71.pir
in r8227?
Cheers,
Nick
I'm seeing this failure too in Linux with r8234:
$ perl t/harness imcc/t/imcpasm/opt1.t
imcc/t/imcpasm/opt1....NOK 71
# Failed test (imcc/t/imcpasm/opt1.t at line 1038)
# '# IMCC does produce b0rken PASM files
# # see http://gu...@rt.perl.org/rt3/Ticket/Display.html?id=32392
# main:
# @pcc_sub_call_0:
# set I0, 1
# set I1, 0
# set I2, 0
# set I3, 0
# set I4, 0
# set S1, ""
# set_p_pc P0, func
# invokecc
# end
# func:
# inc I30
# '
# doesn't match '/func:
# inc I\d+
# null I0
# null I3
# returncc
# /
# '
imcc/t/imcpasm/opt1....ok 72/72# Looks like you failed 1 test of 72.
imcc/t/imcpasm/opt1....dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 71
>
>leo
>
-Dino
--
.~. Dino Morelli
/V\ email: dmor...@reactorweb.net
/( )\ weblog: http://categorically.net/d/blog/
^^-^^ preferred distro: Debian GNU/Linux http://www.debian.org