Repository navigation
Remove the Py_NO_NAN macro: require NAN to build Python 3.11 #90814
Description
| BPO | 46656 |
|---|---|
| Nosy | @mdickinson, @vstinner |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2022-02-25.00:45:52.191>
created_at = <Date 2022-02-06.09:54:34.993>
labels = ['interpreter-core', 'type-bug', 'build', '3.11']
title = 'Remove the Py_NO_NAN macro: require NAN to build Python 3.11'
updated_at = <Date 2022-03-10.16:52:54.326>
user = 'https://github.com/mdickinson'bugs.python.org fields:
activity = <Date 2022-03-10.16:52:54.326>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2022-02-25.00:45:52.191>
closer = 'vstinner'
components = ['Build', 'Interpreter Core']
creation = <Date 2022-02-06.09:54:34.993>
creator = 'mark.dickinson'
dependencies = []
files = []
hgrepos = []
issue_num = 46656
keywords = ['patch']
message_count = 13.0
messages = ['412620', '412621', '412625', '412629', '412630', '412632', '412636', '412640', '412642', '412864', '413944', '413945', '414864']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'vstinner']
pr_nums = ['31160', '31557']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46656'
versions = ['Python 3.11']
Activity
mdickinson commentedon Feb 6, 2022
The macro Py_NAN may or may not be defined: in particular, a platform that doesn't have NaNs is supposed to be able to define Py_NO_NAN in pyport.h to indicate that.
But not all of our uses of
Py_NANare guarded by suitable #ifdef conditionals. As a result, compilation fails if Py_NAN is not defined.mdickinson commentedon Feb 6, 2022
Here's the first point of failure on my machine. Fixing this shows up more failures.
gcc -c -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Objects/complexobject.o Objects/complexobject.c
Objects/complexobject.c:120:27: error: use of undeclared identifier 'Py_NAN'
r.real = r.imag = Py_NAN;
^
Objects/complexobject.c:206:16: error: use of undeclared identifier 'Py_NAN'
return Py_NAN;
^
2 errors generated.
make: *** [Objects/complexobject.o] Error 1
vstinner commentedon Feb 6, 2022
Python uses Py_NAN without "#ifdef Py_NAN" guard since 2008. Building Python with Py_NO_NAN never worked. Nobody reported such build failure in the last 14 years...
IMO it's time to stop supporting platforms without NaN support.
I only try a few Python versions: I reproduce this issue in Python 3.11, 3.5, 3.2 and... even Python 2.7!
The Py_NO_NAN macro was introduced in Python 2.6 (2007) by bpo-1635 "Float patch for inf and nan on Windows (and other platforms)":
commit 0a8143f
Author: Christian Heimes <christian@cheimes.de>
Date: Tue Dec 18 23:22:54 2007 +0000
(...)
+#if !defined(Py_NAN) && !defined(Py_NO_NAN)
+#define Py_NAN (Py_HUGE_VAL * 0.)
+#endif
---
The following change started to use Py_NAN in many C files:
---
commit 6f34109 (HEAD)
Author: Christian Heimes <christian@cheimes.de>
Date: Fri Apr 18 23:13:07 2008 +0000
ork of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and
edge cases related to operations with NaN, INF, very small values and complex math.
ces between platforms like different results or exceptions for edge cases. Have fun :)
---
At this commit, floatobject.c and pymath.c use "#ifdef Py_NAN" carefully, whereas cmathmodule.c and complexobject.c use Py_NAN with no "#ifdef Py_NAN" guard.
vstinner commentedon Feb 6, 2022
If someone suddenly requires platforms without NaN support, they can maintain a (downstream) patch, or we can revert the change in Python.
vstinner commentedon Feb 6, 2022
See also bpo-46640 "Python can now use the C99 NAN constant or __builtin_nan()".
mdickinson commentedon Feb 6, 2022
Okay, the comments I made on bpo-46640 still apply (even though they didn't properly apply on that issue). I think this needs a python-dev discussion before it can be moved forward - requiring the existence of NaNs is very close to requiring IEEE 754 floating-point, and that's something we've been historically reluctant to do.
vstinner commentedon Feb 6, 2022
Is the macro PY_NO_SHORT_FLOAT_REPR also related to platforms which don't support IEEE 754?
In 2022, which platforms don't support IEEE 754?
8 remaining items
[-]Compile fails if Py_NO_NAN is defined[/-][+]Remove the Py_NO_NAN macro: require NAN to build Python 3.11[/+][-]Compile fails if Py_NO_NAN is defined[/-][+]Remove the Py_NO_NAN macro: require NAN to build Python 3.11[/+]vstinner commentedon Mar 10, 2022
Change documented by:
New changeset 7854012 by Victor Stinner in branch 'main':
bpo-46917: math.nan is now always available (GH-31793)
7854012
pythongh-90814: Correct NEWS wording re. optional C11 features
gh-90814: Correct NEWS wording re. optional C11 features (GH-96309)
pythongh-90814: Correct NEWS wording re. optional C11 features (pytho…
gh-90814: Correct NEWS wording re. optional C11 features (GH-96309) (G…