https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123772
Andrew Benson <abensonca at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |abensonca at gcc dot
gnu.org
--- Comment #2 from Andrew Benson <abensonca at gcc dot gnu.org> ---
Created attachment 63472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=63472&action=edit
Proposed patch
Investigating this, I think the problem is that the assignment fileObject=ho()
gets replaced with a subroutine call (by gfc_extend_assign(), called from
resolve_ordinary_assign) during this block in gfc_resolve_code in resolve.cc:
if (resolve_ordinary_assign (code, ns))
{
if (omp_workshare_flag)
{
gfc_error ("Expected intrinsic assignment in OMP WORKSHARE "
"at %L", &code->loc);
break;
}
if (code->op == EXEC_COMPCALL)
goto compcall;
else
goto call;
}
This results in the goto compcall, and so the generate_component_assignments
(&code, ns); on line 14297 of resolve.cc is never reached -
generate_component_assignments() would do the finalization in this case, but
since it is never called, that doesn't happen.
In gfc_finalize_tree_expr() in trans.cc there is an if statement which just
returns if finalization has already been handled by
generate_component_assignments() - but this currently doesn't account for the
above possibility. As a result, it returns, so no finalization is done by
gfc_finalize_tree_expr(), and no finalization was done by
generate_component_assignments() either. So, the function result is never
finalized.
A simple change to fix this is in the attached patch. This just adds a global
variable is_assign_call, which is set to 1 in the case of an EXEC_ASSIGN_CALL,
and then changes the logic in gfc_finalize_tree_expr() so that it always
finalizes in the case of an EXEC_ASSIGN_CALL.
This fixes the problem and causes no regressions.
