memcpy et al. testcase regression

[GoogleCodeExporter]

the gcc.c-torture/execute/builtins/memcpy-chk.c (and related test cases,
actually, most of builtins/ dir) once again fail to execute when built
higher optimization levels.

example: memcpy-chk.c with -O[2|3|s] fails in test4() with SIGILL.

probably caused by latest changes to conditional branching. further
inspection needed.

Original issue reported on code.google.com by jmoc...@gmail.com on 29 Dec 2008 at 11:49

[GoogleCodeExporter]

test case fails in gcc.c-torture/execute/builtins/lib/chk.c:__chk_fail(), at 
line 20,
attempting to do

__builtin_longjmp (chk_fail_buf, 1);

fails with SIGILL at 0x8000001e50 (where, naturally, no meaningful code 
resides, just
zeroes)

chk_fail_buf at this point contains:

0x0000008000001f80,
0x0000000400006a1c,
0x0000008000002200,
0x0000000400006780,
(nil), 
and nils ad inf.

Original comment by jmoc...@gmail.com on 5 Jan 2009 at 1:30

[GoogleCodeExporter]

this longjmp() should return to the first setjmp() in test4. obviously, it 
returns
somewhere strange.

lower addresses in the jmp_buf (4...) are surely return addresses for 
longjmp(), but
what are the high addresses (8...)? they point to sth on the stack, location of 
env
saved by setjmp(), or?

Original comment by jmoc...@gmail.com on 5 Jan 2009 at 1:48

• Added labels: gcc, gcc-builtins

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

this is probably a builtin [set|long]jmp() issue. attached simple test case of 
the
two dumps core at the end of main().

erich, I seem to vaguely remember that you already fixed something wrt. 
non-local
gotos once? perhaps we just need to re-fix it ...

Original comment by jmoc...@gmail.com on 5 Jan 2009 at 3:43

Attachments:

• longjmp.c

[GoogleCodeExporter]

also, gcc.c-torture/execute/builtins/built-in-setjmp.c was failing with -O>0.

it turns out that our initial implementation, providing
TARGET_BUILTIN_SETJMP_FRAME_VALUE that returned hard_frame_pointer_rtx was 
wrong.
resetting it to default (returning virtual_stack_vars_rtx) in r185 made
built-in-setjmp.c testcase work with all optimization levels.

also, memcpy-chk.c testcase now works with all optimization levels, except -O1, 
which
still SIGILLs.

onwards and onwards we go, where no code before has bothered to jump ...

Original comment by jmoc...@gmail.com on 7 Jan 2009 at 3:32

[GoogleCodeExporter]

mkay. this is the problem, as deduced from produced assembly and dbx sessions.

in all cases, $s1 + 272 (virtual stack vars addr, just like we want it) is put 
into
jmp_buf in setjmp().

then, longjmp() reloads all registers (including $s1) from jmp_buf, and jumps to
return address from jmp_buf.

now, with -O0 and -O2, the first instruction executed after the jump does lea 
$s1
-272($s1), which finally restores the proper frame ptr value.

with -O1, this subtraction of 272 is misteriously missing. I am - in an 
instincitve,
feminine manner, with no substantial arguments whatsoever - thinking this 
somehow has
to do with register elimination. might be wrong though, might be wrong ...

but then again, what was wrong with previous definition, where we stored
hard_frame_pointer directly instead of virtual_stack_vars ptr? that one did not 
need
any additional maths ...

also, I am a bit uneasy about the fact that $s3/$s34 (used for access to 
function
parameters) are not store/restored in setjmp()/longjmp(): perhaps we should 
come up
with a test case where parameters are first accessed after setjmp() ...

Original comment by jmoc...@gmail.com on 8 Jan 2009 at 12:14

[GoogleCodeExporter]

my feminine side was right. it had to do with pointer elimination. with FP->HFP,
actually.

now: since our RSA is always 272 bytes, there is no need to differentiate 
between FP
and HFP anyway, thus I removed the distinction. now we only care about FP->SP
elimination, which we can only enable once we rtlize the prologue, anyway.

commit r186 fixes this.

Original comment by jmoc...@gmail.com on 8 Jan 2009 at 1:46

• Changed state: Fixed