Bug in expand_builtin_setjmp_receiver ?

[Frederic Riss]

Hi Ian,

On 19 October 2010 15:31, Ian Lance Taylor <iant@google.com> wrote:
> 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.

Yes, but here we are reconstructing virtual_stack_vars_rtx after some
longjmp or such, thus it needs to take that into account, doesn't it?

> 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.

Is it easy to test lm32 on some simulator? If someone can do it, or
has the test results handy, the test that gets issues when I set
STARTING_FRAME_OFFSET is gcc.c-torture/execute/built-in-setjmp.c at
optimization level O2 and higher. After the longjmp, the code tries to
access some alloca'd variable and it fails.

Cheers,
Fred