[Alexander]
> The flags you may be looking for are -msse2 -mfpmath=sse

Thanks, Alexander!

[Alexander again, from an earlier post...]
> I noticed that you replaced a call to _PyLong_AsScaledDouble with your 
> round to nearest algorithm.  I wonder if _PyLong_AsScaledDouble itself 
> would benefit from your change.  Currently it is used in 
PyLong_AsDouble 
> and long_true_divide.  I would think that long_true_divide would be 
more 
> accurate if longs were rounded to the nearest float.

You read my mind!  I've got another issue open about making long 
division round correctly, somewhere.  And indeed I'd like to make 
_PyLong_AsScaledDouble do correct rounding.  (I'd also like to make it 
return the exponent in bits, rather than digits, so that mathmodule.c 
doesn't have to know about the long int representation, but that's 
another story...)

> I believe _PyLong_AsScaledDouble is written the way it is to support 
> non-IEEE floating formats, but I am not sure that your algorithm would 
> always return the nearest float on an arbitrary non-IEEE platform.

Well, I had other possible formats in mind when I wrote the code, and I 
hope it's good whenever FLT_RADIX is 2.  If you can think of explicit 
cases where it's not going to work, please let me know.  My belief that 
it's safe rests on two facts: (1) it entirely avoids IEEE 754 oddities 
like negative zero, denormals and NaNs, and (2) all the floating-point 
operations actually performed should have exact results, so rounding 
doesn't come into play anywhere.

When FLT_RADIX is some other power of 2 (FLT_RADIX=16 is the only 
example I know of that exists in the wild) the code probably doesn't 
produce correctly rounded results in all cases, but it shouldn't do 
anything catastrophic either---I think the error still should't be more 
than 1ulp in this case.  When FLT_RADIX is not a power of 2 then so much 
else is going to be broken anyway that it's not worth worrying about.