[pull] main from python:main#1034
Merged
pull[bot] merged 15 commits intotj-python:mainfrom May 6, 2026
Merged
Conversation
…in test_buffer (#149345) This amends e79fd60. I'll not fix this for 'F'/'D' complex types as they might be removed.
Fixes a sequential consistency bug whereby two threads that are deleting a struct member may observe both their deletions to be successful.
…46439) Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
Replace "const char *typecode;" with "char typecode[3];" to make the arraydescr structure smaller and avoids an indirection.
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
…kThreads() (#148145) Co-authored-by: Petr Viktorin <encukou@gmail.com> Co-authored-by: Victor Stinner <vstinner@python.org>
-fno-omit-frame-pointer is not enough to make every target walkable by the simple manual frame pointer unwinder. The helper used by test_frame_pointer_unwind used to assume the frame pointer named a two-word record where fp[0] was the previous frame pointer and fp[1] was the return address. That is only the generic layout used by some targets. This patch keeps that default, but moves the slots behind named offsets so architecture-specific layouts can describe where the backchain and return address really live. On s390x, GCC and Clang do not emit a usable backchain unless -mbackchain is enabled. Without it, the unwinder stops at the current C frame and the test reports no Python frames. Once backchains are present, the helper must also stop at the current thread's known C stack bounds; otherwise it can follow the final backchain far enough to dereference an invalid frame and segfault. For Linux s390x backchain frames, the documented z/Architecture stack-frame layout saves r14, the return-address register, at byte offset 112 from the frame pointer, so read the return address from that named slot instead of fp[1]. The 112-byte offset comes from Linux's s390 debugging documentation: its Stack Frame Layout table shows z/Architecture backchain frames with the backchain at offset 0 and saved r14 of the caller function at offset 112: https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#stack-frame-layout This helper remains scoped to Linux s390x backchain frames. GNU SFrame's s390x notes state that the s390x ELF ABI does not generally mandate where RA and FP are saved, or whether they are saved at all: https://sourceware.org/binutils/docs/sframe-spec.html#s390x As Jens Remus noted, -fno-omit-frame-pointer is not needed when -mbackchain is present. On 32-bit ARM, GCC defaults to Thumb mode on common armhf toolchains. The Thumb prologue keeps the saved frame pointer and link register at offsets that depend on the generated frame, which breaks the fp[0]/fp[1] walk used by the helper. Use -marm when it is supported for frame-pointer builds, and teach the helper the GCC ARM-mode slots where the previous frame pointer is at fp[-1] and the saved LR return address is at fp[0]. Co-authored-by: Petr Viktorin <encukou@gmail.com> Co-authored-by: Victor Stinner <vstinner@python.org>
GH-149429) As part of this conversion, we now ensure that we're comparing against the merge-base of the PR branch and the base branch when checking whether an RTD build is worthwhile, deepening the history of the base branch by up to 500 commits if necessary. If the merge-base can't be found or there are merge conflicts with the head of the base branch, the build is skipped since it would give a warped perception of the actual changes anyway. This unfortunately does nothing about RTD preview comments comparing against the wrong base, other than skipping builds that shouldn't produce any diff at all thus avoiding the comment. Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) <wk.cvs.github@sydorenko.org.ua>
The Tcl 9 makefile.vc now uses TCLSH_NATIVE during the build process, not just the installation. We had been setting it to the installed location of the x86 tclsh.exe, which does not yet exist when the x86 build process needs it. That build doesn't actually need TCLSH_NATIVE, though (there's a check specifically allowing TCLSH to be used if MACHINE is IX86 and TCLSH_NATIVE is undefined), so don't set it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )