This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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