platform/switch_ppc64_linux.h | 11 11 + 0 - 0 !
1 file changed, 11 insertions(+)

---

platform/switch_alpha_unix.h | 39 39 + 0 - 0 !
slp_platformselect.h | 2 2 + 0 - 0 !
2 files changed, 41 insertions(+)

 fix ftbfs on alpha due to missing architecture support
 Provides the missing function needed to compile on Alpha.

platform/switch_arm32_gcc.h | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 [patch] arm32: make sure gcc uses a frame pointer

This code assumes that there is a frame pointer. When gcc doesn't use a
frame pointer here and __thumb__ is defined, then the code clobbers r7
without declaring it to the compiler. If the compiler uses r7 for
something else, then this causes arbitrary failures, depending on what
the optimizer did.

To work around this, tell gcc to always use a frame pointer.

Bug: https://github.com/python-greenlet/greenlet/pull/64

platform/switch_arm32_gcc.h | 5 3 + 2 - 0 !
1 file changed, 3 insertions(+), 2 deletions(-)

 [patch] arm32: force return value from asm

In my case, instead of a simple "mov r0, #0", the optimizer had done
this:

    Between calls to slp_save_state and slp_restore_state, it saved the
    value now guaranteed to be 0 using "str r0, [r7]".

    Now, at the end, it restores that value into r0 using "ldr r3, [r7]"
    and then "mov r0, r3".

It isn't clear to me that intermediate values managed by the compiler,
like this one at [r7], would be preserved in the stack this way,