[Python-bugs-list] [ python-Bugs-757818 ] tuple assignment -- SystemError: unknown opcode

SourceForge.net noreply@sourceforge.net
Fri, 20 Jun 2003 07:20:05 -0700


Bugs item #757818, was opened at 2003-06-20 11:19
Message generated for change (Comment added) made by jhylton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Mark J (average)
Assigned to: Nobody/Anonymous (nobody)
Summary: tuple assignment -- SystemError: unknown opcode

Initial Comment:
Python 2.3b1 (#2, Jun  4 2003, 03:08:06)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
>>> i,j = True and (1, -1) or (-1, 1)
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = True and (1, -1)  #works
>>> True and (1, -1) or (-1, 1)  #also works
(1, -1)
>>> i,j = (1, -1) or (-1, 1) #nope
XXX lineno: 1, opcode: 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: unknown opcode
>>> i,j = False and (1, -1) or (-1, 1) #works
>>> i,j
(-1, 1)

Thanks guys!

Mark

P.S. -1 on keyword initialization of dictionary (Liskov)
P.P.S. +1 on adding keys from iterable

$0.02 (*clink*)

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2003-06-20 14:20

Message:
Logged In: YES 
user_id=31392

The failure is a little more obvious if you look at the code
that was generated before optimization.  (I disassembled the
2.2 bytecode.)  The optimization don't respect basic block
boundaries.  In this case, the code that builds seq and
unpacks seq spans two blocks.  Since it's possible to jump
to the unpack, it can't be optimized away.

          0 SET_LINENO               1

          3 SET_LINENO               2
          6 LOAD_GLOBAL              0 (True)
          9 JUMP_IF_FALSE           10 (to 22)
         12 POP_TOP             
         13 LOAD_CONST               1 (1)
         16 LOAD_CONST               2 (-1)
         19 BUILD_TUPLE              2
    >>   22 JUMP_IF_TRUE            10 (to 35)
         25 POP_TOP             
         26 LOAD_CONST               2 (-1)
         29 LOAD_CONST               1 (1)
         32 BUILD_TUPLE              2
    >>   35 UNPACK_SEQUENCE          2
         38 STORE_FAST               0 (i)
         41 STORE_FAST               1 (j)
         44 LOAD_CONST               0 (None)
         47 RETURN_VALUE        


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-06-20 13:01

Message:
Logged In: YES 
user_id=45365

Looks like one of the recent peephole optimizations is to blame, if 
I disassemble a function with i,j = True and (1, -1) or (-1, 1) in it 
I get:
  2           0 LOAD_GLOBAL              0 (True)
              3 JUMP_IF_FALSE           10 (to 16)
              6 POP_TOP             
              7 LOAD_CONST               1 (1)
             10 LOAD_CONST               2 (-1)
             13 BUILD_TUPLE              2
        >>   16 JUMP_IF_TRUE            10 (to 29)
             19 POP_TOP             
             20 LOAD_CONST               2 (-1)
             23 LOAD_CONST               1 (1)
             26 ROT_TWO             
             27 JUMP_FORWARD             2 (to 32)
             30 DUP_TOP             
             31 POP_TOP             
        >>   32 STORE_FAST               0 (i)
             35 STORE_FAST               1 (j)
             38 LOAD_CONST               0 (None)
             41 RETURN_VALUE        

Note the jump at address 16 going to 29, which isn't at an 
instruction boundary. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757818&group_id=5470