This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCSE store motion
- From: Dale Johannesen <dalej at apple dot com>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: Dale Johannesen <dalej at apple dot com>, mark at codesourcery dot com, toon at moene dot indiv dot nluug dot nl, dberlin at dberlin dot org, gcc at gcc dot gnu dot org, law at redhat dot com, roger at eyesopen dot com
- Date: Wed, 15 May 2002 14:06:41 -0700
- Subject: Re: GCSE store motion
On Wednesday, May 15, 2002, at 01:05 PM, Robert Dewar wrote:
> <No, but it'll help any and all Fortran programs that have to be compiled
> with -fno-automatic because they were developed on systems where local
> variables in subroutines kept their values from call to call.
>
> Given the number of times my advice on comp.lang.fortran of compiling
> with -fno-automatic actually `stopped the bug', I'd think that's rather
> important ...
>
> Interesting, considering that *every* version of the Fortran standard has
> emphasized that there is no requirement for local variables in subroutines
> to keep their values from call to call (the only exception is initialized
> data that is never reassigned).
True, but prior to the f77 standard there was no standard way to get the
SAVE
functionality. And just because a standard was adopted in 1978 didn't mean
code written using the new features of that standard was portable; that
didn't
happen until the mid-80s. Most old compilers SAVEd all locals by default,
and there is a lot of old Fortran around that depends on that behavior. At
the time, such code was reasonably portable, as much as anything was (f66
was not complete enough or specified fully enough to support true
portability).
To support these programs, every f77 compiler I know of has a switch
equivalent to -fno-automatic, and they always will.