Re: Problem with log function - Intel fortran compiler under Linux

On 8 okt, 14:58, Gordon Sande <g.sa...@xxxxxxxxxxxxxxxx> wrote:
On 2007-10-08 06:44:15 -0300, Arjen Markus <arjen.mar...@xxxxxxxxxx> said:





On 4 okt, 15:35, Arjen Markus <arjen.mar...@xxxxxxxxxx> wrote:
Hello,

we are experiencing a rather nasty problem with the Intel Fortran
compiler under Linux
(version 9.0). The program is big and so far we have not been able to
trim the code
so that a moderately sized program displays the problem too.

The point is this:

The first application of the log function on double precision reals
causes
an NaN (while the argument is a perfectly acceptable value of about
0.6).

If we add a dummy statement like:

aa =log(r)

as one of the first statements, the value of aa becomes NaN and some
later computations
succeed. (NaNs occur at a different positions).

Here is some more information:

Intel Fortran: 9.0
Linux: Red Hat Enterprise Linux, ES release 4.

Has anyone encounter similar problems? Does anyone know how to solve
this problem?

Regards,

Arjen

Hm, things are brightening a bit:
- My original posting reflected the situation with all
sources compiled with debugging on
- I then tried with debugging on and array bound checking
- no error message about possible array bound violation
but the first NaN appears later on
- Without any options (so only the defaults) the first
NaN appears earlier on.

Especially this latter observation means that I have
a lot less code to worry about :)

Regards,

Arjen

It is rather easy to lie about array sizes in a way that confuses
array bounds checking when using F77 (assumed or explicit sizes)
semantics so the lack of out of bounds diagnostics can be misleading.
To check against that you need to use one of the "sturdier" debugging
systems like Salford/Silverfrost that supplies their own descriptors
at all calls. It makes third party compiled libraries "difficult" if
not impossible. (The problem is that the "new" declaration is not checked
against the "old" declaration across the call but the subscript checking
is only against the "new" declaration and so can be easily mislead.
The better systems check against the descriptors but that requires much
more information than the "traditional" Fortran implementation to be
available at the call.)

When you get into this sort of problem it is time to think multiple
compilers, and even other operating systems. Salford is on Windows.
The choice is between bowing to the needs of the other system (i.e.
running under Windows for a while) or continuing to battle with
ineffective tools. It sounds like you have all sources readily
available so using Salford for a while may not be much of a bother.- Tekst uit oorspronkelijk bericht niet weergeven -

- Tekst uit oorspronkelijk bericht weergeven -

Well, the program runs under Windows, using CVF 6.6C (and has
been developed on several platforms over the years), so we
were unhappily surprised to see these nasty problems occur
under Linux.

To further elaborate on the problem:

The program uses a single REAL array stored in a blank COMMON
block to pass the data around. This REAL array is used as
double precision REAL data and as double precision COMPLEX data
by passing various array elements to the subroutines involved.
(The pieces that arise that way do _NOT_ overlap - I checked)

This is _NOT_ the cause of the problem though:
When I replace that REAL array by a double precision array,
the _SAME_ problem occurs.

My stragegy right now is to radically skip pieces of the
program that seem irrelevant to the computations that show
the problem. I will even try if valgrind offers any insight.

But the problem is very resilient: I have experimented with
many different changes to the code (explicit declaration of
all variables, using INTRINSIC, changing the type of the array
as described above), and most have no effect on the symptoms.

Adding one write statement does make the NaNs disappear, but
that hardly seems a good solution.

Regards,

Arjen

.

Relevant Pages