On 6/21/2026 8:59 PM, Peter Bergner wrote:
On 6/21/26 11:58 AM, Jeffrey Law wrote:
On 6/19/2026 8:54 PM, Peter Bergner wrote:
RISC-V: GLIBC's setjmp preserves callee-saved registers [PR87466]
gcc/
PR target/87466
* config/riscv/riscv.cc (TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P):
Define.
Obviously we can refine to include other libcs once someone chimes in on
their semantics.
My only worry would be cases where we have the ability to dynamically
select a different libc implementation. Is that really a thing these
days? I glibc vs musl, newlib vs pico, others? Not sure where hte LLVM
libc projects fit in either.
I believe musl explicitly does not support ifunc and I don't think
newlib or picolibc support it either. I downloaded musl, newlib and
picolibc and their riscv setjmp functions do save all non-volatile
registers, so it seems we probably don't need to worry about ifuncs
and we can probably enable TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P
for all riscv libcs. I would go so far as saying any riscv libc that
doesn't save/restore all non-volatile regs is broken and should be fixed.
From the old thread where I added the
TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P
support, I think it was just the SPARC libcs that didn't save/restore the
non-volatile regs. I think almost all other (all other?) libcs don't
push the non-volatile save/restore work onto the compilers and instead
implement that in the setjmp/longjmp routines themselves where it belongs.
I was thinking more along the lines of the changes which allow wholesale
replacement of the library that went in for picolibc IIRC. But I was
mistaken, those changes allow adding bits after the C library, not
wholesale replacement of the library. So ISTM the only worry would be
if setjmp was weak and could then be overridden by a routine in that
additional library. I don't think this is worth worrying about.
So the original patch is fine by me.
jeff
