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

On 2006-09-27 04:44:01 -0300, "David Flower" <DavJFlower@xxxxxxx> said:


Jim Klein wrote:
Hi,

First, what ever is wrong is either my fault of I missed reading the
necessary documentation.

Here is the problem.

I have a large engineering analysis code, developed first with Lahey
then CVF for the last 6 years.

It has a named common block that is inside an include file. The
variable in question is named LDIF2 and is used by the program,
depending on how it is set by the user to control some program
behavior. It is declaired as LOGICAL. It is the only variable in the
common block.

The variable is never used in a function or subroutine call and does
not appear in any other common block or in a module.

I started before modules (1987) so that is why I still have static
arrays and variables in common blocks. Up to now no problem.

Under CVF 6.6b is has behaved as it was expected to behave, staying
set either TRUE or FALSE depending upon either how it is initialized
(TRUE) or how the user sets it via a program command.

I compile via batch and have successfully established BAT files which
will wither compile in CVF (under one directory structure) or in IVF
(under a completely different directory structure.) Nothing is shared
between the builds. I'm dumb sometimes but not that dumb. :-)

In the IVF compile, when the program runs, the variable changes from
TRUE to FALSE unexpectedly during somewhat related operations but
nothing that should have changed its state. I have placed traps
wherever LDIF2 is explicitly set in the code (write statements). LDIF2
is not being reset at any code location I can find.

The behavior is similar to a behavior I saw years ago where the same
named common appeared is several places and had different variables in
the different copies. After that I put all my common blocks (all
named) in include files.

I use all of the same switches in compile and link in CVF and IVF.

Is there a difference between how IVF alignes common blocks in memory.
I remember once in an old DEC VAX compiler, you could not mix logical
with real in a common block but I have seen nothing like that since
1990 or was it 16 bit MS Fortran ? Not really sure.

I sure hope the above decription triggers something in somebody, cause
I'm a wee bit on the lost side right now.

I'm going to try a compile with no optimization this evening but that
is just a shot in the dark on my part.

Sincerely and thanks in advance.


James E. Klein
jameseklein@xxxxxxxxxxxxx

Engineering Calculations
http://www.ecalculations.com
ecalculations@xxxxxxxxxxxxxxxxx
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free KDP-2 (DEMO) downloadable!
1-818-507-5706 (Voice and Fax)

Does the compiler have an equivalent to the FTN77 WRITE_BREAK
capability ?
(This sets a hardware trap triggered when a variable is written to).

Also, note that the F77 standard (I don't know about the F90 standard)
specifies that COMMON blocks may become undefined if no routines within
the current calling treew access them - so put all your COMMON blocks
in the main PROGRAM

Dave Flower

This seems to be a classic example of where running under either Lahey/Fujitsu
with /chkglobal or Salford (Siverfrost) FTN95 with /undef would be indicated.
Mr Klein can either spend his effort chasing ghosts and complaining or he
can do the work of moving his Fortran code to a different compiler. FTN95
is free so the price is right. The bother is that he may be locked into
using Winteractor and not have copies for the other systems. (Klien is a
known usenet "character" and uses Winteractor if I recall correctly.) The
solution is then to pay the freight for the relevant libraries, which is
surely rather low when measured in the cost of man days (but cash might
be very expense as it is the wrong budget line!). The other advantage is
that two systems will provide more chances of finding this type of error.
If it is large and under development for a long time portability becomes
a valued attribute so the cost of two compilers and associated libraries
becomes even relatively less. Everbody has subscript checking and complaints
about slow execution under such checking are nonsense compared to the
cost of chasing the bugs that are easily caught with one compiler switch
and rerunning.

CVF is under Windows as are the other two so there is no need to play Unix
(of whatever flavour) purist about not being able to switch platforms. My
experince is the FTN95 has the best checking but more stability problems.
Lahey/Fujitsu (or NAG 5 for that matter) have more limited chacking but
fewer stability problems. Given the development history the limitations
not likely to be much of an issue.

My sympathy level is rather limited for folks who can not be bothered
to use all the debugging tools that are availalbe but do complain
about the difficulty in finding bugs.





.

Relevant Pages

  • Re: Strange Porting Problem CVF to IVF, requesting help and ideas.
    ... It has a named common block that is inside an include file. ... will wither compile in CVF or in IVF ... After that I put all my common blocks (all ...
    (comp.lang.fortran)
  • Re: Pb with the nonlinear solver "hybrd"
    ... first you have to get it to compile. ... HYBRD.F contains multiple routines, and you need to ensure that these ... Although it shouldn't affect CVF ... I would check that there are no COMMON blocks being used to pass data, ...
    (comp.lang.fortran)