[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #19 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Mikael Morin from comment #18) The patches have been committed. I mean the (single) patch has been committed on the two branches.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #17 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sat Jul 25 18:51:23 2015 New Revision: 226224 URL: https://gcc.gnu.org/viewcvs?rev=226224root=gccview=rev Log: Fix gfortran.dg/class_to_type_4.f90 deallocation code misordering failure PR fortran/64986 gcc/fortran/ * trans-expr.c (gfc_trans_assignment_1): Put component deallocation code at the beginning of the block. Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-expr.c
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #11) Yes, this fixes the testsuite failure for me. For me too. The patches have been committed. I assume the problem is fixed now.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #15 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Jul 24 14:44:59 2015 New Revision: 226162 URL: https://gcc.gnu.org/viewcvs?rev=226162root=gccview=rev Log: Fix gfortran.dg/class_to_type_4.f90 deallocation code misordering failure PR fortran/64986 gcc/fortran/ * trans-expr.c (gfc_trans_assignment_1): Put component deallocation code at the beginning of the block. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #14 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #13) A good principle in general is to assume cock-up, rather than conspiracy :-) The reason for this spreading between two functions is incremental development done at very different times. If you can see a way to rationalize the implementation, please do it. All right. Well, as a first move, I will just commit the patch. :-)
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #16 from Mikael Morin mikael at gcc dot gnu.org --- I may as well take the bug.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #13 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Dear Mikael, A good principle in general is to assume cock-up, rather than conspiracy :-) The reason for this spreading between two functions is incremental development done at very different times. If you can see a way to rationalize the implementation, please do it. Many thanks for the patch - assume that it is OK for trunk and 5.x Paul On 22 July 2015 at 18:24, mikael at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) The test has been introduced at revision r220482, That revision adds interesting comments: /* For a function with a class array result, save the result as a temporary, set the info fields needed by the scalarizer and call the finalization function of the temporary. Note that the nullification of allocatable components needed by the result is done in gfc_trans_assignment_1. */ and in gfc_trans_assignment_1, there is: /* Nullify the allocatable components corresponding to those of the lhs derived type, so that the finalization of the function result does not affect the lhs of the assignment. Prepend is used to ensure that the nullification occurs before the call to the finalizer. So, if finalization for derived types with allocatable components means freeing the allocatable components, the above is more or less a justification for the patch in comment #9. What I don't understand is why there is need for two functions gfc_conv_procedure_call and gfc_trans_assignment_1 doing half of the job, and why deallocation of components, deallocation of whole allocatable and finalization are not handled all at once in a single place. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #12 from Mikael Morin mikael at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #6) The test has been introduced at revision r220482, That revision adds interesting comments: /* For a function with a class array result, save the result as a temporary, set the info fields needed by the scalarizer and call the finalization function of the temporary. Note that the nullification of allocatable components needed by the result is done in gfc_trans_assignment_1. */ and in gfc_trans_assignment_1, there is: /* Nullify the allocatable components corresponding to those of the lhs derived type, so that the finalization of the function result does not affect the lhs of the assignment. Prepend is used to ensure that the nullification occurs before the call to the finalizer. So, if finalization for derived types with allocatable components means freeing the allocatable components, the above is more or less a justification for the patch in comment #9. What I don't understand is why there is need for two functions gfc_conv_procedure_call and gfc_trans_assignment_1 doing half of the job, and why deallocation of components, deallocation of whole allocatable and finalization are not handled all at once in a single place.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #11 from Dominique d'Humieres dominiq at lps dot ens.fr --- Yes, this fixes the testsuite failure for me. For me too.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Mikael Morin from comment #9) The components are deallocated after the containing object. Draft patch: Yes, this fixes the testsuite failure for me.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #9 from Mikael Morin mikael at gcc dot gnu.org ---
The components are deallocated after the containing object.
Draft patch:
Index: trans-expr.c
===
--- trans-expr.c(révision 225979)
+++ trans-expr.c(copie de travail)
@@ -9241,7 +9241,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr
if (scalar_to_array dealloc)
{
tmp = gfc_deallocate_alloc_comp_no_caf (expr2-ts.u.derived, rse.expr,
0);
- gfc_add_expr_to_block (loop.post, tmp);
+ gfc_prepend_expr_to_block (loop.post, tmp);
}
/* When assigning a character function result to a deferred-length variable,
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2015-02-13 00:00:00 |2015-4-16 --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org --- I still see this FAIL for cris-elf on trunk at r222131. While it is a regression on trunk and the gcc-5-branch (as mentioned it worked for a brief period on trunk before the branch), it's not a regression compared to a release, AFAIK. I verified that it ICEs also (as described on trunk before the first fix) on the 4.9-branch.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- JFTR: starting with a revision in the range (221618:221635] this fails somewhat similarly for cris-elf; the simulator reports an invalid memory access (any optimization level, different addresses) like so: The test has been introduced at revision r220482, compiling it with an earlier revision gives an ICE and I get the valgrind errors with r220509.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- Further reduced test: program test implicit none type t integer :: ii end type t type, extends(t) :: v real, allocatable :: rr(:) end type v type(v) :: b(3) b = func7() ! scalar daughter type to array - alloc comps in parent type contains function func7() result(res) class(v), allocatable :: res allocate (res, source = v(3,[10.0,20.0])) end function func7 end program test
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org --- JFTR: starting with a revision in the range (221618:221635] this fails somewhat similarly for cris-elf; the simulator reports an invalid memory access (any optimization level, different addresses) like so: PASS: gfortran.dg/class_to_type_4.f90 -O0 (test for excess errors) core: 4 byte read to unmapped address 0x63af0 at 0x2080c program stopped with signal 11 (Segmentation fault). FAIL: gfortran.dg/class_to_type_4.f90 -O0 execution test
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test program test implicit none type t integer :: ii end type t type, extends(t) :: u real :: rr end type u type, extends(t) :: v real, allocatable :: rr(:) end type v type, extends(v) :: w real, allocatable :: rrr(:) end type w type(v) :: b(3) b = func7() ! scalar daughter type to array - alloc comps in parent type contains function func7() result(res) class(v), allocatable :: res allocate (res, source = w(3,[10.0,20.0],[100,200])) end function func7 end program test There is no problem with the original test once the following lines are commented b = func7() ! scalar daughter type to array - alloc comps in parent type if (any (b(2)%rr .ne. [10.0,20.0])) call abort
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compelling the test with -fsanitize=address leads to an error at run time.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 --- Comment #3 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- Dear Uros and Dominique, I'll try to get to this when I can. I have a horrible feeling that it is the old problem of array constructors within array constructors all of which are allocatable components. I have stared and stared at this one and have not found the fault. All the best Paul PS I have marked the message as being 'unread' as a reminder :-) On 13 February 2015 at 11:37, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-13 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Compelling the test with -fsanitize=address leads to an error at run time. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug fortran/64986] class_to_type_4.f90: valgrind error: Invalid read/write of size 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64986 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- The testcase is from PR63205, CC author.
