Thanks for the assembly code---you're running Solaris on x86!  Why 
didn't you say so before? :)

I think I have an idea what's going on:  it's the old extended-precision 
versus double-precision problem.  The calculation of c_exp is done in 
extended precision in the 80-bit registers of the x87 FPU.  The 
imaginary part of the result of c_exp(710+1.5j) is representable in 
extended precision, but is outside the range of double precision.   So 
at the point of the Py_IS_INFINITY call, the comparison is done in the 
FPU and the value being tested isn't infinity.  But sometime after that 
this value is forced out of the 80-bit extended precision FPU register 
and into memory, where it becomes a 64-bit IEEE 754 double precision 
infinity.

I guess the printf calls force the value from register to memory 
earlier, so that by the time of the Py_IS_INFINITY call it's already a 
64-bit double, and hence already an infinity.

Now to prove my theory by turning this into a fix, somehow.

It seems as though this problem isn't really specific to Solaris;  I 
guess it's just luck that it hasn't shown up on other x86 platforms.  It 
should certainly be fixed.


For the test_math failure, there have been problems with log on other 
platforms, too, mostly due to strange libm behaviour.  The obvious 
solution is to adapt the Python implementation to deal with special 
values itself, rather than leaving them to the platform math library.  
Should be a fairly straightforward change.