>>It also doesn't agree with what 'man log1p' says on my OS X 10.6
>>Macbook:  under 'SPECIAL VALUES', it says:  'log1p(+-0) returns +-0.'

That manpage is unchanged for 10.8.

>>I'm puzzled about one thing, though:  there's a test for this problem
>>in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in
>>this case---in that case, the two testAtanSign and testAtanhSign tests
>>are skipped.  So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being
>>defined on this machine;  I'm not sure why---there may be a compiler
>>optimization kicking in in the configure test.

Ah, this rings a bell and points out yet another issue:

1. The configure test is working properly: when run on 10.8, LOG1P_DROPS_ZERO_SIGN is set to 1.  However, something I just ran into recently, the unittest skip idiom using sysconfig.get_config_vars results - as is being used here in test_cmath - doesn't seem to work properly.  I see it is used in test_math and test_subprocess as well.  I'll look into that.

2. These types of run-time tests based on configure-time tests are problematic for binary installations of Python, like the OS X installers.  For example, the OS X installers are built on earlier versions of OS X where a configuration test (like this one) may have one result but not necessarily the same result on all supported target configurations where the binary Pythons may be installed.  And, in general, multiple-architecture builds, in particular, OS X universal builds may have different configuration values per architecture embedded in one executable (i386 vs x86_64 or i386 vs ppc or i386 vs x86_64 vs ppc) that are not reflected in the single architecture ./configure results.  I guess it's time to open an issue on that can of worms.

>>(Is this clang or gcc, BTW?)

It's clang which is now the only supported option with Xcode 4.4 on either 10.7 or 10.8.  More importantly, 10.8 is the first OS X release which itself was built with clang; 10.7 was built with the transitional llvm-gcc compiler.