While looking at the use of gfc_free() in the front-end when discussing its
removal, I noticed one instance where gfc_free_expr() should be used instead.
The patch that fixes it is:
2011-03-12 Francois-Xavier Coudert <fxcoud...@gcc.gnu.org>
* arith.c (arith_power): Plug memory leak.
Index: arith.c
===================================================================
--- arith.c (revision 170612)
+++ arith.c (working copy)
@@ -912,7 +912,7 @@
{
gfc_error ("Raising a negative REAL at %L to "
"a REAL power is prohibited", &op1->where);
- gfc_free (result);
+ gfc_free_expr (result);
return ARITH_PROHIBIT;
}
Without it, the following testcase :
print *, (-2.0)**(1.3)
end
leaks memory, as evidenced by valgrind:
==26601== 16 bytes in 1 blocks are definitely lost in loss record 6 of 287
==26601== at 0x4A05E1C: malloc (vg_replace_malloc.c:195)
==26601== by 0xD86668: __gmp_default_allocate (in /large/gcc/ibin/gcc/f951)
==26601== by 0xD4912C: mpfr_init2 (in /large/gcc/ibin/gcc/f951)
==26601== by 0x4B48D0: gfc_get_constant_expr (expr.c:165)
==26601== by 0x48FEFC: arith_power (arith.c:791)
==26601== by 0x48EB73: reduce_binary (arith.c:1387)
==26601== by 0x48EF2D: eval_intrinsic (arith.c:1568)
==26601== by 0x48F5C7: eval_intrinsic_f3 (arith.c:1701)
==26601== by 0x4B94C5: gfc_simplify_expr (expr.c:1048)
==26601== by 0x501E2A: gfc_resolve_expr (resolve.c:3977)
==26601== by 0x50BA26: resolve_code (resolve.c:8997)
==26601== by 0x50CFDB: gfc_resolve_blocks (resolve.c:8725)
With the patch, the leak disappears. It was regtested on x86_64-linux. OK to
commit to trunk?
FX
