| Summary: | [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Rainer Orth <ro> |
| Component: | bootstrap | Assignee: | Richard Biener <rguenth> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ebotcazou, gcc-bugs, rguenther |
| Priority: | P3 | ||
| Version: | 4.6.0 | ||
| Target Milestone: | 4.6.0 | ||
| Host: | sparc-sun-solaris2* | Target: | sparc-sun-solaris2* |
| Build: | sparc-sun-solaris2* | Known to work: | |
| Known to fail: | Last reconfirmed: | 2010-09-13 09:35:04 | |
Presumably 163997 then. Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC
> ------- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-09-09 10:38 -------
> Presumably 163997 then.
Indeed: a C-only bootstrap on sparc-sun-solaris2.10 works as of rev
163996 and fails with 163997.
Rainer
Richard, could you please have a look? (In reply to comment #3) > Richard, could you please have a look? I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but at most build a cross cc1). 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). Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? Is it a store or a load? The revision in question is supposed to make alignment less strict and I can't see how this can break anything. Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC > ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 ------- > I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but > at most build a cross cc1). Not even sparc-linux? I very much doubt the bug is Solaris-specific. > 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. > Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? > Is it a store or a load? Yes, cf. sparc.h. clr and clrx store 0 (4 or 8 bytes) at the target address, requiring natural alignment (which fails with your patch for the clrx case). Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris 2/SPARC On Fri, 10 Sep 2010, ro at CeBiTec dot Uni-Bielefeld dot DE wrote: > ------- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-10 15:48 ------- > Subject: Re: [4.6 regression] SIGBUS in generate_option_input_file on Solaris > 2/SPARC > > > ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-09 13:27 ------- > > > I don't have access to sparc-sun-solaris2*, so I can't bootstrap it (but > > at most build a cross cc1). > > Not even sparc-linux? I very much doubt the bug is Solaris-specific. No, not even sparc-linux. > > 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. > > > Is sparc-sun-solaris2* a STRICT_ALIGNMENT target? What's the clr instruction? > > Is it a store or a load? > > Yes, cf. sparc.h. > > clr and clrx store 0 (4 or 8 bytes) at the target address, requiring > natural alignment (which fails with your patch for the clrx case). Thanks. 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
I have a patch. Subject: Bug 45611 Author: rguenth Date: Mon Sep 13 10:47:28 2010 New Revision: 164244 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164244 Log: 2010-09-13 Richard Guenther <rguenther@suse.de> PR tree-optimization/45611 * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Fix typo. (copy_ref_info): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c Should be fixed now. *** Bug 45421 has been marked as a duplicate of this bug. *** |
Between rev 163993 and 164013, mainline bootstrap started failing on Solaris 2 SPARC. The stage2 libgcc fails to configure because the stage2 xgcc gets a SIGBUS for % ../../xgcc -B../../gcc/ -c -g -O2 conftest.c Bus Error Running xgcc under gdb, I find that the crash happens here: Program received signal SIGSEGV, Segmentation fault. generate_option_input_file (argc=<value optimized out>, argv=<value optimized out>, lang_mask=<value optimized out>, decoded_options=0xffbff394, decoded_options_count=0xffbff390) at /vol/gcc/src/hg/trunk/local/gcc/opts-common.c:750 1: x/i $pc => 0x28584 <decode_cmdline_options_to_array+168>: clrx [ %l0 + 0x18 ] %lo+0x18 isn't 8-byte aligned at that point. Comparing the assembler code between the working and failing versions, I find that the following change has happened: decode_cmdline_options_to_array+0xa4: c0 24 20 14 clr [%l0 + 0x14] - decode_cmdline_options_to_array+0xa8: c0 24 20 18 clr [%l0 + 0x18] - decode_cmdline_options_to_array+0xac: c0 24 20 1c clr [%l0 + 0x1c] - decode_cmdline_options_to_array+0xb0: c4 24 20 24 st %g2, [%l0 + 0x24] + decode_cmdline_options_to_array+0xa8: c0 74 20 18 clrx [%l0 + 0x18] + decode_cmdline_options_to_array+0xac: c4 24 20 24 st %g2, [%l0 + 0x24] i.e. two clr insns (which are ok with 4-byte alignment) have been replaced by a single clrx. I'll start a reghunt to find the culprit patch.