gh-145633: remove support for ancient ARM platforms with mixed-endian doubles

[skirpichev]

• drop DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754 macro
• use DOUBLE_IS_BIG/LITTLE_ENDIAN_IEEE754 to detect endianness of float/doubles
• drop "unknown_format" code path in PyFloat_Pack/Unpack*()
• drop float_state

• Issue: Remove "unknown_format" code path in PyFloat_Pack/Unpack*() #145633

[skirpichev]

I'll prepare removal of __getformat__ in a separate commit.

Edit: Mark Dickinson suggested to keep this for alternative Python implementations.

[corona10]

cc @diegorusso

[diegorusso]

This is more a generic question about the process. Shouldn't we follow the usual removal process (warning + removal)?
In this specific case, it might be still OK just to drop it as I really doubt these that the OS on these old devices wants to ship Python 3.15.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

[diegorusso]

This is more a generic question about the process. Shouldn't we follow the usual removal process (warning + removal)? In this specific case, it might be still OK just to drop it as I really doubt these that the OS on these old devices wants to ship Python 3.15.

I reply to my own question. This is not a language change hence safe to remove. Also the probability that this will affect users is extremely low.

[skirpichev]

Shouldn't we follow the usual removal process (warning + removal)? In this specific case, it might be still OK just to drop it as I really doubt these that the OS on these old devices wants to ship Python 3.15.

A bit of history, 2a9c380 (eight years ago) says:

RFC because this doesn't yet handle the weird ancient ARMv4 OABI 'mixed-endian' encoding properly. This encoding is ancient and I don't believe the union of "Python 3.8 users" and "OABI users" has anything in. Should the support for this just be dropped too?

I'm OK to make first deprecation. Though, at least lets not wait too much (aka "preferred" scenario per PEP 387).

But honestly, I don't see big reason to delay removal. You know much more about ARM world, can we have any practical use case here?

The struct in pycore_runtime_structs.h still has the _py_float_format_unknown We should remove it from there as well.

Yes, I just removed all logic for handling float_state in favor of macros. BTW, maybe we could just use platform endianness?

I have made the requested changes; please review again.

[bedevere-app]

Thanks for making the requested changes!

@diegorusso: please review the changes made to this pull request.

[vstinner]

LGTM. I'm ok to drop support for this legacy platform right now.

[skirpichev]

@vstinner, what do you think on using platform endianness?

Current version assumes, that endianness for floating-point numbers can be different wrt sys.byteorder. This is odd and is not true for anything mentioned in the PEP 11.

[vstinner]

@vstinner, what do you think on using platform endianness? Current version assumes, that endianness for floating-point numbers can be different wrt sys.byteorder. This is odd and is not true for anything mentioned in the PEP 11.

If you want to remove DOUBLE_IS_BIG_ENDIAN_IEEE754 and DOUBLE_IS_LITTLE_ENDIAN_IEEE754, I suggest doing it in a separated issue. I'm not bothered by these macros, we have to handle endianness somehow anyway.

[diegorusso]

I agree with @vstinner Let's merge this and tackle the removal of the MACROS in another PR.

[diegorusso]

This LGTM and thanks for removing lots of dead code. I'll leave to @vstinner to merge.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @skirpichev for commit f70428d 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F145634%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[skirpichev]

I think there are no failures from buildbots, related to this pr. As expected, it should affect ARM bots, at most.

[vstinner]

"Merge branch 'main' into remove-unknown_format": Please don't touch a PR when buildbots are run on it, otherwise it's way more difficult to check for buildbots status.

I see 3 buildbot failures, all are unrelated to this change.

• https://buildbot.python.org/#/builders/252/builds/1977: unclear internal Twisted error

  File "/srv/buildbot/venv/lib/python3.13/site-packages/twisted/spread/jelly.py", line 539, in jelly
    sxp.extend(self._jellyIterable(tuple_atom, obj))
  File "/srv/buildbot/venv/lib/python3.13/site-packages/twisted/spread/jelly.py", line 588, in _jellyIterable
    yield self.jelly(item)
  File "/srv/buildbot/venv/lib/python3.13/site-packages/twisted/spread/jelly.py", line 450, in jelly
    return obj.jellyFor(self)
  File "/srv/buildbot/venv/lib/python3.13/site-packages/twisted/spread/flavors.py", line 144, in jellyFor
    return [b"remote", jellier.invoker.registerReference(self)]
  File "/srv/buildbot/venv/lib/python3.13/site-packages/twisted/spread/pb.py", line 795, in registerReference
    raise Error("Maximum PB reference count exceeded.")
twisted.spread.pb.Error: Maximum PB reference count exceeded.

• https://buildbot.python.org/#/builders/474/builds/2425: test.test_multiprocessing_fork.test_processes failure, likely a random failure.
• https://buildbot.python.org/#/builders/476/builds/1967: build failed with a timeout: clang -Og takes 2 minutes to build a C program vs 6 seconds for clang -O3, and uses 1.8 GiB of memory llvm/llvm-project#179695

[vstinner]

Merged, thanks for this cleanup. The change should not impact anyone in practice, since it only impacts old architectures (ARMv4L and ARMv5L) using a specific ABI (OABI).

[bedevere-bot]

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot ARM64 macOS 3.x (tier-2) has failed when building commit dae85c4.

What do you need to do:

1. Don't panic.
2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/725/builds/12985) and take a look at the build logs.
4. Check if the failure is related to this commit (dae85c4) or if it is a false positive.
5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/725/builds/12985

Failed tests:

• test_urllib2net

Summary of the results of the build (if available):

==

Click to see traceback logs

remote: Enumerating objects: 52, done.        
remote: Counting objects:   1% (1/52)        
remote: Counting objects:   3% (2/52)        
remote: Counting objects:   5% (3/52)        
remote: Counting objects:   7% (4/52)        
remote: Counting objects:   9% (5/52)        
remote: Counting objects:  11% (6/52)        
remote: Counting objects:  13% (7/52)        
remote: Counting objects:  15% (8/52)        
remote: Counting objects:  17% (9/52)        
remote: Counting objects:  19% (10/52)        
remote: Counting objects:  21% (11/52)        
remote: Counting objects:  23% (12/52)        
remote: Counting objects:  25% (13/52)        
remote: Counting objects:  26% (14/52)        
remote: Counting objects:  28% (15/52)        
remote: Counting objects:  30% (16/52)        
remote: Counting objects:  32% (17/52)        
remote: Counting objects:  34% (18/52)        
remote: Counting objects:  36% (19/52)        
remote: Counting objects:  38% (20/52)        
remote: Counting objects:  40% (21/52)        
remote: Counting objects:  42% (22/52)        
remote: Counting objects:  44% (23/52)        
remote: Counting objects:  46% (24/52)        
remote: Counting objects:  48% (25/52)        
remote: Counting objects:  50% (26/52)        
remote: Counting objects:  51% (27/52)        
remote: Counting objects:  53% (28/52)        
remote: Counting objects:  55% (29/52)        
remote: Counting objects:  57% (30/52)        
remote: Counting objects:  59% (31/52)        
remote: Counting objects:  61% (32/52)        
remote: Counting objects:  63% (33/52)        
remote: Counting objects:  65% (34/52)        
remote: Counting objects:  67% (35/52)        
remote: Counting objects:  69% (36/52)        
remote: Counting objects:  71% (37/52)        
remote: Counting objects:  73% (38/52)        
remote: Counting objects:  75% (39/52)        
remote: Counting objects:  76% (40/52)        
remote: Counting objects:  78% (41/52)        
remote: Counting objects:  80% (42/52)        
remote: Counting objects:  82% (43/52)        
remote: Counting objects:  84% (44/52)        
remote: Counting objects:  86% (45/52)        
remote: Counting objects:  88% (46/52)        
remote: Counting objects:  90% (47/52)        
remote: Counting objects:  92% (48/52)        
remote: Counting objects:  94% (49/52)        
remote: Counting objects:  96% (50/52)        
remote: Counting objects:  98% (51/52)        
remote: Counting objects: 100% (52/52)        
remote: Counting objects: 100% (52/52), done.        
remote: Compressing objects:   5% (1/19)        
remote: Compressing objects:  10% (2/19)        
remote: Compressing objects:  15% (3/19)        
remote: Compressing objects:  21% (4/19)        
remote: Compressing objects:  26% (5/19)        
remote: Compressing objects:  31% (6/19)        
remote: Compressing objects:  36% (7/19)        
remote: Compressing objects:  42% (8/19)        
remote: Compressing objects:  47% (9/19)        
remote: Compressing objects:  52% (10/19)        
remote: Compressing objects:  57% (11/19)        
remote: Compressing objects:  63% (12/19)        
remote: Compressing objects:  68% (13/19)        
remote: Compressing objects:  73% (14/19)        
remote: Compressing objects:  78% (15/19)        
remote: Compressing objects:  84% (16/19)        
remote: Compressing objects:  89% (17/19)        
remote: Compressing objects:  94% (18/19)        
remote: Compressing objects: 100% (19/19)        
remote: Compressing objects: 100% (19/19), done.        
remote: Total 27 (delta 24), reused 10 (delta 8), pack-reused 0 (from 0)        
From https://github.com/python/cpython
 * branch                    main       -> FETCH_HEAD
Note: switching to 'dae85c4d9393b706657a4eb1febc71647a5f544e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at dae85c4d939 gh-145633: Remove support for ancient ARM platforms with mixed-endian doubles (#145634)
Switched to and reset branch 'main'

make: *** [buildbottest] Error 2