From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13643 invoked by alias); 28 Jul 2010 15:01:27 -0000 Received: (qmail 11935 invoked by uid 48); 28 Jul 2010 15:00:56 -0000 Date: Wed, 28 Jul 2010 15:01:00 -0000 Message-ID: <20100728150056.11934.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "danglin at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg03102.txt.bz2 ------- Comment #5 from danglin at gcc dot gnu dot org 2010-07-28 15:00 ------- (In reply to comment #4) > While the ICE nominally results from a hash lookup failure, replacing > libiberty.a with the stage1 version makes no difference. Thus, it > doesn't appear that the problem is with the hash code. This is wrong. Hash related failure is different bug. The backtrace for this ICE is: Program received signal SIGSEGV, Segmentation fault. commutative_operand_precedence (op=0x0) at ../../gcc/gcc/rtlanal.c:2914 2914 enum rtx_code code = GET_CODE (op); (gdb) bt #0 commutative_operand_precedence (op=0x0) at ../../gcc/gcc/rtlanal.c:2914 #1 0x003b135c in swap_commutative_operands_p (x=, y=0x0) at ../../gcc/gcc/rtlanal.c:2980 #2 0x003ee244 in simplify_const_relational_operation (code=NE, mode=SImode, op0=0x400122b8, op1=0x0) at ../../gcc/gcc/simplify-rtx.c:4256 #3 0x003e4ee0 in simplify_relational_operation (code=NE, mode=SImode, cmp_mode=SImode, op0=0x400122b8, op1=0x0) at ../../gcc/gcc/simplify-rtx.c:3904 #4 0x003e565c in simplify_gen_relational (code=NE, mode=VOIDmode, cmp_mode=, op0=0x400122b8, op1=0x0) at ../../gcc/gcc/simplify-rtx.c:346 #5 0x00317ec4 in iv_number_of_iterations (loop=0x7, desc=0x9b62d8) at ../../gcc/gcc/loop-iv.c:2609 #6 check_simple_exit (loop=0x7, desc=0x9b62d8) at ../../gcc/gcc/loop-iv.c:2847 #7 find_simple_exit (loop=0x7, desc=0x9b62d8) at ../../gcc/gcc/loop-iv.c:2872 (gdb) p/x $pc $2 = 0x3b11d8 (gdb) disass 0x3b11c8,0x3b11e8 Dump of assembler code from 0x3b11c8 to 0x3b11e8: 0x003b11c8 : ldo -4(r7),r7 0x003b11cc : b,l 0x3b10f8 ,r0 0x003b11d0 : ldi 0,ret0 0x003b11d4 : stw rp,-14(sp) => 0x003b11d8 : ldh 0(r26),r19 0x003b11dc : ldo 40(sp),sp 0x003b11e0 : ldi 1e,r20 0x003b11e4 : cmpb,<> r20,r19,0x3b11f8 End of assembler dump. (gdb) p/x $r26 $3 = 0x0 ICE also seen on hppa2.0w-hp-hpux11.11. -- danglin at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernds at gcc dot gnu dot | |org GCC build triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) GCC host triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) GCC target triplet|hppa-unknown-linux-gnu |hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063