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