(Re)allocation of allocatable arrays on assignment - F2003

[Tobias Burnus]

Paul Richard Thomas wrote:
> By the way, you will see from the code that if the lhs and rhs sizes
> are the same, control jumps past the new block.  I cannot see any
> measurable performance loss.

Awesome!

I tried your test case and it fails with ifort. The reason seems to be a 
lower-bound problem in gfortran if the RHS is an array constructor; it 
works if the RHS is a normal array.

integer, allocatable :: a(:)
a = [1,2,3]
print *, lbound(a)
end

In this example, "a" has a lower bound of "0" instead of the expected 1. 
(In the test case it fails in line 65 as there is then a value mismatch 
- but the bounds of "a" and "b" are wrong since line 31 and propagated 
through via b in line 35.)

  * * *

In case of functions, I get a segfault with the following program - 
while ifort and Cray print "(1:4): 1, 2, 3, 4". The variant with "f() + 
1" on the RHS also does not work and segfaults.

integer, allocatable :: a(:)
a = f()
print '(a,i0,a,i0,a,99(i0:", "))', '(',lbound(a),':', ubound(a),'): ', a
contains
function f()
   integer :: f(4)
   f = [1,2,3,4]
end function f

  * * *

Bound checks: When re-allocate on assignment is enabled, the following 
should not print an error with -fcheck=bounds - while "a(:) = b" should. 
[When re-allocate on assignment is disabled, both versions of the 
program should print an error]. Currently, one gets:
   Fortran runtime error: Array bound mismatch for dimension 1 of array 
'a' (1/4)

integer, allocatable :: a(:)
integer :: b(4)
allocate(a(1))
a = b
end

  * * *

Otherwise, the patch looks rather nice! I also like the consistent use 
of reallocate, which should speeds up the reallocation. (So far I only 
looked at dumps and did some compile test - I have not looked at the 
patch itself.) I will now do some more test.

Tobias