[rhettinger@users.sourceforge.net]

Modified Files: compile.c Log Message: Teach the peepholer to fold unary operations on constants.

Afterwards, -0.5 loads in a single step and no longer requires a runtime UNARY_NEGATIVE operation.

Aargh. The compiler already folded in a leading minus for ints, and exempting floats from this was deliberate. Stick this in a file: import math print math.atan2(-0.0, -0.0) If you run that directly, a decent 754-conforming libm will display an approximation to -pi (-3.14...; this is the required result in C99 if its optional 754 support is implemented, and even MSVC has done this all along). But if you import the same module from a .pyc or .pyo, now on the HEAD it prints 0.0 instead. In 2.4 it still prints -pi. I often say that all behavior in the presence of infinities, NaNs, and signed zeroes is undefined in CPython, and that's strictly true (just _try_ to find reassuring words about any of those cases in the Python docs <wink>). But it's still the case that we (meaning mostly me) strive to preserve sensible 754 semantics when it's reasonably possible to do so. Not even gonzo-optimizing Fortran compilers will convert -0.0 to 0.0 anymore, precisely because it's not semantically neutral. In this case, it's marshal that drops the sign bit of a float 0 on the floor, so surprises result if and only if you run from a precompiled Python module now. I don't think you need to revert the whole patch, but -0.0 must be left alone (or marshal taught to preserve the sign of a float 0.0 -- but then you have the problem of _detecting_ the sign of a float 0.0, and nothing in standard C89 can do so). Even in 754-land, it's OK to fold in the sign for non-zero float literals (-x is always unexceptional in 754 unless x is a signaling NaN, and there are no signaling NaN literals; and the sign bit of any finite float except zero is already preserved by marshal).