Assigning [...] constructor to allocatable array changes size of that array, if size([...]) is not equal to size(array) program ala implicit none integer, dimension(:), allocatable :: ivec allocate(ivec(3)); write(*,*) shape(ivec) ivec = [1,2]; write(*,*) shape(ivec) !!!!!! end program ala Target: x86_64-pc-linux-gnu Configured with: /dev/shm/portage/sys-devel/gcc-4.6.0_alpha20110226/work/gcc-4.6-20110226/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0-alpha20110226 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0-alpha20110226/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0-alpha20110226/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.0_alpha20110226' Thread model: posix gcc version 4.6.0-alpha20110226 20110226 (experimental) (Gentoo 4.6.0_alpha20110226)
> Assigning [...] constructor to allocatable array changes size of that array, if > size([...]) is not equal to size(array) As far as I understand "reallocation on assignment, this is the expected behavior (default that you can override with -fno-realloc-lhs). There may be a missing error in [macbook] f90/bug% gfc -fno-realloc-lhs -fcheck=all pr48058.f90 [macbook] f90/bug% a.out 3 3 where a length 2 vector is assigned to a length 3 one(?).
Somehow, I've missed this in ChangeLog. Sorry for the noise
(In reply to comment #2) > Somehow, I've missed this in ChangeLog. Sorry for the noise ChangeLog is a horrible place to look at the new features in gfortran. It would be better to look on the gfortran wiki. http://gcc.gnu.org/wiki/GFortran#news
Created attachment 26770 [details] test program to reproduce bug
Robert Hayward wrote in comment #4: > Created attachment 26770 [details] > test program to reproduce bug Please do not attach test cases to random bugreports! But create a new bug report and put more information in the report. -- Except that both issues are related to Fortran 2003's (re)allocation on intrinsic assignment, they do not have anything in common. The issue of comment 4 / Robert Hayward's issue is a bug in gfortran 4.6/4.7, which has been been reported in PR 52012 and fixed around 2012-01-31. Please try a newer version of GCC 4.6/4.7 - or use -fno-realloc-lhs as work around. (The issue in comment 0 is a bug in the original reporter's program for Fortran 90/95: The shape on the right and on the left have to be the same. The proper assignment should have been one of the following: ivec(1:2) = [1,2] ivec(2:3) = [1,2] ivec(1:2:2) = [1,2] ! or ivec([1,3]) = [1,2] With Fortran 2003, the program became valid - as the compiler reallocated "ivec" with the shape of the right side. With -std=f95 or if the left-hand side weren't allocatable, -fcheck=bounds had given a run-time error.)
48058(In reply to comment #4) > Created attachment 26770 [details] > test program to reproduce bug Sorry about that, attached to the wrong bug. It was meant for 52151.