Apple Radar ticket 9908625 has been filed. The clang 2.1 optimizer causes overflows in Object/intobject.c:int_pow() to be missed, so 2**63 turns into a negative integer. The attached test program narrows it down. llvm-gcc is fine, so this ticket is mostly an FYI.

idiotbox:Python-2.7.2 cloomis$ ./seqpoint-OK 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=-611686018
overflow detected: 1

  to turn into:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4294967296 4200000000
a=4294967296, b=4200000000, c(a*b)=-407881430509551616, c/b=4294967296
overflow detected: 0

Blecch: cut-o.
The bad case should have been the matching:

idiotbox:Python-2.7.2 cloomis$ ./seqpoint 4000000000 4000000000
a=4000000000, b=4000000000, c(a*b)=-2446744073709551616, c/b=4000000000
overflow detected: 0

Have you checked if -fwrapv is in the list of compiler arguments in the generated makefile?

There is an open issue about adding that flag when clang is used as the compiler (the flag is already used for gcc). The flag is necessary because the example code contains an integer overflow and that is undefined behavior according to the C standard.

Yup, that was it. Something new learnt. Thanks.

Not sure how to have configure spot that clang needs the flag. OK, the configure stanza for gcc is hardly general; maybe trying $(CC) -fwrapv and  keeping the flag if that does not blow up on the pad? But I guess that other ticket takes care of that.

If there's dependence on undefined behaviour (from overflow of signed integer operations) in intobject.c, I'd call that a bug.  I've been trying to remove similar overflow checks from the Python source when I've encountered them, but there are still a good few left.

Clang has an option "-fcatch-undefined-behavior" that might help in locating other locations where we use undefined behavior.

Is this still a problem in clang 3.2?

I believe the int_pow issue has been resolved, so this bug shouldn't show up in any of the current branches, regardless of which version of Clang is used.

Issue #12973 is the one that led to the eventual fix.  Closing this as a duplicate.