This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR fotran/35820 again: memory leak while resolving nested foralls.
- From: "Paul Richard Thomas" <paul dot richard dot thomas at gmail dot com>
- To: "Mikael Morin" <mikael dot morin at tele2 dot fr>
- Cc: "correctifs gcc" <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Tue, 21 Oct 2008 17:00:24 +0200
- Subject: Re: [Patch, Fortran] PR fotran/35820 again: memory leak while resolving nested foralls.
- References: <48FDD5C1.firstname.lastname@example.org>
> I come back to this PR.
> The second one was it was freeing the var_expr elements at the end of
> the most nested forall construct, which is wrong if there are more than
> one nested forall constructs. This one was found (that's what I think
> looking at his patch) by Paul here
> However, it was not catch by my previous patch.
I was trying, slowly, to get my head around this:-) I could not
understand how it could have been fixed.
> With the attached one, only the memory allocated at the beginning of
> gfc_resolve_forall is released at the end.
> For Dominique, one can add this to make a memory leak results in an ICE:
> Index: resolve.c
> --- resolve.c (révision 141259)
> +++ resolve.c (copie de travail)
> @@ -6264,6 +6264,9 @@
> var_expr[nvar] = gfc_copy_expr (fa->var);
> + /* No memory leak. */
> + gcc_assert (nvar <= total_var);
This is exactly what is needed.
> /* Resolve the FORALL body. */
> With this patchlet, trunk is ICEing with test.f (attached) and
> nested_forall_1.f which I add to the testsuite (see patch).
Let me try to run through the logic tonight - it looks OK at first
glance, except that you need the module clean-up line in the testcase.
Look at the last line(s) of any of the testsuite that have modules or
the testcase notes on the gfortran wiki.