We currently reduce the C recursion limit just for s390x (which is big-endian), but in Gentoo, we hit the same issues on ppc64be, hppa, and sparc.
At least for ppc64, it seems like the ABI used on ppc64be means you end up with bigger stack frames.

That's strange that all big endian archs allocates more memory on the stack. What can explain that only big endian archs are affected?

I think it's a coincidence, and the logic is more related to the fact that big endian architectures aren't tested much. Perhaps the more appropriate logic would be to have a "more conservative" value in the default branch, and make it higher for platforms that we know are safe.

Ok, so I've played a bit with godbolt and got the following numbers for a dummy function with no args or variables:

• ARM (32-bit): 8 bytes (BE/LE)
• AArch64: 16 bytes (BE/LE)
• x86: 8 bytes (+ 4 bytes in 32-bit programs)
• LoongArch: 16 bytes
• MIPS: 24/32 bytes (depending on ABI, BE/LE)
• ppc64 (BE): 128 bytes
• ppc64le: 112 bytes
• ppc32: 16 bytes
• riscv: 16 bytes (32/64-bit)
• s390x: 160 bytes
• s390: 96 bytes
• SPARC: 96 bytes
• SPARC64: 176 bytes

So, looks like ppc64/s390/SPARC are the platforms with unusually large stack frames. However, I don't see any obvious relation between byte order and stack frame size here. ppc64le's is only a little smaller than ppc64 BE, so I have no clue why we're hitting the crash with one but not the other — but maybe it just happened to be on the border. On all other biendian arches, stack frame seems to be of the same size on both variants.

I've used the following code:

voidb() {}voida() {b();}

Tested with various compilers, compiler options (-mbig-endian,-mlittle-endian,-m32…). Enabled "Stack Usage" via "Add new…"

So, looks like ppc64/s390/SPARC are the platforms with unusually large stack frames

Would it be possible to only use lower limit on these 3 archs? Rather than testing "big endian".

Yeah, I suppose so.@thesamesam also mentioned HPPA, but godbolt doesn't cover that.

That's strange that all big endian archs allocates more memory on the stack. What can explain that only big endian archs are affected?

I saw this question just before I went to bed and my assumption (which I wanted to prove/disprove today) was that it was an unfortunate artefact of ABI design and that if we ended up looking at the ABIs for newer (and therefore LE) arches, we'd end up seeing some notable differences.

But mgorny (thank you!) beat me to it and I think his analysis is right. I'll look a bit more then update this PR. Thanks again both.

Ok, now for some real hardware testing of whentest_descr starts crashing. The highest recursion limits I was able to use (with regular build frommain, gcc, default optimization level, GNU/Linux):

• amd64/x86/aarch64/ppc32: 32k
• ppc64 (be): 9k (8k with PGO + forced-O2)
• ppc64le: 11k
• s390x: 12k (7k with PGO +-O2)
• sparc64: 7k (also with PGO +-O2)
• pa-risc: over 10k (host too slow to test more)
• alpha: over 10k (host too slow to test more)

It looks like amd64/x86/etc. are hitting some other issue that looks like a 16-bit signed counter. The values I've gotten for PPC64 suggests that LE was on the edge already. Surprisingly, my value for s390x is much higher than the one currently used — FWICS it was lowered due to buildbots failing.

Honestly, I don't know what values to put here.

@vstinner, with Sam's permission, I have pushed a commit that lowers the limits on PPC64 and SPARC instead.

Thanks! Happy now.

@vstinner Can you take another look please?

Merged, thanks. The final commit is way better than the first iteration only checking for big endian ;-)

Thanks a lot!