This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
[Patch, fortran] PR31609 - module that calls a contained function with an ENTRY point
- From: Paul Thomas <paulthomas2 at wanadoo dot fr>
- To: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 31 Jul 2007 16:13:52 +0200
- Subject: [Patch, fortran] PR31609 - module that calls a contained function with an ENTRY point
:ADDPATCH fortran:
Note that this problem has already been fixed by Jerry - this is an
extension, introduced in comment #8.
I had thought that it had been fixed with PR31474 but, no, I was wrong.
This latter fixed cases where the function itself was declared as a
module procedure. This new one occurred where the function was not a
module procedure but one of its alternate entries was. The symbol for
the entry was winding up in the module namespace, rather than the
function namespace. This patch corrects this in resolve_entries in
similar manner to the function case of PR31474. The testcase is based
on that in comment #8.
Regtested on Cygwin_NT/amd64 - OK for trunk?
Paul
2007-07-31 Paul Thomas <pault@gcc.gnu.org>
PR fortran/31609
* resolve.c (resolve_entries): Entries declared to be module
procedures must point to the function namespace.
2007-07-31 Paul Thomas <pault@gcc.gnu.org>
PR fortran/31609
* gfortran.dg/entry_12.f90: New test.
Index: /svn/trunk/gcc/fortran/resolve.c
===================================================================
*** /svn/trunk/gcc/fortran/resolve.c (revision 127061)
--- /svn/trunk/gcc/fortran/resolve.c (working copy)
*************** resolve_entries (gfc_namespace *ns)
*** 431,436 ****
--- 431,445 ----
&& ns->parent && ns->parent->proc_name->attr.flavor == FL_MODULE)
el->sym->ns = ns;
+ /* Do the same for entries where the master is not a module
+ procedure. These are retained in the module namespace because
+ of the module procedure declaration. */
+ for (el = el->next; el; el = el->next)
+ if (el->sym->ns->proc_name->attr.flavor == FL_MODULE
+ && el->sym->attr.mod_proc)
+ el->sym->ns = ns;
+ el = ns->entries;
+
/* Add an entry statement for it. */
c = gfc_get_code ();
c->op = EXEC_ENTRY;
Index: /svn/trunk/gcc/testsuite/gfortran.dg/entry_12.f90
===================================================================
*** /svn/trunk/gcc/testsuite/gfortran.dg/entry_12.f90 (revision 0)
--- /svn/trunk/gcc/testsuite/gfortran.dg/entry_12.f90 (revision 0)
***************
*** 0 ****
--- 1,30 ----
+ ! { dg-do run }
+ ! Tests the fix for pr31609, where module procedure entries found
+ ! themselves in the wrong namespace. This test checks that all
+ ! combinations of generic and specific calls work correctly.
+ !
+ ! Contributed by Paul Thomas <pault@gcc.gnu.org> as comment #8 to the pr.
+ !
+ MODULE ksbin1_aux_mod
+ interface foo
+ module procedure j
+ end interface
+ interface bar
+ module procedure k
+ end interface
+ interface foobar
+ module procedure j, k
+ end interface
+ CONTAINS
+ FUNCTION j ()
+ j = 1
+ return
+ ENTRY k (i)
+ k = 2
+ END FUNCTION j
+ END MODULE ksbin1_aux_mod
+
+ use ksbin1_aux_mod
+ if (any ((/foo (), bar (99), foobar (), foobar (99), j (), k (99)/) .ne. &
+ (/1, 2, 1, 2, 1, 2/))) Call abort ()
+ end