[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