------- 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
