Hi Max,
> On Tue, Jun 18, 2019 at 4:53 PM Wilco Dijkstra wrote:
> > > It would work if a frame pointer was initialized in the function test, but
> > > it wasn't:
> >
> > Right, because it unwinds, it needs a valid frame pointer since we no
> > longer store the stack pointer. So xtensa_frame_point
On Tue, Jun 18, 2019 at 4:53 PM Wilco Dijkstra wrote:
> > It would work if a frame pointer was initialized in the function test, but
> > it wasn't:
>
> Right, because it unwinds, it needs a valid frame pointer since we no
> longer store the stack pointer. So xtensa_frame_pointer_required
> should
Hi Max,
> It would work if a frame pointer was initialized in the function test, but
> it wasn't:
Right, because it unwinds, it needs a valid frame pointer since we no
longer store the stack pointer. So xtensa_frame_pointer_required
should do something like:
if (cfun->machine->accesses_prev_fr
On Tue, Jun 18, 2019 at 10:07 AM Wilco Dijkstra wrote:
> > The testcase from the patch passes with the trunk xtensa-linux-gcc
> > with windowed ABI. But with the changes in this patch a lot of tests
> > that use longjmp are failing on xtensa-linux.
>
> Interesting. I looked at the _xtensa_nonlocal
Hi,
> > Is this test valid? Can jmp buffer be allowed on stack?
>
> Sure, the contents of the jmp buffer is only valid during the lifetime
> of the call frame anyway.
Indeed. The issue with jmp buffer being on the stack causing incorrect
restore when doing longjmp has just been fixed (PR64242)
On Jun 18 2019, "H.J. Lu" wrote:
>> +void
>> +test (void)
>> +{
>> + void *buf[5];
>> + void *volatile q = p;
>> +
>> + if (!__builtin_setjmp (buf))
>> +broken_longjmp (buf);
>
> Is this test valid? Can jmp buffer be allowed on stack?
Sure, the contents of the jmp buffer is only valid du
Hi Max,
> The testcase from the patch passes with the trunk xtensa-linux-gcc
> with windowed ABI. But with the changes in this patch a lot of tests
> that use longjmp are failing on xtensa-linux.
Interesting. I looked at the _xtensa_nonlocal_goto implementation in
libgcc/config/xtensa/lib2funcs.
On Tue, May 28, 2019 at 10:37 AM Wilco Dijkstra wrote:
>
>
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr84521.c
> b/gcc/testsuite/gcc.c-torture/execute/pr84521.c
> new file mode 100644
> index
> ..995a30223afd1401186c7eaf541f27606aed59b5
> --- /dev
Hello,
On Mon, Jun 17, 2019 at 6:10 PM Jeff Law wrote:
> On 6/17/19 6:58 PM, Wilco Dijkstra wrote:
> >> You mention that arm, mips and xtensa are still broken. Are they worse
> >> after this patch?
The testcase from the patch passes with the trunk xtensa-linux-gcc
with windowed ABI. But with th
On 6/17/19 6:58 PM, Wilco Dijkstra wrote:
> Hi Jeff,
>
>> So I like the significant simplification here. My worry is whether or
>> not this is, in effect, an ABI change. ie, would we be able to mix and
>> match .o files from before/after this change which used the builtin
>> setjmp/longjmp bits?
Hi Jeff,
> So I like the significant simplification here. My worry is whether or
> not this is, in effect, an ABI change. ie, would we be able to mix and
> match .o files from before/after this change which used the builtin
> setjmp/longjmp bits?
No it's not an ABI change. It does affect the va
On 5/28/19 11:37 AM, Wilco Dijkstra wrote:
> This fixes and simplifies the setjmp and non-local goto implementation.
> Currently the virtual frame pointer is saved when using __builtin_setjmp or
> a non-local goto. Depending on whether a frame pointer is used, this may
> either save SP or FP with
ping
From: Wilco Dijkstra
Sent: 14 December 2018 13:16
To: GCC Patches
Cc: nd
Subject: [PATCH] Fix PR84521
This fixes and simplifies the setjmp and non-local goto implementation.
Currently the virtual frame pointer is saved when using __builtin_setjmp or
a non-local goto. Depending on whet
13 matches
Mail list logo
