homepage

On ppc64, on this box, with glibc-2.14.90-19.ppc64, test_cmath fails with:
======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 352,
in test_specific_values
 msg=error_message)
 File "/builddir/build/BUILD/Python-2.7.2/Lib/test/test_cmath.py", line 112,
in rAssertAlmostEqual
 '{!r} and {!r} are not sufficiently close'.format(a, b))
AssertionError: acos0200: acos(complex(1.620686051868302e+308,
1.0308426226285283e+308))
Expected: complex(0.5665082609382622, -710.5420687424156)
Received: complex(0.5665082609382622, -inf)
Received value insufficiently close to expected value.
It turns out (after much debugging) that libm in this version of glibc has an architecture-specific implementation of hypot(3) which returns inf in many of the test cases in tests/cmath_testcases.txt, when the non-architecture-specific implementation returns large finite values.
See downstream bug in Fedora's bug tracker:
 https://bugzilla.redhat.com/show_bug.cgi?id=750811
for more details.
Seen with the Python 2.7.2 tarball, but the code doesn't appear to have changed in hg in either the default or the 2.7 branches.
I will also file a bug in glibc's bug tracker about this.

Reported in glibc's bug tracker as:
 http://sourceware.org/bugzilla/show_bug.cgi?id=13472 

The glibc bug has been fixed in that project's git repo:
http://repo.or.cz/w/glibc.git/commit/850fb039cec802072f70ed9763927881bbbf639c 

Thanks for the report, and all the sleuthing. It's always good to see Python's test suite expose C library (or C compiler) bugs. :-)
I propose closing this as 'won't fix': I certainly wouldn't want to add workarounds in the cmath source (though in theory that would be possible). I don't really think it's worth adding special cases to the test-suite, either. What do you think?

I agree. I filed this here in case anyone else ran into it, but given that this is really a glibc bug (now fixed), I'm closing this out as "won't fix".