Re: [Python-checkins] python/dist/src/Python compile.c, 2.344, 2.345
tim.peters at gmail.com
Wed Feb 23 03:57:22 CET 2005
[rhettinger at users.sourceforge.net]
> Modified Files:
> 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:
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
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).
More information about the Python-Dev