[Patch, Fortran] PR 42647: Missed initialization/dealloc of allocatable scalar DT with allocatable component

[Tobias Burnus]

  On 10/13/2010 02:08 PM, Janus Weil wrote:
> Self-review: Three things were still missing:
> 1) Auto-deallocation of CLASS components.
> 2) Auto-deallocation of "sub-components", i.e. stuff like a%b%c.
> 3) Test cases.

I have not yet had a closer look at the patch, but I think you should 
also take care of the DEALLOCATE statement. Example:

type t
   integer, allocatable :: p
end type t
type(t), allocatable :: a

deallocate(a)
end

(Allocate left away to make dump cleaner.) The DEALLOCATE is translated 
into the following. You see many accesses to "a.p" which cause a 
segfault if "a" is not allocated - assume

       if (a.p != 0B)
         {
           __builtin_free ((void *) a.p);
         }
       a.p = 0B;
       if (a == 0B)         {
           _gfortran_runtime_error_at
         }       else         {
           __builtin_free ((void *) a);
         }
       a = 0B;

Hmm, I actually could not make the program crash - even though the dump 
looks wrong.

In any case the following program leaks memory (without the "if" line); 
with the "if" line it aborts as "istat" is not zero, without stat= it 
aborts with an error message stating that "a" is not allocated. 
Expected: No error, no valgrind error and istat == 0.

type t
   integer, allocatable :: p(:)
end type t
type(t), allocatable :: a

allocate(a)
allocate(a%p(10000))

deallocate(a, stat=istat)
if(istat /= 0) call abort()
end

  * * *

By the way, the dump in "finally:" looks OK.

  * * *

Possibly related: The test case in comment 10 of PR42647. There are two 
failures:

a) allocate(a1, a1%b1, a1%b1%c1)
causes a segfault - it works if one distributes it to three separate 
ALLOCATE statements. I have no idea whether this is valid code or not. 
-- It also applies to array allocatables and fails with NAG, PathScale 
and gfortran while it works with Intel and g95.

b) If one changes this into three separates allocate statements: An 
already-allocated error appears - which is probably a duplicate of the 
issue above.

  * * *

The test case in PR 45451 still fails. (I did not have a closer look.) 
Same for "alloc_comp_scalar_1.f90" (PR 43018). Thus, there are no 
collateral fixes.

Tobias