This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/47654] [4.6 Regression] gcc.dg/vect/no-section-anchors-vect-outer-4h.c FAILs with -floop-block


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]