GeezerVison is showing github.com — Require IEEE 754 floating point to build Python 3.11 · Issue #91073 · python/cpython
Require IEEE 754 floating point to build Python 3.11 #91073Description
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'] Activityvstinner commented on Mar 3, 2022 See "[Python-Dev] Should we require IEEE 754 floating-point for CPython?" thread:
https://mail.python.org/archives/list/[email protected]/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/
I propose to require IEEE 754 floating-point to build Python 3.11. I propose the following build:
- Mention the new build requirement in What's New in Python 3.11.
- Modify configure script to make it fail if the IEEE 754 support is missing.
- Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.
- Remove @requires_IEEE_754 decorator of test.support and tests.
- Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).
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 <[email protected]>
Date: Fri Feb 25 01:32:57 2022 +0100
bpo-46656: Remove Py_NO_NAN macro (GH-31160)
Building Python now requires support for floating point Not-a-Number
(NaN): remove the Py_NO_NAN macro.
commit 5ab745f
Author: Victor Stinner <[email protected]>
Date: Sat Feb 26 00:53:27 2022 +0100
bpo-46852: Remove the float.__set_format__() method (GH-31585)
Remove the undocumented private float.__set_format__() method,
previously known as float.__set_format__() in Python 3.7. Its
docstring said: "You probably don't want to use this function. It
exists mainly to be used in Python's test suite."
By the way, building Python 3.11 now requires a C11 compiler. mdickinson commented on Mar 5, 2022
- Mention the new build requirement in What's New in Python 3.11.
- Modify configure script to make it fail if the IEEE 754 support is missing.
- Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.
That sounds fine.
- Remove @requires_IEEE_754 decorator of test.support and tests.
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.
- Remove "unknown_format" code path of pack/unpack functions like _PyFloat_Pack8() (see bpo-46906 which proposes to make these functions public).
Sounds fine.
platforms with float larger than 64-bit
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 commented on Mar 10, 2022 vstinner commented on 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 commented on Mar 10, 2022 vstinner commented on Mar 10, 2022
bpo-46917: math.nan is now always available (GH-31793)
Technically, it was already the case in practice: see bpo-46656 for the rationale and the history of Py_NAN. vstinner commented on Mar 10, 2022
Remove code handling missing NAN and infinity: float("nan"), float("inf"), math.nan and math.inf are always available.
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:
static double
m_inf(void)
{
#ifndef PY_NO_SHORT_FLOAT_REPR
return _Py_dg_infinity(0);
#else
return Py_HUGE_VAL;
#endif
}mdickinson commented on Apr 11, 2022 vstinner commented on Apr 19, 2022 I still would like to:
Remove "unknown_format" code path of pack/unpack functions
Reacted by Mark Dickinson vstinner commented on Oct 12, 2022
Remove "unknown_format" code path of pack/unpack functions
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 commented on Nov 6, 2025 skirpichev commented on Nov 6, 2025 @vstinner, it was based on your comment:
I still would like to: Remove "unknown_format" code path of pack/unpack functions
Did you change your mind on this? vstinner commented on 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.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|