[LLVMbugs] [Bug 10923] New: Optimiser problem: shows up in Python's pow()

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=10923

           Summary: Optimiser problem: shows up in Python's pow()
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: adam at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7262)
 --> (http://llvm.org/bugs/attachment.cgi?id=7262)
Test program to demonstrate the problem.

The problem showed up when I compiled Python 2.7.2 with Clang-trunk (dated
September 23, 2011), but exactly the same problem occurs for Clang from Xcode
4.2 beta 7 (tags/Apple/clang-211.9).

Running 'python' compiled with clang-3.0-trunk:
>>> 2**63
-9223372036854775808
>>> 2**64
0

Correct results should be:
>>> 2**63
9223372036854775808L
>>> 2**64
18446744073709551616L

When Python is compiled without optimisations (-O0), the problems does not
occur.

I extracted int_pow() function from Python 2.7.2 source code
(Objects/intobject.c) and made a test program (attached as pow.c).

Compiling and running with and without optimisations gives different results:

% clang -Wall -o pow pow.c ; ./pow
case 2: PyLong_Type.tp_as_number->nb_power
0
% clang -Wall -O1 -o pow pow.c ; ./pow
0

The function works correctly after switching types from "long" to "unsigned
long". I guess some operations are optimised out and the condition leading to
"case 2" never happends.

Please, fix. :)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.