I am still trying to get to grips with how one should copy derived types that contain allocatable
arrays. The test program below, when compiled with IVF 10.1, displays the cdata array contents
correctly, but gives an access violation in the deallocation step. If I neglect the deallocation
there are no error messages. When compiled on IBM Linux (with xlf95_r) it runs without errors. But
running my real program, in which I am presumably doing something wrong, on the IBM machine there is
no error until the deallocation step, which is carried out exactly as in the code below, and then I
get a multitude of error messages like

glibc detected *** double free or corruption (!prev): 0x100a0220
and
glibc detected *** corrupted double-linked list: 0x1009db18

Is it OK to do

cell2(i) = cell1(i)

when cell2(i)%%cdata has not been allocated, or do I first need to ensure that %%cdata is allocated?

I must be more tired than I thought. The code I posted previously is obviously wrong, in a couple
of embarrassing ways, and the reason for the access violation is clear. What I meant to do is shown
below. This code executes fine. I thought I was on the scent of the bug in my real program, but I
was confused. The interesting thing (to me) here is that the assignment cell2(i) = cell1(i) has the
effect of allocating cell2(i)%%cdata. Should this be obvious?

program main
integer :: csize(2) = (/10,100/)
integer :: k, i
type cell_type
integer :: ID
real, allocatable :: cdata(:)
end type
type(cell_type), allocatable :: cell1(:),cell2(:)

allocate(cell1(2))
allocate(cell2(2))

"Gib Bogle" auckland.no.spam.ac.nz> wrote in message
news:481fd818$1@news.auckland.ac.nz...

Your problems start at the above loop. Consider that for each
value of i, there is only one cell1(i)*cdata array. Now you are
contemplating deallocating this array 10 or 100 times in the k
loop, but...

Please forgive me for responding to my own posts.

I made csize big: csize(2) = (/1000000,100000000/), put a do loop around the whole program, and
experimented with allocating/not allocating cell2(i)%%cdata in advance of assigning values to it. I
have convinced myself that there is no memory leakage. It seems that when the derived-type
variables cell2(i) and cell1(i) are equated the allocatable component cell2(i)%%cdata is allocated if
not previously allocated, and if it was already allocated it is effectively resized and any unused
memory is deallocated. In other words the compiler does what you'd want it to do.

Probably everyone else already knew this.

"Gib Bogle" auckland.no.spam.ac.nz> wrote in message
news:481ff61f$1@news.auckland.ac.nz...

Yes, that's the way allocatable components are supposed to work.
In fact, you could have simply said:

cell2 = cell1

and cell2 would have been reallocated to the same shape as cell1
and the the components of each element of the cell2 array would
have been allocated if necessary.

WARNING: you said earlier that you were ifort 10.1. This compiler
does not behave in a standard way when assignments to whole
allocatable arrays are carried out, unless you use some switch
at compile time. Check the ifort documentation carefully for
the exact nature of its behavior. It's not standard without
the switch.

On May 5, 11:41 pm, "James Van Buskirk" comcast.net> wrote:

In fairness to Intel, the compiler conforms to the Fortran standard as
of 1998; the switch "-assume realloc_lhs" makes it conform to the
standard (in this particular matter) as of 2003. Agreed, it's odd that
the 1998 TR15581 document created a situation in which allocatable
array assignment behaved differently depending on whether the array
was a component or a variable, but prior to 2003 it was the
responsibility of the programmer to allocate the target explicitly if
it wasn't a component.

"Gib Bogle" auckland.no.spam.ac.nz> wrote in message
news:481ff61f$1@news.auckland.ac.nz...

Kurt Kallblad wrote:

On May 7, 12:15 am, nos...@see.signature (Richard Maine) wrote:

On Wed, 7 May 2008 12:03:34 -0700 (PDT), Damian rouson.net> wrote:

I am not aware of allocatable component leaks in Intel Fortran 10.1. If you
have a support issue number for such, please send it to me in email so that I
can look it up.
--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://support.intel.com/support/performancetools/fortran
My Fortran blog
http://www.intel.com/software/drfortran