I'm really not sure whether to consider this a bug or a "feature". It certainly *seems* to me that it's non-conforming code that compiles and runs happily. [tjf@rscpc28 BadStuff]$ cat alloc.f90 module aa implicit none real(kind=8),dimension(:,:),allocatable::Md end module aa program fred use aa implicit none write(*,*)allocated(Md) write(*,*)Md(1,:) end [tjf@rscpc28 BadStuff]$ gfortran -Wall -O0 -W -Wtabs -g -fbounds-check -fbacktrace -pedantic -std=f95 -o alloc alloc.f90 [tjf@rscpc28 BadStuff]$ ./alloc F [tjf@rscpc28 BadStuff]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3-20080626/configure --disable-multilib --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.2 20080626 (prerelease) (GCC) If Md is in not in a module running ./alloc segfaults. Using a definite element gets picked up as a bounds violation. Writing Md(1,1:0) gives the same silent output as above. Should one really consider an unallocated array to be size 0?
Very similar to PR20520.
*** This bug has been marked as a duplicate of 20520 ***
Not a dupe of PR20520. That one is for questionable code producing (or not) some unexpected (to some) output, and crashing when run. This is illegal code that compiles AND RUNS quietly. Here unallocated is giving the same behaviour as size 0. The array residing in a module matters in this case. I've just tried it again with the same result. If I insert a write(*,*)size(Md,1),size(Md,2) and run it, it prints two 1s.
The first right statement in the original test case is valid fortran and gives the correct result. The second write statement is invalid Fortran. An unallocated allocatable array has no size. It is up to the programmer to use "allocated" to confirm that the array has a size before using it. This is what allocated is for. Therefore this gets down to the same issue as 20520, using an allocatable array before it is allocated. This is regardless of how it is invalidly used, in an arithmetic statement or a write statement. See comments I added 20 20520. *** This bug has been marked as a duplicate of 20520 ***