- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now, we have surpassed the 2GB in statically allocated data limit. I knew that would bring us some problems.
I'm compiling with the following debug options (latest iforte 9.0):
-O0 -fpe0 -g -openmp -fpic -i_dynamic -mcmodel=large -auto-scalar -traceback
also with the optimizations (on Xeon EM64T):
-O2 -xP -fPIC -openmp -i_dynamic -mcmodel=large -auto-scalar
Removing the -auto-scalar option makes it compile without problems, but later fails to run with a segmentation fault. Linking errors (with debug on) are the following:
/tmp/ifortfOKjD2.o: In function `timestep':
nextstep.f:653: relocation truncated to fit: R_X86_64_PC32 against `.bss'
/tmp/ifortfOKjD2.o: In function `lost_particles':
nextstep.f:733: relocation truncated to fit: R_X86_64_PC32 against `.bss'
/tmp/ifortfOKjD2.o: In function `lista':
nextstep.f:763: relocation truncated to fit: R_X86_64_PC32 against `.bss'
nextstep.f:789: relocation truncated to fit: R_X86_64_PC32 against `.bss'
/tmp/ifort3X7vjE.o: In function `sph':
sph.f:41: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: relocation truncated to fit: R_X86_64_PC32 against `.bss'
sph.f:94: additional relocation overflows omitted from the output
with optimization flags, the errors differ:
/tmp/ifort7xOmsU.o: In function `next_step_':
nextstep.f:(.text+0x416): relocation truncated to fit: R_X86_64_PC32 against `::___kmpv_zeronext_step(void)'
nextstep.f:(.text+0xb03): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeronext_step__2'
nextstep.f:(.text+0xd5c): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeronext_step__5'
/tmp/ifort7xOmsU.o: In function `active_particles_':
nextstep.f:(.text+0x230e): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroactive_particles__8'
nextstep.f:(.text+0x2496): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroactive_particles__12'
nextstep.f:(.text+0x2555): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroactive_particles__19'
nextstep.f:(.text+0x264f): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroactive_particles__14'
nextstep.f:(.text+0x275a): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroactive_particles__17'
/tmp/ifort7xOmsU.o: In function `lista_':
nextstep.f:(.text+0x4100): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zerolista__29'
/tmp/ifort7xOmsU.o: In function `accel_':
nextstep.f:(.text+0x4b29): relocation truncated to fit: R_X86_64_PC32 against `___kmpv_zeroaccel__34'
nextstep.f:(.text+0x4cf6): additional relocation overflows omitted from the output
I found out that by including the offending variables (the cause is always statically allocated variables with size given by a parameter, or even scalars) inside a common, it no longer faults at that point. That can also be achieved by adding the automatic option to the declaration or by making them allocatable and allocating them at the beginning of the function.
Any clues? As you can see I've i ncluded all the options suggested for large arrays in these forums.
With the 9.0 ia64 compiler on an Altix machine compiles and works fine.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Cheers!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have same problem when I compile my code. I have seen in forum of intel, but I didn't resolve my problem.
The error it gets is:
relocation truncated to fit: R_X86_64_PC32 against `.bss'
additional relocation overflows omitted from the output.
I used these options, as suggested by forum intel:
-fPIC -shared-intel -mcmodel=large.
Can you help me? Have you a solution for my problem?
Thank you very much
gelsa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
----------------------------------------------------------------------------------------------------------------------------------------
ifort -o csd.x -fpic subseltcc.o csd.o csdsub.o csdvec.o rle.o diis.o linpakd.o diveps.o linalg.o time_LINUX.o utils.o
csdsub.o: In function `t1sqr_':
csdsub.f:(.text+0xccbb): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xcd52): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xcdb1): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xd066): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xd06d): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.o: In function `setreg_':
csdsub.f:(.text+0xdae7): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.o: In function `selt1_':
csdsub.f:(.text+0xde48): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xdf02): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xdf81): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.o: In function `prt_':
csdsub.f:(.text+0xe9d1): relocation truncated to fit: R_X86_64_PC32 against `.bss'
csdsub.f:(.text+0xea07): additional relocation overflows omitted from the output
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
The recommended flags to use when you have >2GB of static data are:
-mcmodel medium -shared-intel
(-mcmodel large -shared-intel should also work, the only difference is that it also allows your code size to be >2GB, which is pretty rare).
You should NOT use -fpic at the same time, as the original poster to this thread pointed out.
I think the confusion arises because libraries that have not themselves been built with -mcmodel medium, (because they do not contain > 2 GB of static data), must instead be built with -fpic so that they use full addressing and can be linked with objects that were built with -mcmodel medium. Otherwise, you get the dreaded "relocation error" from the linker.
The Intel compiler runtime library is not built with -mcmodel medium. The shared version of the runtime library is built with -fpic, but the static version is not. This is why you need to use the flag -shared-intel when compiling your code with -mcmodel medium.
Evidently, users are finding the mention of -fpic in the compiler documentation for -mcmodelto be confusing. We'll try to improve that.
I don't know if there is any fundamental reason why -fpic and -mcmodel medium could not be made to work together. There didn't seem to be a functional need for that, and it hasn't been done, but perhaps it could be looked into.
Please let us know whether building with -mcmodel medium -shared-intel but without -fpic solves your relocation problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I has the same problem, I had to allocate an array with double precision, 5 columns, 25000*300*5 for a 2D output of a simulation.
This works great both with medium and large syntax also in Fortran77.
Thanks again and the best regards
Herger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recently started a post related with this instruction, about HOW exactly use that instruction because inolder versions of the compiler and a linux-based machine it works well. But now, I am working on two Mac OS machines, each one with different versiones of the compilers and I am not able to use -mcmodel.
For version 11.1.058 the error message is: "ifort: command line warning #10152: option '-mcmodel medium' not supported" whereas for a version 10.5.8 it is worse, the message is: "catastrophic error: **Internal compiler error: internal abort** Please report
this error along with the circumstances in which it occurred in a Software Problem Report."
So could someone please tell me how to make the instruction works now?
Thanx!
Hi,
The recommended flags to use when you have >2GB of static data are:
-mcmodel medium -shared-intel
(-mcmodel large -shared-intel should also work, the only difference is that it also allows your code size to be >2GB, which is pretty rare).
You should NOT use -fpic at the same time, as the original poster to this thread pointed out.
I think the confusion arises because libraries that have not themselves been built with -mcmodel medium, (because they do not contain > 2 GB of static data), must instead be built with -fpic so that they use full addressing and can be linked with objects that were built with -mcmodel medium. Otherwise, you get the dreaded "relocation error" from the linker.
The Intel compiler runtime library is not built with -mcmodel medium. The shared version of the runtime library is built with -fpic, but the static version is not. This is why you need to use the flag -shared-intel when compiling your code with -mcmodel medium.
Evidently, users are finding the mention of -fpic in the compiler documentation for -mcmodelto be confusing. We'll try to improve that.
I don't know if there is any fundamental reason why -fpic and -mcmodel medium could not be made to work together. There didn't seem to be a functional need for that, and it hasn't been done, but perhaps it could be looked into.
Please let us know whether building with -mcmodel medium -shared-intel but without -fpic solves your relocation problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I recently started a post related with this instruction, about HOW exactly use that instruction because inolder versions of the compiler and a linux-based machine it works well. But now, I am working on two Mac OS machines, each one with different versiones of the compilers and I am not able to use -mcmodel.
For version 11.1.058 the error message is: "ifort: command line warning #10152: option '-mcmodel medium' not supported" whereas for a version 10.5.8 it is worse, the message is: "catastrophic error: **Internal compiler error: internal abort** Please report
this error along with the circumstances in which it occurred in a Software Problem Report."
So could someone please tell me how to make the instruction works now?
Thanx!
This option, mcmodel, is only available for Linux.
On Mac OS - if you are using OS X 10.5.x or 10.6.x you will want the latest 11.1 compiler. The compiler support for Mac OS and Xcodes evolve rapidly.
First, find get the latest 11.1 compiler. Next, locate the documentation: Particularly the Release_NotesF.pdf. It is located in /opt/intel/Compiler/11.1/067/Documentation/en_US
This lists the compatibility for your compiler.
Next, go into: /opt/intel/Compiler/11.1/067/Documentation/en_US/compiler_f/ and open compiler_documentation_f.html
Under here, open the Intel Fortran Compiler User and Reference Guides. Open 'Compiler Options' for full information on the compiler.
For large memory on Mac: You must use -m64 which is the default for the 64bit compiler.
Make sure you have the 64bit compiler: ifort -V
Intel Fortran Intel 64 Compiler Professional for applications running on Intel 64, Version 11.1 Build 20090827 Package ID: m_cprof_p_11.1.067
Copyright (C) 1985-2009 Intel Corporation. All rights reserved.
Note the "Intel 64" string, it must be there.
ron
ron
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've got the dreaded rellocation error. I'm currently compiling with:
-mcmodel medium -shared-intel -assume byterecl -O3 -fast
I'm using ifort 11.1. I get
/opt/intel/Compiler/11.1/064/lib/intel64/libifport.a(etime.o): In function `dtime_':
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x10d): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp1'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x148): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x1bb): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x1e0): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x205): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x226): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x22d): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x24c): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp1'
/opt/intel/Compiler/11.1/064/lib/intel64/libifport.a(etime.o): In function `dtimer8_':
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x2cc): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp1'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x307): relocation truncated to fit: R_X86_64_PC32 against `tarray_tmp0'
/export/users/nbtester/efi2linux_nightly/branch-11_1/20091202_010000/libdev/libifport/portability/etime.c:(.text+0x36f): additional relocation overflows omitted from the output
I'm able to compile working code with gfortran. Any other ideas?
Thanks,
Payton
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One of the effects of the "-fast" switch is to link against the static libraries, so perhaps the -shared-intel is being overwritten.
Can you try putting -shared-intel at the *end* of your command line, at least after the -fast?
--Lorri
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay moving -shared-intel to the end did not work. However I removed -fast and the code compiled. According to the manual only the -xHOST flag (set during fast) can be overwitten. The answer was to include all the flags -fast includes without the -static.
Thanks for the help,
Payton
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page