User account creation filtered due to spam.

Bug 31609 - module that calls a contained function with an ENTRY point
Summary: module that calls a contained function with an ENTRY point
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2007-04-17 17:29 UTC by Michael Richmond
Modified: 2007-07-31 22:28 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.1.2 4.2.0 4.3.0
Last reconfirmed: 2007-07-30 16:22:41


Attachments
2 include files and 1 f90 (1.87 KB, text/plain)
2007-06-29 18:17 UTC, Al Greynolds
Details
Example of bad translation (352 bytes, text/plain)
2007-07-28 15:29 UTC, Jerry DeLisle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Richmond 2007-04-17 17:29:57 UTC
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
Comment 1 Jerry DeLisle 2007-06-06 01:34:11 UTC
Confirmed.  I will investigate a little.
Comment 2 Jerry DeLisle 2007-06-06 01:59:42 UTC
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.

Comment 3 Al Greynolds 2007-06-29 18:17:15 UTC
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.
Comment 4 Daniel Franke 2007-07-08 15:20:34 UTC
Jerry, 
the patch in PR32157, comment #2 seems to fix this one as well.
Comment 5 Paul Thomas 2007-07-08 19:40:51 UTC
(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
Comment 6 Daniel Franke 2007-07-08 19:44:09 UTC
> Not sure if this is same bug or new one.

Paul, this probably became PR32594.
Comment 7 Jerry DeLisle 2007-07-08 19:54:22 UTC
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
Comment 8 Paul Thomas 2007-07-09 04:45:20 UTC
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
Comment 9 Jerry DeLisle 2007-07-26 05:35:23 UTC
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;
 }
 
 
Comment 10 Jerry DeLisle 2007-07-28 15:29:54 UTC
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
Comment 11 Jerry DeLisle 2007-07-28 21:17:30 UTC
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

Comment 12 Jerry DeLisle 2007-07-28 22:02:53 UTC
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

Comment 13 Jerry DeLisle 2007-07-29 23:23:59 UTC
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.
Comment 14 Paul Thomas 2007-07-30 16:22:40 UTC
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;
Comment 15 Jerry DeLisle 2007-07-31 01:39:22 UTC
Regression tests fine on X86-64-Gnu/Linux
Comment 16 patchapp@dberlin.org 2007-07-31 14:15:26 UTC
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
Comment 17 Paul Thomas 2007-07-31 22:14:40 UTC
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

Comment 18 Paul Thomas 2007-07-31 22:28:28 UTC
Fixed on trunk - this is clearly related to pr31214.... so, hey ho, off to work we go!

Paul