Fortran - repost: very difficult debbuging with ifort

Author

repost: very difficult debbuging with ifort

unknown

2006-04-13, 7:03 pm

Dear all,
I'm reposting since an erroneous description
of the problem leaded to right but unessential
answers. I apologize:

It was atan2(0., -20.)
Anyway, I now understand
that probably one compiler promote
0. and 20. to real*8 before the call to atan2.

If this is the problem,
I need to make the linux compiler (ifort)
to behave like the other one (microsoft)
do you think it is possible?

Thanks

---Begin of old post, with corrections---

Dear all,
I'm trying to debug a very long code
which is giving different result when
running under win (with Microsoft compiler) and
under fedora c4 (with ifort).
The main problem at this stage is that
under win: (just an example)
real*8 var
var=atan2(0., -20.)=3.14159265358979
but under linux:
var=atan2(0., -20.)=3.14159274101257

I'm assuming that the right result is the first
one, and maybe I'm passing some wrong flag
to the ifort compiler.
Unfortunately the error seems very small, but causes
a very big discrepancy after few iterations of
my code.
Can you help me?

Thanks

Ale

Richard E Maine

2006-04-13, 7:03 pm

unknown <qewqwe@qwe.qw> wrote:

> It was atan2(0., -20.)
> Anyway, I now understand
> that probably one compiler promote
> 0. and 20. to real*8 before the call to atan2.
>
> If this is the problem,
> I need to make the linux compiler (ifort)
> to behave like the other one (microsoft)
> do you think it is possible?

I don't know what compiler options ifort might have for this, but far
better is to fix the code so that it actually says what you want -
rather than having the code say one thing and trying to figure out how
to make the compiler do something other than that.

If you want the literals to be double precision, you can write them as

atan2(0.d0, -20.d0)

Then it will work in any compiler. (Or you can use the f90 kind syntax,
but I'll keep this simple for now).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Steve Lionel

2006-04-13, 7:03 pm

unknown wrote:

> It was atan2(0., -20.)
> Anyway, I now understand
> that probably one compiler promote
> 0. and 20. to real*8 before the call to atan2.
>
> If this is the problem,
> I need to make the linux compiler (ifort)
> to behave like the other one (microsoft)
> do you think it is possible?

My guess is that you used an option on the Microsoft compiler to cause
the default real kind to be double precision. With the Intel compiler,
that is -r8, but I agree with the others that this is not the best
solution and that you should instead give your variables and constants
the exact datatype and kind (single, double, etc.) that your application
desires.

If you would like further advice on using the Intel compilers, please
visit our user forums at http://softwareforums.intel.com/

Steve Lionel
Developer Products Division
Intel Corporation

glen herrmannsfeldt

2006-04-14, 7:05 pm

Steve Lionel <Steve.Lionel@removemeintel.com> wrote:
> unknown wrote:

(snip)
[color=darkred]
> My guess is that you used an option on the Microsoft compiler to cause
> the default real kind to be double precision. With the Intel compiler,
> that is -r8, but I agree with the others that this is not the best
> solution and that you should instead give your variables and constants
> the exact datatype and kind (single, double, etc.) that your application
> desires.

It could be, but any compiler that generates x87 code inline and doesn't
change the precision mask or store intermediate values will generate
extra precision. It might be that some set to 53 bits, but I don't
know that any set 24 bits on all single precision operations.

Though generating x87 code inline doesn't allow for the checking
that should be done on the arguments, and I believe is not recommended
by intel.

-- glen

Sponsored Links