Intel
From UF HPC Wiki
Contents |
Documentation
Compilers
Fortran
Environment
You do not have to source any environment variables or anything. This is now done automatically for you and the proper paths should be set.
If you do have issues with this, please file a bug report in the Bugzilla.
Debugging Process
When you are compiling a Fortran program, try compiling it without any optimizations or other strange command line options first to see if it will compile at all. Once it compiles straight from the command line, then try adding in extra optimizations and other options to see if they work with your code.
LD_LIBRARY_PATH
When you use ifort to link a program, it automatically tells the linker (GNU ld) where to find ifort's fortran support libs. You can see this if you give the '-v' option to ifort at link time; ifort automatically gives the linker the flags "-L/opt/intel/fce/9.1.037/lib -lsvml -lifport -lifcore -limf". So you get that for free, without specifying any fancy linker options, and without even telling ifort where to find the its own libs. The resulting program will be linked dynamically against the necessary ifort libs.
At run time it is a different story. The linked program knows it is linked against a bunch of libraries, and knows what they are called, but there is no information recorded in the executable about where to find them. The loader (ld-linux.so) uses its own means to try to find the libraries - there are some built-in paths it will search (like /lib and /usr/lib) as well as places listed in /etc/ld.so.conf - this you get for free. For any shared libraries you need that don't live in these "standard" places, you need to tell the loader how to find them. That is what LD_LIBRARY_PATH is for.
In the case of the Intel compilers and supporting libs, the installation procedure installed them into a "non-standard" place (from ld-linux.so's perspective), and ld.so.conf was not touched. Hence, LD_LIBRARY_PATH must be used.
Minutae
Ran into one annoyance with OpenMPI on the altix in ompi/tools/ompi_info/output.cc ; seen on other ia64 apps built with intel compilers as well:
...
/usr/include/sys/ucontext.h(52): error: identifier "__builtin_offsetof" is
undefined
unsigned long _pad[_SC_GR0_OFFSET/8];
^
/usr/include/sys/ucontext.h(52): error: function call is not allowed in a
constant expression
unsigned long _pad[_SC_GR0_OFFSET/8];
^
/usr/include/sys/ucontext.h(52): error: type name is not allowed
unsigned long _pad[_SC_GR0_OFFSET/8];
^
/usr/include/sys/ucontext.h(52): error: expected a ")"
unsigned long _pad[_SC_GR0_OFFSET/8];
^
/usr/include/sys/ucontext.h(52): error: expected a "]"
unsigned long _pad[_SC_GR0_OFFSET/8];
^
/usr/include/sys/ucontext.h(52): error: expected a ";"
unsigned long _pad[_SC_GR0_OFFSET/8];
^
The problem is that _SC_GR0_OFFSET is not a compile-time constant as far as icc is concerned.
ucontext.h is coming in through the include for signal.h. Luckily, signal.h is totally unnecessary. So the workaround is to just comment out the include.
It compiles fine with g++ without the hack, as the GNU people worked around this when gcc/g++ were built; here's the comment from the GNU 'fixincludes':
/* The /usr/include/sys/ucontext.h on ia64-*linux-gnu systems defines * an _SC_GR0_OFFSET macro using an idiom that isn't a compile time * constant on recent versions of g++. */
Problems
What's the problem with feupdateenv?
If you see the warning:
/usr/local/intel/fce/9.1.036/lib/libimf.so: warning: warning: feupdateenv is not implemented and will always fail
Add -i_dynamic to ifort options.
relocation truncated to fit: R_X86_64_PC32
You might see errors similar to the following:
/tmp/ifortlhbXWg.o(.text+0x1c46): In function `vmdplot1_': : relocation truncated to fit: R_X86_64_PC32 zbc_
There is a solution to this. If you add the following flag to your compile lines, this should fix the problem:
-mcmodel=medium
We have also seen situations where the mcmodel needed to be changed to large instead of medium. This error occurs when you start asking for more than 2gb of memory in a program.
