Debian has a bug report for this issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110

Note m86k is not a supported platform per PEP 11.

Reading the Debian reports, it seems like the plan is for m86k to switch to 4-byte alignment anyway. Do we need to fix this?

Reading the Debian reports, it seems like the plan is for m86k to switch to 4-byte alignment anyway. Do we need to fix this?

@ZeroIntensity, there is no alternative ABI for Linux/m68k. That's why Debian picked up this patch.

No kernel and toolchain patches have been posted that would constitute a new ABI and no effort has been made to design a new ABI to meet the needs of everyone in the Linux/m68k community for the foreseeable future.

Distro maintainers are primarily concerned with their own software and its users, which is understandable.

Regardless, I think the patch stands on its merits because, IMO, the patch improves the python source code by improving correctness, readability, portability and reusability.

Reading the Debian reports, it seems like the plan is for m86k to switch to 4-byte alignment anyway. Do we need to fix this?

Opinions on this do vary. 🙂 However, as someone who would like to see 4-byte alignment, I don't want to force it on anybody and would still like this fixed. Thank you for your efforts, @fthain.

I'm worried that this might cause more problems with portability than solutions. Py_ALIGNED, as proposed in the PR, is a thin wrapper around GCC's __attribute__((aligned(...))). We could use something like _Py_ALIGN_AS, but then all of a sudden we're requiring compilers to support C11 _Alignas. Allowing the object structure to have a different alignment based on the compiler does not sound fun.

We also don't test this, as evidenced by that all buildbots & CI don't fail. I would suggest closing, this is an unsupported platform. Perhaps this could be re-evaluated with a BuildBot, but even then the concerns Peter raises remain.

A

We could use something like _Py_ALIGN_AS, but then all of a sudden we're requiring compilers to support C11 _Alignas

Python already requires C11 in its headers.

Also, the bits in capi-workgroup/decisions#61 make clear that it's fine as-needed.

Python already requires C11 in its headers.

Yes, but people notoriously don't always follow it (looking at you, Windows).

I think we should definitely get sign-off from the C API WG before requiring _Py_ALIGN_AS to build the core (especially for something as fundamental as PyObject).

Python already requires C11 in its headers

It shouldn't, the headers are compatible with C++. _Py_ALIGN_AS is designed to be okay anywhere it's needed, but we'll find out very quickly indeed if it isn't sufficient once it appears in PyObject.

@encukou Thoughts here?

Thoughts here?

If we want to introduce _Py_ALIGN_AS in the regular builds, this looks like the perfect issue to do it.

It is exactly the use case for _Py_ALIGN_AS.

If there are any issues with PyObject, we'll know quickly. If it turns out that we do need to revert, we “only” lose compatibility with an unsupported platform -- we'd be back to the drawing board on this issue.

I'd hold the 3.13 backport though; and maybe even 3.14 just to be safe.
People building for m68k can backport the patch downstream; in GCC-only land there shouldn't be much to worry about.

I think we should definitely get sign-off from the C API WG before requiring _Py_ALIGN_AS to build the core

The sign-off is done. Judging by the vote, the WG prefers _Py_ALIGN_AS being in both builds. It just wasn't needed, and thus tested, in the regular one yet.

We also don't test this [...] this is an unsupported platform.

Read “unsupported” more as “not in our CI” and less as “we won't spend time on this”.

We wouldn't magically add support for m68k with the patch; it's still on Gentoo/m68k & other maintainers to build, test, and report issues/PRs that we might merge.
The important thing for us is that supported platforms don't break.

Thank you for supporting Python on platforms we can't test here!