public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "fxcoudert at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules Date: Fri, 09 Nov 2007 12:36:00 -0000 [thread overview] Message-ID: <20071109123616.18241.qmail@sourceware.org> (raw) In-Reply-To: <bug-30285-6318@http.gcc.gnu.org/bugzilla/> ------- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-11-09 12:36 ------- I think the problem starts with: module mod0 integer mpi_bottom common /mpipriv/ mpi_bottom end module mod0 module mod1 use mod0 end module mod1 module mod2 use mod0 use mod1 end module mod2 Because in that case, mod2.mod already has two copies of the common: (('mpipriv' 2 0 0 'mpipriv') ('mpipriv' 2 0 0 'mpipriv')) and I don't think that's desirable. I think that the module loading is actually wrong here: the code in gfc_get_common (match.c) takes special care to duplicate this common name by creating a unique name for it. While I believe that mangling is necessary, the mangled name shouldn't be unique but simply prefixed, so that of the same name are merged, while prevented to clash with the namespace of the use'ing procedure. I'm regtesting the following patch: Index: match.c =================================================================== --- match.c (revision 129869) +++ match.c (working copy) @@ -2608,23 +2608,19 @@ gfc_common_head * gfc_get_common (const char *name, int from_module) { gfc_symtree *st; - static int serial = 0; - char mangled_name[GFC_MAX_SYMBOL_LEN + 1]; + char mangled_name[GFC_MAX_SYMBOL_LEN + 12]; if (from_module) - { - /* A use associated common block is only needed to correctly layout - the variables it contains. */ - snprintf (mangled_name, GFC_MAX_SYMBOL_LEN, "_%d_%s", serial++, name); - st = gfc_new_symtree (&gfc_current_ns->common_root, mangled_name); - } - else - { - st = gfc_find_symtree (gfc_current_ns->common_root, name); - - if (st == NULL) - st = gfc_new_symtree (&gfc_current_ns->common_root, name); - } + /* A use associated common block is only needed to correctly layout + the variables it contains. */ + snprintf (mangled_name, GFC_MAX_SYMBOL_LEN, "_frommodule_%s", name); + + st = gfc_find_symtree (gfc_current_ns->common_root, + from_module ? mangled_name : name); + + if (st == NULL) + st = gfc_new_symtree (&gfc_current_ns->common_root, + from_module ? mangled_name : name); if (st->n.common == NULL) { -- fxcoudert at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxcoudert at gcc dot gnu dot | |org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|2006-12-24 10:47:43 |2007-11-09 12:36:15 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
next prev parent reply other threads:[~2007-11-09 12:36 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-12-24 0:26 [Bug fortran/30285] New: gfortran huge (excessive?) memory usage with large modules anlauf at gmx dot de 2006-12-24 0:28 ` [Bug fortran/30285] " anlauf at gmx dot de 2006-12-24 10:47 ` [Bug fortran/30285] gfortran excessive " steven at gcc dot gnu dot org 2007-02-02 1:50 ` bdavis at gcc dot gnu dot org 2007-02-02 9:35 ` bdavis at gcc dot gnu dot org 2007-02-02 11:10 ` anlauf at gmx dot de 2007-02-02 21:44 ` anlauf at gmx dot de 2007-02-02 22:37 ` bdavis at gcc dot gnu dot org 2007-02-25 4:42 ` bdavis at gcc dot gnu dot org 2007-02-26 13:05 ` anlauf at gmx dot de 2007-04-13 18:44 ` tobi at gcc dot gnu dot org 2007-04-20 2:41 ` bdavis at gcc dot gnu dot org 2007-04-20 19:56 ` bdavis at gcc dot gnu dot org 2007-10-22 7:35 ` [Bug fortran/30285] gfortran excessive memory usage with COMMON blocks in modules anlauf at gmx dot de 2007-11-09 12:36 ` fxcoudert at gcc dot gnu dot org [this message] 2007-11-09 12:44 ` Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-11-10 0:00 ` fxcoudert at gcc dot gnu dot org 2007-11-10 1:16 ` Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-11-10 4:01 ` patchapp at dberlin dot org 2007-11-10 12:29 ` burnus at gcc dot gnu dot org 2007-11-10 15:18 ` anlauf at gmx dot de 2007-11-10 18:09 ` fxcoudert at gcc dot gnu dot org 2007-11-11 22:18 ` anlauf at gmx dot de 2007-11-12 5:55 ` patchapp at dberlin dot org 2007-11-17 13:47 ` fxcoudert at gcc dot gnu dot org 2007-11-17 13:49 ` fxcoudert at gcc dot gnu dot org [not found] <bug-30285-4@http.gcc.gnu.org/bugzilla/> 2015-10-10 9:12 ` 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=20071109123616.18241.qmail@sourceware.org \ --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: linkBe 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).