The md.texi entry for nonlocal_goto_receiver says "A typical reason
why you might need this pattern is if some value, such as a pointer to
a global table, must be restored when the frame pointer is restored.
Note that a nonlocal goto only occurs within a unit-of-translation, so
a global table point
> But, in the builtins.c:expand_builtin_setjmp_receiver, the
> frame-pointer is *clobbered* for a mysterious and fuddy reason:
>
> /* This might change the hard frame pointer in ways that aren't
>apparent to early optimization passes, so force a clobber. */
> emit_clobber (har
On Fri, 12 Oct 2012, Eric Botcazou wrote:
> > (insn 168 49 51 3 (set (reg/f:DI 253 $253)
> > (plus:DI (reg/f:DI 253 $253)
> > (const_int 24 [0x18])))
> > /tmp/mmiximp2/gcc/gcc/testsuite/gcc.c-torture/execute/built-in-setjmp.c:21
> > -1 (nil))
> > (insn 51 168 52 3 (clobber (reg/
CC:ing middle-end maintainers this time. I was a bit surprised
when Eric Botcazou wrote in his review, quoted below, that he's
not one of you. Maybe approve that too?
On Mon, 15 Oct 2012, Hans-Peter Nilsson wrote:
> On Fri, 12 Oct 2012, Eric Botcazou wrote:
> > > (insn 168 49 51 3 (set (reg/f:D
This patch (r192676) is probably causing
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/memset-chk.c exec
On Tue, 23 Oct 2012, Dominique Dhumieres wrote:
> This patch (r192676) is probably causing
>
> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os
> FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution, -Os
> FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution, -Os
On Sun, 21 Oct 2012, Hans-Peter Nilsson wrote:
> CC:ing middle-end maintainers this time. I was a bit surprised
> when Eric Botcazou wrote in his review, quoted below, that he's
> not one of you. Maybe approve that too?
If Eric is fine with the patch it is ok. Yes, he is not
middle-end maintai
