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.
If the array has been allocated prior to being passed to the subroutine the subroutine is indifferent to the allocatable-ness, the effect is the same as if the array were static. There is nothing to object to, nor practice to avoid, in the snippets you show us. However, those snippets actually do very little and it is easy to think of ways to extend them to invalidate this advice.
Now do yourself a favour and change
Real*8, INTENT(Out), DIMENSION(1000) :: dblA
to
Real*8, INTENT(Out), DIMENSION(:) :: dblA
so that the subroutine works correctly whatever the size of the array it gets passed. It's probably also a bad idea to use dblA
as the name for both the dummy and actual arguments, you'll just confuse yourself.
And real*8
is not, and never has been, a standard-compliant way of declaring an 8-byte real. On this point, see numerous questions and answers here on SO.