From: Lynn McGuire on
> Have you tried the Salford FTN77? It is a Fortran 77 debugging compiler
> that offers strong checking including undefined variable checking.

Open Watcom F77 does a good job of notifying one of undefined
variables being used.

We use structures and unions. I think that Salford FTN77
does not support these vax vms extensions that never got
moved into the fortran standard. We started using structures
about 6 years ago to solve a precision problem that we were
having and the usage is now prevalent through our code.

> Clear the undefined variables by setting things to zero manually and
> at the end there will be no zero initialization issues.

It is worse than zero init. Somewhere in the bowels of
our code there are several key local variables that expect
to retain their last used value between subroutine calls.
If I could find these I would SAVE them all ...

Thanks,
Lynn
From: e p chandler on
On Feb 2, 1:36 pm, Lynn McGuire <l...(a)winsim.com> wrote:
> > No, you are not "locked into a F77 compiler". Many current F95/F03
> > compilers have options to give you the zero-initialization and assumed
> > SAVE semantics that some old compilers offered.
>
> Nope.  I have specifically tried IVF and still have problems
> with zero initialization.  I dont know what the specific
> problem was (it could have been certain arrays not getting
> zero initialized - it has been well over a year since I tried).
>
> Our code works with the Open Watcom F77 compiler on Win32 and
> the F77 generic unix compiler just fine.  And the old Vax VMS
> F77 compiler, the old Apollo Domain F77 compiler, the old ...
> (we supported 12 platforms at one point).
>
> > Intel Fortran has a "generated interface checking" option. You compile
> > your sources with -warn interface (/warn:interface on Windows) and it
> > automatically generates interface blocks and modules for subroutines and
> > functions and checks calls against them, warning you of mismatches. For
> > best success, I suggest two builds, leaving the generated .mod files in
> > place after the first build, because a call to a routine that has not
> > yet been compiled can't be checked.
>
> I have not tried this.  I may do this but the setup is very
> painful with 5,000 files, 4 EXE files and 3 DLLs.
>
> > For compatibility with the "F77" compiler you may have used before, add
> > the -Qzero and -Qsave (/Qzero and /Qsave) options.
>
> Nope, does not work for us.  You and I have discussed this
> before.
>
> Thanks,
> Lynn

Is it possible that what you think are zero-initialization problems
are really symptoms of some other kind of bug? Your project is already
old, and it won't be finished any time soon. Perhsps it would be worth
the effort to re-engineer it with a F95+ compiler that offers better
diagnostics and interface checking. I'm sure that Richard would say
that it's far cheaper in the long run to do it right the first time.

-- e

From: glen herrmannsfeldt on
Lynn McGuire <lmc(a)winsim.com> wrote:
(snip)

> It is worse than zero init. Somewhere in the bowels of
> our code there are several key local variables that expect
> to retain their last used value between subroutine calls.
> If I could find these I would SAVE them all ...

You can put a SAVE statement with no variables listed in each
subroutine. That then applies to all local variables in
that subroutine. If that is really the problem, that should
fix it.

I once had a program that (accidentally) depended on a variable
being initialized to a non-zero value. I didn't find the bug until
running it on a system that did zero initialize everything.

The chance that your program doesn't (always) do what you think
it does is probably high enough that you should find the problem.

-- glen

From: Gordon Sande on
On 2010-02-02 17:08:36 -0400, Lynn McGuire <lmc(a)winsim.com> said:

>> Have you tried the Salford FTN77? It is a Fortran 77 debugging compiler
>> that offers strong checking including undefined variable checking.
>
> Open Watcom F77 does a good job of notifying one of undefined
> variables being used.

When I last looked at WatCom F77 it warned if there was no setting
of a variable before it was used as a byproduct of its flow analysis.
This is a compile time analysis only. I do not recall how extensive
te analysis was.

That is that there was some path that sets it as oppoesd to its being set for
all possible paths. The undefined variable checking tells you that it has
not been set for the actual path used. VERY DIFFERENT!! Much stronger analysis.
It is a run time analysis as it not possible with compile time only. If the
path used is data dependent and whether a variable gets set is path dependent
then a compile time analysis can not work.

If you set one element of an array for Watcom it acts like the whole
array is set.
The undefined variable checking of NAG, Salford, Lahey will tell you if
the particular element of the array has not been defined.

The no initialization compile time diagnostic is nice but it seems to be
a cheat that is intended to trick those who check boxes into believing that
they have gotten what the undefined variable checking delivers when it has
not done so. The precise words matter as the capability is very diferent.
The flow analysis is a quick check for blatant errors while the undefined
variable analysis is a slow check at run time for actual errors. One of
the bothers with the undefined variable checking compilers is that they
often need all the source so use of third party object is out. The run time
checking has overhead. But then looking for errors has overhead! Usually
tje compile time diagnostic goes by the name of uninitialized as opposed
to undefined. A subtle distinction that is easy to miss.

> We use structures and unions. I think that Salford FTN77
> does not support these vax vms extensions that never got
> moved into the fortran standard. We started using structures
> about 6 years ago to solve a precision problem that we were
> having and the usage is now prevalent through our code.
>
>> Clear the undefined variables by setting things to zero manually and
>> at the end there will be no zero initialization issues.
>
> It is worse than zero init. Somewhere in the bowels of
> our code there are several key local variables that expect
> to retain their last used value between subroutine calls.
> If I could find these I would SAVE them all ...
>
> Thanks,
> Lynn


From: Gordon Sande on
On 2010-02-02 17:08:36 -0400, Lynn McGuire <lmc(a)winsim.com> said:

>> Have you tried the Salford FTN77? It is a Fortran 77 debugging compiler
>> that offers strong checking including undefined variable checking.
>
> Open Watcom F77 does a good job of notifying one of undefined
> variables being used.
>
> We use structures and unions. I think that Salford FTN77
> does not support these vax vms extensions that never got
> moved into the fortran standard. We started using structures
> about 6 years ago to solve a precision problem that we were
> having and the usage is now prevalent through our code.

Lahey offers structures and unions even if Salford does not.
Lahey's undefined vaiable checking is good but not a complete
as Salford's. My recollection is that Lahey does not analysis
allocated variables.

>> Clear the undefined variables by setting things to zero manually and
>> at the end there will be no zero initialization issues.
>
> It is worse than zero init. Somewhere in the bowels of
> our code there are several key local variables that expect
> to retain their last used value between subroutine calls.
> If I could find these I would SAVE them all ...
>
> Thanks,
> Lynn


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: managing identities
Next: Call Tree Generator