Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-05 13:24 Message: Logged In: YES user_id=6380 Hmm... There's a philosophical issue here. I'll post to python-dev (if anyone still reads that). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-17 05:47 Message: Logged In: YES user_id=6656 Oh, so maybe the fact that Lib/compiler has a problem in the same place *isn't* a problem with the compiler package... What ever gets done here should probably coincide with whatever happens in patch 661536. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 14:53 Message: Logged In: YES user_id=6380 I believe that test relies on the bug. :-( So the test should be fixed. The value ought to be equal to -(020000000000L). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 14:45 Message: Logged In: YES user_id=33168 The test fails because of line test_grammar.py:40: if -2147483647-1 != -020000000000: What should -020000000000 be? Without the -, it is: -(2**31)-1, so it can't be represented in an int (on 32-bit arches). With the patch, it is: 2147483648L. Later, I'll take a look at doing what Guido suggested. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 13:38 Message: Logged In: YES user_id=33168 mwh pointed out that my patch breaks test_grammar. I'll take another look later, unless Raymond beats me to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 12:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4