------- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10
19:10 -------
Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris
2/SPARC
>> > So please attach a testcase (easiest is probably in a non-bootstrapped
>> > tree run make check and pick a simple one that fails from the C testsuite).
>>
>> Ok, I'll try to find one.
I've found one (in fact, it seems to be the only C one):
+FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2
+FAIL: gcc.c-torture/execute/20100708-1.c execution, -Os
+FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2 -flto
+FAIL: gcc.c-torture/execute/20100708-1.c execution, -O2 -fwhopr
Without and with your patch, it shows the following difference, just
like the change that causes xgcc to get a SIGBUS:
--- /homes/ro/20100708-1.s 2010-09-10 20:53:11.730613000 +0200
+++ 20100708-1.s 2010-09-10 20:51:09.161003200 +0200
@@ -7,8 +7,7 @@
f:
mov 16, %g1
.LL2:
- st %g0, [%o0+8]
- st %g0, [%o0+12]
+ stx %g0, [%o0+8]
st %g0, [%o0+16]
addcc %g1, -1, %g1
bne,pt %icc, .LL2
clr and clrx are just synthetic instructions, the real thing can be
seen above: st resp. stx are stores of 4 resp. 8 bytes, and the %g0
register always reads as 0.
%o0 isn't 8-byte aligned in this case, so the testcase dies with SIGBUS.
Compile with
$ cc1 20100708-1.c -mcpu=v9 -O2
to reproduce.
Thanks.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45611
