[Patch, Fortran] Plug memory leaks; fix tree-check ICE for PR

[Tobias Burnus]

This patch fixes one ICE and several memory leaks. But there are more.

*********************

The patch with symbol.c and resolve.c fixes the following issue: 
gfortran leaks memory for:

       REAL FUNCTION GGL(ds)
       GGL = 16806.D0
       END

The problem is the following code in resolve_symbol:

   /* Make sure the formal namespace is present.  */
   if (sym->formal && !sym->formal_ns)
...
       if (formal)
         {
           sym->formal_ns = formal->sym->ns;
           sym->formal_ns->refs++;
         }

Thus, there are now two references to the same namespace. At the end, 
the memory is freed via
gfc_symbol_done_2, which calls gfc_free_namespace (gfc_current_ns). In 
the latter, one has:

   ns->refs--;
   if (ns->refs > 0)
     return;
   free_sym_tree (ns->sym_root);

and the latter frees the formal namespace. The problem is that "ns->ref 
== 2" won't get decreased. That's fixed by the first patch.

  * * *

A similar issue existed for the CONTAINS leakage, which was mentioned 
the other day. Here, the problem is the increment in get_proc_name. 
However, a simple patch with the sym->refs++ in decl.c and symbol.c's 
special case for ENTRY wasn't sufficient as 
gfortran.dg/proc_ptr_result_1.f90 failed. I have now added some extra 
code to parse. to handle "ppr@".

(If one uses valgrind on gfortran.dg/proc_ptr_result_1.f90 it leaks some 
gfc_symbol memory; however, the problems seem to be unrelated.)

* * *

gfortran didn't free gfc_common_head; I added a refs and free it now. 
(For blank commons, no special code is needed as ns->common_head is not 
a pointer.)

* * *

TODO: Despite my hopes for previous patch, there is at least one gfc_ss 
leak left (for channel.f90):

==12987==    by 0xE6A7A8: xcalloc (xmalloc.c:162)
==12987==    by 0x6074A3: gfc_get_array_ss(gfc_ss*, gfc_expr*, int, 
gfc_ss_type) (trans-array.c:561)
==12987==    by 0x613870: gfc_walk_expr(gfc_expr*) (trans-array.c:8787)
==12987==    by 0x63A908: gfc_trans_arrayfunc_assign(gfc_expr*, 
gfc_expr*) (trans-expr.c:6749)
==12987==    by 0x63C281: gfc_trans_assignment(gfc_expr*, gfc_expr*, 
bool, bool) (trans-expr.c:7438)
==12987==    by 0x602C31: trans_code(gfc_code*, tree_node*) (trans.c:1312)
==12987==    by 0x65ED66: gfc_trans_do(gfc_code*, tree_node*) 
(trans-stmt.c:1395)


TODO: There are some more failures, e.g. fatigue.f90 shows invalid reads
==13021==    at 0x57C718: _ZL10show_locusP5locusii.isra.3 (error.c:392)
==13021==    by 0x57CD55: error_print(char const*, char const*, 
__va_list_tag*) (error.c:661)
==13021==    by 0x57D878: gfc_error(char const*, ...) (error.c:956)
==13021==    by 0x5C3C16: match_complex_part(gfc_expr**) (primary.c:1205)
==13021==    by 0x5C3DE6: gfc_match_literal_constant(gfc_expr**, int) 
(primary.c:1296)
and memory leakage in
==13021==    by 0xE6A7A8: xcalloc (xmalloc.c:162)
==13021==    by 0x5F0077: gfc_new_symbol(char const*, gfc_namespace*) 
(symbol.c:2569)
==13021==    by 0x5B5A75: read_module() (module.c:4698)
==13021==    by 0x5B5E5B: gfc_use_module(gfc_use_list*) (module.c:6147)
==13021==    by 0x5B7233: gfc_use_modules() (module.c:6270)
==13021==    by 0x5BC147: use_modules() (parse.c:88)


  * * * * * * * * * * * * * * *

The trans-stmt.c patch fixes a tree-check ICE as we mix different 
logical types; I decided to use the previous type instead folding to the 
boolean_type_node.

Do you think it makes sense to backport it to 4.6/4.7?

  * * *

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: I wonder why gfortran.dg/interface_3.f90 passed before, given that 
"proc_locus" wasn't set before. I also wonder why my patch causes the 
test case to segfault. Well, at least that bug is now also fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: memplug-v2.diff
Type: text/x-patch
Size: 6147 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20120826/f48e5917/attachment.bin>