ifort fatal error lnk 1248 image size (CAB9600) larger than max 80000000

[runnin__ken]

I realize the problem with this most likely is a large array on the stack - that I need to move to allocate. But is there any way to find which array this is? the program is several hundred subs with over 100k LOC. Any help. works fine in *nix

I am in visual studio environ, with intel vis fortran. 

Also, I am in x64, I have enable large memory aware, set link optimization heap to 0. 

What else can I try? 

thanks

[Steve_Lionel · Accepted solution]

This is not a stack array, it's a large, statically declared array, likely in COMMON. The individual array won't be over 2GB , because the compiler would tell you if it was, but if multiple arrays are large, you can also hit the limit.

The Windows 2GB limit on static code and data is baked into the EXE file format and can't be worked around, even on x64. See https://software.intel.com/en-us/articles/memory-limits-applications-windows

You can generate a link map and it will tell you the sizes of the various contributions. A compiler listing will also tell you array sizes. But first take a look at COMMON declarations and look for very large arrays.

[JohnNichols]

Steve Lionel (Ret.) (Blackbelt) wrote:

This is not a stack array, it's a large, statically declared array, likely in COMMON. The individual array won't be over 2GB , because the compiler would tell you if it was, but if multiple arrays are large, you can also hit the limit.

The Windows 2GB limit on static code and data is baked into the EXE file format and can't be worked around, even on x64. See https://software.intel.com/en-us/articles/memory-limits-applications-win...

You can generate a link map and it will tell you the sizes of the various contributions. A compiler listing will also tell you array sizes. But first take a look at COMMON declarations and look for very large arrays.

Yes this is a problem 

[runnin__ken]

Steve Lionel (Ret.) (Blackbelt) wrote:

You can generate a link map and it will tell you the sizes of the various contributions. A compiler listing will also tell you array sizes. But first take a look at COMMON declarations and look for very large arrays.

Do you have any references that can help with this (making and using a linkmap or the compiler listing you mentioned). The plan is to migrate over to modules and dynamic allocation now, but I need to do so in a way that will give us a working exe faster - Ie without having to convert every common. 

I was able to shrink the params file that set the size of the arrays and get a working exe. but I need more mem soon for production runs. 

If there was a way to get a list of arrays and memory storage sizes associated with those, I can make a better plan of attack. Even if it told me which common blocks and sizes would be helpful.

Thanks for your help Dr. Fortran! you've been a great help for many years and glad you are still active here.

[Steve_Lionel]

As I mentioned, a compiler listing file includes the sizes of all fixed-dimension arrays. Use the /list option or, in Visual Studio, Fortran > Output FIles > Source Listing. Here's an example:

Page 1           Source Listing                  _UNNAMED_MAIN$$
2019-11-22 14:22                                 t.f90

      1 real bigarray(10000)
      2 common /cmn/ bigarray
      3 end


ENTRY POINTS

  Name              
                    
 MAIN__             


SYMBOL CROSS REFERENCE

 Name                       Object Declared Type            Bytes Dimen Elements Attributes       References                        
                                                                                                                                    
 CMN                        Common 2                                    40000                                                       
 _UNNAMED_MAIN$$            Prog   1                                                                                                


TYPE COMPONENTS/COMMON VARIABLES

 Name                       Type            Bytes Offset   Dimen Elements Attributes       References                         
                                                                                                                              
 BIGARRAY                   R(4)            4     0        1     10000    COM                     

[jimdempseyatthecove]

First rule of order in converting "legacy" programs into modern code is to:

1) Verify that all named COMMON /YourNameHere/ ... have the exact same variable names and orders. If (when) they differ you must be very careful that any changes (alteration) or removal from one do not adversely affect the other.

2) Find all use of EQUIVILANCE and, if possible, choose one of the names to be your primary name and then use ASSOCIATE to perform the name change in the other source files. *** note, do this also in the situation were a same named COMMON uses different namings.

Once you have that working (compiling and run tests certified) then continue modernizing.

>>I was able to shrink the params file that set the size of the arrays and get a working exe. but I need more mem soon for production runs. 
>>If there was a way to get a list of arrays and memory storage sizes associated with those, I can make a better plan of attack

Because you know the names of the params involved, and what sizes makes it work and what sizes fail, you can search the solution for uses of the params. Probably starting with the largest and working towards the lowest. And identify the arrays, and one by one make them allocatable, add code to allocate and initialize. *** Note, this may be a little more difficult for those arrays that have DATA... initialization, so those arrays could be left for last (these you would likely initialize via READ).

Jim Dempsey

[ysuda]

hello

I am yuji suda and I have the similar  problem in linking an object created by icx.exe (oneAPI tool basekit 2024.1.0).  icx can compile my source but linking the object fails due to 

LINK : fatal error LNK1248: Image size (D761D000) exceeds maximum allowed size (80000000)

I tried compile and link the same source in icx in Linux oneAPI tool base kit, v2024.1.0

and the error message was the following

2024.1.0 Linux icx problem
icx myMain.c
/opt/intel/oneapi/compiler/2024.1/bin/compiler/../../lib/libirc.a(fast_mem_ops.c.o): in function `__cacheSize':
fast_mem_ops.c:(.text.__cacheSize+0x13): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text.__cacheSize+0x25): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
/opt/intel/oneapi/compiler/2024.1/bin/compiler/../../lib/libirc.a(fast_mem_ops.c.o): in function `__libirc_init_cache_tbl()':
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0xbd): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0xc5): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x14a): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x1d2): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x29c): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x612): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x619): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x620): relocation truncated to fit: R_X86_64_PC32 against `.bss._ZL18__libirc_cache_tbl'
fast_mem_ops.c:(.text._ZL23__libirc_init_cache_tblv+0x626): additional relocation overflows omitted from the output
/opt/intel/oneapi/compiler/2024.1/bin/compiler/../../lib/libirc.a(fastmemset.c.o): in function `__intel_get_fast_memset_impl':
fastmemset.c:(.text.__intel_get_fast_memset_impl[__intel_get_fast_memset_impl]+0x4):
failed to convert GOTPCREL relocation against '__intel_cpu_feature_indicator_x'; relink with --no-relax
icx: error: linker command failed with exit code 1 (use -v to see invocation)

I tired to compile and link using microsoft visual studio cl.exe, and it did the job perfectly without any problem.

I hope icx in windows and linux can does the proper job in the future version of oneAPI tool base kit.

With best regards,

Yuji Suda

g.ysuda@gmail.com

[ysuda]

one more comment on this issue,

>I tired to compile and link using microsoft visual studio cl.exe, and it did the job perfectly without any problem.

I also tried my source with gcc in Linux,  and it turned out that everything went well.

cl.exe in microsoft windows and gcc in Linux are good but icx in windows and Linux are not good.

I would like to try with intel's classic c++ compiler but it is no longer available at the moment.  I will be happy if I am informed the way to download v2022 oneAPI tool base kit and classic HPC kit.

Yuji Suda

[Steve_Lionel]

Hi Yuji. It is much better to start a new thread rather than replying to a five-year-old thread, even if you think it's the same issue. You can add a link to the old thread if you wish.

You have posted in the Fortran forum, but say you are using C/C++. That said, what I wrote in 2019 still holds - Windows has a fixed limit of 2GB for static code and data. Since you didn't show your source, that's all I can tell you.

If you want further help, please start a new thread in Intel® C++ Compiler - Intel Community

[ysuda]

Hi Steve

Thank you for the comment.  SInce I have no problem in C/C++ compilation and linkage and my issue is on oneAPI tool base kit icx.exe, I will post my problem in oneAPI icx forum.

Yuji