From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 439DE3858C62; Fri, 2 Dec 2022 20:50:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 439DE3858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670014208; bh=kOgiT9zV9l5aXj5aoOauW118sipEWAxM9hE2B5467Cg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QPu5YVwBxVsczb2dJRuKSl4cbn+STMkejEdGJrQhwk7jAW5QTO+Y3W3PVjAekW3N6 nT+syIHkgIwlm0SbpNiZ616/yRScUeU/n+15pUdk6rWFznm0fl/5qYxQMo2SEpIsKs IZ5SW+NCbQ/lSQoeQ4jDUvSmjcfPbzq6v5YS+M8k= From: "john.harper at vuw dot ac.nz" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/107874] merge not using all its arguments Date: Fri, 02 Dec 2022 20:50:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: unknown X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: john.harper at vuw dot ac.nz X-Bugzilla-Status: REOPENED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: anlauf at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107874 --- Comment #18 from john.harper at vuw dot ac.nz --- An interesting problem! But I thought my original test case did not have=20 recursive I/O because tstuff and fstuff each print something in the=20 statement y =3D 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=20 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 > To: John Harper > Subject: [Bug fortran/107874] merge not using all its arguments > Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT) > Resent-From: >=20 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107874 > > --- 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 mu= tex >> 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=3D4) D.4279; > logical(kind=3D4) D.4280; > logical(kind=3D4) D.4281; > logical(kind=3D4) D.4282; > > D.4279 =3D tstuff (); > D.4280 =3D fstuff (); > D.4281 =3D x[(integer(kind=3D8)) i + -1]; > D.4282 =3D 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()/fstuf= f(), > 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 th= at > 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. > > --=20 > 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=