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.

On Thu, 04 Oct 2007 06:35:05 -0700, Arjen Markus
wrote in <1191504905.477207.290650@r29g2000hsg.googlegroups.com>:

I've been doing a lot of DP logs lately (roughly 8.5E11 in 800
minutes CPU time.. :-) and haven't seen any problem.

Arjen:

The LOG function is used so much that I am skeptical that this is the
source of this problem. If the code is complicated it is possible that
the compiler is having other problems that manifest themselves in the
LOG call, but first I suggest you

1. Insert IMPLICIT NONEs in all codes/modules to activate type
checking
2. Turn on array bounds checking
3. Wrap codes with modules to make all interfaces explicit
4. Ensure that the code does not have its own LOG that is being used
instead of the standard LOG. (INTRINSIC LOG would help here).

On 4 okt, 18:58, wclod...@lanl.gov wrote:

I was afraid it would not be that easy ;).

The code is voluminous and uses a complicated memory management scheme
(most of it dates from the FORTRAN 77 era). That pretty much prohibits
array bounds checking.

"Arjen Markus" wrote in message
news:1191566230.964301.246240@g4g2000hsf.googlegroups.com...

Hello,

Arjen Markus wrote:

This point, to me, indicates that one should verify whether the problem
appears in the optimized code only, or in optimized code and debug code.
(That is, code compiled with -O, n>0 only, or compiled with -O and
compiled with -g.)

If the problem appears in the optimized code only, a binary search
of object modules for the offending procedure is one possibly useful
course of action. This will at least point to the offending procedure.

The point is that modifying every file is an O( n) operation (where n
is the number of files) while a binary search
for the offending procedure is O( log( n)).

On Oct 4, 2:35?pm, Arjen Markus wrote:

David Flower wrote:

[snip]

log(x)= 2.302585 * log10(x) = log10(x) / log10(exp(1.0))

I doubt it would matter, especially if the log10 intrinsic is based on
the log intrinsic

John Smith wrote:

(snip)

For x87 both are based on log2(x).

-- glen

"Arjen Markus" wrote in message
news:1191566230.964301.246240@g4g2000hsf.googlegroups.com...