Fortran - implicit SAVE in gfortran

Author

implicit SAVE in gfortran

Charles Russell

2004-11-21, 3:58 pm

I was contemplating with horror the prospect of adding SAVE statements to my
40-year collection of old code, but on trying out the cygwin snapshot of
gfortran, the current behavior seems to be implicit SAVE. Is that correct?

Incidentally, the gfortran snapshot met my most critical requirement -
handling the PORT optimization package (netlib) and its maximum likelihood
extension (TOMS). Diagnostics look good, it ran twice as fast as g77 (with
bounds check enabled, my default mode) , and required no change in my
makefiles.

Richard E Maine

2004-11-22, 3:58 pm

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> I was contemplating with horror the prospect of adding SAVE statements to my
> 40-year collection of old code,...

It isn't that much of a horror. If you want to fine tune things,
applying SAVE only to those things that need it, then that can
indeed be a horror. Been there. Long ago with my own codes, and
more recently when helping debug otheer people's codes.

But if all you want to do is apply SAVE to everything it makes
sense for, then all you need is a single statement that says
just SAVE in each procedure. (It being legacy code, there is
no need to bring up questions like internal procedures and module
procedures). Don't name anything in specific to be saved, just
plain SAVE. One could come close to doing it with a simple editor
macro. (By which, I'm not counting all the things one could do
in emacs - one could probably write a Fortran compiler in emacs,
but I wouldn't count that as simple... or recommended. :-))

I don't know the answer to your particular question about gfortran
behavior... though I'd personally recommend not counting on it.
But then that's the same recommendation I've had for about the
past 25 years or so. I've noticed that not everyone follows
all of my recommendations. :-) Your choice, obviously.

I will throw in the plea to notice now non-horrible a minimally
standard-conformant solution is.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Charles Russell

2004-11-22, 3:58 pm

"Richard E Maine" wrote
>
to my[color=darkred]
[color=darkred]
>all you need is a single statement that says
> just SAVE in each procedure. (It being legacy code, there is
> no need to bring up questions like internal procedures and module
> procedures). Don't name anything in specific to be saved, just
> plain SAVE.

Thanks. That trick is new to me.

I never gave any thought to SAVE, always using an implicit SAVE switch to
ensure " the usual behavior." I was upset to see that switch missing from
gfortran. But I was just now looking at a couple of books and discovered
that f90, unlike f77, applies SAVE implicitly to DATA statements. That
would take care of most problems. All that are left, that I am aware of,
are COMMON blocks not included in the main routine, and occasional old
routines that require default initialization-to-zero.

Richard E Maine

2004-11-22, 8:57 pm

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> routines that require default initialization-to-zero.

That's a separate question from SAVE. Related, but separate.
There exist (plenty of) implementations that do default save,
but don't do default initialization to zero.

There is no standard way to do the initialization to zero.
(Compiler-specific ways in several compilers, but no standard
one).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Charles Russell

2004-11-23, 3:57 am

"Richard E Maine" wrote

> That's a separate question from SAVE.

I was trying to think of ways to initialize prior to f90 other than with a
DATA statement and that might also require SAVE. Maybe there are other
situations that also need SAVE, but I hope not.

The thought occurs: if SAVE is available as a simple toggle in the source
code, surely it is easy to implement as a compiler option, which is how I
have always dealt with it. But perhaps such a compiler option is pointless
if it is already the default behavior in gfortran, except to reassure people
like me.

Richard Maine

2004-11-23, 3:57 am

"Charles Russell" <STOPworworSPAM@bellsouth.net> writes:

> The thought occurs: if SAVE is available as a simple toggle in the source
> code, surely it is easy to implement as a compiler option,

Definitely. And many compilers have such an option. Perhaps even most
compilers today. You might even be able to convince me that the set
included all current actively maintained compilers. (I don't know that,
but it is plausible enough.)

I just prefer the standard solution. That way, I know that the code will
work on all compilers, including any future ones, not just many or most.
Plus, even if it turns out to be that every compiler I use has such a switch,
I darned well know that all the compilers don't have the same name for the
switch. So with the standard solution, I get easy portability without
having to research how to spell it on each compiler. That kind of
portability is one of the things that standards are good for.

Maybe its just me, but I have a very strong bias towards using standard
solutions where they exist and aren't unreasonably painful.

I have seen people asking questions on this forum about how to find such
switches for particular compilers. Users of my codes will never have to
ask that one.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Sponsored Links