From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-323912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15634 invoked by alias); 7 Jul 2010 14:25:56 -0000
Received: (qmail 15297 invoked by uid 48); 7 Jul 2010 14:25:11 -0000
Date: Wed, 07 Jul 2010 14:25:00 -0000
Message-ID: <20100707142511.15293.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-43945-13404@http.gcc.gnu.org/bugzilla/>
Subject: [Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
In-Reply-To: <bug-43945-13404@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "sfilippone at uniroma2 dot it" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2010-07/txt/msg00744.txt.bz2



------- Comment #27 from sfilippone at uniroma2 dot it  2010-07-07 14:25 -------
(In reply to comment #26)
For the test_coo.f03 case, what happens is shown in the following dump. 
 {
    struct class$base_sparse_mat class.6;

    if (vtab$d_coo_sparse_mat.allocate == 0B)
      {
        vtab$d_coo_sparse_mat.allocate_mnnz = (void (*<T62>) (void))
d_coo_allocate_mnnz;
        vtab$d_coo_sparse_mat.set_null = (void (*<T62>) (void)) d_coo_set_null;
        vtab$d_coo_sparse_mat.get_fmt = (void (*<T62>) (void)) d_coo_get_fmt;
      }
    class.6.$vptr = (struct vtype$base_sparse_mat * {ref-all})
&vtab$d_coo_sparse_mat;
    class.6.$data = (struct base_sparse_mat *) &acoo;
    base_allocate_mnnz (&n, &n, &class.6, &nnz);
  }
At the end of the block, since the type of acoo is known at compile time, the
call gets resolved to base_allocate_mnnz, instead of resolving to
vtab$d_coo_sparse_mat.allocate_mnnz  
which would contain the correct function. 
As shown in test_vt2, when the dynamic type is not known at compile time the
naive diff I posted works. 

What happens in the code is that when the compiler enters this function

static gfc_try
resolve_typebound_static (gfc_expr* e, gfc_symtree** target,
                          gfc_actual_arglist** actual)
{
  gcc_assert (e->expr_type == EXPR_COMPCALL);
  gcc_assert (!e->value.compcall.tbp->is_generic);

  /* Update the actual arglist for PASS.  */
  if (update_compcall_arglist (e) == FAILURE)
    return FAILURE;

  *actual = e->value.compcall.actual;
  *target = e->value.compcall.tbp->u.specific;

  gfc_free_ref_list (e->ref);
  e->ref = NULL;
  e->value.compcall.actual = NULL;

  return SUCCESS;
}

we have
(gdb) print *(e->value.compcall.tbp->u.specific) 
$7 = {priority = 3856, left = 0x0, right = 0x0, name = 0x7ffff1ae24c8
"base_allocate_mnnz", ambiguous = 0, n = {sym = 0x13c6580, uop = 0x13c6580,
common = 0x13c6580, tb = 0x13c6580}}
instead of pointing to the correct  d_coo_allocate_mnnz (to which the vtab is
correctly pointing).  
I have nowhere near enough knowledge of the code to conceive a fix, hopefully
someone knowledgeable will take up.. 


Moreover, there still is the issue of initializing CLASS allocatables (see
generic_23_1.f03) where it appears that something is missing after (sourced)
allocation. 


-- 


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