Dear All,

This bug generates an ICE because the symbol for dummy 'n' in the
specification expression for the result of 'fun1' is not the same as
the symbol in the formal arglist. For some reason that I have been
unable to uncover, this false dummy is associated with a unique
symtree. The odd thing is that the dump of the parse tree for the
failing module procedure case is identical to that where the interface
is explcitely reproduced in the submodule. The cause of the ICE is
that the false dummy has no backend_decl as it should.

This patch hits the problem directly on the head by using the
backend_decl from the symbol in the namespace of the formal arglist,
as described in the comment in the patch. If it is deemed to be more
hygenic, the chunk of code can be lifted out and deposited in a
separate function.

Bootstraps and regtests on FC23/x86_64 - OK for trunk?

Cheers

Paul

2017-02-07  Paul Thomas  <pa...@gcc.gnu.org>

    PR fortran/79344
    * trans-decl.c (gfc_get_symbol_decl): If a dummy apparently has
    a null backend_decl, look for a replacement symbol in the
    namespace of the 1st formal argument and use its backend_decl.

2017-02-07  Paul Thomas  <pa...@gcc.gnu.org>

    PR fortran/79344
    * gfortran.dg/submodule_23.f90: New test.
Index: gcc/fortran/trans-decl.c
===================================================================
*** gcc/fortran/trans-decl.c    (revision 245196)
--- gcc/fortran/trans-decl.c    (working copy)
*************** gfc_get_symbol_decl (gfc_symbol * sym)
*** 1510,1516 ****
            sym->backend_decl = DECL_CHAIN (sym->backend_decl);
        }
  
!       /* Dummy variables should already have been created.  */
        gcc_assert (sym->backend_decl);
  
        /* Create a character length variable.  */
--- 1510,1538 ----
            sym->backend_decl = DECL_CHAIN (sym->backend_decl);
        }
  
!       /* Dummy variables should already have been created.  However,
!        sometimes variables in specification expressions of the result
!        of module procedures in submodules wind up not being the 'real'
!        dummy.  Find this, if possible, in the namespace of the first
!        formal argument.  */
!       if (sym->backend_decl == NULL_TREE)
!       {
!         gfc_symtree *st = NULL;
!         gfc_symbol *s = NULL;
! 
!         if (sym->ns->proc_name
!             && sym->ns->proc_name->formal)
!           s = sym->ns->proc_name->formal->sym;
! 
!         if (s != NULL)
!           st = gfc_find_symtree (s->ns->sym_root, sym->name);
! 
!         if (st != NULL
!             && st->n.sym != NULL
!             && st->n.sym->attr.dummy)
!           sym->backend_decl = st->n.sym->backend_decl;
!       }
! 
        gcc_assert (sym->backend_decl);
  
        /* Create a character length variable.  */
Index: gcc/testsuite/gfortran.dg/submodule_23.f90
===================================================================
*** gcc/testsuite/gfortran.dg/submodule_23.f90  (nonexistent)
--- gcc/testsuite/gfortran.dg/submodule_23.f90  (working copy)
***************
*** 0 ****
--- 1,29 ----
+ ! { dg-do compile }
+ !
+ ! Test the fix for PR79402, in which the module procedure 'fun1' picked
+ ! up a spurious symbol for the dummy 'n' in the specification expression
+ ! for the result 'y'.
+ !
+ ! Contributed by Chris Coutinho  <chrisbcouti...@gmail.com>
+ !
+ module mod
+   interface myfun
+     module function fun1(n) result(y)
+       integer,  intent(in)    :: n
+       real, dimension(n)  :: y
+     end function fun1
+   end interface myfun
+ 
+ end module mod
+ 
+ submodule (mod) submod
+ contains
+   module procedure fun1
+     integer :: i
+     y = [(float (i), i = 1, n)]
+   end procedure fun1
+ end submodule
+ 
+   use mod
+   print *, fun1(10)
+ end

Reply via email to