[Bug fortran/51487] New: leak memory with eoshift(..,...,boundary)

[Bug fortran/51487] New: leak memory with eoshift(..,...,boundary)

[herve.manche at libertysurf dot fr]

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

             Bug #: 51487
           Summary: leak memory with eoshift(..,...,boundary)
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: herve.manche@libertysurf.fr


! The following short program seems to induce a memory leak
!************************************************************************
program test_eoshift
  implicit none
  integer, dimension(:,:), allocatable :: matrix
  integer :: i

  allocate(matrix(1:3,1:5))

  matrix(:,:)=0
  do i=1,20000000 
    matrix=eoshift(matrix,-1,dim=2,boundary=(/ i, i+1, i+2/))
    end do

  deallocate(matrix)

  end program test_eoshift
!************************************************************************
! The problem remains with real arrays
! There is NO PROBLEM if matrix is not allocatable (integer, dimension(3,5) ::)
! There is NO PROBLEM if no boundary inside eoshift(..,..)
! There is NO PROBLEM with ifort
! The problem arises on following versions (gfortran -v)
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

Using built-in specs.
COLLECT_GCC=gfortran47
COLLECT_LTO_WRAPPER=/opt/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7-source/gcc-4.7-20110910/configure
--enable-languages=c,c++,fortran --enable-checking=release --disable-bootstrap
--disable-libmudflap --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=/usr/bin/gold --prefix=/usr/local/gcc-4.7
Thread model: posix
gcc version 4.7.0 20110910 (experimental) (GCC)

[Bug fortran/51487] leak memory with eoshift(..,...,boundary)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-02-26
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-26 20:32:16 UTC ---
Running the test under valgrind does not give any error for trunk, 4.7.2.
However I see a large memory leak with 4.6.3 under valgrind (I did not have the
patience to wait and killed the process after some time and more than 4Gb of
memory). This PR should probably be closed as won't fix unless someone wants to
backport the fix used in 4.7.2 (or it is already done for 4.6.4).

[Bug fortran/51487] leak memory with eoshift(..,...,boundary)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-27 11:09:50 UTC ---
This appears to be a duplicate of pr53310 fixed on trunk at revision 187395 and
backported to 4.5-4.7.

*** This bug has been marked as a duplicate of bug 53310 ***