From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-488059-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 66477 invoked by alias); 4 Jun 2015 04:13:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 65443 invoked by uid 48); 4 Jun 2015 04:13:15 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/66396] [6 regression] FAIL: gcc.dg/graphite/run-id-pr47593.c execution test
Date: Thu, 04 Jun 2015 04:13:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66396-4-Y1jwq0rrJ0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66396-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66396-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-06/txt/msg00391.txt.bz2

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.