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
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
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
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:DI
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/f:DI 253
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
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
