[Bug rtl-optimization/32405] New: assertion failure in loop-iv.c; probable dataflow regression

[Bug rtl-optimization/32405] New: assertion failure in loop-iv.c; probable dataflow regression

[bwilson at gcc dot gnu dot org]

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

[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression

[rakdver at kam dot mff dot cuni dot cz]

------- Comment #1 from rakdver at kam dot mff dot cuni dot cz  2007-06-19 22:07 -------
Subject: Re:   New: assertion failure in loop-iv.c; probable dataflow
regression

> 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.

this looks more like some latent problem exposed by df branch merge.  I
will have a look.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405

[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression

[rakdver at gcc dot gnu dot org]

-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-19 22:26:15
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405

[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression

[rakdver at gcc dot gnu dot org]

------- Comment #2 from rakdver at gcc dot gnu dot org  2007-06-20 06:56 -------
Subject: Bug 32405

Author: rakdver
Date: Wed Jun 20 06:56:26 2007
New Revision: 125881

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125881
Log:
        PR rtl-optimization/32405
        * loop-iv.c (iv_get_reaching_def): Fail for partial defs.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/loop-iv.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405

[Bug rtl-optimization/32405] assertion failure in loop-iv.c; probable dataflow regression

[rakdver at gcc dot gnu dot org]

------- Comment #3 from rakdver at gcc dot gnu dot org  2007-06-20 06:57 -------
Should be fixed now.


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32405