Optimiser problem: shows up in Python's pow()

[llvmbot]

Bugzilla Link	10923
Resolution	INVALID
Resolved on	Sep 13, 2011 08:44
Version	trunk
OS	All
Attachments	Test program to demonstrate the problem.
Reporter	LLVM Bugzilla Contributor

Extended Description

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:

263
-9223372036854775808
264
0

Correct results should be:

263
9223372036854775808L
264
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. :)

[llvmbot]

The C language standard says that overflowing signed arithmetic results in
undefined behaviour. Since temp / prev != prev can only be true if there
was a signed arithmetic overflow, the compiler is allowed to assume that
this never occurs. Use unsigned arithmetic instead.