Re: Strange Porting Problem CVF to IVF, requesting help and ideas.

Jim Klein wrote:

For the time being, /Qzero and /Qsave seem to have been the fixes
required.

I know how to remove Qzero. Initialize all uninitialized variables but
is the removal of Qsave related to converting COMMON blocks in
includes to modules ?

/Qsave has no actual effect on COMMON blocks in Intel Fortran. There
are several things that may be at work so I'll try to offer some
background.

CVF had a default that all local variables had implied SAVE semantics.
This was for historical reasons because so many "dusty deck" programs
assumed that all variables were statically allocated and retained their
value across calls.

Intel Fortran does not default SAVE for local variables (although the
documentation suggests it does, that is being fixed.) The default in
Intel Fortran is that local scalar variables without the SAVE attribute
are allocated on the stack (or maybe in a register). Arrays and
derived types are still allocated statically by default. (I'm ignoring
such things as RECURSIVE that obviously change defaults.) This change
was made to improve run-time performance.

So what happens is that programs that "worked" in CVF may not work in
Intel Fortran because the programmer either did not explicitly SAVE
variables that needed to be saved, or didn't initialize variables
properly, or both. The proper action is to correct the code so that
variables which need the SAVE attribute are given it and that variables
that need to be initialized before use are so initialized.

If you don't want to do that, then Intel Fortran (like many compilers)
offers two crutches: /Qsave and /Qzero. /Qsave really means "make all
local variables static by default" (again, RECURSIVE overrides that).
/Qzero in Intel Fortran has a limited effect - it forces a link-time
zero initialization of statically allocated variables. As I noted
earlier, without also specifying /Qsave, /Qzero tends to have little
effect.

COMMON blocks and module variables are not affected by either of these
options in Intel Fortran. It is true that the standard has wording
saying that SAVE has meaning for such, depending on whether the use of
the common or module is "active", but our implementation makes no
distinction and always allocates such things statically. For now.
(Don't let me stop you adding SAVE to such things if you want to.)

I don't know what in particular fixed Jim's problem. From what he has
written, it is more likely the change in implied SAVE semantics so that
a routine either didn't initialize a variable before use or assumed
that a value would be retained across calls. The compiler's
uninitialized variable checking SHOULD catch the first case, at least,
but it has limitations.


Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
My Fortran blog
http://www.intel.com/software/drfortran

.