Is this a compiler bug?

[Gus Gassmann]

I have done some more testing an have come upon the following strange
behaviour. Program 1 below:

module stor
implicit none
integer, allocatable, dimension (:) :: array
end module stor

module s1
contains
subroutine sub1(k)
use s2
implicit none
integer :: k(:)
call sub2
k = 1
return
end subroutine
end module

module s2
contains
subroutine sub2
use stor
implicit none
integer, allocatable, dimension (:) :: a2
allocate(a2(100))
a2 = array
deallocate (array)
allocate (array(200))
array( 1:100) = a2
array(101:200) = 0
deallocate(a2)
return
end subroutine
end module

program test
use s1
use stor
implicit none
allocate (array(100))
array = 0
call sub1(array)
write (*,*) 'array(1)=',array(1)
stop
end program

prints out

array(1)= 0

(In fact, every entry of array is 0, while I think it should be 1.)

I prepared the following, second program with very minor modifications
works correctly. (The changed lines have been marked.)

module stor
implicit none
integer, allocatable, dimension (:) :: array
end module stor

module s1
contains
subroutine sub1 !!!
use stor !!!
use s2
implicit none
call sub2
array = 1 !!!
return
end subroutine
end module

module s2
contains
subroutine sub2
use stor
implicit none
integer, allocatable, dimension (:) :: a2
allocate(a2(100))
a2 = array
deallocate (array)
allocate (array(200))
array( 1:100) = a2
array(101:200) = 0
deallocate(a2)
return
end subroutine
end module

program test
use s1
use stor
implicit none
allocate (array(100))
array = 0
call sub1 !!!
write (*,*) 'array(1)=',array(1)
stop
end program

(I am using Lahey fortran 95, release 7.10, under windows XP.)

Is this behaviour a bug, or am I missing some subtlety I should be
aware of? Thanks for any ideas.

gus gassmann

[robert....@sun.com]

Your program is not standard-conforming. It violates the
requirements of Section 12.4.1.6 of the Fortran 95 standard,
in particular, the part

While an entity is associated with a dummy argument,
the following restrictions hold:

(1) No action that affects the allocation
status of the entity may be taken.

The subroutine sub2 affects the allocation status of array
while array is associated with the dummy argument k of sub1.

Bob Corbett

[Gus Gassmann]

On Aug 21, 6:31 am, robert.corb...@sun.com wrote:
> On Aug 20, 6:17 am, Gus Gassmann <Horand.Gassm...@dal.ca> wrote:
>

[...]

> Bob Corbett- Hide quoted text -
>
> - Show quoted text -

Thank you very much for the explanation. Can you confirm that the
second version (included above) does conform to the standard?

[robert....@sun.com]

The second version is standard conforming with respect to the
treatment of the array array.

To see why Fortran 2003 includes the restriction cited earlier,
consider how the array is passed to the subroutine FOO when it
is associated with an assumed-shape dummy argument. The
code generated for the call will pass the address of the array
and its related shape information to FOO. The subroutine FOO
does not know that the array passed to it is an allocated
array. If, as in your example, the array is dellocated and
reallocated, FOO has no way of knowing it. Therefore, it will
try addressing the array through the address that was
originally passed to it. If the reallocated array does not
happen to land at the same address as the original array,
the update is going to fail.

Bob Corbett

[glen herrmannsfeldt]

robert....@sun.com wrote:
(snip, someone previously wrote)

>>> While an entity is associated with a dummy argument,
>>> the following restrictions hold:

>>> (1) No action that affects the allocation
>>> status of the entity may be taken.

(snip)

> To see why Fortran 2003 includes the restriction cited earlier,
> consider how the array is passed to the subroutine FOO when it
> is associated with an assumed-shape dummy argument. The
> code generated for the call will pass the address of the array
> and its related shape information to FOO. The subroutine FOO
> does not know that the array passed to it is an allocated
> array. If, as in your example, the array is dellocated and
> reallocated, FOO has no way of knowing it. Therefore, it will
> try addressing the array through the address that was
> originally passed to it. If the reallocated array does not
> happen to land at the same address as the original array,
> the update is going to fail.

What usually happens is that you reference the memory where the
array was, though it isn't there anymore. Most of the time the
memory hasn't been reused, or at least hasn't been overwritten such
that your program seems to work. I would say it is unusual to have
a segfault accessing such an array. If you write over it, you might
overwrite the housekeeping data and cause a segfault on a later
allocate or free operation.

-- glen