Say we have this variable definition
Real*8, Dimension(:), Allocatable :: dblA
Allocate (dblA(1000))
Now I call this subroutine:
High Performance Mark's answer says about all I wanted. I will repeat one aspect though, for emphasis.
It is very much required that the allocatable array in the subroutine be allocated when the subroutine is called. [And in the case of the question, of sufficient size.]
To make this answer more than just a comment I'll address the more general question title. Before that, I'll look at things which could feature in the thinking around "allocatable or non-allocatable dummy argument".
Because the dummy argument (the one in the subroutine) has the intent(out)
attribute it, and the actual argument, becomes undefined. If the dummy argument is allocatable it is also deallocated on entry. In this case, the actual argument remains allocated and of its original size.
Without being allocatable, the dummy argument (and the actual argument) cannot have allocation status queried or changed; the dummy argument cannot further be passed to a procedure expecting an allocatable argument even though the actual argument could be.
If the dummy argument were allocatable instead of being a (static) explicit shape array, the actual argument must also be an allocatable array.
With an allocatable dummy argument an explicit interface would be required when the subroutine is referenced. [Some would say this is a good idea even in the cases where an implicit interface is fine.]
Coming to the more general thing, I'll give an example where there is a restriction on allocatable actual/non-allocatable dummy (F2008, 12.5.2.4):
If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic.
But this isn't something to worry about for most people.
Oh, and another thing I'll restress from that other answer: Real*8
should be avoided.