https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83368
--- Comment #10 from James Clarke <jrtc27 at jrtc27 dot com> ---
(In reply to James Clarke from comment #9)
> (In reply to Eric Botcazou from comment #7)
> > > And for what it's worth, 32-bit Solaris/SPARC's setjmp isn't saving any of
> > > the caller's input or local registers either, so it's not glibc-specific.
> >
> > Again you're wrong, the call-saved registers are properly preserved if you
> > don't clobber the stack pointer, just write a small test or simply tweak
> > yours.
>
> Yes, I know that. But GCC doesn't rely on that for *any other use* of the
> input and local registers; they are spilled to the stack and reloaded after
> the setjmp when needed. Also the fact that alloca clobbers the stack pointer
> is an implementation detail; for example, LLVM allocates all the space up
> front in the function prologue in this case, which means it would not run
> into this issue (and in fact it also spills its PIC base register).
(In reply to Eric Botcazou from comment #8)
> > You already have code in sched-deps.c to deal with setjmp potentially not
> > saving registers it should across all architectures:
> >
> > if (find_reg_note (insn, REG_SETJMP, NULL))
> > {
> > /* This is setjmp. Assume that all registers, not just
> > hard registers, may be clobbered by this call. */
> > reg_pending_barrier = MOVE_BARRIER;
> > }
>
> GCC expects all call-saved registers to be preserved by setjmp/longjmp
> though and I think that's what is implemented in glibc for other
> architectures.
No, it doesn't. Try it yourself. Make a local variable live across a setjmp
call, and even under -O3 you will see it spilled to the stack and reloaded
after setjmp returns.
> > Why is it so hard to fix this bug? It's a very simple problem that only
> > affects %l7; all it needs is for it to be spilled and reloaded.
>
> Because it's a call-saved register.
Not for setjmp, but this is where we disagree.
> > This is breaking real-world code that works on every other architecture I
> > have
> > tried it on, and telling people to use non-portable built-in functions
> > isn't
> > going to necessarily be well-received.
>
> Then you need to convince someone to fix glibc and make setjmp/longjmp
> preserve call-saved registers even if the stack pointer is subsequently
> clobbered. Or maybe just the PIC register, but I think it's only the tip of
> the iceberg.
Can't be done without an ABI break. But it is just the PIC register, and I'm
still of the view this is a GCC bug. You seem to not be listening to my
arguments and just reciting that "setjmp must save call-saved registers", which
would be nice if it were true, but that's not what actually happens, and GCC
already tries to handle this; it just misses a case on SPARC.
