public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/54384] New: gfortran memory leaks
Date: Mon, 27 Aug 2012 10:40:00 -0000	[thread overview]
Message-ID: <bug-54384-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             Bug #: 54384
           Summary: gfortran memory leaks
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Running valgrind on gfortran (or rather f951) -fsyntax-only shows the following
leaks.

(This PR assumed that my patch
http://gcc.gnu.org/ml/fortran/2012-08/msg00180.html has been applied plus a
follow up for module.c's mio_symbol which removes the "sym->refs++".)


With Polyhedron 2005's channel.f90 (and rnflow.f90):
  by 0x606B33: gfc_get_array_ss(gfc_ss*, gfc_expr*, int, gfc_ss_type)
(trans-array.c:561)
  by 0x612F00: gfc_walk_expr(gfc_expr*) (trans-array.c:8787)
  by 0x639F98: gfc_trans_arrayfunc_assign(gfc_expr*, gfc_expr*)
(trans-expr.c:6749)
  by 0x63B911: gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool)
(trans-expr.c:7438)


With Polyhedron 2005's mdbx.f90:
  by 0x57D7BF: gfc_get_expr() (expr.c:49)
  by 0x57E123: gfc_copy_expr(gfc_expr*) (expr.c:272)
  by 0x5C63EA: gfc_match_rvalue(gfc_expr**) (primary.c:2788)
  by 0x56D3A2: match_data_constant(gfc_expr**) (decl.c:354)


With Polyhedron 2005's nf.f90:
  by 0x57E1807: __gmpz_init (in /usr/lib64/libgmp.so.10.0.5)
  by 0x57D9EB: gfc_get_constant_expr(bt, int, locus*) (expr.c:161)
  by 0x57DB17: gfc_get_int_expr(int, locus*, int) (expr.c:217)
  by 0x5F592C: _ZL24check_section_vs_sectionP13gfc_array_refS0_i.part.4
(dependency.c:1213)
  by 0x5F6C47: gfc_dep_resolver(gfc_ref*, gfc_ref*, gfc_reverse*)
(dependency.c:1155)
  by 0x60C585: gfc_conv_resolve_dependencies(gfc_loopinfo*, gfc_ss*, gfc_ss*)
(trans-array.c:4309)
  by 0x63A891: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool)
(trans-expr.c:7238)


With Polyhedron 2005's capacita.f90:  Several. I think the only new one is:
  by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325)
  by 0x5F0F09: gfc_copy_formal_args_intr(gfc_symbol*, gfc_intrinsic_sym*)
(symbol.c:4161)
  by 0x63C50C: gfc_get_symbol_for_expr(gfc_expr*) (trans-intrinsic.c:2334)
  by 0x64A0EB: gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
(trans-intrinsic.c:4525)


With Polyhedron 2005's capacita.f90 (and some more):
  by 0x57D9EB: gfc_get_constant_expr(bt, int, locus*) (expr.c:161)
  by 0x57DB17: gfc_get_int_expr(int, locus*, int) (expr.c:217)
  by 0x55C016: gfc_simplify_iterator_var(gfc_expr*) (array.c:1445)
  by 0x5826E4: gfc_simplify_expr(gfc_expr*, int) (expr.c:1894)
  by 0x56A394: gfc_assign_data_value(gfc_expr*, gfc_expr*, __mpz_struct*,
__mpz_struct (*) [1]) (data.c:61)



With gfortran.dg/proc_ptr_result_1.f90:
  by 0x5EF6E7: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:2569)
  by 0x5716DA: gfc_match_procedure() (decl.c:4916)

---- and ----

  by 0x5EF6E7: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:2569)
  by 0x5EFA62: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**,
bool) (symbol.c:2753)
  by 0x56B76C: find_special(char const*, gfc_symbol**, bool) (decl.c:802)
  by 0x574F28: attr_decl() (decl.c:6174)

---- and ----

  by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325)
  by 0x5F0D3C: gfc_copy_formal_args(gfc_symbol*, gfc_symbol*, ifsrc)
(symbol.c:4104)
  by 0x5F0E30: gfc_copy_formal_args(gfc_symbol*, gfc_symbol*, ifsrc)
(symbol.c:4117)
  by 0x5D7A5E: resolve_procedure_interface(gfc_symbol*) (resolve.c:228)
  by 0x5CC420: resolve_symbol(gfc_symbol*) (resolve.c:12581)

---- and ----

  by 0x5EF33E: gfc_get_namespace(gfc_namespace*, int) (symbol.c:2325)
  by 0x5B4040: load_needed(pointer_info*) (module.c:4375)
  by 0x5B4DCB: read_module() (module.c:4773)

---- and ----

  the gfc_match_rvalue issue of mdbx.f90.



Also leaking, but I lost the overview whether those are already covered:
doduc.f90. (I also haven't tested all of Polyhedron.)


             reply	other threads:[~2012-08-27 10:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27 10:40 burnus at gcc dot gnu.org [this message]
2012-08-27 14:43 ` [Bug fortran/54384] " burnus at gcc dot gnu.org
2012-08-27 14:57 ` burnus at gcc dot gnu.org
2012-08-27 18:48 ` burnus at gcc dot gnu.org
2012-08-27 18:52 ` burnus at gcc dot gnu.org
2012-08-27 20:52 ` burnus at gcc dot gnu.org
2012-08-27 20:55 ` burnus at gcc dot gnu.org
2012-08-28  5:35 ` burnus at gcc dot gnu.org
2012-08-28  5:37 ` burnus at gcc dot gnu.org
2012-08-28 14:49 ` burnus at gcc dot gnu.org
2012-08-28 14:51 ` burnus at gcc dot gnu.org
2013-06-29 21:24 ` dominiq at lps dot ens.fr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-54384-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).