Bug 15553 - Array copy operation produces garbage
Array copy operation produces garbage
Status: RESOLVED WORKSFORME
Product: gcc
Classification: Unclassified
Component: fortran
4.0.0
: P2 normal
: 4.0.0
Assigned To: Not yet assigned to anyone
: wrong-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-20 13:25 UTC by Erik Schnetter
Modified: 2005-01-07 14:10 UTC (History)
3 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-01-06 16:28:46


Attachments
failing source code (751 bytes, text/plain)
2004-05-20 13:25 UTC, Erik Schnetter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Schnetter 2004-05-20 13:25:05 UTC
The attached programme fails with GNU Fortran 95 (GCC 3.5.0 20040520 
(experimental)). 
 
The programme packs the 2D array x.  The array has the shape (10,10), of which 
only the subarray (6,5) is used.  The programme copies the 6*5=30 elements 
into the "first" 30 elements of x, where "first" is here according to the 
Fortran array ordering. 
 
When run, I expect the output 
 
          11   11.0000000000000      
          12   12.0000000000000      
          13   13.0000000000000      
          14   14.0000000000000      
          15   15.0000000000000      
          16   16.0000000000000      
          17   21.0000000000000      
          18   22.0000000000000      
          19   23.0000000000000      
          20   24.0000000000000      
          21   25.0000000000000      
          22   26.0000000000000      
          23   31.0000000000000      
          24   32.0000000000000      
          25   33.0000000000000      
          26   34.0000000000000      
          27   35.0000000000000      
          28   36.0000000000000      
          29   41.0000000000000      
          30   42.0000000000000      
          31   43.0000000000000      
          32   44.0000000000000      
          33   45.0000000000000      
          34   46.0000000000000      
          35   51.0000000000000      
          36   52.0000000000000      
          37   53.0000000000000      
          38   54.0000000000000      
          39   55.0000000000000      
          40   56.0000000000000      
 
but i receive only garbage: 
 
          11  5.030513618404220E-270      
          12   -1.99744415283204     
          13   -1.99659731990728     
          14   -1.99665522575300     
          15    0.00000000000000     
          16    0.00000000000000     
          17    0.00000000000000     
          18  2.334195370061799E-313      
          19  2.334195374458983E-313      
          20  1.060997895759312E-312      
          21   -1.99665832519531     
          22  1.141633735539316E-311      
          23  2.121995791459338E-314      
          24  2.121995791459338E-313      
          25  2.121995791014678E-313      
          26    0.00000000000000     
          27    0.00000000000000     
          28  1.273197474579163E-313      
          29  6.747412213442543E-270      
          30  9.555629329992950E-313      
          31  4.857336695425104E-270      
          32   -1.99665141105572     
          33  1.591495110041668E-314      
          34    0.00000000000000     
          35    0.00000000000000     
          36    0.00000000000000     
          37  1.888576254013439E-312      
          38  1.188317642994899E-312      
          39  2.470328229206232E-322      
          40  1.591495112017931E-314
Comment 1 Erik Schnetter 2004-05-20 13:25:49 UTC
Created attachment 6347 [details]
failing source code
Comment 2 Andrew Pinski 2004-05-20 13:37:39 UTC
Confirmed.
Comment 3 Andrew Pinski 2004-09-15 03:17:41 UTC
Fixed, how long a long I do not know.
Comment 4 Tobias Schlüter 2004-09-21 13:45:28 UTC
Are you sure, Andrew. My reduced testcase still fails for me on i686-pc-linux:
program arrpack
  implicit none

  integer x(1,1), y(1,1)
  integer i, j

  x = -1
  call pack (x, 1, 1)
  x = -1
  call copy (y, x, 1, 1)

contains

  subroutine pack (arr, ni, nj)
    integer, intent(in) :: ni, nj
    integer, intent(inout) :: arr(:,:)
    integer :: tmp(ni,nj)
    tmp(:,:) = arr(1:ni, 1:nj)
    print *, "pack"
    tmp(1,1) = -2
    call copy (arr, tmp, ni,nj) !tmp, ni, nj)
  end subroutine pack

  subroutine copy (dst, src, ni, nj)
    integer, intent(in) :: ni, nj
    integer :: dst(ni, nj)
    integer :: src(ni, nj)
    print *, "copy"
    print *, dst, src
    dst = src
    print *, dst, src
  end subroutine copy

end program arrpack

prints: 
[tobi@marktplatz tests]$ ./a.out
 pack
 copy
          -1          -2
          -2          -2
 copy
     9612368          -1
          -1          -1
Comment 5 Tobias Schlüter 2004-09-21 13:51:25 UTC
Reopened. Might be target specific.
Comment 6 Tobias Schlüter 2004-10-21 19:27:23 UTC
*** Bug 18022 has been marked as a duplicate of this bug. ***
Comment 7 Thomas Koenig 2005-01-06 16:10:46 UTC
The reduced testcase does not fail with 20050102 snapshot
on ia64-unknown-linux-gnu:

$ gfortran arrpack.f90
$ ./a.out
 pack
 copy
          -1          -2
          -2          -2
 copy
           0          -1
          -1          -1
$ ifort arrpack.f90
$ ./a.out
 pack
 copy
          -1          -2
          -2          -2
 copy
           0          -1
          -1          -1
Comment 8 Tobias Schlüter 2005-01-06 16:28:46 UTC
Still fails on i686-pc-linux:
[tobi@marktplatz tests]$ ./a.out
 pack
 copy
          -1          -2
          -2          -2
 copy
     9049312          -1
          -1          -1
[tobi@marktplatz tests]$ gfortran --version
GNU Fortran 95 (GCC 4.0.0 20050104 (experimental))
Copyright (C) 2004 Free Software Foundation, Inc.

Comment 9 Thomas Koenig 2005-01-07 10:37:17 UTC
(In reply to comment #8)
> Still fails on i686-pc-linux:

Is this something that should be put into the test suite,
so it is possible to get a better overview of when and
on which machines this fails?
Comment 10 Tobias Schlüter 2005-01-07 11:19:33 UTC
Subject: Re:  Array copy operation produces garbage

Thomas dot Koenig at online dot de wrote:
> ------- Additional Comments From Thomas dot Koenig at online dot de  2005-01-07 10:37 -------
> (In reply to comment #8)
> 
>>Still fails on i686-pc-linux:
> 
> 
> Is this something that should be put into the test suite,
> so it is possible to get a better overview of when and
> on which machines this fails?

gcc's policy is no known failures in the testsuite, so I'm afraid this is not
possible.  I do think this is a good idea, but only to the extent that other
people's development work is not interfered with by spurious testsuite FAILs /
XPASSes, which is inevitable in this case.
Comment 11 Tobias Schlüter 2005-01-07 11:37:40 UTC
I took time to look at this again, and I'm sorry to say that my reduced testcase
did print out an uninitialized variable, and was therefore wrong. My apologies
to all those who have wasted their time on this.

Since I don't know when or how this was fixed, I'll close this as WORKSFORME.
I'll see about creating something for the testsuite.
Comment 12 CVS Commits 2005-01-07 11:56:20 UTC
Subject: Bug 15553

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	tobi@gcc.gnu.org	2005-01-07 11:56:12

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: array-1.f90 

Log message:
	PR fortran/15553
	* gfortran.dg/array-1.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4863&r2=1.4864
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/array-1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1