http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52650
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> 2012-03-21 15:51:23 UTC ---
> and with #if 1 they fail? As they are wrong-code regressions on
> an architecture I have no access to, can you see what is the issue here?
Right. I've compared assembler output for
FAIL: gcc.dg/torture/20090618-1.c -O1 execution test
which aborts with the #if 1 code:
> diff -u 285{,.orig}/gcc/testsuite/gcc/20090618-1.s
--- 285/gcc/testsuite/gcc/20090618-1.s 2012-03-21 16:38:25.780827400 +0100
+++ 285.orig/gcc/testsuite/gcc/20090618-1.s 2012-03-21 16:38:13.525278500
+0100
@@ -6,10 +6,7 @@
.proc 04
foo:
add %sp, -96, %sp
- st %g0, [%sp+92]
- mov 1, %g1
- st %g1, [%sp+88]
- mov 1, %o0
+ ld [%sp+88], %o0
jmp %o7+8
sub %sp, -96, %sp
.size foo, .-foo
As you can see, the i = 0, j = 1 initializations are lost completely,
and the ld insn reads from an uninitialized stack slot.
Rainer
