[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

2016-01-17 Thread pault at gcc dot gnu.org
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

2015-07-22 Thread mikael at gcc dot gnu.org
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

2015-07-21 Thread mikael at gcc dot gnu.org
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

2015-07-21 Thread mikael at gcc dot gnu.org
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

2015-07-21 Thread dominiq at lps dot ens.fr
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

2015-07-18 Thread ubizjak at gmail dot com
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

2015-07-18 Thread mikael at gcc dot gnu.org
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

2015-07-18 Thread mikael at gcc dot gnu.org
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

2015-07-17 Thread ubizjak at gmail dot com
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

2015-07-17 Thread mikael at gcc dot gnu.org
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

2015-07-17 Thread dominiq at lps dot ens.fr
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

2015-07-17 Thread mikael at gcc dot gnu.org
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

2015-06-26 Thread jakub at gcc dot gnu.org
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

2015-06-26 Thread jakub at gcc dot gnu.org
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

2015-05-22 Thread mikael at gcc dot gnu.org
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

2015-04-17 Thread dominiq at lps dot ens.fr
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

2015-04-16 Thread dominiq at lps dot ens.fr
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

2015-03-03 Thread mikael at gcc dot gnu.org
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

2015-02-27 Thread dominiq at lps dot ens.fr
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

2015-02-23 Thread mikael at gcc dot gnu.org
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

2015-02-23 Thread mikael at gcc dot gnu.org
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

2015-02-23 Thread mikael at gcc dot gnu.org
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

2015-02-22 Thread mikael at gcc dot gnu.org
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

2015-02-14 Thread mikael at gcc dot gnu.org
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

2015-02-14 Thread dominiq at lps dot ens.fr
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

2015-01-25 Thread mikael at gcc dot gnu.org
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

2015-01-22 Thread dominiq at lps dot ens.fr
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

2014-11-24 Thread rguenth at gcc dot gnu.org
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

2014-11-19 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3