[Bug tree-optimization/57396] New: Wrong code with -fpredictive-commoning in Fortran double-loop

[Bug tree-optimization/57396] New: Wrong code with -fpredictive-commoning in Fortran double-loop

[bugs at stellardeath dot org]

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

            Bug ID: 57396
           Summary: Wrong code with -fpredictive-commoning in Fortran
                    double-loop
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugs at stellardeath dot org

Created attachment 30182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30182&action=edit
Small test case

The following example program produces incorrect output when compiled with -O3,
but remains correct with -O3 -fno-predictive-commining:

> cat test.f90
module testmod
  implicit none

  contains

  subroutine foo(n)
    integer, intent(in) :: n
    real :: r(0:n,-n:n), a(0:n,-n:n), dj
    integer :: k, j

    ! initialize with some dummy values
    do j = -n, n
      a(:, j) = j
      r(:,j) = j + 1
    end do

    ! here be dragons
    do k = 0, n
      dj = r(k, k - 2) * a(k, k - 2)
      r(k,k) = a(k, k - 1) * dj
    enddo

    print *, r(0,0)

  end subroutine

end module

program test
  use testmod
  implicit none
  call foo(5)
end program

> gfortran -O3 test.f90
> ./a.out 
  -3.00000000    
>
> gfortran -O3 -fno-predictive-commoning test.f90
> ./a.out 
  -2.00000000    
>

This only happens with gfortran 4.8, with 4.7.2 it produces the correct output
(-2.0). My specific version is:

> gfortran --version
GNU Fortran (GCC) 4.9.0 20130517 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

[Bug tree-optimization/57396] Wrong code with -fpredictive-commoning in Fortran double-loop

[bugs at stellardeath dot org]

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

--- Comment #1 from Lorenz Hüdepohl <bugs at stellardeath dot org> ---
As the loop is quite confusing, i wrote a small python program to reproduce the
correct result:

> cat test.py
def foo(n):
    r = {}
    a = {}

    # initialize with some dummy values
    for i in range(-n, n + 1):
        for j in range(-n, n + 1):
            a[(i,j)] = j
            r[(i,j)] = j + 1

    # here be dragons
    for k in range(0, n + 1):
      dj = r[(k, k - 2)] * a[(k, k - 2)]
      r[(k,k)] = a[(k, k - 1)] * dj

    # print it out
    print "{0:12.8f}".format(r[(0,0)])

foo(5)
> python ./test.py
 -2.00000000
>
>From gcc-bugs-return-423038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 24 10:50:38 2013
Return-Path: <gcc-bugs-return-423038-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25485 invoked by alias); 24 May 2013 10:50:38 -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 25448 invoked by uid 48); 24 May 2013 10:50:32 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56991] constexpr std::initializer_list rejects too complex initialization
Date: Fri, 24 May 2013 10:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56991-4-CkQ5aR9y93@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56991-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56991-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-05/txt/msg01711.txt.bz2
Content-length: 752

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

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Matheus Izvekov from comment #2)
> I get also a similar bug:
> 
> #include <initializer_list>
> 
> //is accepted by gcc
> constexpr std::initializer_list<int> good1 = { 1, 2, 3 };
> 
> struct foo { int a, b; };
> 
> //still ok
> constexpr foo good2 = { 1, 2 };
> 
> //gcc rejects this
> constexpr std::initializer_list<foo> bad = { { 1, 2 }, { 3, 4} };

A variation of the last line also produces the same error:

constexpr std::initializer_list<foo> bad2 = { good2, good2 };

I can confirm that the error also occurs for the trunk, tested with gcc 4.9.0
20130519 (experimental).
>From gcc-bugs-return-423039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 24 10:51:57 2013
Return-Path: <gcc-bugs-return-423039-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27942 invoked by alias); 24 May 2013 10:51:57 -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 27906 invoked by uid 48); 24 May 2013 10:51:54 -0000
From: "jasonwucj at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57377] compiler cannot be built with RTL checking
Date: Fri, 24 May 2013 10:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jasonwucj at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-57377-4-mDvJP4yRZi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57377-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57377-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: 2013-05/txt/msg01712.txt.bz2
Content-length: 600

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

Chung-Ju Wu <jasonwucj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasonwucj at gmail dot com

--- Comment #1 from Chung-Ju Wu <jasonwucj at gmail dot com> ---
The s390 maintainer provided a patch to this problem:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html

He also added documentation for the mnemonic attribute:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01436.html

[Bug tree-optimization/57396] [4.7/4.8/4.9 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-24
   Target Milestone|---                         |4.7.4
            Summary|Wrong code with             |[4.7/4.8/4.9 Regression]
                   |-fpredictive-commoning in   |Wrong code with
                   |Fortran double-loop         |-fpredictive-commoning in
                   |                            |Fortran double-loop
     Ever confirmed|0                           |1
      Known to fail|                            |4.3.4, 4.6.4, 4.7.2, 4.8.1,
                   |                            |4.9.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have

  {stride.3_18 * -2 - _30, +, stride.3_18 + 1}_4

vs.

  {-stride.3_18 - _30, +, stride.3_18 + 1}_4

for the two a-based accesses.  But that isn't stride.3_18 + 1 apart.

Regression since predictive commoning is enabled by default at -O3.

[Bug tree-optimization/57396] [4.7/4.8/4.9 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
DR_OFFSETs are (ssizetype) ((sizetype) (-stride.3_18 - _30) * 4)
vs. (ssizetype) ((sizetype) (stride.3_18 * -2 - _30) * 4)

and in the affine combination together with DR_INITs of zero we get

{
  type = ssizetype
  offset = 0
  elements = {
    [0] = MAX_EXPR <stride.3_17, 0> * -8, 
    [1] = lbound.1_20 * stride.3_18 * -4
  }
}
{
  type = ssizetype
  offset = 0
  elements = {
    [0] = MAX_EXPR <stride.3_17, 0> * -4, 
    [1] = lbound.1_20 * stride.3_18 * -4
  }
}

(_30 = lbound.1_20 * stride.3_18)

With the difference

{
  type = ssizetype
  offset = 0
  elements = {
    [0] = MAX_EXPR <stride.3_17, 0> * -4
  }
}


DR_STEP is (ssizetype) ((sizetype) (stride.3_18 + 1) * 4)

{
  type = ssizetype
  offset = 4
  elements = {
    [0] = MAX_EXPR <stride.3_17, 0> * 4
  }
}

and double_int_constant_multiple_p's result is not interpreted correctly in
aff_combination_constant_multiple_p:

  if (!double_int_constant_multiple_p (val->offset, div->offset,
                                       &mult_set, mult))
    return false;

which doesn't handle the val->offset == 0 case where it returns true
but does not set mult.  So it looks like it should return false if
!mult_set and val->offset is not equal to div->offset.

I have a patch.

[Bug tree-optimization/57396] [4.7/4.8/4.9 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On x86_64-apple-darwin10, the test gives the right output for GCC 4.7.3.
Revision 187340 (2012-05-09) is OK, but revision 187440 (2012-05-13) is not.

[Bug tree-optimization/57396] [4.8/4.9 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.3.4, 4.6.4, 4.7.2
            Summary|[4.7/4.8/4.9 Regression]    |[4.8/4.9 Regression] Wrong
                   |Wrong code with             |code with
                   |-fpredictive-commoning in   |-fpredictive-commoning in
                   |Fortran double-loop         |Fortran double-loop
      Known to fail|4.3.4, 4.6.4, 4.7.2, 4.8.1  |4.8.0

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #4)
> On x86_64-apple-darwin10, the test gives the right output for GCC 4.7.3.
> Revision 187340 (2012-05-09) is OK, but revision 187440 (2012-05-13) is not.

Ah, yes, my testing of older releases was flawed.  Still the piece I patch
has the same error since forever, so it was just latent.

[Bug tree-optimization/57396] [4.8 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.9.0
   Target Milestone|4.7.4                       |4.8.2
            Summary|[4.8/4.9 Regression] Wrong  |[4.8 Regression] Wrong code
                   |code with                   |with -fpredictive-commoning
                   |-fpredictive-commoning in   |in Fortran double-loop
                   |Fortran double-loop         |
      Known to fail|4.9.0                       |4.8.1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon May 27 07:48:37 2013
New Revision: 199350

URL: http://gcc.gnu.org/viewcvs?rev=199350&root=gcc&view=rev
Log:
2013-05-27  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/57396
    * tree-affine.c (double_int_constant_multiple_p): Properly
    return false for val == 0 and div != 0.

    * gfortran.fortran-torture/execute/pr57396.f90: New testcase.

Added:
    trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr57396.f90
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-affine.c

[Bug tree-optimization/57396] [4.8 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Aug 29 13:11:01 2013
New Revision: 202073

URL: http://gcc.gnu.org/viewcvs?rev=202073&root=gcc&view=rev
Log:
    Backported from mainline
    2013-05-27  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/57396
    * tree-affine.c (double_int_constant_multiple_p): Properly
    return false for val == 0 and div != 0.

    * gfortran.fortran-torture/execute/pr57396.f90: New testcase.

Added:
   
branches/gcc-4_8-branch/gcc/testsuite/gfortran.fortran-torture/execute/pr57396.f90
Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/tree-affine.c

[Bug tree-optimization/57396] [4.8 Regression] Wrong code with -fpredictive-commoning in Fortran double-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.