Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

f77 > ifort

sony97onegmail_com
1,148 Views
Hello,

I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.

Which are the the changes I have to do?

Thanks in advance,
Sony
0 Kudos
9 Replies
Ron_Green
Moderator
1,148 Views
Hello,

I have set up Ifort on Linux Ubuntu 9.04 32Bits.
I worked with F77 and all was good. Now with ifort , compilation : OK, calculation : OK but NaN in results files.

Which are the the changes I have to do?

Thanks in advance,
Sony

I would try to isolate the cause of the fault. Compile with:

-g -traceback -fp-stack-check -check all -fpe0 -warn all

and run.
This will trap on floating point exceptions, look for array boundary problems, check for illegal calling sequences, and a whole lot of other checks.

ron
0 Kudos
sony97onegmail_com
1,148 Views
Thanks for your help,

I have this warning message :

warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.

I have another program in explicit (with no "implicit none") and it work and it is very fast with Intel Compiler ;)!

I can give you the code if it's possible...

Thanks again
Sony

Quoting - Ronald Green (Intel)

I would try to isolate the cause of the fault. Compile with:

-g -traceback -fp-stack-check -check all -fpe0 -warn all

and run.
This will trap on floating point exceptions, look for array boundary problems, check for illegal calling sequences, and a whole lot of other checks.

ron

0 Kudos
Ron_Green
Moderator
1,148 Views
The -warn all has caught something:

warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.

you have truncated the actual message: it should look something like this:

testit.f(3): warning #5194: Source line truncated.

This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.

OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)

Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.

Then once that is done, you can remove -warn all and continue with the other compiler options given.


0 Kudos
sony97onegmail_com
1,148 Views
Ok,

When I extended I have these messages :

/tmp/ifortDb0QBC.o: In function `lblirt':
/home/sony/Bureau/LBLIRT/lblod.f:188: undefined reference to `sgeisac_'
BIB/bib.a(CONTINUUM-NEW.o): In function `cont_o3':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:285: undefined reference to `o3chapw_'
BIB/bib.a(CONTINUUM-NEW.o): In function `continuumnew':
/home/sony/Bureau/LBLIRT/BIB/CONTINUUM-NEW.f:45: undefined reference to `o3chapw_'
BIB/bib.a(CONTNM.o): In function `abscnt':
/home/sony/Bureau/LBLIRT/BIB/CONTNM.f:30: undefined reference to `o3chapw_'
sony@sony-desktop:~/Bureau/LBLIRT$

Previously:

SURFAC.f(49): warning #6717: This name has not been given an explicit type. [MI]
REAL BDR( MI,0:* ), BEM(*), CMU(*), CWT(*), EMU(*),
--------------------^
SURFAC.f(50): warning #6717: This name has not been given an explicit type. [MXUMU]
$ HLPR(0:*), RMU( MXUMU,0:* ), UMU(*),
-------------------------------^

But MI and MXUMU are define in the main code lblod.f

In /home/sony/Bureau/LBLIRT/BIB/ I have put my subroutines
I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c -O3 *.f
rm D1MACH.o
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -c D1MACH.f
ar r bib.a *.o
rm *.o

In in /home/sony/Bureau/LBLIRT/ I compile :
ifort -g -traceback -fp-stack-check -check all -fpe0 -warn all -O3 $1.f -o $1 BIB/bib.a

All lines are less 72 characters and it run with f77.

I really want to use Intel Compiler because I saw that it's faster in other program... ;)

Thanks
Sony

Quoting - Ronald Green (Intel)
The -warn all has caught something:

warning #6717: This name has not been given an explicit type.
warning #5194: Source line truncated.

you have truncated the actual message: it should look something like this:

testit.f(3): warning #5194: Source line truncated.

This is because you have a fixed-format file (.f for example, or .f77) and you've exceeded column 72. Note that the "testif.f(3)" tells me this warning is in file "testit.f" and the line number is 3 "(3)". Go to that line and find the problem.

OR you can use -extend-source 80 to make the compiler accept source out to column 80 (132 is also an option if you need it)

Now the message: "name has not been given an explicit type" Is this on the same line as the 'truncated' message? If so, the extend-source will fix it. If not, you have an undeclared variable. Go to the line indicated in "(#)" to find it and fix it.

Then once that is done, you can remove -warn all and continue with the other compiler options given.



0 Kudos
Ron_Green
Moderator
1,148 Views
Sony,

On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.

ron
0 Kudos
sony97onegmail_com
1,148 Views
Hello,

In attachement you will find the whole 'clean' directory ;)!
I put 2 versions :
1 with f77 and the results files in RES
1 with ifort and the results files in RES with NaN

You have to remove "bib.a" in BIB directory then

First run "./job" in BIB directory (to create bib.a) then "./compil lblod" in the parent directory then "./lblod" to run the program.

Thanks
Sony


Quoting - Ronald Green (Intel)
Sony,

On my signature is a link that describes how to upload files to this forum. Would you like to tar up the whole directory and upload? Do a 'clean' first before the tar.

ron

0 Kudos
TimP
Honored Contributor III
1,148 Views
Did you watch the screen echo when you compiled? You have constants which underflow to zero at compile time, as if your application depended on a platform which automatically extends range beyond the range of IEEE default real. Did you try setting -r8?
You have code which depends on your use of -g to turn off optimizations. As has been discussed many times on these forums, it is better to update your source code to use intrinsics such as EPSILON and TINY, rather than depending on platform dependent code last updated 25 years ago.
The source code appears to be intentionally obfuscated, which is not a good sign.
Nevertheless, it does run (painfully slowly) with your compile scripts and a recent ifort version.
0 Kudos
Ron_Green
Moderator
1,148 Views
Sony,

As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f

line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code

line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)

It is hard to say if there are more bugs in there. This code does look quite old.

ron

0 Kudos
sony97onegmail_com
1,148 Views
Thanks Tim & Ron,
-r8 solve the problem!

Sony

Quoting - Ronald Green (Intel)
Sony,

As Tim said, there is some really old and bad code that needs to be addressed. BIB/GEISHA.f

line 207, 259, and 349 have hardcoded some small numbers that do not properly fit into 32bits. You were lucky that f77 extended these to denormalized values and that f77 does not flush denormals to zero. As you noticed, ifort will not do this: other compilers may or may not. So it is best to correct the bad code

line 207: SMAX=TINY(SMAX)
line 259: SMAX=TINY(SMAX)
line 349: AMAX=TINY(AMAX)

It is hard to say if there are more bugs in there. This code does look quite old.

ron


0 Kudos
Reply