https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66396

--- Comment #3 from amker at gcc dot gnu.org ---
Interesting case.
I know nothing about graphite, but I guess the case is fixed in patch for
PR47653 by skipping graphite transofromation on loops in specific forms.  The
skip mechanism is kind of nullified by the overflow change.  But as far as I
can see, we shouldn't skip graphite transformation on the case in the first
place because it looks good to me.

See dumps before graphite pass:

bar ()
{
  _Bool j_lsm.8;
  int j_lsm.7;
  int * y;
  int * x;
  char * p;
  int i;
  int j;
  struct Foo f;
  unsigned int j.2_11;
  int j.1_13;
  int * * _15;
  int * _16;
  int _17;
  int j.0_31;

  <bb 2>:
  i = 1;
  x = &i;
  y = &j;
  f.p = &y;
  f.q = &x;

  <bb 3>:
  # p_27 = PHI <&f(2), p_12(4)>
  # j.0_31 = PHI <0(2), j.1_13(4)>
  p_12 = p_27 + 1;
  j.1_13 = j.0_31 + 1;
  j.2_11 = (unsigned int) j.1_13;
  if (j.2_11 <= 3)
    goto <bb 4>;
  else
    goto <bb 5>;

  <bb 4>:
  goto <bb 3>;

  <bb 5>:
  p_25 = &f + 4;
  j = 4;
  _15 = MEM[(int * * *)p_25];
  _16 = *_15;
  _17 = *_16;
  f ={v} {CLOBBER};
  j ={v} {CLOBBER};
  i ={v} {CLOBBER};
  x ={v} {CLOBBER};
  y ={v} {CLOBBER};
  return _17;

}
graphite transforms it infor below shape:
bar ()
{
  _Bool j_lsm.8;
  int j_lsm.7;
  int * y;
  int * x;
  char * p;
  int i;
  int j;
  struct Foo f;
  int * * _15;
  int * _16;
  int _17;

  <bb 2>:
  i = 1;
  x = &i;
  y = &j;
  f.p = &y;
  f.q = &x;
  p_25 = &f + 4;
  j = 4;
  _15 = MEM[(int * * *)p_25];
  _16 = *_15;
  _17 = *_16;
  f ={v} {CLOBBER};
  j ={v} {CLOBBER};
  i ={v} {CLOBBER};
  x ={v} {CLOBBER};
  y ={v} {CLOBBER};
  return _17;

}

It is dce4 pass that deletes the bounch of initialization code at beginning of
bb 2.  dce4.dump is as below:
bar ()
{
  _Bool j_lsm.8;
  int j_lsm.7;
  int * y;
  int * x;
  char * p;
  int i;
  int j;
  struct Foo f;
  int * * _15;
  int * _16;
  int _17;

  <bb 2>:
  p_25 = &f + 4;
  j = 4;
  _15 = MEM[(int * * *)p_25];
  _16 = *_15;
  _17 = *_16;
  f ={v} {CLOBBER};
  j ={v} {CLOBBER};
  i ={v} {CLOBBER};
  x ={v} {CLOBBER};
  y ={v} {CLOBBER};
  return _17;

}

I thought this was a strict-aliasing issue, but specifying
"-fno-strict-aliasing" doesn't give any difference.

Reply via email to