- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Hi all,
I just installed Intel Fortran Compiler for Linux (IA32). I followed the steps of installation and I checked with a given example that it works. Everything OK.
Then I tried to compile an example of mine, written in F77. To be sure that all the environment variables are loaded I source the ifortvars.sh at the beginning of my session. To use this code I must first build some libraries, what I did with ifort. Everything went well. The libraries were built without any error message. Then, to run the code, I have an input file which must be compiled and linked to the libraries. Everything goes well, the executable is made without any error. However, the executable does nothing. Does any one have an idea ? First question, is ifort compatible with F77 programs ? Is it due to a flag option missing ? I am not familiar with the options of ifort...
Many thanks in advance.
I just installed Intel Fortran Compiler for Linux (IA32). I followed the steps of installation and I checked with a given example that it works. Everything OK.
Then I tried to compile an example of mine, written in F77. To be sure that all the environment variables are loaded I source the ifortvars.sh at the beginning of my session. To use this code I must first build some libraries, what I did with ifort. Everything went well. The libraries were built without any error message. Then, to run the code, I have an input file which must be compiled and linked to the libraries. Everything goes well, the executable is made without any error. However, the executable does nothing. Does any one have an idea ? First question, is ifort compatible with F77 programs ? Is it due to a flag option missing ? I am not familiar with the options of ifort...
Many thanks in advance.
링크가 복사됨
8 응답
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
ifort supports F77 programs and there's no option needed. How do you know that the executable "does nothing"? Does the program write to a file?
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
The code prints to the screen some data and also writes some files. But
nothing. All these operation normally take several minutes with g77.
Here, I type enter and that's it, nothing happens.
I tried a basic f77 example (print *,'Hello !' !!), it works. So it might be something with my code.
I used the option -warn to see...I have some warnings because some variables have not been given an explicit type, some variables have not been used and some source lines have been truncated. Just warnings...could it be that ?
Thanks in advance for your help.
I tried a basic f77 example (print *,'Hello !' !!), it works. So it might be something with my code.
I used the option -warn to see...I have some warnings because some variables have not been given an explicit type, some variables have not been used and some source lines have been truncated. Just warnings...could it be that ?
Thanks in advance for your help.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
To explain you a little bit more how my code works with g77...I replaced g77 by ifort and removed the options.
First I build the libraries .a. The objects are created from .f files and put into the libraries .a.
Then I compile my input and link it to the libraries as follows and with the following options:
FFLAGS="-c -Wuninitialized -O2 -ffortran-bounds-check -funix-intrinsics-delete -malign-double -I$DIRRECTORY/source/include"
This is for g77.
Then compilation:
g77 FFLAGS$ input.f
And linking:
g77 -o name_executable input.o -L$LIBDIRECTORY -llibrary
So, is it correct to just replace g77 by ifort ? Should I change something else (except the options that are not adequate) ?
Xtof
First I build the libraries .a. The objects are created from .f files and put into the libraries .a.
Then I compile my input and link it to the libraries as follows and with the following options:
FFLAGS="-c -Wuninitialized -O2 -ffortran-bounds-check -funix-intrinsics-delete -malign-double -I$DIRRECTORY/source/include"
This is for g77.
Then compilation:
g77 FFLAGS$ input.f
And linking:
g77 -o name_executable input.o -L$LIBDIRECTORY -llibrary
So, is it correct to just replace g77 by ifort ? Should I change something else (except the options that are not adequate) ?
Xtof
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
The only time I've seen something like this is when a program tries to use much more memory than the system has available in physical+swap. How much VM does your system have, and how much data is your code trying to use?
As an example, if I try this:
program foo
real :: x(400000000)
x = 1.0
print*, "hello, I hope!"
end program foo
Now if I got the number of zeros right, which is sometimes a challenge before my morning coffee, this should TRY to allocate 1.6GB. If I try to run this on a system with 1GB physical RAM and 500MB of swap, the message is usually 'killed' immediately with no other indication. Is this what you see and are doing? Here, this is the example on a 32bit Linux with just 512MB:
$ ifort -o ff ff.f90
./ff
Killed
$
cat /proc/meminfo to determine how much memory you have. As a rule of thumb, I try to keep my apps at 80% or LESS than physical memory (RAM) in footprint. This to make sure I fit in physical memory and don't page or swap (killing performance).
ron
As an example, if I try this:
program foo
real :: x(400000000)
x = 1.0
print*, "hello, I hope!"
end program foo
Now if I got the number of zeros right, which is sometimes a challenge before my morning coffee, this should TRY to allocate 1.6GB. If I try to run this on a system with 1GB physical RAM and 500MB of swap, the message is usually 'killed' immediately with no other indication. Is this what you see and are doing? Here, this is the example on a 32bit Linux with just 512MB:
$ ifort -o ff ff.f90
./ff
Killed
$
cat /proc/meminfo to determine how much memory you have. As a rule of thumb, I try to keep my apps at 80% or LESS than physical memory (RAM) in footprint. This to make sure I fit in physical memory and don't page or swap (killing performance).
ron
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
I have 1 GB + 256 MB of RAM. However, I have a little less for Linux
since I am running the Suse 10.0 under Virtual box. For Linux I
allocated 800 MB + 512 MB swap. Windows XP is taking the rest.
I tried your small program, and as you said, it was killed. I checked the memory after that and it was full. With my program it is not even that. I don't even get the message Killed. After trying to run my program I checked the memory with cat /proc/meminfo and the memory was ok, around 400 MB RAM left. So it might be something else.
Do you think that replacing g77 by ifort in the commands (see my previous post) for compiling and linking is enough ? Should I use some options proper to ifort when compiling and linking ? For instance, what is the equivalent to -funix-intrinsics-delete in ifort ?
Xtof
I tried your small program, and as you said, it was killed. I checked the memory after that and it was full. With my program it is not even that. I don't even get the message Killed. After trying to run my program I checked the memory with cat /proc/meminfo and the memory was ok, around 400 MB RAM left. So it might be something else.
Do you think that replacing g77 by ifort in the commands (see my previous post) for compiling and linking is enough ? Should I use some options proper to ifort when compiling and linking ? For instance, what is the equivalent to -funix-intrinsics-delete in ifort ?
Xtof
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
There is no ifort equivalent of that g77 option.
I would suggest at this point that you contact Intel Premier Support and attach your program so that we can see what might be wrong. It's very difficult to speculate here without seeing the source.
I would suggest at this point that you contact Intel Premier Support and attach your program so that we can see what might be wrong. It's very difficult to speculate here without seeing the source.
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
Xtof,
Can you attempt to run the application in Debug mode via a Step Into as opposed to breaking at the 1st statement in the application. That is to say start debugging at the C Runtime initialization code for the application.
If the application fails to load up to that point then it is a execuitable image problem.
If it makes it to the C runtime initialization code then it is an allocation problem (either heap or stack). By tracing through the initialization code you might discover just what is causing the problem.
Jim Dempsey