Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ucbvax!bbnj.arpa!kfield From: kfield@BBNJ.ARPA (Ken Field) Newsgroups: fa.info-vax Subject: Re: another fortran problem? Message-ID: <8509201817.AA19865@UCB-VAX.ARPA> Date: Fri, 20-Sep-85 12:45:56 EDT Article-I.D.: UCB-VAX.8509201817.AA19865 Posted: Fri Sep 20 12:45:56 1985 Date-Received: Sat, 21-Sep-85 04:44:29 EDT Sender: daemon@ucbvax.ARPA Reply-To: info-vax@ucb-vax.arpa Organization: The ARPA Internet Lines: 20 I have isolated a problem in a Fortran program (that we did not write) that ran ok under VMS 3.x but exhibited strange behavior under VMS 4.1. This may be of interest to those of you who are complaining about changes in results from Fortran programs under VMS 4.1. The problem is with a statement of the form if (a() .and. b) then ... where 'a()' is a function call that returns a logical value and 'b' is a logical variable. The function 'a' also has some side- effects. The problem is that the compiler (when run with the /optimize switch) generates code to check the value of 'b' first, and if 'b' evaluates to .false., then 'a' is not evaluated, leaving the side-effects undone. (Under VMS 3.x, 'a' was always evaluated.) I should note in the compiler's defense that the function 'a' is really only an entry point in another function and is never actually declared to be a function (as I said, I didn't write this program...). -Ken