Hi Ian, On 19 October 2010 15:31, Ian Lance Taylor <i...@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