[Bug fortran/57762] New: [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[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]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762

            Bug ID: 57762
           Summary: [4.9 Regression] Memory leak in
                    gfortran.dg/class_array_7.f03 after revision 200084
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: burnus@net-b.de
              Host: x86_64-apple-darwin10
            Target: x86_64-apple-darwin10
             Build: x86_64-apple-darwin10

As said in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596#c2, I see the
following memory leak under valgrind --leak-check=full

==47095== HEAP SUMMARY:
==47095==     in use at exit: 168 bytes in 2 blocks
==47095==   total heap usage: 25 allocs, 23 frees, 7,125 bytes allocated
==47095== 
==47095== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2
==47095==    at 0x100013679: malloc (vg_replace_malloc.c:266)
==47095==    by 0x100001378: __realloc_MOD_reallocate (class_array_7.f03:31)
==47095==    by 0x1000019E6: MAIN__ (class_array_7.f03:55)
==47095==    by 0x100001B7B: main (class_array_7.f03:49)
==47095== 
==47095== LEAK SUMMARY:
==47095==    definitely lost: 80 bytes in 1 blocks
==47095==    indirectly lost: 0 bytes in 0 blocks
==47095==      possibly lost: 0 bytes in 0 blocks
==47095==    still reachable: 0 bytes in 0 blocks
==47095==         suppressed: 88 bytes in 1 blocks
==47095== 
==47095== For counts of detected and suppressed errors, rerun with: -v
==47095== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

starting at revision 200085 (no leak at r200083).

Note that I messed up the bracketing in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596#c3

[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[burnus at gcc dot gnu.org]

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.

[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[dominiq at lps dot ens.fr]

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?

[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[janus at gcc dot gnu.org]

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 ...

[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[burnus at gcc dot gnu.org]

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.

[Bug fortran/57762] [4.9 Regression] Memory leak in gfortran.dg/class_array_7.f03 after revision 200084

[burnus at gcc dot gnu.org]

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