https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to anlauf from comment #15)
> --- snip ---
> > Can you please verify?
>
> Yes, this fixes the test case.
OK, thanks for confirming.
> However if the orginal test case is valid
> fortran we probably need to fix something else. Paul Thomas was noticing a
> similar problem with his Finalization patches. He was doing the
> finalization inside trans_transfer or similar so it was blocking on a mutex
> trying to finalize in the middle of an I/O operation.
>
> So in this case, my guess is the merge expression needs to be resolved
> before the translation phase.
If I interprete the tree-dump correctly, we have e.g.:
_gfortran_st_write (&dt_parm.2);
{
logical(kind=4) D.4279;
logical(kind=4) D.4280;
logical(kind=4) D.4281;
logical(kind=4) D.4282;
D.4279 = tstuff ();
D.4280 = fstuff ();
D.4281 = x[(integer(kind=8)) i + -1];
D.4282 = D.4281 ? D.4279 : D.4280;
_gfortran_transfer_logical_write (&dt_parm.2, &D.4282, 4);
}
_gfortran_st_write_done (&dt_parm.2);
so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
and which does its own I/O, and then return to continue with the transfer.
So this might be non-conforming code, see
F2018:12.12 Restrictions on input/output statements
(2) An input/output statement that is executed while another input/output
statement is being executed is a recursive input/output statement.
A recursive input/output statement shall not identify an external unit that
is identified by another input/output statement being executed except that
a child data transfer statement may identify its parent data transfer
statement external unit.
I am not sure I fully understand the last sentence in this paragraph,
but I think the pushed testcase might be invalid and should be replaced.
If you agree, I'll simply do this.
