[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have opened pr57762 for the memory leak reported in comments #2 and #3 (with the right bracketing this time).
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 55482 has been marked as a duplicate of this bug. ***
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to janus from comment #1) allocate (extended_type :: a(2)) a._data.data = (void * restrict) __builtin_malloc (8); The allocation size seems to be independent of whether one allocates with base_type or extended type. (In reply to Dominique d'Humieres from comment #3) This seems to have been fixed [...] revision 199528? Yes, it has been fixed by the patch for PR57456, r199528 - Close as FIXED.
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-06-27 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I no longer see the valgrind error at revision 200078 (clean tree). Can this be confirmed? On my working tree (r200429, several patches) using valgrind with --leak-check=full gives ==85435== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==85435==at 0x100013679: malloc (vg_replace_malloc.c:266) ==85435==by 0x11358: __realloc_MOD_reallocate (class_array_7.f03:31) ==85435==by 0x119C6: MAIN__ (class_array_7.f03:55) ==85435==by 0x11B5B: main (class_array_7.f03:49) (no error without --leak-check=full). Investigating.
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This seems to have been fixed between revision 199435 (2013-05-30) and revision 199885 (2013-06-03): revision 199528? The error ==15298== 80 bytes in 1 blocks are definitely lost in loss record 1 of 2 ==15298==at 0x100013679: malloc (vg_replace_malloc.c:266) ==15298==by 0x11358: __realloc_MOD_reallocate (class_array_7.f03:31) ==15298==by 0x119C6: MAIN__ (class_array_7.f03:55) ==15298==by 0x11B5B: main (class_array_7.f03:49) appeared between revisions 200350 (2013-06-23) with the patch of revision 200361 and a clean revision 200361 (2013-06-24). Could it be caused by revision 200360?
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2013-03-13 14:17:40 UTC --- Reduced test case: program main implicit none type :: base_type integer :: i end type type, extends(base_type) :: extended_type integer :: j end type class(base_type), dimension(:), allocatable :: a type(extended_type), dimension(1:2) :: tmp allocate (extended_type :: a(2)) tmp%i=a%i end I think the problem is in the allocate statement: a._data.data = (void * restrict) __builtin_malloc (8); The allocation size seems to be independent of whether one allocates with base_type or extended type.
