Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!pikes!aspen.craycos.com!jrbd From: jrbd@craycos.com (James Davies) Newsgroups: comp.lang.fortran Subject: Re: COMMON and SAVE statements Message-ID: <1990Aug3.195438.223@craycos.com> Date: 3 Aug 90 19:54:38 GMT References: <65861@lll-winken.LLNL.GOV> Organization: Cray Computer Corporation Lines: 34 In article <65861@lll-winken.LLNL.GOV> ray@rogue.llnl.gov writes: > >2. What could possibly be the motivation for the standard allowing > variables in COMMON to be become undefined without a SAVE statement? > I can't think of a case where this would be desirable behavior. > Hence why isn't it built into the COMMON framework? From the Fortran 77 standard, page 17-4, section 17.3: (6) The execution of a RETURN statement or and END statement within a subprogram causes all entities within the subprogram to become undefined except for the following: (...) (d) Entities in a named common block that appears in the subprogram and appears in at least one other program unit that is either directly or indirectly referencing the subprogram. Basically, this means that the standard allows the common storage to be reused for other purposes when a subprogram exits and no other currently active subprogram references it. This would allow a smart compiler and/or linker to use the same area for two named common blocks as long as they aren't both active on the same branch of the calling tree. (In practice, I don't know of any compiler that does this. It would probably break a lot of programs, especially programs that don't routinely declare every named common block in the main program.) In the presence of enough interprocedural information, a compiler could also use this provision of the standard to aid in optimization - if a common block was allowed to become undefined at subprogram exit, then variables in the common block need not be treated as output from the subprogram, and this might help dead code elimination, for example.