Repository navigation
Require IEEE 754 floating point to build Python 3.11 #91073
Description
| BPO | 46917 |
|---|---|
| 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 = None
created_at = <Date 2022-03-03.22:39:43.097>
labels = ['build', '3.11']
title = 'Require IEEE 754 floating point to build Python 3.11'
updated_at = <Date 2022-03-10.16:56:24.469>
user = 'https://github.com/vstinner'bugs.python.org fields:
activity = <Date 2022-03-10.16:56:24.469>
actor = 'vstinner'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2022-03-03.22:39:43.097>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 46917
keywords = ['patch']
message_count = 7.0
messages = ['414485', '414575', '414847', '414862', '414863', '414865', '414866']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'vstinner']
pr_nums = ['31790', '31793']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue46917'
versions = ['Python 3.11']
Activity
vstinner commentedon Mar 3, 2022
See "[Python-Dev] Should we require IEEE 754 floating-point for CPython?" thread:
https://mail.python.org/archives/list/python-dev@python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
I propose to require IEEE 754 floating-point to build Python 3.11. I propose the following build:
The _PY_SHORT_FLOAT_REPR==0 code path is kept. For now, platforms with float larger than 64-bit but without HAVE_PY_SET_53BIT_PRECISION are still supported (but don't get "short float repr"). See #75773 for details.
I prepared this requirement with these two changes:
commit 1b2611e
Author: Victor Stinner <vstinner@python.org>
Date: Fri Feb 25 01:32:57 2022 +0100
commit 5ab745f
Author: Victor Stinner <vstinner@python.org>
Date: Sat Feb 26 00:53:27 2022 +0100
By the way, building Python 3.11 now requires a C11 compiler.
mdickinson commentedon Mar 5, 2022
That sounds fine.
I'd suggest leaving those decorators. Some of the tests are used by Python implementations other than CPython, and we're not requiring IEEE 754 on all Python implementations.
Sounds fine.
I'm assuming you mean Python "float" / C "double" here. There seems to be a persistent misunderstanding here, and I'd really like to be sure that everyone understands what the current code is doing before changing anything. There are *no* platforms that Python cares about where the C double is larger than 64-bits, and as far as I'm aware there never have been.
What there *is* is a set of platforms where the C double is IEEE 754 binary64 format, but where arithmetic operations between doubles may be performed in extended precision (usually 64-bit precision), so those arithmetic operations don't conform strictly to IEEE 754 semantics. Most flavours of Linux on x86 match that description.
Then there's a (possibly empty, but we don't know that for sure) subset of *that* set of platforms where we don't know how to temporarily enforce 53-bit precision during numeric parsing / formatting operations.
It's that second subset where dtoa.c can't be used, and where we need the fallback of the "legacy" float repr.
I'd be more than happy to deprecate and eventually remove support for the legacy float repr, but I think it's too big a change to make for 3.11: we'd need to deprecate the support for 3.11 and eventually remove it in 3.13.
vstinner commentedon Mar 10, 2022
New changeset 9b51fd5 by Victor Stinner in branch 'main':
bpo-46917: Require IEEE 754 to build Python (GH-31790)
9b51fd5
vstinner commentedon Mar 10, 2022
See also bpo-46906 "Add PyFloat_(Pack|Unpack)(2|4|8) to the public C API": the implementation supports non-IEEE 754 formats. Once the public C API is added, support for non-IEEE 754 formats should be removed.
vstinner commentedon Mar 10, 2022
New changeset 7854012 by Victor Stinner in branch 'main':
bpo-46917: math.nan is now always available (GH-31793)
7854012
vstinner commentedon Mar 10, 2022
Technically, it was already the case in practice: see bpo-46656 for the rationale and the history of Py_NAN.
vstinner commentedon Mar 10, 2022
The code to support missing NaN was already removed by:
New changeset 1b2611e by Victor Stinner in branch 'main':
bpo-46656: Remove Py_NO_NAN macro (GH-31160)
1b2611e
In fact, math.inf is already always available in Python 3.10 and older. There was no "#ifdef" for missing infinity support. In Python 3.10, math.inf is implemented as:
mdickinson commentedon Apr 11, 2022
@vstinner Can this be closed?
vstinner commentedon Apr 19, 2022
I still would like to:
vstinner commentedon Oct 12, 2022
Sorry but I failed to find the bandwidth to get ride of this code, so I will just close the issue.
If someone wants to work on that, please go ahead and write a PR and maybe open a new dedicated issue (specific to this).
At least, the main part, requiring IEEE 754 to build Python, is implemented in Python 3.11! It's written in What's New in Python 3.11 ;-)
vstinner commentedon Nov 6, 2025
@skirpichev: Why did you reopen this old issue?
skirpichev commentedon Nov 6, 2025
@vstinner, it was based on your comment:
Did you change your mind on this?
vstinner commentedon Nov 6, 2025
I tried but failed to remove this code. Go ahead if you're motivated. But since this issue was closed 3 years ago, I would suggest opening a new issue instead.