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

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

[sfilippone at uniroma2 dot it]

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

--- Comment #11 from Salvatore Filippone <sfilippone at uniroma2 dot it> 2010-10-05 19:39:44 UTC ---
(In reply to comment #4)
> Ok, I could reduce this quite a bit:
> 

> 
>            1           3           4           5
>            1           3           4           5
>            0           0           4           5
> 
> The last line here should be the same as the first two. Changing the CLASS
> variable into a TYPE makes it work. Running through valgrind shows:
> 

Strange thing is that guarding with a SELECT TYPE statement as in 
===========================
 allocate(a,source=acsr)

  write(*,*) acsr%irp(:)

  select type(aa=>a) 
  type is (psb_base_sparse_mat)
    call move_alloc(acsr%irp, aa%irp)

    write(*,*) aa%irp(:)
  class default
    write(*,*) 'Wrong class default'
  end select
================================ 
still gives the wrong answer
[sfilippo@localhost bug23]$ ./bug23_janus 
           1           3           4           5
           1           3           4           5
           0           0           4           5

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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-24 19:56:08 UTC ---
(In reply to comment #4)
> Ok, I could reduce this quite a bit:
>   allocate(acsr%irp(4)) 
>   allocate(a,source=acsr)

If one looks at the dump, one sees a similar problem to PR 43018. For the first
allocate, one has:
              D.1530 = (void * restrict) __builtin_malloc (16);
which makes sense: 4 * integer(4) = 16 byte. However, for the second allocate
one sees:
              D.1532 = (void * restrict) __builtin_malloc (48);
which might be OK. However, the following is definitely invalid - and causes
here a segfault
      (void) __builtin_memcpy ((void *) a.$data, (void *) &acsr, 48);

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

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-24 21:42:33 UTC ---
(In reply to comment #12)
> If one looks at the dump

Scratch that part. In one case one allocates the component (integr(4)*4) in the
other case the type, i.e. the array descriptor.

The actual issue is that only a shallow copy is done:

      (void) __builtin_memcpy ((void *) a.$data, (void *) &acsr, 48);

Thus, a.$data->irp.data and acsr.irp.data point to the same memory. Of course,
this will fail at
  finally
      if (acsr.irp.data != 0B)
          __builtin_free ((void *) acsr.irp.data);
      if (a.$data != 0B)
          if (a.$data->irp.data != 0B)
              __builtin_free ((void *) a.$data->irp.data);

The problem is in trans-stmt.c's gfc_trans_allocate:

      if (code->expr3 && !code->expr3->mold)
        {
          /* Initialization via SOURCE block
             (or static default initializer).  */
          gfc_expr *rhs = gfc_copy_expr (code->expr3);
          if (al->expr->ts.type == BT_CLASS)
              [...]
              tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz);
            }
          else
            tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr),
                                        rhs, false, false);

The gfc_trans_assignment properly takes care of allocatable components (cf. PR
43018) while a simple memcopy does not.


The following works - though I am not sure whether it is the correct patch.
Janus, what do you think?

--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -4489,15 +4489,9 @@ gfc_trans_allocate (gfc_code * code)
          gfc_expr *rhs = gfc_copy_expr (code->expr3);
          if (al->expr->ts.type == BT_CLASS)
            {
-             gfc_se dst,src;
              if (rhs->ts.type == BT_CLASS)
                gfc_add_component_ref (rhs, "$data");
-             gfc_init_se (&dst, NULL);
-             gfc_init_se (&src, NULL);
-             gfc_conv_expr (&dst, expr);
-             gfc_conv_expr (&src, rhs);
-             gfc_add_block_to_block (&block, &src.pre);
-             tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz);
+             tmp = gfc_trans_assignment (expr, rhs, false, false);
            }
          else
            tmp = gfc_trans_assignment (gfc_expr_to_initialize (expr),

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

[burnus at gcc dot gnu.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.

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

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-26 06:49:47 UTC ---
Author: burnus
Date: Tue Oct 26 06:49:43 2010
New Revision: 165936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165936
Log:
2010-10-26  Tobias Burnus  <burnus@net-b.de>

        PR fortran/45451
        * trans-stmt.c (gfc_trans_allocate): Do a deep-copy for SOURCE=.

        PR fortran/43018
        * trans-array.c (duplicate_allocatable): Use size of type and not
        the size of the pointer to the type.

2010-10-26  Tobias Burnus <burnus@net-b.de>

        PR fortran/45451
        * gfortran.dg/class_allocate_5.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_allocate_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

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

[burnus at gcc dot gnu.org]

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

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

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org 2010-11-05 18:15:02 UTC ---
Author: janus
Date: Fri Nov  5 18:14:52 2010
New Revision: 166368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166368
Log:
2010-11-05  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/45451
    PR fortran/46174
    * class.c (gfc_find_derived_vtab): Improved search for existing vtab.
    Add component '$copy' to vtype symbol for polymorphic deep copying.
    * expr.c (gfc_check_pointer_assign): Make sure the vtab is generated
    during resolution stage.
    * resolve.c (resolve_codes): Don't resolve code if namespace is already
    resolved.
    * trans-stmt.c (gfc_trans_allocate): Call '$copy' procedure for
    polymorphic ALLOCATE statements with SOURCE.

2010-11-05  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/45451
    PR fortran/46174
    * gfortran.dg/class_19.f03: Modified.
    * gfortran.dg/class_allocate_6.f03: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_allocate_6.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/class_19.f03

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

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #18 from janus at gcc dot gnu.org 2010-11-05 18:41:37 UTC ---
r166368 fixes the deep copy issue and makes the original test case give the
correct output.

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

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-09-01 12:02 -------
I think this is a variant of PR 42647: Allocatable components of allocatable
scalars are not correctly handled.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |42647


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

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

[sfilippone at uniroma2 dot it]

------- Comment #9 from sfilippone at uniroma2 dot it  2010-08-31 19:21 -------
Created an attachment (id=21613)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613&action=view)
test case


-- 


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

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

[sfilippone at uniroma2 dot it]

------- Comment #8 from sfilippone at uniroma2 dot it  2010-08-31 19:20 -------
(In reply to comment #7)
> (In reply to comment #6)
> 
> Fine. Waiting for it.... 
> 
Consider the following variation: upon exit from DOIT, the ACSR variable should
be deallocated (since it was MOVE_ALLOCed to atx%a) but it is not, hence double
free. 
===============================================================================
[sfilippo@localhost bug23]$ ./bug23_1 
 Allocation status acsr:  T
 Allocation status atx:  T T T
           1           3           4           5
           1           1           2           3           0           0       
   0           0           0           0           0           0
   1.0000000000000000        1.0000000000000000        2.0000000000000000      
 3.0000000000000000        0.0000000000000000        0.0000000000000000       
0.0000000000000000        0.0000000000000000        0.0000000000000000       
0.0000000000000000        0.0000000000000000        0.0000000000000000     
*** glibc detected *** ./bug23_1: double free or corruption (!prev):
0x00000000023bbfe0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x3d69675676]
./bug23_1[0x401876]
./bug23_1[0x4018da]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x3d6961ec5d]
./bug23_1[0x400869]
======= Memory map: ========
00400000-00402000 r-xp 00000000 08:05 2187330                           
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug23/bug2
........................


-- 


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

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

[sfilippone at uniroma2 dot it]

------- Comment #7 from sfilippone at uniroma2 dot it  2010-08-31 14:18 -------
(In reply to comment #6)
> 
> Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now
> MOLD works only with non-polymorphic expressions. Once the PR is fixed,
> polymorphics should work too. Until this has happened, please refrain from
> opening further PRs on MOLD.
> 

Fine. Waiting for it.... 


-- 


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

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

[janus at gcc dot gnu dot org]

------- Comment #6 from janus at gcc dot gnu dot org  2010-08-31 14:17 -------
(In reply to comment #5)
> In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
> application it still gives a segfault; I think that variant should be checked
> as well. 

Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now
MOLD works only with non-polymorphic expressions. Once the PR is fixed,
polymorphics should work too. Until this has happened, please refrain from
opening further PRs on MOLD.


-- 


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

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

[sfilippone at uniroma2 dot it]

------- Comment #5 from sfilippone at uniroma2 dot it  2010-08-31 14:04 -------
(In reply to comment #4)
> Ok, I could reduce this quite a bit:
> 
Good :) 
In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
application it still gives a segfault; I think that variant should be checked
as well. 
Actually, MOLD= is preferrable for the kind of thing I am doing, but since it's
an F2008 feature I had to put it under IFDEF for the time being. 

Salvatore 


-- 


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

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

[janus at gcc dot gnu dot org]

------- Comment #4 from janus at gcc dot gnu dot org  2010-08-30 20:48 -------
Ok, I could reduce this quite a bit:


program bug23
  implicit none

  type  :: psb_base_sparse_mat
    integer, allocatable :: irp(:)
  end type psb_base_sparse_mat

  class(psb_base_sparse_mat), allocatable  :: a 
  type(psb_base_sparse_mat) :: acsr

  allocate(acsr%irp(4)) 
  acsr%irp(1:4) = (/1,3,4,5/)

  write(*,*) acsr%irp(:)

  allocate(a,source=acsr)

  write(*,*) a%irp(:)

  call move_alloc(acsr%irp, a%irp)

  write(*,*) a%irp(:)

end program bug23


Executing gives:

           1           3           4           5
           1           3           4           5
           0           0           4           5

The last line here should be the same as the first two. Changing the CLASS
variable into a TYPE makes it work. Running through valgrind shows:

==11502== Command: ./a.out
==11502== 
           1           3           4           5
           1           3           4           5
==11502== Invalid read of size 4
==11502==    at 0x4EE59B8: extract_int (write.c:450)
==11502==    by 0x4EE67B1: write_integer (write.c:1260)
==11502==    by 0x4EE9BDE: _gfortrani_list_formatted_write (write.c:1552)
==11502==    by 0x4EDECA7: _gfortran_transfer_array (transfer.c:2000)
==11502==    by 0x400B07: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out)
==11502==    by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out)
==11502==  Address 0x5934360 is 0 bytes inside a block of size 16 free'd
==11502==    at 0x4C280BD: free (vg_replace_malloc.c:366)
==11502==    by 0x4EEF5A8: _gfortran_move_alloc (move_alloc.c:41)
==11502==    by 0x400AAC: MAIN__ (in /home/jweil/GSoC/PRs/45451/a.out)
==11502==    by 0x400BA8: main (in /home/jweil/GSoC/PRs/45451/a.out)
==11502== 
           1           3           4           5
==11502== 
==11502== HEAP SUMMARY:
==11502==     in use at exit: 0 bytes in 0 blocks
==11502==   total heap usage: 18 allocs, 18 frees, 3,844 bytes allocated
==11502== 
==11502== All heap blocks were freed -- no leaks are possible
==11502== 
==11502== For counts of detected and suppressed errors, rerun with: -v
==11502== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 4 from 4)


-- 


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

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

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2010-08-30 16:31:56
               date|                            |


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

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

[sfilippone at uniroma2 dot it]

------- Comment #3 from sfilippone at uniroma2 dot it  2010-08-30 12:13 -------

And here is the (expected) output with XLF.
[snfilip@josquin ~]$ xlf2003_r -o bug23 bug23.f03 
** psb_const_mod   === End of Compilation 1 ===
** psb_base_mat_mod   === End of Compilation 2 ===
** psb_d_base_mat_mod   === End of Compilation 3 ===
** psb_d_csr_mat_mod   === End of Compilation 4 ===
** psb_d_mat_mod   === End of Compilation 5 ===
** bug23   === End of Compilation 6 ===
1501-510  Compilation successful for file bug23.f03.
[snfilip@josquin ~]$ ./bug23 
 New version 
 Allocation status:  T T T
 1 3 4 5
 1 1 2 3 0 0 0 0 0 0 0 0
 1.00000000000000000 1.00000000000000000 2.00000000000000000
3.00000000000000000 0.000000000000000000E+00 0.000000000000000000E+00
0.000000000000000000E+00 0.000000000000000000E+00 0.000000000000000000E+00
0.000000000000000000E+00 0.000000000000000000E+00 0.000000000000000000E+00


-- 


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

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

[sfilippone at uniroma2 dot it]

------- Comment #2 from sfilippone at uniroma2 dot it  2010-08-30 12:12 -------
(In reply to comment #0)
> Hello,
> After a lot (a LOT) of work, I've come up with this test case. The test case
> *appears* to run fine, but valgrind shows something is amiss, and in the full
> application (much more complex) there follow multiple segfaults. I did not find
> (so far) a way to have a test case both small and exibiting the error out of
> valgrind, hope you'll pardon me. 
> The error: the ALLOCATABLE components of the ATX%A variable are detected as
> ALLOCATED, and seemingly are printed OK, but VALGRIND says they were already
> freed.
> 
>

Should be more careful before talking: the output is visibly wrong. 

> [sfilippo@donald bug23]$ ./bug23
>  New version 
>  Allocation status:  T T T
>            0           0           4           5
>            0           0           2           3           0           0       
>    0           0           0           0           0           0
>    0.0000000000000000        1.0000000000000000        2.0000000000000000      
>  3.0000000000000000        0.0000000000000000        0.0000000000000000       
> 0.0000000000000000        0.0000000000000000        0.0000000000000000       
> 0.0000000000000000        0.0000000000000000        0.0000000000000000     
> [sfilippo@donald bug23]$ valgrind ./bug23
> ==6940== Memcheck, a memory error detector
> ==6940== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==6940== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> ==6940== Command: ./bug23
> ==6940== 
>  New version 
>  Allocation status:  T T T
> ==6940== Invalid read of size 4
> ==6940==    at 0x4CC19B8: extract_int (write.c:450)
> ==6940==    by 0x4CC27B1: write_integer (write.c:1260)
> ==6940==    by 0x4CC5BDE: _gfortrani_list_formatted_write (write.c:1552)
> ==6940==    by 0x4CBACA7: _gfortran_transfer_array (transfer.c:2000)
> ==6940==    by 0x401834: MAIN__ (bug23.f03:308)
> ==6940==    by 0x40197A: main (bug23.f03:284)
> ==6940==  Address 0x5141450 is 0 bytes inside a block of size 16 free'd
> ==6940==    at 0x4A04D72: free (vg_replace_malloc.c:325)
> ==6940==    by 0x4CCB5A8: _gfortran_move_alloc (move_alloc.c:41)
> ==6940==    by 0x400B90: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt
> (bug23.f03:238)
> ==6940==    by 0x401449: __psb_d_mat_mod_MOD_psb_d_mv_from (bug23.f03:277)
> ==6940==    by 0x4016C6: MAIN__ (bug23.f03:302)
> ==6940==    by 0x40197A: main (bug23.f03:284)
> ==6940== 
>            1           3           4           5
>            1           1           2           3           0           0       
>    0           0           0           0           0           0
> ==6940== Invalid read of size 8
> ==6940==    at 0x4CC3795: write_float (write_float.def:1050)
> ==6940==    by 0x4CC508C: _gfortrani_write_real (write.c:1470)
> ==6940==    by 0x4CC5BAE: _gfortrani_list_formatted_write (write.c:1561)
> ==6940==    by 0x4CBACA7: _gfortran_transfer_array (transfer.c:2000)
> ==6940==    by 0x401904: MAIN__ (bug23.f03:310)
> ==6940==    by 0x40197A: main (bug23.f03:284)
> ==6940==  Address 0x5141510 is 0 bytes inside a block of size 96 free'd
> ==6940==    at 0x4A04D72: free (vg_replace_malloc.c:325)
> ==6940==    by 0x4CCB5A8: _gfortran_move_alloc (move_alloc.c:41)
> ==6940==    by 0x400BDC: __psb_d_csr_mat_mod_MOD_psb_d_mv_csr_from_fmt
> (bug23.f03:240)
> ==6940==    by 0x401449: __psb_d_mat_mod_MOD_psb_d_mv_from (bug23.f03:277)
> ==6940==    by 0x4016C6: MAIN__ (bug23.f03:302)
> ==6940==    by 0x40197A: main (bug23.f03:284)
> ==6940== 
>    1.0000000000000000        1.0000000000000000        2.0000000000000000      
>  3.0000000000000000        0.0000000000000000        0.0000000000000000       
> 0.0000000000000000        0.0000000000000000        0.0000000000000000       
> 0.0000000000000000        0.0000000000000000        0.0000000000000000     
> ==6940== 
> ==6940== HEAP SUMMARY:
> ==6940==     in use at exit: 0 bytes in 0 blocks
> ==6940==   total heap usage: 33 allocs, 33 frees, 4,938 bytes allocated
> ==6940== 
> ==6940== All heap blocks were freed -- no leaks are possible
> ==6940== 
> ==6940== For counts of detected and suppressed errors, rerun with: -v
> ==6940== ERROR SUMMARY: 28 errors from 2 contexts (suppressed: 6 from 6)
> 


-- 


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

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

[sfilippone at uniroma2 dot it]

------- Comment #1 from sfilippone at uniroma2 dot it  2010-08-30 12:09 -------
Created an attachment (id=21592)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21592&action=view)
test case


-- 


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