* [Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
2013-06-30 15:22 [Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084 dominiq at lps dot ens.fr
@ 2013-07-02 9:20 ` burnus at gcc dot gnu.org
2013-07-02 9:43 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-07-02 9:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
If it makes you happy, the following plugs the memory leak:
--- a/gcc/testsuite/gfortran.dg/class_array_7.f03
+++ b/gcc/testsuite/gfortran.dg/class_array_7.f03
@@ -56,2 +56,3 @@ program main
if (trim (print_type ("a", a)) .ne. "a is base_type") call abort
+ deallocate (a)
end program main
The reason is that gfortran no longer automatically deallocates allocatables at
the end of the main program (with very few exceptions). That's in order to
prevent finalization.
Fortran 2008 has:
"A variable, common block, or procedure pointer declared in the scoping unit of
a main program, module, or submodule implicitly has the SAVE attribute, which
may be con\frmed by explicit specification."
And:
"4.5.6.3 When finalization occurs":
"A nonpointer, nonallocatable object that is not a dummy argument or function
result is finalized immediately before it would become unde\fned due to
execution of a RETURN or END statement (16.6.6, item (3))."
which excludes SAVE:
"(3) When execution of an instance of a subprogram completes,
(a) its unsaved local variables become undefined,"
Okay, that was for nonallocatables - and we have an allocatable. But there the
same applies:
"When an allocatable entity is deallocated, it is finalized."
and
"When the execution of a procedure is terminated by execution of a RETURN or
END statement, an unsaved allocatable local variable of the procedure retains
its allocation and definition status if it is a function result variable or a
subobject thereof; otherwise, it is deallocated."
Before finalization entered the game, it was undetectable - within the program
- whether the compiler deallocated variables in the main program or not. Now,
it is no longer. Hence, there is no automatic deallocation - and you see the
memory leak.
See also http://gcc.gnu.org/wiki/GFortran#GCC4.9
>From gcc-bugs-return-425559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 09:25:31 2013
Return-Path: <gcc-bugs-return-425559-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7409 invoked by alias); 2 Jul 2013 09:25:31 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7337 invoked by uid 48); 2 Jul 2013 09:25:21 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/56789] Wrong code with contiguous dummy argument
Date: Tue, 02 Jul 2013 09:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-56789-4-stVxuhwiRe@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56789-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56789-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00066.txt.bz2
Content-length: 616
http://gcc.gnu.org/bugzilla/show_bug.cgi?idV789
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-07-02
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On x86_64-apple-darwin10 at revision 200581, I don't get any error at run time,
but valgrind complains for an Invalid write of size 4.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
2013-06-30 15:22 [Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084 dominiq at lps dot ens.fr
2013-07-02 9:20 ` [Bug fortran/57762] " burnus at gcc dot gnu.org
@ 2013-07-02 9:43 ` dominiq at lps dot ens.fr
2013-07-22 11:03 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-07-02 9:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-07-02
Ever confirmed|0 |1
--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> If it makes you happy, the following plugs the memory leak:
>
> --- a/gcc/testsuite/gfortran.dg/class_array_7.f03
> +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03
> @@ -56,2 +56,3 @@ program main
> if (trim (print_type ("a", a)) .ne. "a is base_type") call abort
> + deallocate (a)
> end program main
>
> ...
Well, it makes valgrind happy. Is there any connection with PR55207 - Automatic
deallocation of variables declared in the main program?
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
2013-06-30 15:22 [Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084 dominiq at lps dot ens.fr
2013-07-02 9:20 ` [Bug fortran/57762] " burnus at gcc dot gnu.org
2013-07-02 9:43 ` dominiq at lps dot ens.fr
@ 2013-07-22 11:03 ` janus at gcc dot gnu.org
2013-07-22 17:05 ` burnus at gcc dot gnu.org
2013-07-22 17:05 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: janus at gcc dot gnu.org @ 2013-07-22 11:03 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |janus at gcc dot gnu.org
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #2)
> > If it makes you happy, the following plugs the memory leak:
> >
> > --- a/gcc/testsuite/gfortran.dg/class_array_7.f03
> > +++ b/gcc/testsuite/gfortran.dg/class_array_7.f03
> > @@ -56,2 +56,3 @@ program main
> > if (trim (print_type ("a", a)) .ne. "a is base_type") call abort
> > + deallocate (a)
> > end program main
> >
> > ...
>
> Well, it makes valgrind happy.
And it certainly does not hurt to fix the test case in this regard.
> Is there any connection with PR55207 -
> Automatic deallocation of variables declared in the main program?
Yes, sure.
However, I don't directly see how the leak is related to r200084 ...
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
2013-06-30 15:22 [Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084 dominiq at lps dot ens.fr
` (2 preceding siblings ...)
2013-07-22 11:03 ` janus at gcc dot gnu.org
@ 2013-07-22 17:05 ` burnus at gcc dot gnu.org
2013-07-22 17:05 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-07-22 17:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Mon Jul 22 17:02:26 2013
New Revision: 201137
URL: http://gcc.gnu.org/viewcvs?rev=201137&root=gcc&view=rev
Log:
2013-07-22 Tobias Burnus <burnus@net-b.de>
PR fortran/57762
* gfortran.dg/class_array_7.f03: Fix memory leak.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_7.f03
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084
2013-06-30 15:22 [Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084 dominiq at lps dot ens.fr
` (3 preceding siblings ...)
2013-07-22 17:05 ` burnus at gcc dot gnu.org
@ 2013-07-22 17:05 ` burnus at gcc dot gnu.org
4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-07-22 17:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The memory leak is now plugged - hence, close it as FIXED.
^ permalink raw reply [flat|nested] 6+ messages in thread