Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!genrad!decvax!decwrl!ucbvax!LBL-RTSG.ARPA!vern%lbl-helios
From: vern%lbl-helios@LBL-RTSG.ARPA (Vern Paxson)
Newsgroups: comp.lang.fortran
Subject: Re: FORTRAN value passed parameters revisited
Message-ID: <8710100545.AA07078@lbl-helios>
Date: Sat, 10-Oct-87 01:45:32 EDT
Article-I.D.: lbl-heli.8710100545.AA07078
Posted: Sat Oct 10 01:45:32 1987
Date-Received: Mon, 12-Oct-87 05:37:48 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: vern%lbl-helios.arpa@lbl-rtsg.arpa
Lines: 41

Kent, the man from xanth:

> Wow!  It seems to me that changing an expression to a variable ought
> to count as a MAJOR, MAJOR bug in an f77 compiler.  That can NEVER be
> what the programmer intended; that also means the compiler did the
> conversion of "+0" to a nil action BEFORE classifying the string
> "(X+0)" as an expression.  Yuk!
>
> Comments?

From 15.9.3.2 of the ANSI FORTRAN 77 standard:

	"If the actual argument is a constant, a symbolic name of a constant,
	 a function reference, an expression involving operators, or an
	 expression enclosed in parentheses, the associated dummy argument
	 must not be redefined within the subprogram."

This means that you are not allowed to pass an expression like "(x)" to
a subprogram unless the subprogram won't try to change it.  In this
case, it's safe for the compiler to make the optimization of passing
the address of x itself rather than copying it and passing the address of
the copy, and the compiler IS doing what the programmer intended,
*assuming the programmer is complying with the standard*.

Also, this change can be made simply as part of the optimization process,
and does not require any gross hack in the compiler.  The compilation
sequence could be something like:

	parse "(x + 0)" as an expression
	apply optimization "x + 0 -> x" to get "(x)"
	apply optimization "(x) -> x" to get "x"

When it's done it still has an expression in its hands, but one which it
knows it can load directly without having to do further evaluation. (Variable
names are expressions.)

		Vern

	Vern Paxson				vern@lbl-csam.arpa
	Real Time Systems			ucbvax!lbl-csam.arpa!vern
	Lawrence Berkeley Laboratory		(415) 486-6411