Skip to content

Commit e1091e0

Browse files
committed
Fix existing bug in the PREDICT() macro for the codepath without computed gotos
1 parent fc36be1 commit e1091e0

File tree

1 file changed

+5
-6
lines changed

1 file changed

+5
-6
lines changed

Python/ceval.c

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1372,6 +1372,7 @@ eval_frame_handle_pending(PyThreadState *tstate)
13721372
opcode = _Py_OPCODE(word); \
13731373
if (opcode == op) { \
13741374
oparg = _Py_OPARG(word); \
1375+
frame->f_lasti = INSTR_OFFSET(); \
13751376
next_instr++; \
13761377
goto PREDICT_ID(op); \
13771378
} \
@@ -1615,12 +1616,10 @@ _PyEval_EvalFrameDefault(PyThreadState *tstate, InterpreterFrame *frame, int thr
16151616
multiple values.
16161617
16171618
When the PREDICT() macros are enabled, some opcode pairs follow in
1618-
direct succession without updating frame->f_lasti. A successful
1619-
prediction effectively links the two codes together as if they
1620-
were a single new opcode; accordingly,frame->f_lasti will point to
1621-
the first code in the pair (for instance, GET_ITER followed by
1622-
FOR_ITER is effectively a single opcode and frame->f_lasti will point
1623-
to the beginning of the combined pair.)
1619+
direct succession. A successful prediction effectively links the two
1620+
codes together as if they were a single new opcode, but the value
1621+
of frame->f_lasti is correctly updated so potential inlined calls
1622+
or lookups of frame->f_lasti are aways correct when the macros are used.
16241623
*/
16251624
assert(frame->f_lasti >= -1);
16261625
_Py_CODEUNIT *next_instr = first_instr + frame->f_lasti + 1;

0 commit comments

Comments
 (0)