Prev: gfortran/ifort format issues in files
Next: Problem dynamically loading a library
From: Lynn McGuire on 4 Jul 2010 14:57
As many have advised on this board, we are looking to remove the /save
compiler option from our compiles. The /save option initializes all local
variable to zero and saves their values between subroutine calls. Does
anyone have experience doing this and have any advice ? We have about
600,000 lines of code and 100,000 local variables to initialize.

I was wondering what would be the best procedure for doing this:
1. initialize all local variables to zero in a data statement
2. initialize all local variables to zero in a statement at the beginning of the
subroutine (my favorite)
3. something else ?

Thanks,
Lynn


From: Ron Shepard on 4 Jul 2010 15:25
In article
<2sGdncUF-9gCRK3RnZ2dnUVZ_vadnZ2d(a)posted.internetamerica>,
"Lynn McGuire" <lmc(a)winsim.com> wrote:

> As many have advised on this board, we are looking to remove the /save
> compiler option from our compiles. The /save option initializes all local
> variable to zero and saves their values between subroutine calls. Does
> anyone have experience doing this and have any advice ? We have about
> 600,000 lines of code and 100,000 local variables to initialize.
>
> I was wondering what would be the best procedure for doing this:
> 1. initialize all local variables to zero in a data statement
> 2. initialize all local variables to zero in a statement at the beginning of
> the
> subroutine (my favorite)

These do different things, and you will need to figure out which
kind of initialization is required. Also, along with this, you will
need to determine which variables really do need to be saved so that
their values are retained between calls. With the current code and
nonstandard /save compiler directives, you are almost certainly
initializing and saving variables that do not need it, but since
your code does not work without these options, there are apparently
some variables that do need one or the other. You don't want to
save variables, particularly large arrays, that do not need to be
saved.

> 3. something else ?

Something I recommended a while back is to find a compiler that
allows default initializations to arbitrary bit patterns. Then you
can set all variables that are otherwise not initialized the right
way (i.e. with save statements, data statements, and normal
assignments) to various values (large positive or negative values
for integers, signaling/quiet NaNs or positive or negative HUGE()
for floating point) and watch where the program errs. You can work
through your program one routine at a time or in blocks of routines
as appropriate. Hopefully, the bad code is limited and localized.
Perhaps you can identify it as mostly being written by a single bad
programmer, and track it down that way. When your code is finally
correct, you should be able to set this default memory
initialization to any value at all, and every final and intermediate
result ever computed throughout your entire program will have the
same correct value.

$.02 -Ron Shepard
From: Richard Maine on 4 Jul 2010 16:20
Lynn McGuire <lmc(a)winsim.com> wrote:

> As many have advised on this board, we are looking to remove the /save
> compiler option from our compiles. The /save option initializes all local
> variable to zero and saves their values between subroutine calls. Does
> anyone have experience doing this and have any advice ? We have about
> 600,000 lines of code and 100,000 local variables to initialize.
>
> I was wondering what would be the best procedure for doing this:
> 1. initialize all local variables to zero in a data statement
> 2. initialize all local variables to zero in a statement at the beginning
> of the subroutine (my favorite)
> 3. something else ?

Note that SAVE and zero initialization are very different things. It is
not uncommon for old codes to require both of them, but that doesn't
mean they are equivalent. Between choices 1 and 2, probably 1 is the
"safest" in most cases, but there are exceptions.

Choice 1 does zero initialization (and implicitly also SAVE because
initialized variables are implicitly saved as of f90). If you code needs
both, then that's what you want.

If your code actually needs SAVE, then 2 is not what you want. Choice 2
would be pretty much the opposite of SAVE in that it zeros the variables
on each entry, throwing away whatever values they had before.

Now there are cases where choice 2 is superior. But they are all cases
where the code does not need SAVE. In particular, if you have code that
assumes zero initialialization, does not need SAVE, and might get
converted to being invoked multiple times in a single program, then
choice 2 does the needed zero initialization for each invocation.
Parallelization is a prime area where this could be relevant.

I'm not addressing option 3. There might be possibilities there, such as
along the line that Ron mentioned. I'm just pointing out the important
difference between 1 and 2.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Lynn McGuire on 4 Jul 2010 23:03
> Something I recommended a while back is to find a compiler that
> allows default initializations to arbitrary bit patterns. Then you
> can set all variables that are otherwise not initialized the right
> way (i.e. with save statements, data statements, and normal
> assignments) to various values (large positive or negative values
> for integers, signaling/quiet NaNs or positive or negative HUGE()
> for floating point) and watch where the program errs. You can work
> through your program one routine at a time or in blocks of routines
> as appropriate. Hopefully, the bad code is limited and localized.

I think that I want to stay with our current compiler until we get everything
to working without /save. That way we have a baseline and can run two
debug sessions, one with /save and one without.

> Perhaps you can identify it as mostly being written by a single bad
> programmer, and track it down that way. When your code is finally

Over 100 programmers wrote our software. Maybe 200 over the 40+
years.

Thanks,
Lynn


From: Louis Krupp on 5 Jul 2010 03:50
On 7/4/2010 9:03 PM, Lynn McGuire wrote:
>> Something I recommended a while back is to find a compiler that
>> allows default initializations to arbitrary bit patterns. Then you
>> can set all variables that are otherwise not initialized the right
>> way (i.e. with save statements, data statements, and normal
>> assignments) to various values (large positive or negative values
>> for integers, signaling/quiet NaNs or positive or negative HUGE()
>> for floating point) and watch where the program errs. You can work
>> through your program one routine at a time or in blocks of routines
>> as appropriate. Hopefully, the bad code is limited and localized.
>
> I think that I want to stay with our current compiler until we get everything
> to working without /save. That way we have a baseline and can run two
> debug sessions, one with /save and one without.

I think Ron is suggesting using a different compiler to help you find
uninitialized variables and get things to work without /save. In the
best-case scenario, you could find a compiler that could let you specify
/save or /init_to_funny_bits on a file by file basis. If everything
works with /save, change /save to /init_to_funny on one source file, add
the save attribute if and where it is needed, move on to another file,
and repeat until done.

Louis
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: gfortran/ifort format issues in files
Next: Problem dynamically loading a library