This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch, fortran] PR16940 - module interfaces to containedprocedures

This patch fixes the ICE that occurred with module interfaces to
contained procedures, where implicit none was declared in the

The problem arose because the symbol arrived in resolve_symbol,
with next to nothing set, so that it was being identified as
FL_VARIABLE by default.  A few lines down, setting default type
fails because of the implicit none.  By looking in for the symbol
name in parent namespaces and checking if it corresponds to an
interface, the variable can be set to FL_PROCEDURE, which is set
to no error on not finding an implicit type.  This also makes the
result look better in the parse tree.  This incomplete sysmbol is
ignored later on,when the interfaces are resolved.

Notice that the testcase triggers a latent fault in
dump_parse_tree.c that was hidden by the compiler fault.  I will
post the patch for this over the weekend.

I will also retest the patch, using cvs mainline, as soon as I get

Subject to regtesting on mainline, OK to commit on 4.1 and,
sometime, on 4.0?

Paul T

NB The attached version is properly tabbed.

2005-07-01 Paul Thomas  <>
 PR fortran/16940
 * resolve.c (resolve_symbol): Set symbol attributes
 of use associated, module interfaces to FL_PROCEDURE
 to avoid ICE and so that parse tree dump looks OK.

2005-07-01  Paul Thomas  <>
 PR fortran/16940
 * gfortran.dg/module_interface_1.f90: New.

*** resolve.c.bak Thu Jun 30 11:57:22 2005
--- gcc-4.1-20050522/gcc/fortran/resolve.c Thu Jun 30 19:46:40 2005
*************** resolve_symbol (gfc_symbol * sym)
*** 4031,4036 ****
--- 4031,4056 ----
    int i;
    const char *whynot;
    gfc_namelist *nl;
+   gfc_symtree * symtree;
+   gfc_namespace * ns;
+   /* If we find that the symbol is an interface in one of the
+      parent namespaces, set its flavor to that of a procedure
+      so that it looks sensible in the parse tree.  It gets
+      resolved away later on so its type does not matter.  */ 
+   if (sym->ts.type == BT_UNKNOWN
+  && sym->attr.flavor == FL_UNKNOWN)
+     {
+       for (ns = gfc_current_ns->parent; ns; ns = ns->parent)
+  {
+    symtree = gfc_find_symtree (ns->sym_root, sym->name);
+    if (symtree && symtree->n.sym->generic)
+      {
+        sym->attr.flavor = FL_PROCEDURE;
+        sym->attr.use_assoc = 1;
+      }
+  }
+     }
    if (sym->attr.flavor == FL_UNKNOWN)

! { dg-do run }
! This tests the fix for PR16940, module interfaces to
! contained functions caused ICEs.
! This is a simplified version of the example in the PR
! discussion, which was due to L.Meissner.
! Submitted by Paul Thomas
  module Max_Loc_Mod
    implicit none
    interface Max_Location
      module procedure I_Max_Loc
    end interface
    function I_Max_Loc (Vector) result(Ans)
      integer, intent (in), dimension(:) :: Vector
      integer, dimension(1) :: Ans
      Ans = maxloc(Vector)
    end function I_Max_Loc
  end module Max_Loc_Mod
  program module_interface
    use Max_Loc_Mod
    use Max_Loc_Mod
    implicit none
    integer :: Vector (7)
    Vector = (/1,6,3,5,19,1,2/)
    call Selection_Sort (Vector)
    subroutine Selection_Sort (Unsorted)
      integer, intent (in), dimension(:) :: Unsorted
      integer, dimension (1) :: N
      N = Max_Location (Unsorted)
      if (N(1).ne.5) call abort ()
    end subroutine Selection_Sort
  end program module_interface

Attachment: module_interface.msg
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]