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/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.


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).


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