You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In DUALNUM, the behaviour of BC_FORI is subtly different between the interpreter and the JIT: if the loop control variables all fit as integers but stop+step overflows, then the interpreter will choose to have all the control variables as integers but the JIT will choose to have all the control variables as numbers. This is mostly fine, but there's one place it can cause problems.
In DUALNUM, JIT-compilation of BC_FORL will elide type checks for the loop control variables if they're all initialised by constants outside the loop and the runtime type of those variables at recording-time matches the type chosen by the JIT for those variables. Unfortunately, the runtime type of those variables can differ if stop+step overflows (because of the BC_FORI difference).
The following example shows this:
localfunctionf(case)
ifcase==0thenendlocaln=0fori=2147483580, 2147483647doifcase==1thenbreakendn=n+1endreturnnend-- Compile the head of f, up to and including the FORI:fori=1, 50dof(1) endfori=1, 50dof(1) endfori=1, 50dof(1) end-- Initialise f's loop with a compiled FORI, then compile the FORL:localf2=f(2)
-- Initialise f's loop with an interpreted FORI, then hit the compiled FORL:localf0=f(0)
-- This can fail on DUALNUM:assert(f2==f0)
In DUALNUM, the behaviour of
BC_FORI
is subtly different between the interpreter and the JIT: if the loop control variables all fit as integers but stop+step overflows, then the interpreter will choose to have all the control variables as integers but the JIT will choose to have all the control variables as numbers. This is mostly fine, but there's one place it can cause problems.In DUALNUM, JIT-compilation of
BC_FORL
will elide type checks for the loop control variables if they're all initialised by constants outside the loop and the runtime type of those variables at recording-time matches the type chosen by the JIT for those variables. Unfortunately, the runtime type of those variables can differ if stop+step overflows (because of theBC_FORI
difference).The following example shows this:
One possible solution might be:
The text was updated successfully, but these errors were encountered: