[Bug middle-end/56932] New: [regression 4.8]: vrp and/or niter-related wrong-code bug

[Bug middle-end/56932] New: [regression 4.8]: vrp and/or niter-related wrong-code bug

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

             Bug #: 56932
           Summary: [regression 4.8]: vrp and/or niter-related wrong-code
                    bug
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ktietz@gcc.gnu.org


The following testcase triggers this wrong code-bug.

int a[250];
__attribute__ ((noinline))
t(int i)
{
  if (i==0)
    exit(0);
  if (i>255)
    abort ();
}
main()
{
  unsigned int i;
  for (i=0;;i++)
    {
      a[i]=t((i+5)&0xff);
    }
}

It fails with vrp-pass enabled.  The issue is that overflow of (i+5)&0xff isn't
detected correct.

This test is related to existing testcase pr/55875 in gcc.c-torture/execute.

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-04-12 11:28:02 UTC ---
a[i]

causes undefined behavior as there is an access above the array bounds.

If I change the loop to be:
  for (i=0;i<250;i++)

Or

  for (i=0;i<1024;i++)
and increase the size of a to 1024.  The code works correctly.

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-12 11:50:23 UTC ---
The testcase in gcc.c-torture/execute/pr55875.c does seem off by 1. For i==250,
i+5 is 255 and we don't exit yet (that happens for 251) but we do write to the
array. Increasing the size of the array to 251 is enough.

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[graham.stott at btinternet dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

--- Comment #3 from graham.stott at btinternet dot com 2013-04-12 12:21:59 UTC ---
ktietz.

Access to a[250] is undefined  as pointed out by andrew.

Increase size of a to 251 to get the test passing.

Graham
>From gcc-bugs-return-419920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 12 12:40:08 2013
Return-Path: <gcc-bugs-return-419920-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5154 invoked by alias); 12 Apr 2013 12:40:08 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5081 invoked by uid 48); 12 Apr 2013 12:40:05 -0000
From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/56933] New: [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
Date: Fri, 12 Apr 2013 12:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wschmidt at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56933-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg01065.txt.bz2
Content-length: 2317


http://gcc.gnu.org/bugzilla/show_bug.cgi?idV933

             Bug #: 56933
           Summary: [4.9 Regression] Vectorizer missing read-write
                    dependency for interleaved accesses
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: wschmidt@gcc.gnu.org
                CC: bergner@gcc.gnu.org, dje@gcc.gnu.org,
                    rguenth@gcc.gnu.org
              Host: powerpc*-*-*
            Target: powerpc*-*-*
             Build: powerpc*-*-*


Created attachment 29861
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id)861
Vectorization details dump for the test case

vect_analyze_group_access() in tree-vect-data-refs.c contains a test for
load-store dependencies:

              if (GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (next))
                  || GROUP_READ_WRITE_DEPENDENCE (vinfo_for_stmt (prev)))

Currently this always returns false because this field has not yet been set in
the vinfo.  This began with r196872, where the code to analyze accesses was
moved ahead of the code to analyze dependences.

I put together a test demonstrating that it's possible for us to generate
incorrect code as a result:

       subroutine test(a,b,c,d,e,f)
       integer k
       real*4, intent(out) :: a(1000)
       real*4, intent(out) :: b(1000)
       real*4, intent(in) :: c(1000)
       real*4, intent(inout) :: d(2000)
       real*4, intent(out) :: e(1000)
       real*4, intent(out) :: f(1000)

       do k = 1,1000
          a(k) = 3.0 * d(2*k)
          e(k) = 3.3 * d(2*k+1)
          d(2*k) = 2.0 * c(k)
          d(2*k+1) = 2.3 * c(k)
          b(k) = d(2*k) - 5.5;
          f(k) = d(2*k+1) + 5.5;
       enddo

       return
       end

I'm attaching a detailed dump of the vectorization pass that shows that the
values of d(2*k) and d(2*k+1) used to compute b(k) and f(k) are the ones loaded
prior to the stores to those locations.

To reproduce on powerpc64-unknown-linux-gnu:

$ gfortran -O3 -ffast-math -mcpu=power7 -fno-vect-cost-model interl-lsl-2.f

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

--- Comment #4 from Kai Tietz <ktietz at gcc dot gnu.org> 2013-04-12 18:31:05 UTC ---
Well, indeed increasing the array-size helps to avoid this issue.  Nevertheless
I don't get why it produces wrong code for argument of call of function t here.
That there is a out-of-bounds access is one thing, but there is still wrong
code produced.  Also why - if gcc already detects an out-of-bounds access -
there is no warning for that?

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-04-12 19:00:02 UTC ---
(In reply to comment #4)
> Well, indeed increasing the array-size helps to avoid this issue.  Nevertheless
> I don't get why it produces wrong code for argument of call of function t here.
> That there is a out-of-bounds access is one thing, but there is still wrong
> code produced.  Also why - if gcc already detects an out-of-bounds access -
> there is no warning for that?

There should be a warning that was added before 4.8 was released (Jakub knows
more about it and maybe even why the warning in this case is not happening).

[Bug middle-end/56932] [regression 4.8]: vrp and/or niter-related wrong-code bug

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56932

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-12 20:02:01 UTC ---
(In reply to comment #4)
> Well, indeed increasing the array-size helps to avoid this issue.  Nevertheless
> I don't get why it produces wrong code for argument of call of function t here.

At iteration i, you write to a[i], so i is obviously <250. This means that at
the next iteration, i<251, i+5<256, and the &0xff can be omitted.

> That there is a out-of-bounds access is one thing, but there is still wrong
> code produced.

Well, no, the program could have crashed for the out of bounds access before
even reaching the point where you noticed the "wrong code".

> Also why - if gcc already detects an out-of-bounds access -
> there is no warning for that?

There is a lot of progress to be made here...