[Patch, Fortran] SELECT TYPE via ASSOCIATE

Salvatore Filippone salvatore.filippone@uniroma2.it
Thu Aug 26 15:18:00 GMT 2010


While the PR test case is fixed, a different problem  crops up in the
application it was cut from. 

Consider the following code snippet
------------------------------------------------------
  class(psb_d_csr_sparse_mat), intent(inout)  :: a
  class(psb_d_base_sparse_mat), intent(inout) :: b
  integer, intent(out)                         :: info

  info = psb_success_
  string = b%get_fmt()
  write(0,*) 'Actual format for B in inner mv_from before SELECT_TYPE: ',string

  select type (b)
  type is (psb_d_coo_sparse_mat) 
    call a%mv_from_coo(b,info)
  class default
    string = b%get_fmt()
    write(0,*) 'Actual format for B in inner mv_from (CSR) class default clause: ',string
    call b%mv_to_coo(tmp,info)
    if (info == psb_success_) call a%mv_from_coo(tmp,info)
  end select
------------------------------------------------------------
As you can see, what I'm doing here is pretty straigthforward: all
derived types have a MV_TO_COO and MV_FROM_COO method, and I switch
based on whether I can take a shortcut or not. The GET_FMT() method just
prints a descriptive name of the dynamic type of the object.
If I run the above code I get:
------------------------------
 Actual format for B in outer mv_from CSR                 
 Actual format for B in inner mv_from before SELECT_TYPE: CSR                 
 Actual format for B in inner mv_from (CSR) class default clause: COO   
----------------------------------
and the call to b%mv_to_coo gets routed (confimred via gdb) to 
COO_MV_TO_COO instead of CSR_MV_TO_COO. 

These symptoms look like the first TYPE clause clobbers the dynamic type
of the object (and this is *slightly annoying*). 
If this is sufficient for Daniel to figure out, ok, otherwise I'll need
a couple hours before I can go back to cutting a new test case. 

Sorry to bear bad news :-( 

Salvatore 



More information about the Gcc-patches mailing list