There are some buildbot failures due to platform-specific bugs that need
to be marked as expected failures, using the unittest.expectedFailure
decorator.  This may require reorganizing the tests slightly.

* tanh(-0.0) produces 0.0 instead of -0.0 on FreeBSD 6;  this causes
test_math and test_cmath to fail.  E.g.,

http://www.python.org/dev/buildbot/builders/x86%20FreeBSD%20trunk/builds/2741

* the libm round function on Debian alpha seems to be buggy;  this
causes test_round in test_builtin.py to fail.  E.g.,

http://www.python.org/dev/buildbot/builders/alpha%20Debian%20trunk/builds/30

Oops.  I meant 'platform' bugs, not 'platform-specific' bugs.  These are
not bugs in Python, but in the underlying C library.

For 2.6.4 I get a test_float failure on Solaris as well:

test test_float failed -- Traceback (most recent call last):
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 765, in test_roundtrip
   self.identical(-x, roundtrip(-x))
 File "/home/tuba/skipm/src/python/Python-2.6.4/Lib/test/test_float.py",
line 375, in identical
   self.fail('%r not identical to %r' % (x, y))
AssertionError: -0.0 not identical to 0.0

Haven't looked at 2.7 or 3.1 yet, but it seems to fall into the same
class of test failures as the tanh(-0.0) critter.

May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
set by configure check.

Skip, that looks like a float.hex failure.  I'm not sure what the 
underlying problem is here;  my best guess is that it's something to do 
with the copysign function.  Please could you tell me what the Solaris 
results are for the following interactive session? (Results shown are on 
OS X 10.5.)

Python 2.6.4+ (release26-maint:76116, Nov  5 2009, 13:30:59) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> (-0.0).hex()
'-0x0.0p+0'
>>> float.fromhex((-0.0).hex())
-0.0
>>> math.copysign(1.0, -0.0)
-1.0

Also, is HAVE_COPYSIGN defined in pyconfig.h?

> May be one day python modules will deal with TANH_PRESERVES_ZERO_SIGN
> set by configure check.

Maybe.  I added that configure check mainly as a diagnostic, to verify a 
suspected cause of test failures.  I'm not sure to what degree it's worth 
working around system libm bugs in the Python source:  an explosion of 
#ifdefs in mathmodule.c and cmathmodule.c would reduce readability and 
maintainability.

The test_round failure on Debian alpha is likely related to this glibc 
bug:

http://sources.redhat.com/bugzilla/show_bug.cgi?id=5350

The round tests for large values have been broken out into their own test;  
this test is now skipped (only if it would fail) on Linux/alpha.  See 
r76176 (trunk), r76177 (py3k) and r76178 (release31-maint).

The round function itself needs fixing in release26-maint:  issue #7070.

The round function in release26-maint is fixed (r76179).  I'm not sure 
whether the round_large test needs to be skipped for release26-maint, 
since the Python  2.6 version of round doesn't use the libm round 
function.

The tanh-related failures are no longer happening, since the FreeBSD 
buildbot was upgraded from FreeBSD 6.2 to FreeBSD 6.4.

I'm still worried by Skip's report, but that's a separate issue.

Closing.

Postscript:  the failure Skip reported looks like a duplicate of issue 9069, which was tracked down to a gcc compiler bug in gcc 4.4.x (x <= 4) and gcc 4.5.x (x <= 0).  That compiler bug is now fixed.