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

["sfilippone at uniroma2 dot it" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #22 from sfilippone at uniroma2 dot it  2010-06-25 15:31 -------
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I have found at least one
thing differentiating generic_23 from test_coo above (this is the static
example, not the allocatable one). The "fixed name" thing comes from the
snippet of code
 success:
  /* Make sure that we have the right specific instance for the name.  */
  genname = e->value.compcall.tbp->u.specific->name;

---------------------------
[sfilippo@donald bug15]$ gfortran -c  test_coo.f03 
Warning: Matched Name: '---' genname 'allocate' 
Warning: Fixed Name: '---' genname 'base_allocate_mnnz' 
---------------------------------
As you can see, the name is resolved to the specific procedure. The declaration
was 
 type  :: base_sparse_mat
    integer, private     :: m, n
    integer, private     :: state, duplicate 
    logical, private     :: triangle, unitd, upper, sorted
  contains 

    procedure, pass(a) :: get_fmt => base_get_fmt
    procedure, pass(a) :: set_null => base_set_null
    procedure, pass(a) :: allocate_mnnz => base_allocate_mnnz
    generic,   public  :: allocate => allocate_mnnz
  end type base_sparse_mat

So the generics resolution is homing in to the procedure name. 
However my copy of the Fortran 2003 handbook says (at pages 95-97):
1. Specifinc bindings: 
PROCEDURE [ [,NON-OVERRIDABLE] [, binding-attribute-list] ::] binding-name [ =>
procedure-name ]
2. Generic bindings: 
GENERIC [ , access-spec ] :: generic-spec => binding-name-list

Looks to me the existing mechanism is NOT doing the correct thing, as it should
home on the BINDING-NAME (allocate_mnnz) and not on the procedure name
(base_allocate_mnnz) 

Hope this will help in fixing this thing; as of now, I have no idea if this is
related to the allocatable case (see my attachment generic_23_1) 

Salvatore 


-- 


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