msg144604 - (view) |
Author: Joshua Bleecher Snyder (josharian) |
Date: 2011-09-29 17:27 |
When Python is compiled on OS X with llvm, the decimal module behaves erratically (simple calculations are wrong, most doctests fail). This was originally reported here: http://stackoverflow.com/questions/7590137/dividing-decimals-yields-invalid-results-in-python-2-5-to-2-7 and the compiler dependency was tracked down here: https://trac.macports.org/ticket/31444 Although it looks like MacPorts is going to force use of gcc, it'd still be better for Python to behave correctly when compiled with llvm. Possibly related to http://bugs.python.org/issue11149? |
|
|
msg144615 - (view) |
Author: Stefan Krah (skrah) *  |
Date: 2011-09-29 19:17 |
> Possibly related to http://bugs.python.org/issue11149? Maybe I missed it in the links you gave, but that is easily settled by compiling with and without -fwrapv. |
|
|
msg144623 - (view) |
Author: Joshua Bleecher Snyder (josharian) |
Date: 2011-09-29 19:45 |
>> Possibly related to http://bugs.python.org/issue11149? > Maybe I missed it in the links you gave, but that is easily > settled by compiling with and without -fwrapv. Apologies -- I didn't do enough homework on this one. Yes, I can confirm that compiling with -fwrapv solves this issue. Not sure whether that makes this bug a straight duplicate of http://bugs.python.org/issue11149... |
|
|
msg144637 - (view) |
Author: Stefan Krah (skrah) *  |
Date: 2011-09-29 20:41 |
It's more a straight duplicate of #12973, but the underlying cause (signed integer overflow) is the same. For people who are finding this via a search engine: A lot of bugs have been fixed in #12973, but even if the test suite passes without -fwrapv it is *still* recommended to use -fwrapv. Could anyone test if the attached patch works for llvm-gcc? |
|
|
msg144653 - (view) |
Author: Ned Deily (ned.deily) *  |
Date: 2011-09-29 22:31 |
There is some confusion here, I think. As best as I can tell, the original problem reported in the Stackoverflow question and to MacPorts involved using the clang compiler, not llvm-gcc and the Decimal problem reported here was only ever a problem when using clang. It's not an issue when using Apple's llvm-gcc compiler because the pre-#11149 configure test works properly with llvm-gcc. That test looks for "-fwrapv" in the compiler help string: $ llvm-gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ llvm-gcc -v --help 2>/dev/null | grep -- -fwrapv -fwrapv Assume signed arithmetic overflow wraps around $ gcc-4.2 --version i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gcc-4.2 -v --help 2>/dev/null |
grep -- -fwrapv -fwrapv Assume signed arithmetic overflow wraps around $ clang --version Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn) Target: x86_64-apple-darwin11.1.0 Thread model: posix $ clang -v --help 2>/dev/null |
grep -- -fwrapv The above was using the 3 Apple-supplied compilers with the OS X 10.7 (Lion) version of Xcode 4.1 (Build version 4B110). The 10.6 compiler versions should work the same way. So this issue should be closed as a duplicate of Issue11149. I'm setting it to pending and will close it if there are no objections. |