Bug 24483 - [4.1 Regression] ICE in ivopts
Summary: [4.1 Regression] ICE in ivopts
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.0
: P1 critical
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, patch
Depends on:
Blocks: 18595
  Show dependency treegraph
 
Reported: 2005-10-22 03:32 UTC by Andrew Pinski
Modified: 2005-11-03 18:12 UTC (History)
2 users (show)

See Also:
Host:
Target: x86_64-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-10-25 15:30:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-10-22 03:32:48 UTC
Take the following code:
int f ()
{       int j0, j1, j2, j3, j4, j5, j6, j7, j8, j9, a;
        a = 0;
        for (j0 = 0; j0 < 2; j0 ++)
        for (j1 = j0; j1 < 2; j1 ++)
        for (j2 = j1; j2 < 2; j2 ++)
        for (j3 = j2; j3 < 2; j3 ++)
        for (j4 = j3; j4 < 2; j4 ++)
        for (j5 = j4; j5 < 2; j5 ++)
        for (j6 = j5; j6 < 2; j6 ++)
        for (j7 = j6; j7 < 2; j7 ++)
        for (j8 = j7; j8 < 2; j8 ++)
        for (j9 = j8; j9 < 2; j9 ++)
        a += j0 + j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8 + j9;
        return a;
}

---

Right now we ICE:
t.c:2: internal compiler error: in aff_combination_to_tree, at tree-ssa-loop-ivopts.c:2948
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

This was generated with the awk script from PR 18595.
Comment 1 Steven Bosscher 2005-10-25 15:30:24 UTC
Backtrace:

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?

Comment 2 Zdenek Dvorak 2005-10-25 15:56:01 UTC
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.
Comment 3 Zdenek Dvorak 2005-10-26 13:02:03 UTC
Patch:

http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01527.html
Comment 4 Mark Mitchell 2005-10-31 06:35:11 UTC
ICE on reasonable code; showstopper.
Comment 5 Zdenek Dvorak 2005-11-03 16:28:12 UTC
Subject: Bug 24483

Author: rakdver
Date: Thu Nov  3 16:28:09 2005
New Revision: 106440

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106440
Log:
	PR tree-optimization/24483
	* tree-ssa-loop-ivopts.c (aff_combination_add_elt): Move rest
	field to elts if possible.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c

Comment 6 Andrew Pinski 2005-11-03 18:12:39 UTC
Fixed.