[Bug fortran/47085] New: [OOP] Problem in allocate( SOURCE=) for polymorphic component

[Bug fortran/47085] New: [OOP] Problem in allocate( SOURCE=) for polymorphic component

[sfilippone at uniroma2 dot it]

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

           Summary: [OOP] Problem in allocate( SOURCE=)  for polymorphic
                    component
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sfilippone@uniroma2.it


Created attachment 22859
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22859
test case

With trunk at r168261 plus the patch for PR46838 I get the following error when
running under valgrind:
[sfilippo@localhost bug29]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnudev/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-dev/configure --prefix=/usr/local/gnudev
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/gmp
--with-mpfr=/home/travel/GCC/mpfr --with-mpc=/home/travel/GCC/mpc :
(reconfigured) ../gcc-dev/configure --prefix=/usr/local/gnudev
--with-gmp=/home/travel/GCC/gmp --with-mpfr=/home/travel/GCC/mpfr
--with-mpc=/home/travel/GCC/mpc --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20101227 (experimental) (GCC) 
[sfilippo@localhost bug29]$ gfortran -o ppde ppde.f90
[sfilippo@localhost bug29]$ valgrind ./ppde 
==9847== Memcheck, a memory error detector
==9847== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9847== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9847== Command: ./ppde
==9847== 
==9847== Conditional jump or move depends on uninitialised value(s)
==9847==    at 0x400C08: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x4019C7: psb_cdcpy_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401B85: MAIN__ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401BD9: main (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847== 
==9847== Conditional jump or move depends on uninitialised value(s)
==9847==    at 0x400C2E: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x4019C7: psb_cdcpy_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401B85: MAIN__ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401BD9: main (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847== 
==9847== Conditional jump or move depends on uninitialised value(s)
==9847==    at 0x400C51: __copy_psb_gen_block_map_mod_psb_gen_block_map_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x4019C7: psb_cdcpy_ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401B85: MAIN__ (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847==    by 0x401BD9: main (in
/home/sfilippo/NUMERICAL/NewPSBLAS/GNUbugs/bug29/ppde)
==9847== 
==9847== 
==9847== HEAP SUMMARY:
==9847==     in use at exit: 648 bytes in 6 blocks
==9847==   total heap usage: 22 allocs, 16 frees, 4,473 bytes allocated
==9847== 
==9847== LEAK SUMMARY:
==9847==    definitely lost: 0 bytes in 0 blocks
==9847==    indirectly lost: 0 bytes in 0 blocks
==9847==      possibly lost: 0 bytes in 0 blocks
==9847==    still reachable: 648 bytes in 6 blocks
==9847==         suppressed: 0 bytes in 0 blocks
==9847== Rerun with --leak-check=full to see details of leaked memory
==9847== 
==9847== For counts of detected and suppressed errors, rerun with: -v
==9847== Use --track-origins=yes to see where uninitialised values come from
==9847== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 6)


The test case is reduced from a complex application, where the error shows up
as follows:
[sfilippo@localhost runs]$ ./ppde 
Generating Matrix (size=64)...
The matrix has been generated and assembled in CSR format.
-allocation  time :  1.42813E-04
-coeff. gen. time :  3.26872E-04
-assembly    time :  6.09159E-04
-total       time :  1.11485E-03
Overall matrix creation time :  1.47796E-03


Program received signal 11 (SIGSEGV): Segmentation fault.

Backtrace for this error:
  + /lib64/libc.so.6(+0x32970) [0x7fa574efe970]
  + /lib64/libc.so.6(cfree+0x1c) [0x7fa574f462dc]
  + function __copy_psb_gen_block_map_mod_psb_gen_block_map_ (0x4382E6)
    at line 97 of file psb_gen_block_map_mod.f03
  + function psb_cdcpy_ (0x420B06)
    at line 93 of file psb_cdcpy.f90
  + function ppde (0x403E4A)
    at line 82 of file ppde.f90
  + /lib64/libc.so.6(__libc_start_main+0xfd) [0x7fa574eeac5d]

With the reduced test case the segfault is not apparent, but the cause is still
operational.

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.29 22:39:46
     Ever Confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org 2010-12-29 22:39:46 UTC ---
I have reduced the test case quite a bit, while maintaining the valgrind error:


program ppde
  implicit none

  type :: t0
  end type

  type, extends(t0) :: t1
    integer, allocatable :: c(:)
  end type

  class(t0), allocatable :: x, y

  allocate(t1 :: x)
  allocate(y, source=x) 

end


When compiling this with -g and running under valgrind, I get:

==26472== Conditional jump or move depends on uninitialised value(s)
==26472==    at 0x4009B7: __copy_ppde_t1.1550 (ppde.f90:1)
==26472==    by 0x400AD1: MAIN__ (ppde.f90:16)
==26472==    by 0x400B74: main (ppde.f90:16)

This means the error happens inside the copying routine of the extended type,
and seems to be related to the allocatable component. In the original test case
the error message appeared in a triple, because three allocatable components
were involved. This is the same issue as described in PR 46408.

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org 2010-12-29 22:44:26 UTC ---
While reducing the test case I noticed that the following invalid code triggers
an ICE:


  type :: t0
  end type
  class(t0) :: x
  allocate(x)
  end


Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000520e06 in gfc_match_varspec (primary=0x1939130, equiv_flag=0,
sub_flag=0 '\000', ppc_arg=0 '\000') at
/home/jweil/gcc46/trunk/gcc/fortran/primary.c:1777
1777          || (sym->ts.type == BT_CLASS && CLASS_DATA
(sym)->attr.dimension))
(gdb) bt
#0  0x0000000000520e06 in gfc_match_varspec (primary=0x1939130, equiv_flag=0,
sub_flag=0 '\000', ppc_arg=0 '\000') at
/home/jweil/gcc46/trunk/gcc/fortran/primary.c:1777
#1  0x0000000000523b56 in match_variable (result=0x192eb80, equiv_flag=0,
host_flag=1) at /home/jweil/gcc46/trunk/gcc/fortran/primary.c:3104
#2  0x0000000000523bac in gfc_match_variable (result=0x192eb80, equiv_flag=0)
at /home/jweil/gcc46/trunk/gcc/fortran/primary.c:3119
#3  0x0000000000503697 in gfc_match_allocate () at
/home/jweil/gcc46/trunk/gcc/fortran/match.c:2908

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2010-12-30 11:53:40 UTC ---
Author: janus
Date: Thu Dec 30 11:53:35 2010
New Revision: 168340

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

    PR fortran/47085
    * match.c (gfc_match_allocate): Check for 'class_ok'.
    * primary.c (gfc_match_varspec): Ditto.


2010-12-30  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/47085
    * gfortran.dg/allocate_class_1.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_class_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/47085] [OOP] Problem in allocate( SOURCE=) for polymorphic component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #4 from janus at gcc dot gnu.org 2011-01-02 17:51:39 UTC ---
With the ICE-on-invalid problem solved, this is really just a duplicate of
PR46408.

*** This bug has been marked as a duplicate of bug 46408 ***