Bug 51487 - leak memory with eoshift(..,...,boundary)
Summary: leak memory with eoshift(..,...,boundary)
Status: RESOLVED DUPLICATE of bug 53310
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-09 19:46 UTC by rookie91
Modified: 2013-02-27 11:09 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-02-26 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rookie91 2011-12-09 19:46:33 UTC
! 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)
Comment 1 Dominique d'Humieres 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).
Comment 2 Dominique d'Humieres 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 ***