http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47654
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P2
CC| |law at redhat dot com
AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Jeffrey A. Law <law at redhat dot com> 2011-02-18 19:35:31
UTC ---
Looks to be a graphite problem as well. I'm not 100% sure I've got the root
cause of the problem, but there's definitely something fishy in the code
graphite generated.
Prior to graphite we had this nice little loop nest:
# BLOCK 2 freq:3
# PRED: ENTRY [100.0%] (fallthru,exec)
goto <bb 7>;
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 3 freq:9801
# PRED: 4 [99.0%] (true,exec)
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 4 freq:9900
# PRED: 3 [100.0%] (fallthru,exec) 7 [100.0%] (fallthru,exec)
# j_16 = PHI <j_5(3), 0(7)>
# .MEM_17 = PHI <.MEM_10(3), .MEM_4(7)>
# .MEM_10 = VDEF <.MEM_17>
a[j_16][i_13] = 4;
j_5 = j_16 + 1;
if (j_5 <= 127)
goto <bb 3>;
else
goto <bb 5>;
# SUCC: 3 [99.0%] (true,exec) 5 [1.0%] (false,exec)
# BLOCK 5 freq:100
# PRED: 4 [1.0%] (false,exec)
i_6 = i_13 + 1;
if (i_6 <= 39)
goto <bb 6>;
else
goto <bb 8>;
# SUCC: 6 [97.6%] (true,exec) 8 [2.4%] (false,exec)
# BLOCK 6 freq:98
# PRED: 5 [97.6%] (true,exec)
# SUCC: 7 [100.0%] (fallthru,exec)
# BLOCK 7 freq:100
# PRED: 6 [100.0%] (fallthru,exec) 2 [100.0%] (fallthru,exec)
# .MEM_4 = PHI <.MEM_10(6), .MEM_9(D)(2)>
# i_13 = PHI <i_6(6), 0(2)>
goto <bb 4>;
# SUCC: 4 [100.0%] (fallthru,exec)
# BLOCK 8 freq:3
# PRED: 5 [2.4%] (false,exec)
return;
# SUCC: EXIT [100.0%]
After graphite blocking the loop we have:
# BLOCK 2 freq:15
# PRED: ENTRY [100.0%] (fallthru,exec)
# SUCC: 3 [100.0%] (fallthru)
# BLOCK 3 freq:45
# PRED: 2 [100.0%] (fallthru) 11 [100.0%] (fallthru,dfs_back)
# graphite_IV.1_18 = PHI <0(2), graphite_IV.1_3(11)>
# .MEM_30 = PHI <.MEM_9(D)(2), .MEM_31(11)>
D.2713_8 = graphite_IV.1_18 * 51;
D.2714_1 = MAX_EXPR <D.2713_8, 0>;
D.2713_15 = graphite_IV.1_18 * 51;
D.2715_14 = D.2713_15 + 50;
D.2716_7 = MIN_EXPR <D.2715_14, 127>;
D.2717_2 = D.2716_7 + 1;
D.2718_12 = D.2714_1 < D.2717_2;
if (D.2718_12 != 0)
goto <bb 4>;
else
goto <bb 10>;
# SUCC: 4 [50.0%] (true) 10 [50.0%] (false)
# BLOCK 4 freq:22
# PRED: 3 [50.0%] (true)
D.2720_11 = graphite_IV.1_18 * 51;
graphite_IV.2_19 = MAX_EXPR <D.2720_11, 0>;
D.2721_20 = graphite_IV.1_18 * 51;
D.2722_21 = D.2721_20 + 50;
D.2723_22 = MIN_EXPR <D.2722_21, 127>;
# SUCC: 5 [100.0%] (fallthru)
# BLOCK 5 freq:250
# PRED: 4 [100.0%] (fallthru) 9 [100.0%] (fallthru,dfs_back)
# graphite_IV.2_23 = PHI <graphite_IV.2_19(4), graphite_IV.2_24(9)>
# .MEM_32 = PHI <.MEM_30(4), .MEM_33(9)>
# SUCC: 6 [100.0%] (fallthru)
# BLOCK 6 freq:10000
# PRED: 5 [100.0%] (fallthru) 7 [100.0%] (fallthru,dfs_back)
# graphite_IV.3_25 = PHI <0(5), graphite_IV.3_26(7)>
# .MEM_34 = PHI <.MEM_32(5), .MEM_27(7)>
D.2725_28 = (int) graphite_IV.2_23;
D.2726_29 = (int) graphite_IV.3_25;
# .MEM_27 = VDEF <.MEM_34>
a[D.2725_28][D.2726_29] = 4;
graphite_IV.3_26 = graphite_IV.3_25 + 1;
if (graphite_IV.3_25 < 39)
goto <bb 7>;
else
goto <bb 8>;
# SUCC: 7 [97.5%] (true) 8 [2.5%] (loop_exit,false)
# BLOCK 7 freq:9750
# PRED: 6 [97.5%] (true)
goto <bb 6>;
# SUCC: 6 [100.0%] (fallthru,dfs_back)
# BLOCK 8 freq:250
# PRED: 6 [2.5%] (loop_exit,false)
# .MEM_33 = PHI <.MEM_27(6)>
graphite_IV.2_24 = graphite_IV.2_23 + 1;
if (graphite_IV.2_23 < D.2723_22)
goto <bb 9>;
else
goto <bb 10>;
# SUCC: 9 [91.0%] (true) 10 [9.0%] (loop_exit,false)
# BLOCK 9 freq:227
# PRED: 8 [91.0%] (true)
goto <bb 5>;
# SUCC: 5 [100.0%] (fallthru,dfs_back)
# BLOCK 10 freq:45
# PRED: 8 [9.0%] (loop_exit,false) 3 [50.0%] (false)
# .MEM_31 = PHI <.MEM_33(8), .MEM_30(3)>
graphite_IV.1_3 = graphite_IV.1_18 + 1;
if (graphite_IV.1_18 < 2)
goto <bb 11>;
else
goto <bb 12>;
# SUCC: 11 [66.7%] (true) 12 [33.3%] (loop_exit,false)
The first thing I've noticed is we're using relational comparisons on signed
values that are overflowing. Consider just about everything in block #3.
Most of the variables are 8 bit signed integers and overflow on this testcase,
including the test for terminating or iterating the loop.
I don't know if that's the root cause of the problem, but I am certain that we
are exiting the middle or outer loop too early, resulting in a partially
initialized array that ultimately triggers the abort.
