This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]