[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref

["janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.01.31 10:29:20
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #5 from janus at gcc dot gnu.org 2011-01-31 10:29:20 UTC ---
Alright, here is a draft patch:


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c    (revision 169407)
+++ gcc/fortran/resolve.c    (working copy)
@@ -5877,14 +5877,12 @@ resolve_typebound_subroutine (gfc_code *code)

   /* Deal with typebound operators for CLASS objects.  */
   expr = code->expr1->value.compcall.base_object;
-  if (expr && expr->symtree->n.sym->ts.type == BT_CLASS
-    && code->expr1->value.compcall.name)
+  if (expr && expr->ts.type == BT_CLASS && code->expr1->value.compcall.name)
     {
       /* Since the typebound operators are generic, we have to ensure
      that any delays in resolution are corrected and that the vtab
      is present.  */
-      ts = expr->symtree->n.sym->ts;
-      declared = ts.u.derived;
+      declared = expr->ts.u.derived;
       c = gfc_find_component (declared, "_vptr", true, true);
       if (c->ts.u.derived == NULL)
     c->ts.u.derived = gfc_find_derived_vtab (declared);
@@ -5895,6 +5893,7 @@ resolve_typebound_subroutine (gfc_code *code)
       /* Use the generic name if it is there.  */
       name = name ? name : code->expr1->value.function.esym->name;
       code->expr1->symtree = expr->symtree;
+      code->expr1->ref = gfc_copy_ref (expr->ref);
       expr->symtree->n.sym->ts.u.derived = declared;
       gfc_add_vptr_component (code->expr1);
       gfc_add_component_ref (code->expr1, name);



This fixes comment #1 and comment #4. For the original test case I now get:

gfortran-4.6  -std=f2003   -c hydro_types.f90
gfortran-4.6  -std=f2003   -c hydro_state.f90
gfortran-4.6  -std=f2003   -c hydro_speeds.f90
gfortran-4.6  -std=f2003   -c hydro_grid.f90
gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.13:

    call this%init(st, gr)
             1
Error: Found no matching specific binding for the call to the GENERIC 'init' at
(1)



Changing this generic call to the corresponding specific type-bound procedure,
I get:

gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.13:

    call this%init_comps(st, gr)
             1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)



And the same without type-binding:

gfortran-4.6  -std=f2003   -c hydro_flow.f90
hydro_flow.f90:55.20:

    call init_comps(this, st, gr)
                    1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)



The code does look valid to me (unless I'm missing something), so this seems to
be another gfortran bug.