[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #7 from Tobias Burnus --- *** Bug 46487 has been marked as a duplicate of this bug. ***
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 Tobias Burnus changed: What|Removed |Added CC||jwmwalrus at gmail dot com --- Comment #6 from Tobias Burnus --- *** Bug 58229 has been marked as a duplicate of this bug. ***
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #5 from Damian Rouson 2013-01-20 18:59:54 UTC --- Hi Janus and Tobias, We're moving toward an internal release of the open-source package that exposed this bug. Any chance of this being fixed in the near future? The lead developer Karla Morris is cc'd on this. Damian
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #4 from janus at gcc dot gnu.org 2012-12-28 16:01:57 UTC --- (In reply to comment #2) > The issue seems to only occur with scalars. Right. When using an array in Damian's test case, a temporary is generated by calling gfc_trans_create_temp_array from gfc_conv_procedure_call (trans-expr.c:4979).
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 --- Comment #3 from Tobias Burnus 2012-12-05 10:14:03 UTC --- (In reply to comment #1) > The problem seems to be that we fail to do auto-deallocation of the function > result (after the assignment). One should check the standard, if and where > this > is actually demanded. Nowhere. It only falls into the category "quality of implementation". But a reasonable place would be after the place where finalization would occur. > Btw, this will also be important for the future FINAL implementation. Yes, after the function has evaluated, its result has to be finalized. I think it should be as following: tmp = bar(); final_wrapper (a); ! must be after "bar()" a = *tmp; final_wrapper (*tmp); free (tmp); With an allocatable LHS it gets messier due to the length type parameter (and shape). In addition, it seems as if one had always to finalize the LHS in an intrinsic assignment while the (re)allocation is only allowed if the shape doesn't match. >From F2008, "4.5.6.3 When finalization occurs": "If an executable construct references a function, the result is finalized after execution of the innermost executable construct containing the reference." "When an intrinsic assignment statement is executed, the variable is finalized after evaluation of expr and before the definition of the variable." By the way, the latter implies that a temporary variable has to be used if there is a finalizer and the RHS doesn't return a pointer/allocatable. Otherwise one had to finalize the LHS before evaluating the RHS expr.
[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603 Tobias Burnus changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-05 CC||burnus at gcc dot gnu.org Summary|Memory leak in intrinsic|Memory leak in intrinsic |assignment of allocatable |assignment of a scalar |derived type function |allocatable function result |result | Ever Confirmed|0 |1 --- Comment #2 from Tobias Burnus 2012-12-05 10:00:09 UTC --- The issue seems to only occur with scalars. Generated code a = *bar (); Expected: One uses a temporary as in tmp = bar (); a = *tmp; free (tmp); The same issue occurs with reallocate LHS, were also a temporary should be used. [Check that the allocation/freeing is properly done for variables with length type parameter (currently only deferred-length CHARACTER strings).]
