clang (as with gcc 4.x) assumes signed integer overflow is undefined. But Python depends on the fact that signed integer overflow wraps. 

Currently configure script adds -fwrapv flag for GCC (added by me back in the day), same should be done with clang.

Patch attached.

You should maybe add a test into _testcapi for this issue.

Currently test_overflow inside test_list fails without this patch. Is that good enough or should we create a specific test?

Ah, there is already a test for that: ok, it's fine and enough.

I am using LLVM/Clang 2.8 and test_list passes fine for me as-is. Does it only fail under 32 or 64-bit conditions? Configure compiles under 32-bits for me even though I have -arch x86_64 set.

This is only reproducable with clang 2.9 trunk builds due to new optimizations. Also note that clang commits confirm that -fwrapv must be provided if you assume signed integer overflow wraps. This was also the case with a spec test.

I tested this on OSX 10.6.6 with x86-64 build.

I think the patch is good to go, any comments/questions ?

This is a potential crasher.
It would also be nice if you listed those cases where Python assumes signed overflow behaviour. Can you open a separate issue for that?

@Antoine Pitrou , that is tracked by http://bugs.python.org/issue1621

Whats holding this up?

Someone having the time to do a patch review.

Brett, can you test this?

Can someone please review this patch? test_list fails with clang without this patch.

Recent clang and Python2.7 (without the patch):

Python 2.7.2+ (2.7:e8d8eb9e05fd, Sep 14 2011, 00:35:51) 
[GCC 4.2.1 Compatible Clang 3.0 (trunk 139637)] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.
>>> 2**63
-9223372036854775808
>>> 2**64
0
>>> 


The patch is fine and I'm going to commit it tomorrow if there are no
objections.

"Recent clang and Python2.7 (without the patch):

>>> 2**64
0"

Does the test suite catch this bug?

>>> 2**64
0

Urk!  I'd call that a release blocker.

> Does the test suite catch this bug?

I think all of those fail due to the bug in pow():

20 tests failed:
    test_array test_builtin test_bytes test_decimal test_float
    test_fractions test_getargs2 test_index test_int test_itertools
    test_list test_long test_long_future test_math test_random test_re
    test_strtod test_tokenize test_types test_xrange

New changeset 0f1e8c246a7b by Stefan Krah in branch '3.2':
Issue #11149: recent versions of clang require the -fwrapv flag.
http://hg.python.org/cpython/rev/0f1e8c246a7b

New changeset 637c67b34a1a by Stefan Krah in branch 'default':
Merge fix for issue #11149.
http://hg.python.org/cpython/rev/637c67b34a1a

New changeset feed6d2097b1 by Stefan Krah in branch '2.7':
Backport fix for issue #11149.
http://hg.python.org/cpython/rev/feed6d2097b1

The new issue #12980 may be a regression introduced by this issue.

No, that's me playing around. I tried to use clang as the compiler
for the build slave. I can't figure out yet why the segfaults occur.

When I'm running the test manually, everything seems to work.

The buildbots are fine, though I think that in this instance
Gentoo-Non-Debug-3.x is the only bot that actually exercises
the new code path.

So I tested manually on FreeBSD/clang-3.0 and I don't see
anything surprising.

The fix that was committed doesn't work if CC is a full path like /usr/bin/clang.

New changeset 7efad6256e58 by Stefan Krah in branch '3.2':
Issue #11149: Also enable -fwrapv if $CC is a full path
http://hg.python.org/cpython/rev/7efad6256e58

New changeset e48df59af394 by Stefan Krah in branch 'default':
Merge second fix for issue #11149.
http://hg.python.org/cpython/rev/e48df59af394

New changeset 9d329adbbb01 by Stefan Krah in branch '2.7':
Backport second fix for issue #11149.
http://hg.python.org/cpython/rev/9d329adbbb01