From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19160 invoked by alias); 19 Jun 2007 17:41:23 -0000 Received: (qmail 19101 invoked by uid 48); 19 Jun 2007 17:41:13 -0000 Date: Tue, 19 Jun 2007 17:41:00 -0000 Subject: [Bug rtl-optimization/32405] New: assertion failure in loop-iv.c; probable dataflow regression X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bwilson 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: 2007-06/txt/msg01590.txt.bz2 The following 2 testcases began failing for an xtensa-elf target when the dataflow branch was merged: gcc.c-torture/execute/920501-6.c gcc.c-torture/execute/930921-1.c Both tests fail at -O3 with "internal compiler error: in get_biv_step, at loop-iv.c:792". Neither the Xtensa port nor the loop-iv.c code changed at the time of the regression in a way that obviously affects this. I'm suspecting it is somehow related to the dataflow merge. Here is what appears to be happening for 930921-1.c. The test program is: f (x) unsigned x; { return (unsigned) (((unsigned long long) x * 0xAAAAAAAB) >> 32) >> 1; } main () { unsigned i; for (i = 0; i < 10000; i++) if (f (i) != i / 3) abort (); exit (0); } At -O3, function f is inlined into main and "x * 0xAAAAAAAB" is recognized as a DImode induction variable. I'm pretty sure the problem is related to the lack of an adddi3 pattern in xtensa.md. We rely on optabs.c to expand DImode addition. If I dump the RTL file, the induction variable increment looks like: ;; ivtmp$55 = ivtmp$55 + 0x0aaaaaaab (insn 26 25 27 930921-1.c:4 (set (reg:DI 50) (mem/u/c/i:DI (symbol_ref/u:SI ("*.LC1") [flags 0x2]) [2 S8 A64])) -1 (expr_list:REG_EQUAL (const_double -1431655765 [0xaaaaaaab] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0] 0 [0x0]) (nil))) (insn 27 26 28 930921-1.c:4 (clobber (reg:DI 51)) -1 (nil)) (insn 28 27 29 930921-1.c:4 (set (subreg:SI (reg:DI 51) 4) (plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4) (subreg:SI (reg:DI 50) 4))) -1 (nil)) (insn 29 28 30 930921-1.c:4 (set (reg:SI 52) (const_int 1 [0x1])) -1 (nil)) (jump_insn 30 29 31 930921-1.c:4 (set (pc) (if_then_else (ltu (subreg:SI (reg:DI 51) 4) (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 4)) (label_ref 32) (pc))) -1 (nil)) (insn 31 30 32 930921-1.c:4 (set (reg:SI 52) (const_int 0 [0x0])) -1 (nil)) (code_label 32 31 33 6 "" [0 uses]) (insn 33 32 34 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0) (plus:SI (subreg:SI (reg:DI 45 [ ivtmp$55 ]) 0) (subreg:SI (reg:DI 50) 0))) -1 (nil)) (insn 34 33 35 930921-1.c:4 (set (reg:SI 53) (plus:SI (reg:SI 52) (subreg:SI (reg:DI 51) 0))) -1 (nil)) (insn 35 34 36 930921-1.c:4 (set (subreg:SI (reg:DI 51) 0) (reg:SI 53)) -1 (nil)) (insn 36 35 0 930921-1.c:4 (set (reg:DI 45 [ ivtmp$55 ]) (reg:DI 51)) -1 (expr_list:REG_EQUAL (plus:DI (reg:DI 45 [ ivtmp$55 ]) (reg:DI 50)) (nil))) The failing assertion in get_biv_step() is: gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN)); The outer_mode is DImode; the inner_mode is SImode; and extend is UNKNOWN, since there are no SIGN_EXTEND or ZERO_EXTEND operations involved here. Is this code intended to work for DImode IVs when the machine doesn't directly support DImode operations? I don't know if the problem is in this loop-iv.c code or whether it ought not recognize the DImode induction variable in the first place. -- Summary: assertion failure in loop-iv.c; probable dataflow regression Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bwilson at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: xtensa-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405