Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!hirchert
From: hirchert@ux1.cso.uiuc.edu (Kurt Hirchert)
Newsgroups: comp.lang.fortran
Subject: Re: Function calls in the middle of subroutine CALLs? -- Is it standard fortran 77 ????
Message-ID: <1990Jul21.191129.26187@ux1.cso.uiuc.edu>
Date: 21 Jul 90 19:11:29 GMT
References: <1990Jul20.153135.11273@ux1.cso.uiuc.edu> <10074@brazos.Rice.edu> <BURLEY.90Jul21054349@world.std.com>
Organization: National Center for Supercomputing Applications
Lines: 51

In article <BURLEY.90Jul21054349@world.std.com> burley@world.std.com (James C Burley) writes:
>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.

o  It is clear from talking with the people who wrote the FORTRAN 77 standard
   that their intent was to address only those side effects that might
   interfere with optimization, and that the primary example they had in mind
   was optimizing logical expressions involving .AND. and .OR..  Nevertheless,
   no limitation was placed on the methods by which a processor might determine
   the value of an expression without executing the function reference.  In
   subsequent official interpretation of FORTRAN 77, X3J3 considered the case
   of a "moralistic" optimizer that converted each reference to a function with
   effects into a reference to an equivalent function without side effects and
   concluded that such a processor was allowed by the rules of FORTRAN 77.
   (The "moralistic" optimizer was hypothetical.)

o  Note that the implication of this interpretation is _not_ to prohibit
   functions with side effects.  It merely renders the results of those side
   effects undefined and, by implication, prohibits the use of those side
   effects.  For example, a function could communicate with some lower-level
   function through a common block.  The changed value in the common block
   would be a side-effect.  This is permitted by FORTRAN 77.  What is not
   permitted (under this interpretation of the rules) is a subsequent reference
   to the value in the common block.

o  In other words, inadvertant side effects are permitted as long as they do
   not interfere with other parts of the same statement.  Intentional side
   effects should be coded as subroutines rather than functions.

o  I know of no Fortran compiler that takes full advantage of this dictum, but
   I have seen enough that come close, that I would say this dictum represents
   practical advice for portable programming as well as being an abstract
   restriction from the standard.

o  As others have noted, these restrictions apply to the programmer, not the
   compiler.  A compiler is free to support functions with side effects.  Just
   don't expect consistency in the handling of these side effects as you go
   from compiler to compiler.
-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications