I believe you're right. The 2.7.2 MacPorts portfile definitely passes the -fwrapv flag to clang, but the bad behavior still occurs with exponents. I verified the current head of the 2.7 branch does not have this problem when built with clang, so I'm assuming that issue12973 resolved this with a patch to int_pow() and that it will be out in the next release.
-Derek On Thu, Nov 3, 2011 at 4:30 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Wed, 2 Nov 2011 19:41:30 -0700 > Guido van Rossum <gu...@python.org> wrote: >> Apparently Macports is still using a buggy compiler. > > If I understand things correctly, this is technically not a buggy > compiler but Python making optimistic assumptions about the C standard. > (from issue11149: "clang (as with gcc 4.x) assumes signed integer > overflow is undefined. But Python depends on the fact that signed > integer overflow wraps") > > I'd happily call that a buggy C standard, though :-) > > Regards > > Antoine. > > >> I reported a >> similar issue before and got this reply from Ned Delly: >> >> """ >> Thanks for the pointer. That looks like a duplicate of Issue11149 (and >> Issue12701). Another manifestation of this was reported in Issue13061 >> which also originated from MacPorts. I'll remind them that the >> configure change is likely needed for all Pythons. It's still safest to >> stick with good old gcc-4.2 on OS X at the moment. >> """ >> >> (Those issues are on bugs.python.org.) >> >> --Guido >> >> On Wed, Nov 2, 2011 at 7:32 PM, Derek Shockey <derek.shoc...@gmail.com> >> wrote: >> > I just found an unexpected behavior and I'm wondering if it is a bug. >> > In my 2.7.2 interpreter on OS X, built and installed via MacPorts, it >> > appears that integers are not correctly overflowing into longs and >> > instead are yielding bizarre results. I can only reproduce this when >> > using the exponent operator with two ints (declaring either operand >> > explicitly as long prevents the behavior). >> > >> >>>> 2**100 >> > 0 >> >>>> 2**100L >> > 1267650600228229401496703205376L >> > >> >>>> 20**20 >> > -2101438300051996672 >> >>>> 20L**20 >> > 104857600000000000000000000L >> > >> >>>> 10**20 >> > 7766279631452241920 >> >>>> 10L**20L >> > 100000000000000000000L >> > >> > To confirm I'm not crazy, I tried in the 2.7.1 and 2.6.7 installations >> > included in OS X 10.7, and also a 2.7.2+ (not sure what the + is) on >> > an Ubuntu machine and didn't see this behavior. This looks like some >> > kind of truncation error, but I don't know much about the internals of >> > Python and have no idea what's going on. I assume since it's only in >> > my MacPorts installation, it must be build configuration issue that is >> > specific to OS X, perhaps only 10.7, or MacPorts. >> > >> > Am I doing something wrong, and is there a way to fix it before I >> > compile? I could find any references to this problem as a known issue. >> > >> > Thanks, >> > Derek >> > _______________________________________________ >> > Python-Dev mailing list >> > Python-Dev@python.org >> > http://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/derek.shockey%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
