Question about allocatable functions in gfortran

[Nick Fort]

On 28 July 2010 10:43, Tobias Burnus <burnus@net-b.de> wrote:
> On 07/28/2010 10:00 AM, Nick Fort wrote:
>> Ah, I see! All right, that clears that up. Well, almost. How come the
>> subroutine version works?
>
> Well, you allocate the array explicitly:
>
> subroutine random_vector(vector)
> real, dimension(:), allocatable, intent(out) :: vector
> allocate (vector(length))
>
>
> That works. And after it is allocated, assigning to "vector" is fine -
> unless the shape of the right-hand side (RHS) is different from the LHS;
> in that case one had to reallocate the LHS, which gfortran currently
> does not do. But in LO5 you don't do this.

Don't I do this in both?

I mean:

-----------------------------
subroutine random_vector(vector)
implicit none
real, dimension(:), allocatable, intent(out) :: vector
integer :: length
real :: length_real

if (allocated(vector)) deallocate(vector)
call init_random_seed()
call random_number(length_real)
length = int(length_real*10.) + 1
allocate (vector(length))    ! < Allocating "vector" here
call random_number(vector)

end subroutine random_vector
-----------------------------

and then

-----------------------------
function random_vector() result(vector)
implicit none
real, dimension(:), allocatable :: vector
integer :: length
real :: length_real

if (allocated(vector)) deallocate(vector)
call init_random_seed()
call random_number(length_real)
length = int(length_real*10.) + 1
allocate (vector(length))    ! < Allocating "vector" here
call random_number(vector)

end function random_vector
-----------------------------

I might be misunderstanding you, but is "vector" not allocated
explicitly in both?

>> I understand.  If I knew anything about writing compilers, I'd jump
>> right in, but I guess I have to leave it to more knowledgeable people
>> than myself. I do, however, look forward to the gfortran release that
>> supports the complete F2003 set one day.
>>
>
> Well, writing a compiler is no magic and you do not have to be a
> computer scientist to do so ;-) I think essentially all gfortran
> developers are from fields like physics, chemistry, meteorology, etc.
> and work on gfortran only in their spare time. (That's different to the
> rest of GCC, where most developers are paid for their work - which
> doesn't rule out that they also do GCC tasks in their spare time.)
> Additionally, there as some simpler tasks in gfortran, thus if you are
> interested, every helping hand is welcome :-)

I am actually interested in helping; I'm unsure of my usefulness, but
if I can help, I'm in. I'll message you privately.

> Regarding F2003 support, I think gfortran is on the right track. Between
> 2009-04-21 and  2010-04-14 the following new features were added for GCC
> 4.5: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
> and since April, to the features listed following were added for GCC
> 4.6: http://gcc.gnu.org/gcc-4.6/changes.html#Fortran (Additionally,
> several minor fixes were done and experimental features became more
> solid.) Currently, work is being done for ASSOCIATE and for the
> polymorphic data types - besides the usual smaller, janitoral, and bug
> fixing work
>
> Tobias
>