gfortran segfaults when I compile the following module. It also segfaults if I change "i = k()" to "i = j()". MODULE ksbin1_aux_mod CONTAINS SUBROUTINE sub i = k() END SUBROUTINE sub FUNCTION j () j = 0 ENTRY k () k = 0 END FUNCTION j END MODULE ksbin1_aux_mod
Confirmed. I will investigate a little.
The problem is here in resolve.c: static int generic_sym (gfc_symbol *sym) { gfc_symbol *s; if (sym->attr.generic || (sym->attr.intrinsic && gfc_generic_intrinsic (sym->name))) return 1; if (was_declared (sym) || sym->ns->parent == NULL) return 0; gfc_find_symbol (sym->name, sym->ns->parent, 1, &s); return (s == NULL) ? 0 : generic_sym (s); } gfc_find_symbol is returning the same symbol that is called with generic_sym and thus we are in an infinite loop, calling genric_sym with that same symbol over and over again. I think this is related to 32157. gfortran does not discriminate symbols of the same name but with different scope or type.
Created attachment 13806 [details] 2 include files and 1 f90 gfortran -c utility.f90 utility.f90:0: internal compiler error: Bus error Not sure if this is same bug or new one.
Jerry, the patch in PR32157, comment #2 seems to fix this one as well.
(In reply to comment #4) > Not sure if this is same bug or new one. > Al, How do I load a .zip file through Bugzilla, please? Paul
> Not sure if this is same bug or new one. Paul, this probably became PR32594.
Subject: Re: module that calls a contained function with an ENTRY point pault at gcc dot gnu dot org wrote: > ------- Comment #5 from pault at gcc dot gnu dot org 2007-07-08 19:40 ------- > (In reply to comment #4) > >> Not sure if this is same bug or new one. >> > > Al, > > How do I load a .zip file through Bugzilla, please? > > Paul > > goto irc and we talk. Jerry
This ICEs as well: MODULE ksbin1_aux_mod interface foo module procedure k end interface CONTAINS FUNCTION j () j = 1 ENTRY k () k = 2 END FUNCTION j END MODULE ksbin1_aux_mod I thought that such things had been fixed a while since *sigh* Paul
This fixes the infinite recursive loop and fixes a segfault I was getting on the original test case. The test case in comment #8 is something different. Index: resolve.c =================================================================== --- resolve.c (revision 126937) +++ resolve.c (working copy) @@ -789,8 +789,16 @@ generic_sym (gfc_symbol *sym) return 0; gfc_find_symbol (sym->name, sym->ns->parent, 1, &s); + + if (s != NULL) + { + if (s == sym) + return 0; + else + return generic_sym (s); + } - return (s == NULL) ? 0 : generic_sym (s); + return 0; }
Created attachment 13994 [details] Example of bad translation This attached example of tree-dump-original shows that we are getting a translation error. See the k=2B . It should be k.1 = 2. So the error is after my initial patch with test case in #8: pr31609-2.f90:11: internal compiler error: gimplification failed Getting closer I hope
Subject: Bug 31609 Author: jvdelisle Date: Sat Jul 28 21:17:20 2007 New Revision: 127026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127026 Log: 2007-07-28 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/31609 * resolve.c (generic_sym): Check for a same symbol and if so, return to avoid infinite recursion. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
Subject: Bug 31609 Author: jvdelisle Date: Sat Jul 28 22:02:42 2007 New Revision: 127028 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127028 Log: 2007-07-29 Jerry DeLisle <jvdelisle@gcc.gnu.org> PR fortran/31609 * gfortran.dg/entry_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_11.f90 Modified: trunk/gcc/testsuite/ChangeLog
The patch applied in Comment #11 fixes the original test case. The modified test case in Comment #8 is still broken. pr31609-2.f90: In function ‘master.0.j’: pr31609-2.f90:10: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:452 I am going to have to leave this to others.
To my amazement, the patch below fixes the problem and, I am pretty sure, will complete its regtest OK. Before posting it, I want to thoroughly check that I have understood the problem and that the fix is valid. Cheers Paul 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) *** 390,396 **** gfc_namespace *old_ns; gfc_code *c; gfc_symbol *proc; ! gfc_entry_list *el; char name[GFC_MAX_SYMBOL_LEN + 1]; static int master_count = 0; --- 390,396 ---- gfc_namespace *old_ns; gfc_code *c; gfc_symbol *proc; ! gfc_entry_list *el, *el2; char name[GFC_MAX_SYMBOL_LEN + 1]; static int master_count = 0; *************** resolve_entries (gfc_namespace *ns) *** 431,436 **** --- 431,444 ---- && 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 (el2 = el->next; el2; el2 = el2->next) + if (el2->sym->ns->proc_name->attr.flavor == FL_MODULE + && el2->sym->attr.mod_proc) + el2->sym->ns = ns; + /* Add an entry statement for it. */ c = gfc_get_code (); c->op = EXEC_ENTRY;
Regression tests fine on X86-64-Gnu/Linux
Subject: Bug number PR31609 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02177.html
Subject: Bug 31609 Author: pault Date: Tue Jul 31 22:14:29 2007 New Revision: 127108 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127108 Log: 2007-08-01 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-08-01 Paul Thomas <pault@gcc.gnu.org> PR fortran/31609 * gfortran.dg/entry_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/entry_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk - this is clearly related to pr31214.... so, hey ho, off to work we go! Paul