From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5E4BA3858C52; Fri,  2 Dec 2022 21:27:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5E4BA3858C52
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670016449;
	bh=xsw9hoPnnzB0rGVOHhiwYcCUFKxFYcSnM6OyAyRZ4eI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=DpIJVJt1ZyVlRMlwil4Ejtnqhff2hlJJL2gQwSUAm+167MJppmXFeHAhgKTeIjZ4Q
	 P86NThcb7lCbwfvFztFVvwOMFx1J9JO5RSe2Spe03UgPUYdXvNn7R53cyteIEopPE6
	 splALBLGCTUxROTgRLNq3MLU/odnP4MpTv+BfIQI=
From: "john.harper at vuw dot ac.nz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/107874] merge not using all its arguments
Date: Fri, 02 Dec 2022 21:27:29 +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: <bug-107874-4-6OKLRbKI6Z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107874-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107874-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

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

--- Comment #21 from john.harper at vuw dot ac.nz ---
I now have a new test case that avoids the possibility of recursive I/O
by tstuff and fstuff doing internal writes to two different character=20
variables. It still reveals the merge problem. It compiles and runs with
gfortran-12 and ifort, giving different outputs.

! Must merge evaluate all 3 arguments?
program testmerge10
   implicit none
   character(7):: string(2) =3D ' '
   logical:: x(2) =3D [.true., .false.], y
   integer i
   do i =3D 1,2
      y =3D merge(tstuff(),fstuff(),x(i))
      print *,y,string
      string =3D ' '
   end do
contains

logical function tstuff()
     write(string(1),"(A)") ' tstuff'
     tstuff =3D .true.
   end function tstuff

   logical function fstuff()
     write(string(2),"(A)") ' fstuff'
     fstuff =3D .false.
   end function fstuff
end program testmerge10

Good luck with your bughunt!
John H

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

> Date: Fri, 2 Dec 2022 21:05:43 +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 10:05:53 +1300 (NZDT)
> Resent-From: <john.harper@vuw.ac.nz>
>=20
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107874
>
> --- Comment #19 from anlauf at gcc dot gnu.org ---
> (In reply to john.harper from comment #18)
>> 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 =3D merge(tstuff(),fstuff(),x(i))
>> but y itself is printed only in the next statement,
>>     print *,y
>
> John, your original testcase in comment#0 was fine.
> I tried to extend it to check for constant as well as non-constant mask,
> and as you see I made a mistake by trying to make it smaller.  Bad idea.
>
>> 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?
>
> I don't recall having seen a mentioning in the standard of the order of
> evaluation of different function (or subroutine) arguments.  Do you?
>
> (Of course, if side-effects happen during that evaluation, such as I/O,
> unexpected things may happen.)
>
>> If so, whether the program is valid Fortran depends on the
>> kind of system on which it is being executed.
>
> Well, even if the print in tstuff/fstuff were a problem, one could constr=
uct
> other testcases with side-effects that might be conforming.
>
> --=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=