https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #35 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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.c 2014-10-04 12:59:45.000000000
+0200
+++ ../4.9_work/gcc/fortran/trans-expr.c 2014-10-04 13:11:36.000000000 +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.f03 2014-07-07
14:33:14.000000000 +0200
+++ ../4.9_work/gcc/testsuite/gfortran.dg/class_array_15.f03 2014-11-08
14:26:21.000000000 +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.
