Frederic Riss <frederic.r...@gmail.com> writes:
> in builtins.c:expand_builtin_setjmp_receiver I see the following code:
>
> 827 /* Now put in the code to restore the frame pointer, and argument
> 828 pointer, if needed. */
> 829 #ifdef HAVE_nonlocal_goto
> 830 if (! HAVE_nonlocal_goto)
> 831 #endif
> 832 {
> 833 emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
> 834 /* This might change the hard frame pointer in ways that aren't
> 835 apparent to early optimization passes, so force a clobber. */
> 836 emit_clobber (hard_frame_pointer_rtx);
> 837 }
>
> Shouldn't that code somehow honor STARTING_FRAME_OFFSET ?
> Or maybe virtual_stack_vars_rtx shouldn't include that offset? The
> thing is I'm playing with a port these days, and I'm not able to make
> all the testsuite pass when STARTING_FRAME_OFFSET is not 0. I tracked
> the failures down to that move instruction that makes following stack
> vars accesses fail when there's an offset between the frame pointer
> and the first stack variable.
It should not be necessary to use STARTING_FRAME_OFFSET when using
virtual_stack_vars_rtx, as it should be added in by the vregs pass. See
instantiate_new_reg, and note that var_offset is set to
STARTING_FRAME_OFFSET.
However, I agree that it does seem that it should be added to or
subtracted from hard_frame_pointer_rtx before setting
virtual_stack_vars_rtx, or something. I only see one existing target
which sets STARTING_FRAME_OFFSET to a non-zero value and does not have a
nonlocal_goto expander: lm32. It would be interesting to know whether
that target works here.
Ian
