Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!samsung!xylogics!world!burley From: burley@world.std.com (James C Burley) Newsgroups: comp.lang.fortran Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ???? Message-ID: Date: 21 Jul 90 09:43:49 GMT References: <57505@lanl.gov> <1990Jul20.153135.11273@ux1.cso.uiuc.edu> <10074@brazos.Rice.edu> Sender: burley@world.std.com (James C Burley) Organization: The World Lines: 88 In-Reply-To: saltzman@mora.rice.edu's message of 20 Jul 90 21:31:51 GMT In article <10074@brazos.Rice.edu> saltzman@mora.rice.edu (Matthew Saltzman) writes: In article <1990Jul20.153135.11273@ux1.cso.uiuc.edu> hirchert@ux1.cso.uiuc.edu (Kurt Hirchert) writes: >1. On the subject of functions with side effects: > > a. Fortran allows functions with side effects. > b. However, you are not allowed to use a function with a side effect if that > side effect could change the value of any other expression or > subexpression in the same statement. (The one exception to this general > rule is that in a statement of the form IF(), > a side-effect in _can_ affect . (A couple of other postings have asserted something similar.) I'm sorry, but I don't see how a compiler can practically enforce such a restriction. *Any* time a variable appears as an argument to a function, it's a candidate for modification. If I write X = F(Y) + Y + Z how can the compiler know if Y is modified by F()? F() doesn't need to even appear in the same source file as the statement. Detection of the modification at run-time seems to be an unreasonable restriction on optimization. F() could even modify Z, if Z appeared in COMMON. Am I missing something? Yes, you are missing something quite simple: you are not allowed to write such a statement in a standard-conforming program, but then again a standard- conforming compiler is NOT required to detect such a statement and report it as an error. This restriction is just like the restriction that you can't reference a variable without first defining it (no read before write or DATA of it); if you try it, the compiler can do anything it wants. Some are nice and give you warning messages, but they can't detect all cases of it and aren't required to. Almost anyone who hasn't stuck their foolish head in the world of interpreting standards documents (as I have) can easily get confused by the wording standards use to describe restrictions and requirements. Standards are basically like contracts and often suffer from the same deficiencies as far as readability by the audience for whom they are intended! (-: > c. Fortran does not guarantee that your function with side-effects will be > executed. If the expression in which it appears can be evaluated without > it, your processor is free to skip the execution of the function. If > there is a possibility of this occurring, whether or not your processor > suppresses the execution of the function, the standard calls for you > to consider the side-effects of the function to be undefined and > prohibits your making use of them. (Since the standard does not limit > the methods the processor can use in determining the expression value > without calling the function, it has been argued that you should always > treat function side-effects as undefined.) This is a reasonable specification, but it is not the same as "not allowed." My Sun FORTRAN compiler has no problem with the above construct (with F(Y) modifying Y). I understand that if I actually *did* do this, it would be at my peril. Well, in one sense "not allowed" can be taken to mean "doesn't work on my machine". But I think the sense of "not allowed" in the original posting was "not allowed in a standard-conforming program". > d. All of the above contributes to my recommendation that you not use > functions with side-effects in Fortran. Yes! Personally, I'm not sure that the standard even theoretically allows such severe treatment of functions with side effects, but I may be wrong. It seems to me the spirit, if not the letter, of the F77 standard in this area was to say "the compiler can avoid making function calls if it can determine, by simply looking at only the program unit being compiled, that they are not needed at compile or run time". Now if a compiler looks at more than one program unit at a time (truly global optimization) and decides to eliminate function calls, then IMHO it must still perform any side effects coded for that function unless it determines that they, too, can be eliminated on a global basis. In other words, it should perform those side effects "as if" the function had been called if the removal of that function call is based on partial (rather than complete) global optimization techniques. > [deleted] >Kurt W. Hirchert hirchert@ncsa.uiuc.edu >National Center for Supercomputing Applications Matthew Saltzman saltzman@rice.edu Disclaimer: Institutions can't have opinions. James Craig Burley "Nor can opinions be considered institutions!" (-: