https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125391
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #4)
> @Mikael, please take a look at this.
>
Mine again, it seems. Taking.
> Not only is D.4929 declared in the wrong place but it is never given a value.
>
This restores the missing assignment giving it a value:
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index 1d7006a6963..e5e57899bef 100644
--- a/gcc/fortran/trans.cc
+++ b/gcc/fortran/trans.cc
@@ -1598,6 +1598,8 @@ gfc_assignment_finalizer_call (gfc_se *lse, gfc_expr
*expr1, bool init_flag)
build_empty_stmt (input_location));
}
+ gfc_add_block_to_block (&lse->finalblock, &se.pre);
+ gfc_add_block_to_block (&lse->post, &se.post);
gfc_add_expr_to_block (&lse->finalblock, final_expr);
return true;
Moving the declaration to the right place requires more head scratching.
Basically, the finalization code is generated out of the scalarization loop, so
it shouldn't happen between the gfc_start_scalarized_body and
gfc_trans_scalarizing_loops pair of calls. If it happens between them, any
necessary variable will be generated in the loop body.
But moving the finalization generation somewhere else seems to contradict the
standard requirement that the finalization happens after the evaluation of the
rhs and before the assignment to the lhs.
