[Bug fortran/107874] merge not using all its arguments

["john.harper at vuw dot ac.nz" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874

--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have 
recursive I/O because tstuff and fstuff each print something in the 
statement
    y = merge(tstuff(),fstuff(),x(i))
but y itself is printed only in the next statement,
    print *,y

Or does evaluating merge allow each of tstuff and fstuff to be evaluated
at the same time? I was thinking of tstuff and fstuff being evaluated
in succession but could there be systems in which they are evaluated 
simultaneously? If so, whether the program is valid Fortran depends on the
kind of system on which it is being executed.

John Harper

On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:

> Date: Fri, 2 Dec 2022 20:22:23 +0000
> From: anlauf at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
> To: John Harper <john.harper@vuw.ac.nz>
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT)
> Resent-From: <john.harper@vuw.ac.nz>
> 
> 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.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.harper@vuw.ac.nz phone +64(0) 4 463 5276