Re: Allocatable arrays in derived types

On 29 avr, 11:26, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
That is *A* difference. It is certainly not *THE* difference. [...]
No. [...]
Not typically. [...]
No. [...]

Despite appearances, I think that we do not disagree that much !
I really do not understand what happens internally in the
compilers, so I experimented a little bit, with the gfortran
compiler and the -fdump-tree-original option, which generates
an intermediate code, before the creation of the final executable.
I used the following source code :

program extra_mem
integer, allocatable, dimension(:) :: mydata
allocate ( mydata ( 10 ))
deallocate ( mydata )
end program

Then I replaced "allocatable" with pointer, generated again the
intermediate code and compared : the files are exactly the same,
which confirms what you both (Richard and Jugoslav) say.
What I was interested in is the content of the intermediate
code, which also confirms what Arjen stated.
This is an abstract :

extra_mem ()
{
struct array1_integer(kind=4) mydata;
static integer(kind=4) options.0[7] = {68, 255, 0, 0, 0, 1, 0};
mydata.data = 0B;
_gfortran_set_options (7, (void *) &options.0);
{
void * D.567;
mydata.dtype = 265;
mydata.dim[0].lbound = 1;
mydata.dim[0].ubound = 10;
mydata.dim[0].stride = 1;
[... with a "D.568 = __builtin_malloc (40);" and "D.567 = D.568;"]
mydata.data = D.567;
mydata.offset = -1;
[...]

We can see the dtype (data type ?), the lower bound 1, the upper
bound 10 (what is stride ? what is offset) and the memory location
is probably in mydata.data.

If we use the source code :

program extra_mem
call mysub ()
contains
subroutine mysub ()
integer, allocatable, dimension(:) :: mydata
allocate ( mydata ( 10 ))
end subroutine mysub
end program

and compare the intermediate code with allocatable and pointer
versions, one can see that only the "allocatable" version contains
the following code, near the end of the source :

if (mydata.data != 0B)
{
__builtin_free (mydata.data);
}
mydata.data = 0B;

which clearly shows how gfortran deallocate the array
before exiting from the subroutine.

I now have a better understanding of what happens, but all
is not clear :

"The primary cause of the overhead is complexity of Fortran arrays:
they can have multiple dimensions; they may start at index other
than default (1); they are of known size; the may have non-unit
strides... etc."
It just may be a problem of english understanding, but
what are "strides" ?

The same experiments with gfortran may be done with the other source
codes provided by Gib and Arjen to see how gfortran deals
internally with the derived types.

Regards,

Michaël
.

Relevant Pages

  • Re: read syntax error
    ... I am getting the following error using gfortran (on OS X 10.4.5, XCode 2.2): ... Syntax error in READ statement at ... source code where the file name ends in .f90. ...
    (comp.lang.fortran)
  • Re: moving up to f90/f95: automatic arrays, stack limits, etc
    ... >> The wonderful thing about g95 and gfortran is that the source code ... > If the source code were in fortran, and if all fortran users were ...
    (comp.lang.fortran)