http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451
Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |46174 --- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-26 07:35:44 UTC --- The test case of comment 4 is now fixed, namely: ALLOCATE (polymorphic, SOURCE=non-polymorphic) Unfixed is a polymorphic SOURCE= as this requires a deep copying of the effective type, cf. PR 46174. Consequently, the first test case (attachment 21592) will fail at allocate(a%a,source=b, stat=info) if "b" has any allocatable components. That's the case if "b" is of the effective type "psb_d_csr_sparse_mat". Interestingly, wrapping the ALLOCATE in select type (b) type is (psb_d_csr_sparse_mat) allocate(a%a,source=b, stat=info) end select does not help :-( I do not know whether this SOURCE= problem is the only or only the main bug exposed by the first test case. * * * Unfixed is the diagnostic of passing a non-polymorphic actual to an *allocatable* polymorphic dummy. That accepts-invalid bug is PR 46161 and affects the second attachment (attachment 21613).