------- Comment #2 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2005-10-25 15:56 -------
Subject: Re: [4.1 Regression] ICE in ivopts
Hello,
> Breakpoint 1, fancy_abort (file=0xb1cc18
> "../../mainline/gcc/tree-ssa-loop-ivopts.c",
> line=2948, function=0xb1d0bb "aff_combination_to_tree") at
> diagnostic.c:590
> 590 internal_error ("in %s, at %s:%d", function, trim_filename (file),
> line);
> (gdb) up
> #1 0x000000000056db37 in aff_combination_to_tree (comb=0x7fbfffec30)
> at tree-ssa-loop-ivopts.c:2948
> 2948 gcc_assert (comb->n == MAX_AFF_ELTS || comb->rest == NULL_TREE);
> (gdb) p *comb
> $17 = {type = 0x2a9589e580, mask = 4294967295, offset = 0, n = 2, elts =
> {0x2a95a8f680,
> 0x2a95a639a0, 0x2a95a6d8c0, 0x2a95a6d850, 0x2a95a6d850, 0x2a95a6d8c0,
> 0x2a95a6d930,
> 0x2a95a6d9a0}, coefs = {1, 1, 0, 0, 1, 1, 1, 1}, rest = 0x2a95a8f700}
> (gdb) call debug_generic_expr (comb->elts[0])
> (unsigned intD.3) -j9D.1618_41
> (gdb) call debug_generic_expr (comb->elts[1])
> ivtmp.30D.1722_4
> (gdb) call debug_generic_expr (comb->elts[2])
> j6D.1615_65
> (gdb) call debug_generic_expr (comb->elts[3])
> j5D.1614_64
> (gdb) call debug_generic_expr (comb->elts[4])
> j5D.1614_64
> (gdb) call debug_generic_expr (comb->elts[5])
> j6D.1615_65
> (gdb) call debug_generic_expr (comb->elts[6])
> j7D.1616_66
> (gdb) call debug_generic_expr (comb->elts[7])
> j8D.1617_67
> (gdb) call debug_generic_expr (comb->rest)
> (unsigned intD.3) j9D.1618_41
> (gdb)
>
> Why do we have (comb->n == 2) when we have 8 elts?
that's not necessarily a bug, # of elements in the combination may get
changed due to arithmetical operations with it, and the old elements
are not zeroed. But once comb->n < MAX_AFF_ELTS, comb->rest should be
moved to the available slot in elts, which apparently some function
fails to do. I will have a look.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24483
