lagache@violet.berkeley.edu (Edouard Lagache) (10/08/87)
A few days ago I pointed out a dirty trick that ought to make
if possible to have the effect of value passed parameters in FORTRAN.
Because this is a Kluge of the first degree, it is very implementation
dependant and shouldn't be used as normal practice, but I would think
that is a useful fact to know for desperate emergencies.
I recieved mail to this effect from several people (whom I thank for
reminding me of exactly how dirty this trick is), but I also recieved
a message that it doesn't work under some cases. Apparantly, the f77
compiler "sees" through the 'X+0' trick and makes X a variable pass
parameter. However, just wrapping an extra set of parantheses does
seem to do the trick.
It might be interesting to see what must be done to "tickle" various
FORTRAN compilers to give value passed parameters.
Edouard Lagache
lagache@violet.berkeley.edukent@xanth.UUCP (Kent Paul Dolan) (10/09/87)
In article <5359@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes: > > A few days ago I pointed out a dirty trick that ought to make > if possible to have the effect of value passed parameters in FORTRAN. >[...]but I also recieved > a message that it doesn't work under some cases. Apparantly, the f77 > compiler "sees" through the 'X+0' trick and makes X a variable pass > parameter. 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? Kent, the man from xanth.
vern%lbl-helios@LBL-RTSG.ARPA (Vern Paxson) (10/10/87)
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
przemek@gondor.psu.edu (Przemyslaw Klosowski) (10/16/87)
In article <5359@jade.BERKELEY.EDU> lagache@violet.berkeley.edu (Edouard Lagache) writes: > > A few days ago I pointed out a dirty trick that ought to make > if possible to have the effect of value passed parameters in FORTRAN. >[...]but I also recieved > a message that it doesn't work under some cases. Apparantly, the f77 > compiler "sees" through the 'X+0' trick and makes X a variable pass > parameter. Several people pointed that optimizing compilers do see thru that, and call foo((x+0)) compiles to the same thing as call foo(x). Let me point however that if you want to avoid the ``variable'' problem, you are probably safe with dummy=x call foo(dummy) which is (to me) cleaner. REMINDER: there is always this proverbial bug when you do: call foo(5) print(*,*)5 .... subroutine foo(n) n=6 end and you get ``6'' printed out! przemek przemek@psuvaxg.bitnet psuvax1!gondor!przemek