[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-24 22:31:19 UTC ---
(In reply to comment #13)
> The following works - though I am not sure whether it is the correct patch.
> Janus, what do you think?

I mean in particular gfc_expr_to_initialize (expr) vs. expr and questions
regarding the default initializer.


Further comments:

a) The first example (attachment 21592) produces the correct numbers (or at
least the same as Cray and as in comment 3). Also in comment 0 the numbers are
OK for the the valgrind run - only the ones of the non-valgrind run were wrong.

If one uses GLIBC's MALLOC checks the program still segfaults; valgrind shows a
failure for:
  Conditional jump or move depends on uninitialised value(s)
    at 0x4EF7FD2: _gfortran_move_alloc (move_alloc.c:40)
    by 0x400C8C: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt (long1.f90:238)
which is   if (to->data)  and
    call move_alloc(b%irp, a%irp)
if one checks the allocation status of "b%irp" after the mvoe_alloc call, the
result is "T" rather than the expect "F".


b) The second example (attachment 21613) fails with crayftn at it is invalid.
(In "call doit(atx,acsr)" the second argument is TYPE instead of CLASS as the
*allocatable* dummy is.) gfortran does not detect this. -- See new PR 46161.