This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in expand_builtin_setjmp_receiver ?
Frederic Riss <frederic.riss@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