This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP



------- Comment #24 from sfilippone at uniroma2 dot it  2010-07-06 10:14 -------
(In reply to comment #23)
> (In reply to comment #22)
> > 
> generic_23.f03 obviously works becase the binding name DOIT and the procedure
> name are one and the same.... 
> 
Hi all
Another variation to the test case, to have the guilty statements in a one-line
function of their own, and the -fdump-tree-original shows what's going on:
tryset is correct, tryall has this  "a->$vptr->allocate->allocate_mnnz "  
thing which leads to error. If it was just "a->$vptr->allocate_mnnz " (which I
tested by changing the statement to invoke directly the specific binding name)
it would work. 
So, it looks like the code that resolves the generic procedure would do well to
just avoid the GENERIC part of the vtab, resolve the generic to a specific and
invoke the vtab for the specific. I have tried to follow the resolve code, but
I got lost (I guess it's a bit coplex as a first trip inside gfortran guts :-) 
I suppose the originator(s) of the code would do much better. 

tryall (struct class$d_base_sparse_mat & restrict a, integer(kind=4) & restrict
m, integer(kind=4) & restrict n, integer(kind=4) & restrict nz)
{
  a->$vptr->allocate->allocate_mnnz ((integer(kind=4) *) m, (integer(kind=4) *)
n, (struct class$d_base_sparse_mat *) a, (integer(kind=4) *) nz);
}


tryset (struct class$d_base_sparse_mat & restrict a)
{
  a->$vptr->set_null ((struct class$d_base_sparse_mat *) a);
}


-- 


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


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