intel compiler error : relocation truncated to fit: R_X86_64_PC32

Resolving The Problem

What is exactly this error I get when I try to recompile my code using the intel compiler ?
relocation truncated to fit: R_X86_64_PC32 for__l_excpt_info when using the intel compiler
This has nothing to do with the physical memory on the nodes.
It is all about 64 bit and memory model. Basically, when you need more than
2GB of data (you can check it using the gnu size), you will have to use
another memory model (medium; the default is small). For example : N=13 :
(bss : unitialized static data)

[user1@frontend host1]$ size hsnj_obsd_ft_64.f.x
text data bss dec hex filename
420494 51052 1390428072 1390899618 52e771a2
hsnj_obsd_ft_64.f.x

But, for N=14 :

[user1@frontend host1]$ ifort -c hsnj_obsd_ft_64.f
[user1@frontend host1]$ size hsnj_obsd_ft_64.o
text data bss dec hex filename
1312 128 2168857600 2168859040 814629a0
hsnj_obsd_ft_64.o

The extra compiler option to use should be something like -mcmodel=medium
but you will have to recompile all the libraries.

Here are some detail information for you.

------------------------------------------------------------------------------

Small, Medium and Large Memory Models on Intel EM64T

Applications built to take advantage of Intel EM64T can be built with one of three memory models:

Small (default)

Code and data are restricted to the first 2GB of address space, so that all accesses of code and data can be done with Instruction Pointer (IP)-relative addressing

Medium (|-mcmodel=medium|) Code is restricted to the first 2GB, no restriction on data; code can be accessed with IP-relative addressing, but access of data must use absolute addressing

Large (|-mcmodel=large|) No restrictions on code or data; accesses to both code and data use absolute addressing

IP-relative addressing requires only 32 bits, whereas absolute addressing requires 64-bits. This can affect code size and performance (IP-relative addressing is somewhat faster.)

*Note: *When the medium or large memory models are specified, you must also specify -i-dynamic to ensure that the correct dynamic versions of the Intel run-time libraries are used.

When shared objects (.so) are built, Position-Independent Code (PIC) is specified (|-fpic| is added by the compiler driver) so that a single .so can support all three memory models. However, code that is to be placed in a static library, or linked statically, must be built with the proper memory model specified. Note that there is a performance impact to specifying the Medium or Large memory models.

--------------------------------------------------------------------------------

We did some tests in Platform house.

Test 1 : no particular option (code adapted from http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html#ps)

[user1@frontend host1]$ ifort -o test2 simple.f90 /opt/intel/fce/9.0/lib/libifcore.a(for_init.o)(.text+0xb): In function

`for__signal_handler':

...

: additional relocation overflows omitted from the output

Test 2 : using the mcmodel=medium option

[user1@frontend host1]$ ifort -o test2 -mcmodel=medium simple.f90

/opt/intel/fce/9.0/lib/libifcore.a(for_init.o)(.text+0xb): In function

`for__signal_handler':

: relocation truncated to fit: R_X86_64_PC32 for__l_excpt_info

...

: additional relocation overflows omitted from the output

Test 3 : -mcmodel=medium and -i-dynamic is the winner (-i-dynamic is for dynamic link)

[user1@frontend host1]$ ifort -mcmodel=medium -i-dynamic -o test simple.o

[user1@frontend host1]$ size test

text data bss dec hex filename

2472 688 4000000032 4000003192 ee6b3478 test