On Thu May 24 14:45:02 2007, coke wrote:
> ... or so I think:
> 
> This works:
> 
> .sub zero_check
> 
>    push_eh one
>      $N0 = 0.0
>      $N1 = 3 / $N0
>    clear_eh
> 
> one:
>    print "ok\n"
> .end
> 
> 
> This doesn't:
> 
> .sub zero_check
> 
>    push_eh one
>      $N1 = 3 / 0.0
>    clear_eh
> 
> one:
>    print "ok\n"
> .end
> 
> Guessing that imcc is doing constant folding without the guards that  
> the ops use.
> 
> mj41++ for prompting the test.
> 
> --
> Will "Coke" Coleda
> [EMAIL PROTECTED]
> 
> 
Ok. What was really happening is that IMCC actually invoking the
appropriate opcode (at compile time) and then immediately (during
compile!) throwing the error from the opcode; this generated an
appropriate exception, but during the compile phase, so it circumvented
the exception handlers we tried to set in the PIR.

I applied a patch that if during this particular type of constant
folding, if an exception occurs when running the opcode, abort the
optimization. This allows the runtime to catch the error as we expected.

This in turn exposed one invalid test each in t/op/{number,integer}.t
that tested opcodes that don't exist: because we invoked the constant
folding, the invalid opcode was never actually seen... removed those tests.

Also added a (now passing) test in t/compilers/syn/imcc/regression.t.

See r26657.


Reply via email to