[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #60 from Paul Thomas --- Author: pault Date: Sun Jan 17 17:34:12 2016 New Revision: 232482 URL: https://gcc.gnu.org/viewcvs?rev=232482&root=gcc&view=rev Log: 2016-01-17 Mikael Morin Backport from trunk. PR fortran/61831 * gfortran.dg/derived_constructor_components_6.f90: New file. * gfortran.dg/allocate_with_source_14.f03: Change count of __builtin_malloc from 21 to 23. 2016-01-17 Paul Thomas Backport from trunk. PR fortran/66082 * gfortran.dg/alloc_comp_auto_array_3.f90: New file. Count of __builtin_malloc increased from 3 to 4, relative to trunk. 2016-01-17 Mikael Morin Dominique d'Humieres Backport from trunk. PR fortran/61831 * trans-array.c (gfc_conv_array_parameter): Guard allocatable component deallocation code generation with descriptorless calling convention flag. * trans-expr.c (gfc_conv_expr_reference): Remove allocatable component deallocation code generation from revision 212329. (expr_may_alias_variables): New function. (gfc_conv_procedure_call): New boolean elemental_proc to factor check for procedure elemental-ness. Rename boolean f to nodesc_arg and declare it in the outer scope. Use expr_may_alias_variables, elemental_proc and nodesc_arg to decide whether generate allocatable component deallocation code. (gfc_trans_subarray_assign): Set deep copy flag. 2016-01-17 Paul Thomas Backport from trunk. PR fortran/66082 * trans-array.c (gfc_conv_array_parameter): Ensure that all non-variable arrays with allocatable components have the components deallocated after the procedure call. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90 branches/gcc-5-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/trans-array.c branches/gcc-5-branch/gcc/fortran/trans-expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #59 from Mikael Morin --- Author: mikael Date: Wed Jul 22 15:26:52 2015 New Revision: 226074 URL: https://gcc.gnu.org/viewcvs?rev=226074&root=gcc&view=rev Log: Fix r225926's iso_varying_string ICE regression PR fortran/61831 PR fortran/66929 gcc/fortran/ * trans-array.c (gfc_get_proc_ifc_for_expr): Use esym as procedure symbol if available. gcc/testsuite/ * gfortran.dg/generic_30.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/generic_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #58 from Mikael Morin --- Author: mikael Date: Tue Jul 21 11:33:15 2015 New Revision: 226038 URL: https://gcc.gnu.org/viewcvs?rev=226038&root=gcc&view=rev Log: Fix r225926's broken testcase gcc/testsuite/ PR fortran/61831 * gfortran.dg/derived_constructor_comps_6.f90: Fix dg directive. Drop address sanitization. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #57 from Mikael Morin --- Author: mikael Revision: 225926 Modified property: svn:log Modified: svn:log at Tue Jul 21 10:07:29 2015 -- --- svn:log (original) +++ svn:log Tue Jul 21 10:07:29 2015 @@ -24,5 +24,5 @@ PR fortran/61831 * gfortran.dg/alloc_comp_auto_array_3.f90: Count the number of generated while loops in the tree dump. - * gfortran.dg/derived_constructor_components_6.f90: New file. + * gfortran.dg/derived_constructor_comps_6.f90: New file.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #56 from Dominique d'Humieres ---
BTW there is a typo in gfortran.dg/derived_constructor_comps_6.f90 which leads
to several
UNRESOLVED: gfortran.dg/derived_constructor_comps_6.f90 -O*
scan-tree-dump-times original "__builtin_free" 33
UNRESOLVED: gfortran.dg/derived_constructor_comps_6.f90 -O*
scan-tree-dump-times original "__builtin_malloc" 15
This is fixed by the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
2015-07-17 12:24:40.0 +0200
+++ gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90 2015-07-18
12:12:26.0 +0200
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-additional-options "-fsanitize=address -fdump-tree-original"
+! { dg-additional-options "-fsanitize=address -fdump-tree-original" }
!
! PR fortran/61831
! The deallocation of components of array constructor elements
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #55 from Uroš Bizjak --- (In reply to Mikael Morin from comment #54) > (In reply to Uroš Bizjak from comment #52) > > There is another PR that seems related, PR 64986. > > Is it? I see no ICE there. > Oh, you mean related to this original bug, not the regression of comment#50? Yes, to the original bug, problems with calling free.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #54 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #50) > Should I file a new PR? I opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929 (In reply to Uroš Bizjak from comment #52) > There is another PR that seems related, PR 64986. Is it? I see no ICE there. Oh, you mean related to this original bug, not the regression of comment#50?
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #53 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #50) > Compiling the original test of pr40440 after revision r225926 gives an ICE: > You can try: Index: trans-array.c === --- trans-array.c (révision 225979) +++ trans-array.c (copie de travail) @@ -9166,7 +9166,11 @@ gfc_get_proc_ifc_for_expr (gfc_expr *procedure_ref return NULL; /* Normal procedure case. */ - sym = procedure_ref->symtree->n.sym; + if (procedure_ref->expr_type == EXPR_FUNCTION + && procedure_ref->value.function.esym) +sym = procedure_ref->value.function.esym; + else +sym = procedure_ref->symtree->n.sym; /* Typebound procedure case. */ for (ref = procedure_ref->ref; ref; ref = ref->next)
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #52 from Uroš Bizjak --- (In reply to Mikael Morin from comment #51) > (In reply to Dominique d'Humieres from comment #50) > > Should I file a new PR? > > Yes, please. > Two commits today, two regressions. There is another PR that seems related, PR 64986.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #51 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #50) > Should I file a new PR? Yes, please. Two commits today, two regressions.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #50 from Dominique d'Humieres --- Compiling the original test of pr40440 after revision r225926 gives an ICE: [Book15] f90/bug% gfcp pr40440.f90 iso_varying_string.o pr40440.f90:69:0: call ifile_append_from_string (ifile, var_str (trim (char))) 1 internal compiler error: Segmentation fault: 11 A variant that does not require iso_varying_string ICE with pr40440_2.f90:2456:0: rep_string = substring//extract(work_string, start=i_target+length_target)//rep_string 1 internal compiler error: Segmentation fault: 11 Should I file a new PR?
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #49 from Mikael Morin --- Author: mikael Date: Fri Jul 17 09:40:29 2015 New Revision: 225926 URL: https://gcc.gnu.org/viewcvs?rev=225926&root=gcc&view=rev Log: Fix PR61831: Side-effect variable component deallocation gcc/fortran/ 2015-07-17 Mikael Morin Dominique d'Humieres PR fortran/61831 * trans-array.c (gfc_conv_array_parameter): Guard allocatable component deallocation code generation with descriptorless calling convention flag. * trans-expr.c (gfc_conv_expr_reference): Remove allocatable component deallocation code generation from revision 212329. (expr_may_alias_variables): New function. (gfc_conv_procedure_call): New boolean elemental_proc to factor check for procedure elemental-ness. Rename boolean f to nodesc_arg and declare it in the outer scope. Use expr_may_alias_variables, elemental_proc and nodesc_arg to decide whether generate allocatable component deallocation code. (gfc_trans_subarray_assign): Set deep copy flag. gcc/testsuite/ 2015-07-17 Mikael Morin PR fortran/61831 * gfortran.dg/alloc_comp_auto_array_3.f90: Count the number of generated while loops in the tree dump. * gfortran.dg/derived_constructor_components_6.f90: New file. Added: trunk/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Jakub Jelinek changed: What|Removed |Added Target Milestone|4.9.3 |4.9.4
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #48 from Jakub Jelinek --- GCC 4.9.3 has been released.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Mikael Morin changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #47 from Mikael Morin --- Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01491.html
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #46 from Dominique d'Humieres --- > > And I haven't looked yet at Dominique's feedback in comment #43. > > The test in comment #41 fails at run time when compiled with > -fsanitize=address. > If I take the "complement" of the reduced test posted in comment #43, > everything works fine, but for one builtin_free less. > > I did not investigated what is wrong with the test in comment #43 (will do). The problem occurs even with a clean tree. I have filed PR65792 for it. The test in comment 41 runs without error if compiled with -fsanitize=address and no valgrind error if I remove/comment the lines 58 and 62: tmpc = new_prt_spec2 (string_container_t(prt_in)) and deallocate(tmpc%comp%chars) > The patch (without the above hunk) fixes a lot of problems and makes > the code simpler. IMO it should be submitted and the few left issues > can be deferred (with new PRs). I have bootstrapper 4.9.3 with the patch and I am currently regtesting gfortran. I am planing to do that same for 5.0.1.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #45 from Dominique d'Humieres --- > Created attachment 34942 [details] > Better patch Sorry for the delay, but I noticed this new patch only yesterday!-( > I'm not working on this, so I'm attaching the current patch in my work tree, > before it's lost. With this patch there is no memory leak gfortran.dg/alloc_comp_constructor_1.f90 (19 builtin_free) and gfortran.dg/class_array_15.f03 (12 builtin_free). > If I remember correctly, the patch passes the testsuite without regressing. With this patch I see a regression for gfortran.dg/alloc_comp_assign_10.f90. > The test in comment #41 exhibits some leaks with it though. With the patch I see 33 builtin_free instead of 34 without the patch. > And I haven't looked yet at Dominique's feedback in comment #43. The test in comment #41 fails at run time when compiled with -fsanitize=address. If I take the "complement" of the reduced test posted in comment #43, everything works fine, but for one builtin_free less. I did not investigated what is wrong with the test in comment #43 (will do). > Oh, and I have to double check that the gfc_trans_subarray_assign hunk > is really necessary. If you are speaking of the hunk @@ -6263,7 +6283,7 @@ gfc_trans_subarray_assign (tree dest, gfc_componen gfc_conv_expr (&rse, expr); - tmp = gfc_trans_scalar_assign (&lse, &rse, cm->ts, true, false, true); + tmp = gfc_trans_scalar_assign (&lse, &rse, cm->ts, true, true, true); gfc_add_expr_to_block (&body, tmp); gcc_assert (rse.ss == gfc_ss_terminator); I think it is needed, otherwise the test in comment #41 fails at run time with a.out(89696,0x7fff74744300) malloc: *** mach_vm_map(size=18446603338973675520) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. However the hunk @@ -4990,7 +5010,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * tmp = gfc_deallocate_alloc_comp (e->ts.u.derived, tmp, parm_rank); - gfc_add_expr_to_block (&se->post, tmp); + gfc_prepend_expr_to_block (&se->post, tmp); } /* Add argument checking of passing an unallocated/NULL actual to does not seems necessary, but is the cause of the regression, i.e., no regression without it. The patch (without the above hunk) fixes a lot of problems and makes the code simpler. IMO it should be submitted and the few left issues can be deferred (with new PRs).
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #44 from Mikael Morin --- Created attachment 34942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34942&action=edit Better patch I'm not working on this, so I'm attaching the current patch in my work tree, before it's lost. If I remember correctly, the patch passes the testsuite without regressing. The test in comment #41 exhibits some leaks with it though. And I haven't looked yet at Dominique's feedback in comment #43. Oh, and I have to double check that the gfc_trans_subarray_assign hunk is really necessary.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #43 from Dominique d'Humieres --- > The testcase passes with it, at the price of leaking memory Yes: gfortran.dg/alloc_comp_constructor_1.f90 (17 builtin_free instead of 19) and gfortran.dg/class_array_15.f03 (11 builtin_free instead of 12). I think to fix this PR without memory leak one has to avoid to free the temporary for elemental procs For the reduced test program main implicit none integer, parameter :: n = 2 type :: string_t character(LEN=1), dimension(:), allocatable :: chars end type string_t type :: string_container_t type(string_t) :: comp end type string_container_t type :: string_array_container_t type(string_t) :: comp(n) end type string_array_container_t type(string_t) :: prt_in, tmp, tmpa(n) type(string_container_t) :: tmpc, tmpca(n) type(string_array_container_t) :: tmpac, tmpaca(n) integer :: i, j, k do i=1,16 ! Test without intermediary function prt_in = string_t(["A"]) if (.not. allocated(prt_in%chars)) call abort if (any(prt_in%chars .ne. "A")) call abort deallocate (prt_in%chars) ! scalar elemental function with structure constructor prt_in = string_t(["D"]) if (.not. allocated(prt_in%chars)) call abort if (any(prt_in%chars .ne. "D")) call abort tmpc = new_prt_spec2 (string_container_t(prt_in)) if (.not. allocated(prt_in%chars)) call abort if (any(prt_in%chars .ne. "D")) call abort deallocate (prt_in%chars) deallocate(tmpc%comp%chars) end do contains elemental function new_prt_spec2 (name) result (prt_spec) type(string_container_t), intent(in) :: name type(string_container_t) :: prt_spec prt_spec = name end function new_prt_spec2 end program main I also see at run time (with/without the patch in comment 42) a.out(69499,0x7fff748b3300) malloc: *** mach_vm_map(size=18446603339087888384) failed (error code=3) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x10a9e4c62 #1 0x10a9e3f80 #2 0x7fff8de21f19 Segmentation fault
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #42 from Mikael Morin ---
(In reply to Mikael Morin from comment #41)
> My work patch is:
updated work patch below.
The testcase passes with it, at the price of leaking memory
Index: trans-expr.c
===
--- trans-expr.c(révision 220717)
+++ trans-expr.c(copie de travail)
@@ -4949,7 +4949,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
if (e && (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS)
&& e->ts.u.derived->attr.alloc_comp
&& !(e->symtree && e->symtree->n.sym->attr.pointer)
-&& (e->expr_type != EXPR_VARIABLE && !e->rank))
+&& (e->expr_type != EXPR_VARIABLE
+&& e->expr_type != EXPR_STRUCTURE && !e->rank))
{
int parm_rank;
tmp = build_fold_indirect_ref_loc (input_location,
@@ -7131,7 +7132,8 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * e
if (expr->ts.type == BT_DERIVED && expr->rank
&& !gfc_is_finalizable (expr->ts.u.derived, NULL)
&& expr->ts.u.derived->attr.alloc_comp
- && expr->expr_type != EXPR_VARIABLE)
+ && expr->expr_type != EXPR_VARIABLE
+ && expr->expr_type != EXPR_ARRAY)
{
tree tmp;
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #41 from Mikael Morin ---
Created attachment 34846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34846&action=edit
extended testcase
My work patch is:
Index: trans-expr.c
===
--- trans-expr.c(révision 220717)
+++ trans-expr.c(copie de travail)
@@ -7131,7 +7131,8 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * e
if (expr->ts.type == BT_DERIVED && expr->rank
&& !gfc_is_finalizable (expr->ts.u.derived, NULL)
&& expr->ts.u.derived->attr.alloc_comp
- && expr->expr_type != EXPR_VARIABLE)
+ && expr->expr_type != EXPR_VARIABLE
+ && expr->expr_type != EXPR_ARRAY)
{
tree tmp;
It fails with the above testcase at line 80.
ptr_in in simple-copied twice to elements of an array, which is itself copied
to the temporary structure of the structure constructor.
After using the latter, the temporary structure cleanup code frees ptr_in
(twice).
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #40 from Mikael Morin --- (In reply to Mikael Morin from comment #39) > A function will do a deep copy, so I think the only problematic cases are > EXPR_ARRAY, and maybe EXPR_STRUCTURE. EXPR_STRUCTURE deep-copy variable components, and simple-copy non-variables.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #39 from Mikael Morin --- (In reply to Mikael Morin from comment #38) > By the way, I'm not sure that it's at all correct to avoid deep copies. This seems to be safe: as long as the procedure is pure, there is no way it can modify its input data. > It's an artefact of temporary management which on one hand avoids deep > copies, but on the other hand frees allocated components as for a regular > object, as if a deep copy had happened before. So, the problem is limited to derived types, which basically come from expressions of type EXPR_FUNCTION (or its variants EXPR_PPC, EXPR_COMPCALL), EXPR_ARRAY, and EXPR_STRUCTURE. A function will do a deep copy, so I think the only problematic cases are EXPR_ARRAY, and maybe EXPR_STRUCTURE.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #38 from Mikael Morin ---
(In reply to Dominique d'Humieres from comment #37)
> > >[...]
> > >if (D.3430.chars.data != 0B)
> > > {
> > >__builtin_free ((void *) D.3430.chars.data);
> > > }
> > >D.3430.chars.data = 0B;
> >
> > D.3430.chars.data is freed.
> >
> > So every iteration of the do loop has the side-effect of freeing
> > prt_in.chars.data.
>
> Could you please give me a pointer to the code emitting this side-effect?
The code you quoted (the call to free) comes from:
#0 gfc_deallocate_with_status at fortran/trans.c:1279
#1 gfc_trans_dealloc_allocated at fortran/trans-array.c:7428
#2 structure_alloc_comps at fortran/trans-array.c:7760
#3 gfc_deallocate_alloc_comp at fortran/trans-array.c:8060
#4 gfc_conv_expr_reference at fortran/trans-expr.c:7139
#5 gfc_conv_procedure_call at fortran/trans-expr.c:4360
#6 gfc_conv_function_expr at fortran/trans-expr.c:6974
#8 gfc_trans_assignment_1 at /fortran/trans-expr.c:8710
#9 trans_code at fortran/trans.c:1650
#10 gfc_trans_code_cond at fortran/trans.c:1946
#11 gfc_trans_simple_do at fortran/trans-stmt.c:1540
#12 gfc_trans_do at fortran/trans-stmt.c:1703
#13 trans_code at fortran/trans.c:1759
#14 gfc_trans_code at fortran/trans.c:1954
#15 gfc_generate_function_code at fortran/trans-decl.c:5842
#16 gfc_generate_code at fortran/trans.c:1971
#17 translate_all_program_units at fortran/parse.c:5341
#18 gfc_parse_file at fortran/parse.c:5538
#19 gfc_be_parse_file at fortran/f95-lang.c:228
#20 compile_file at toplev.c:594
#21 do_compile at toplev.c:2066
#22 toplev::main at toplev.c:2164
#23 main at main.c:39
However, it's not clear to me where the bug comes from, or at least where the
fix should go.
It's an artefact of temporary management which on one hand avoids deep copies,
but on the other hand frees allocated components as for a regular object, as if
a deep copy had happened before.
By the way, I'm not sure that it's at all correct to avoid deep copies.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #37 from Dominique d'Humieres ---
> >[...]
> >if (D.3430.chars.data != 0B)
> > {
> >__builtin_free ((void *) D.3430.chars.data);
> > }
> >D.3430.chars.data = 0B;
>
> D.3430.chars.data is freed.
>
> So every iteration of the do loop has the side-effect of freeing
> prt_in.chars.data.
Could you please give me a pointer to the code emitting this side-effect?
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #36 from Mikael Morin ---
>[...]
> (*(struct string_t[1] * restrict) atmp.7.data)[0] = prt_in;
prt_in.chars.data is copied to atmp.7.data[0].
>[...]
>while (1)
> {
>[...]
>D.3430 = (*(struct string_t[1] * restrict) atmp.7.data)[S.10];
atmp.7.data[0].chars.data is copied to D.3430
>[...]
>if (D.3430.chars.data != 0B)
> {
>__builtin_free ((void *) D.3430.chars.data);
> }
>D.3430.chars.data = 0B;
D.3430.chars.data is freed.
So every iteration of the do loop has the side-effect of freeing
prt_in.chars.data.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #35 from Dominique d'Humieres ---
I see three possibilities for this PR:
(1) Revert r211405 for 5.0 and r212329 for 4.9.
(2) Understand why elemental procedures expose the problem when expr->expr_type
== EXPR_ARRAY.
(3) Apply the conservative patch
--- ../4.9_clean/gcc/fortran/trans-expr.c2014-10-04 12:59:45.0
+0200
+++ ../4.9_work/gcc/fortran/trans-expr.c2014-10-04 13:11:36.0 +0200
@@ -6475,7 +6475,7 @@ gfc_conv_expr_reference (gfc_se * se, gf
if (expr->ts.type == BT_DERIVED && expr->rank
&& !gfc_is_finalizable (expr->ts.u.derived, NULL)
&& expr->ts.u.derived->attr.alloc_comp
- && expr->expr_type != EXPR_VARIABLE)
+ && expr->expr_type == EXPR_FUNCTION)
{
tree tmp;
--- ../4.9_clean/gcc/testsuite/gfortran.dg/class_array_15.f032014-07-07
14:33:14.0 +0200
+++ ../4.9_work/gcc/testsuite/gfortran.dg/class_array_15.f032014-11-08
14:26:21.0 +0100
@@ -115,5 +115,5 @@ subroutine pr54992 ! This test remains
bh => bhGet(b,instance=2)
if (loc (b) .ne. loc(bh%hostNode)) call abort
end
-! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" } }
+! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" { xfail *-*-*
} } }
! { dg-final { cleanup-tree-dump "original" } }
I am not fond of (1).
For (2) I need some help. So far the problem has been looked from the 'if'
block point of view. It may be easier to look at the alloc/free machinery
handling elemental.
I think (3) is probably the best solution for 4.9. What I have not done so far
is a test to check this PR, e.g., the test in comment 31, a test for pr41936,
and open a new PR for the memory leak in gfortran.dg/class_array_15.f03.
Feedback welcomed.
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Known to fail|4.10.0 |5.0
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.3
