Re: [Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

[Paul Richard Thomas]

Hi Steve,

Thanks - Committed as revision 228940.

I'll commit to 5 branch next Sunday.

Cheers

Paul


On 17 October 2015 at 22:51, Steve Kargl
 wrote:
> On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote:
>>
>> I was moved by a report on clf of memory leaks in move_alloc to
>> investigate the cause. This turned out to be trivial but led to the
>> above PRs, which themselves were trivial. The result is the attached
>> patch. I am aware that I have not investigated the further
>> ramifications that I can imagine are there. Rather, I thought just to
>> fix the reported problems.
>>
>> It should be noted that there is no PR directly associated with the
>> memory leaks. Since the standard does not require this, I did not
>> think that it was worthwhile to raise a PR and then close it!
>>
>> Bootstraps and regtests on FC21/x86_64 - OK for trunk? ... and 5.2
>> after a decent interval?
>
> OK.
>
> --
> steve



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

[Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

[Paul Richard Thomas]

Dear All,

I was moved by a report on clf of memory leaks in move_alloc to
investigate the cause. This turned out to be trivial but led to the
above PRs, which themselves were trivial. The result is the attached
patch. I am aware that I have not investigated the further
ramifications that I can imagine are there. Rather, I thought just to
fix the reported problems.

It should be noted that there is no PR directly associated with the
memory leaks. Since the standard does not require this, I did not
think that it was worthwhile to raise a PR and then close it!

Bootstraps and regtests on FC21/x86_64 - OK for trunk? ... and 5.2
after a decent interval?

Cheers

Paul

2015-10-17  Paul Thomas  

PR fortran/67177
PR fortran/67977
* primary.c (match_substring): Add an argument 'deferred' to
flag that a substring reference with null start and end should
not be optimized away for deferred length strings.
(match_string_constant, gfc_match_rvalue): Set the argument.
* trans-expr.c (alloc_scalar_allocatable_for_assignment): If
there is a substring reference return.
* trans-intrinsic.c (conv_intrinsic_move_alloc): For deferred
characters, assign the 'from' string length to the 'to' string
length. If the 'from' expression is deferred, set its string
length to zero. If the 'to' expression has allocatable
components, deallocate them.

2015-10-17  Paul Thomas  

PR fortran/67177
* gfortran.dg/move_alloc_15.f90: New test
* gfortran.dg/move_alloc_16.f90: New test

PR fortran/67977
* gfortran.dg/deferred_character_assignment_1.f90: New test
Index: gcc/fortran/primary.c
===
*** gcc/fortran/primary.c   (revision 228849)
--- gcc/fortran/primary.c   (working copy)
*** cleanup:
*** 800,806 
  /* Match a substring reference.  */
  
  static match
! match_substring (gfc_charlen *cl, int init, gfc_ref **result)
  {
gfc_expr *start, *end;
locus old_loc;
--- 800,806 
  /* Match a substring reference.  */
  
  static match
! match_substring (gfc_charlen *cl, int init, gfc_ref **result, bool deferred)
  {
gfc_expr *start, *end;
locus old_loc;
*** match_substring (gfc_charlen *cl, int in
*** 852,858 
  }
  
/* Optimize away the (:) reference.  */
!   if (start == NULL && end == NULL)
  ref = NULL;
else
  {
--- 852,858 
  }
  
/* Optimize away the (:) reference.  */
!   if (start == NULL && end == NULL && !deferred)
  ref = NULL;
else
  {
*** got_delim:
*** 1150,1156 
if (ret != -1)
  gfc_internal_error ("match_string_constant(): Delimiter not found");
  
!   if (match_substring (NULL, 0, >ref) != MATCH_NO)
  e->expr_type = EXPR_SUBSTRING;
  
*result = e;
--- 1150,1156 
if (ret != -1)
  gfc_internal_error ("match_string_constant(): Delimiter not found");
  
!   if (match_substring (NULL, 0, >ref, false) != MATCH_NO)
  e->expr_type = EXPR_SUBSTRING;
  
*result = e;
*** check_substring:
*** 2133,2139 
  
if (primary->ts.type == BT_CHARACTER)
  {
!   switch (match_substring (primary->ts.u.cl, equiv_flag, ))
{
case MATCH_YES:
  if (tail == NULL)
--- 2133,2140 
  
if (primary->ts.type == BT_CHARACTER)
  {
!   bool def = primary->ts.deferred == 1;
!   switch (match_substring (primary->ts.u.cl, equiv_flag, , def))
{
case MATCH_YES:
  if (tail == NULL)
*** gfc_match_rvalue (gfc_expr **result)
*** 3147,3153 
 that we're not sure is a variable yet.  */
  
  if ((implicit_char || sym->ts.type == BT_CHARACTER)
! && match_substring (sym->ts.u.cl, 0, >ref) == MATCH_YES)
{
  
  e->expr_type = EXPR_VARIABLE;
--- 3148,3154 
 that we're not sure is a variable yet.  */
  
  if ((implicit_char || sym->ts.type == BT_CHARACTER)
! && match_substring (sym->ts.u.cl, 0, >ref, false) == MATCH_YES)
{
  
  e->expr_type = EXPR_VARIABLE;
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 228849)
--- gcc/fortran/trans-expr.c(working copy)
*** alloc_scalar_allocatable_for_assignment
*** 8891,8896 
--- 8891,8897 
tree jump_label1;
tree jump_label2;
gfc_se lse;
+   gfc_ref *ref;
  
if (!expr1 || expr1->rank)
  return;
*** alloc_scalar_allocatable_for_assignment
*** 8898,8903 
--- 8899,8908 
if (!expr2 || expr2->rank)
  return;
  
+   for (ref = expr1->ref; ref; ref = ref->next)
+ if (ref->type == REF_SUBSTRING)
+   return;
+ 
realloc_lhs_warning (expr2->ts.type, false, >where);
  
/* Since this is a scalar lhs, we can afford to do this.  That is,

Re: [Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

[Steve Kargl]

On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote:
> 
> I was moved by a report on clf of memory leaks in move_alloc to
> investigate the cause. This turned out to be trivial but led to the
> above PRs, which themselves were trivial. The result is the attached
> patch. I am aware that I have not investigated the further
> ramifications that I can imagine are there. Rather, I thought just to
> fix the reported problems.
> 
> It should be noted that there is no PR directly associated with the
> memory leaks. Since the standard does not require this, I did not
> think that it was worthwhile to raise a PR and then close it!
> 
> Bootstraps and regtests on FC21/x86_64 - OK for trunk? ... and 5.2
> after a decent interval?

OK.

-- 
steve