[Bug fortran/34006] New: vectorization with 64-bit integers

[Bug fortran/34006] New: vectorization with 64-bit integers

[valera dot veryazov at teokem dot lu dot se]

Hi, 
the code (see below) compiled with 
gfortran -O2 -Wall -fdefault-integer-8 -ftree-vectorize a.f
gives a complete garbage, since compiler changing the order of execution 
inside the loop. 
=========================

     DIMENSION Nvec(10),iVEC(10)
      do i=1,10
        Nvec(i)=i
      enddo
      call Zbase(Nvec,iVec,10)
      print *,iVec
      end

      SUBROUTINE ZBASE(NVEC,IVEC,NCLASS)
      DIMENSION NVEC(NCLASS),IVEC(NCLASS)
      IVEC(1) = 1
      DO 100 ICLASS = 2,NCLASS
        IVEC(ICLASS) = IVEC(ICLASS-1)+NVEC(ICLASS-1)
  100 CONTINUE

      RETURN
      END



=========================



Removing -ftree-vectorize, or -fdefault-integer-8, or changing loop to 
'Do 100 ICLASS= 2, 10' solves the problem.

           Best Regards,
                    Valera.


-- 
           Summary: vectorization with 64-bit integers
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: valera dot veryazov at teokem dot lu dot se
  GCC host triplet: Linux_x86-64 CentOS


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

[Bug fortran/34006] vectorization with 64-bit integers

[kargl at gcc dot gnu dot org]

------- Comment #1 from kargl at gcc dot gnu dot org  2007-11-06 17:45 -------
Works for me on trunk.  Doesn't work in 4.2.  

troutmask:sgk[217] gfc4x -o z -O2 -ftree-vectorize -fdefault-integer-8 z.f
troutmask:sgk[218] ./z
1 2 4 7 11 16 22 29 37 46
troutmask:sgk[219] gfc4x -o z -O2 -ftree-vectorize z.f
troutmask:sgk[220] ./z
1 2 4 7 11 16 22 29 37 46
troutmask:sgk[221] gfc -o z -O2 -ftree-vectorize z.f
troutmask:sgk[222] ./z
1 2 4 7 11 16 22 29 37 46
troutmask:sgk[223] gfc -o z -O2 -ftree-vectorize -fdefault-integer-8 z.f
troutmask:sgk[224] ./z
1 2 4 140737488348667 140737488348671 5 11 8601384231 8601384239 9

IMHO, one should avoid -fdefault-integer-8 because it typically doesn't
do what one thinks!


-- 


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

[Bug fortran/34006] vectorization with 64-bit integers

[valera dot veryazov at teokem dot lu dot se]

------- Comment #2 from valera dot veryazov at teokem dot lu dot se  2007-11-07 09:45 -------
VV: confirmed also in 4.2.2


-- 


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

[Bug middle-end/34006] [4.2 only] vectorization with 64-bit integers

[fxcoudert at gcc dot gnu dot org]

------- Comment #3 from fxcoudert at gcc dot gnu dot org  2007-11-08 14:04 -------
Testcase that doesn't require -fdefault-integer-8:

$ cat a.f90
program test
  integer(kind=8) nvec(10), ivec(10), nclass
  integer i
  nvec(:)= 1
  ivec(:) = 0
  call zbase(nvec,ivec,10)
  write(*,'(10I3)') ivec
end

subroutine zbase(nvec,ivec,nclass)
  integer(kind=8) nvec(10), ivec(10), iclass
  integer nclass
  do iclass = 2,nclass
    ivec(iclass) = ivec(iclass-1)+nvec(iclass-1)
  end do
end
$ gfortran-4.2.2 -O1 a.f90 && ./a.out
  0  1  2  3  4  5  6  7  8  9
$ gfortran-4.2.2 -O1 -ftree-vectorize a.f90 && ./a.out
  0  1  2  1  2  1  2  1  2  1

I can't make a C testcase out of this, but I really think that the code emitted
by the front-end is fine, thus I'm recategorizing this as middle-end.

Also: on my x86_64-linux, it works fine for 4.1.2.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
          Component|fortran                     |middle-end
     Ever Confirmed|0                           |1
   GCC host triplet|Linux_x86-64 CentOS         |
 GCC target triplet|                            |x86_64-linux
           Keywords|                            |wrong-code
      Known to fail|                            |4.2.2
      Known to work|                            |4.3.0
   Last reconfirmed|0000-00-00 00:00:00         |2007-11-08 14:04:26
               date|                            |
            Summary|vectorization with 64-bit   |[4.2 only] vectorization
                   |integers                    |with 64-bit integers


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

[Bug middle-end/34006] [4.2 only] vectorization with 64-bit integers

[victork at gcc dot gnu dot org]

------- Comment #4 from victork at gcc dot gnu dot org  2007-12-12 04:06 -------
I have tried both testcases with compiler built from svn branch of 4.2
(svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch) on x86_64.
Both cases run correctly. Looks like this bug is already fixed in 4.2 and 4.3.


-- 

victork at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |victork at il dot ibm dot
                   |                            |com


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

[Bug middle-end/34006] [4.2 Regression] vectorization with 64-bit integers

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|4.3.0                       |4.1.3 4.3.0
            Summary|[4.2 only] vectorization    |[4.2 Regression]
                   |with 64-bit integers        |vectorization with 64-bit
                   |                            |integers
   Target Milestone|---                         |4.2.4


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

[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization
           Priority|P3                          |P2


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

[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers

[victork at gcc dot gnu dot org]

------- Comment #5 from victork at gcc dot gnu dot org  2008-03-26 10:27 -------
I've managed to reproduce the problem with gcc from 4.2 branch on x86_64
machine.
Note that the reduced testcase works with -m32 command line switch.


-- 

victork at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |victork at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-11-08 14:04:26         |2008-03-26 10:27:41
               date|                            |


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

[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers

[victork at gcc dot gnu dot org]

------- Comment #6 from victork at gcc dot gnu dot org  2008-04-10 10:36 -------
The problem in reduced testcase is that loop gets vectorized by gcc 4.2 despite
a dependency between iterations with distance 1.
compute_data_dependences_for_loop () returns "chrec_known" for DDR {
ivec(iclass), ivec(iclass-1) }.

Here is part of dump produced by scev in 4.2:

(compute_affine_dependence
  (stmt_a =
D.1282_9 = (*ivec_8)[D.1281_7])
  (stmt_b =
(*ivec_8)[D.1280_6] = D.1284_13)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {0, +, 1}_1)
  (chrec_b = {1, +, 1}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = scev_known)
  (overlaps_b = scev_known)
)
)
  (overlap_iterations_a = scev_known)
  (overlap_iterations_b = scev_known)
)
(dependence classified: scev_known)
)
)


While in gcc 4.3 the scev produces the following dump for same DDR:

(compute_affine_dependence
  (stmt_a =
D.970_9 = (*ivec_8(D))[D.969_7])
  (stmt_b =
(*ivec_8(D))[D.968_6] = D.972_13)
(subscript_dependence_tester
(analyze_overlapping_iterations
  (chrec_a = {0, +, 1}_1)
  (chrec_b = {1, +, 1}_1)
(analyze_siv_subscript
(analyze_subscript_affine_affine
  (overlaps_a = [1 + 1 * x_1]
)
  (overlaps_b = [0 + 1 * x_1]
)
)
)
  (overlap_iterations_a = [1 + 1 * x_1]
)
  (overlap_iterations_b = [0 + 1 * x_1]
)
)
(analyze_overlapping_iterations
  (chrec_a = 0B)
  (chrec_b = 0B)
(analyze_ziv_subscript
)
  (overlap_iterations_a = [0]
)
  (overlap_iterations_b = [0]
)
)
(build_classic_dist_vector
  dist_vector = (  1
  )
)
)
)


Sebastian, can you take a look?
Thanks.


-- 

victork at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spop at gcc dot gnu dot org
         AssignedTo|victork at gcc dot gnu dot  |spop at gcc dot gnu dot org
                   |org                         |


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

[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers

[jsm28 at gcc dot gnu dot org]

------- Comment #7 from jsm28 at gcc dot gnu dot org  2008-05-19 20:23 -------
4.2.4 is being released, changing milestones to 4.2.5.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.4                       |4.2.5


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

[Bug tree-optimization/34006] [4.2 Regression] vectorization with 64-bit integers

[jsm28 at gcc dot gnu dot org]

------- Comment #8 from jsm28 at gcc dot gnu dot org  2009-03-31 00:37 -------
Closing 4.2 branch, fixed in 4.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|4.2.2                       |4.2.2 4.2.5
         Resolution|                            |FIXED
   Target Milestone|4.2.5                       |4.3.0


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