Changes by R. David Murray rdmur...@bitdance.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Larry Hastings added the comment:
Pull request accepted and merged.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
R. David Murray added the comment:
Here's the pull request:
https://bitbucket.org/larry/cpython350/pull-requests/4/21167-fix-definition-of-nan-when-icc-used/diff
--
status: closed - open
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset d9c85b6bab3a by R David Murray in branch '2.7':
#21167: Fix definition of NAN when ICC used without -fp-model strict.
https://hg.python.org/cpython/rev/d9c85b6bab3a
New changeset 5e71a489f01d by R David Murray in branch '3.4':
#21167: Fix
R. David Murray added the comment:
Thanks Chris, and Mark.
I ran the tests on 3.6 both on Linux (non ICC) and on Mac (with ICC without
-fp-model strict) and all the tests passed.
--
resolution: - fixed
stage: - resolved
status: open - closed
___
R. David Murray added the comment:
Larry, do you want this for 3.5.0a2? It's an innocuous patch for anyone not
using ICC, and makes ICC just work (with the default ICC build arguments) for
people using ICC. (Well, on (lin/u)nux and mac, anyway, I'm not sure we've
resolved all the ICC issues
Larry Hastings added the comment:
Assuming that ICC_NAN_STRICT is only on for Intel icc: yes, please.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
R. David Murray added the comment:
I've applied this patch to 2.7 on OSX and compiled without -fp-model strict,
and all of the tests now pass.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
R. David Murray added the comment:
Now, what's the equivalent patch for python3? Should I open a new issue for
that?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
R. David Murray added the comment:
Nevermind, I forgot to try and see if it applied...and it does :)
--
versions: +Python 3.4, Python 3.5, Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
Chris Hogan added the comment:
From Clark Nelson:
In my opinion, exactly how and where the macro is defined that indicates our
conformance to the FP standard
doesn't really matter. The point is that it is our intention to conform, at
least to some degree and under
some circumstances.
R. David Murray added the comment:
Note that Chris' patch is coming from Intel. (The ICC buildbots are currently
building with -fp-model strict, by the way.)
Mark, Stefan, what do you think? Is this a good idea? IIUC we would then not
have to worry about differentiating between the python
Chris Hogan added the comment:
Producing NaN by Py_HUGE_VAL / Py_HUGE_VAL as in the suggested patch is unsafe
as it can generate a FP exception during runtime. Also aggresive compiler FP
optimizations can eliminate this calculation on compile-time. For this reason,
we've used constant
Mark Dickinson added the comment:
Looks fine to me. IIRC, we moved the PyFloat_FromString implementation away
from using Py_NAN in Python 3 for exactly this reason.
On this point, though:
An aggressively optimizing compiler could treat 0 * x = 0 no matter what x is.
Wouldn't such a
Scholes C added the comment:
please disregard , the issue is resolved with your patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
Scholes C added the comment:
HI,
can you please look into this ?
thanks.
icc builds of python 2.7 seem to have issues handling nan, inf, etc
$ /usr/local/python-2.7.6/bin/python
Python 2.7.6 (default, Jan 10 2014, 12:14:02)
[GCC Intel(R) C++ gcc 4.1 mode] on linux2
Type help, copyright,
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list
Hrvoje Nikšić added the comment:
Note that defaulting to unsafe math in extensions will make *their* use of the
Py_NAN macro break under icc.
If we go that route (-fp-model strict for Python build, but not for
extensions), we should also apply the attached patch that defines Py_NAN as
Hrvoje Nikšić added the comment:
Using -fp-model strict (or other appropriate icc flag) seems like a reasonable
resolution.
It should likely also be applied to Python 3.x, despite the version field of
this issue. (Even if float('nan') happens to work in current 3.x, internal code
that
Stefan Krah added the comment:
Mark, if you agree that fp-model strict should not show up in
the distutils CFLAGS once Python is installed, the issue now depends
on #21121.
--
dependencies: +-Werror=declaration-after-statement is added even for extension
modules through setup.py
Mark Dickinson added the comment:
Sure, if that's really the expectation. I'm not sure I'd want any of *my*
extension modules being built with non-strict FP, but there's a bit of a
personal bias there.
--
___
Python tracker rep...@bugs.python.org
Stefan Krah added the comment:
I quite agree, and it's hard to tell what users want. Basically I'm afraid
of a bug report C extension using unsafe math got slower in Python-3.5.
I would find either decision reasonable.
--
___
Python tracker
New submission from Hrvoje Nikšić:
On a Python compiled with Intel C compiler, float('nan') returns 0.0. This
behavior can be reproduced with icc versions 11 and 12.
The definition of Py_NAN in include/pymath.h expects `HUGE_VAL * 0.0` to
compile to a NaN value on IEEE754 platforms:
/*
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Stefan Krah added the comment:
Did you compile with -fp-model strict? IIRC icc is not IEEE-754
compliant by default.
--
nosy: +skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
Changes by Jurica Bradarić jbrada...@gmail.com:
--
nosy: +jbradaric
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Python-bugs-list
Mark Dickinson added the comment:
What's `sys.float_repr_style` for this build? For Python 3.5 and short float
repr, `float('nan')` shouldn't even be using Py_NAN. It should land in
_Py_parse_inf_or_nan in pystrtod.c, which uses `_Py_dg_stdnan` to get the NaN
value directly from a suitable
Hrvoje Nikšić added the comment:
sys.float_repr_style is 'short'.
I haven't actually tried this in Python 3.5, but I did note the same definition
of Py_NAN (which is used elsewhere in the code), so I tagged the issue as
likely also present in 3.x.
--
Hrvoje Nikšić added the comment:
The compilation was performed with the default flags, i.e. without -fp-model
strict or similar.
If Python requires strict IEEE 754 floating-point, it should probably be
mentioned at a prominent place in the documentation. Administrators building
Python with
Mark Dickinson added the comment:
I tagged the issue as likely also present in 3.x.
So I believe that this particular issue (float('nan') giving zero) should not
be present on Python 3.4 or above. The bogus definition of Py_NAN will still
cause problems in some math and cmath return values,
Mark Dickinson added the comment:
If Python requires strict IEEE 754 floating-point,
It doesn't (at the moment).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
Changes by Mark Dickinson dicki...@gmail.com:
--
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21167
___
___
Hrvoje Nikšić added the comment:
Mark:
If Python requires strict IEEE 754 floating-point,
It doesn't (at the moment).
Does this imply that my patch is a better fix than requiring the builder to
specify -fp-model strict to icc?
For our use case either solution is valid. For administrators
Mark Dickinson added the comment:
It doesn't (at the moment).
Sorry; that was an unhelpful kneejerk reply.
There are two aspects to this. (1) Currently, at least in theory, CPython
doesn't require IEEE 754 *at all*: in theory, it should work with whatever
floating-point format the
Stefan Krah added the comment:
I agree we should add -fp-model strict to the icc build flags, provided that
there is a way that it does not show up in the distutils flags.
Apparently icc users want unsafe fast math by default, so this flag should
probably not be enforced in extension module
35 matches
Mail list logo
