Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28543 Discussions

Error LNK1248: image size (10B608EB8) exceeds maximum allowable size (FFFFFFFF) - x64 debug

New Contributor III

I am trying to compile my 64bit application using IFX 2023.2.0 (in Microsoft Visual Studio Community 2022 (64-bit) Version 17.6.5).

It is compiled succesfully in Release but when compiled in Debug I obtained

fatal error LNK1248: image size (10B608EB8) exceeds maximum allowable size (FFFFFFFF) - x64 debug

The application is quite extensive, combining static and dynamic libraries. Everything is compiled using IFX.

I would like to finally switch from IFORT to IFX. Release is OK, but I want to debug it too.


Does anyone know how to solve the problem? Thanks in advance for the advice.


0 Kudos
14 Replies
Honored Contributor III

If you have significantly large static arrays (common or module or save), then consider making these allocatable (and allocate them at the start of the program).


If on the other hand, the issue is the code size becomes too large (not likely, but possible), then you may need to compile some sources in release (optimized for size), and the ones of interest for debugging in debug mode then link those together.


It may be enlightening for you to make a Release build (the links) .AND. produce the load map file, then attach it to a response to this thread. This may give use some insight as to how to address your debug build/link issue.


Jim Dempsey

0 Kudos
New Contributor III

Jim, thank you for fast response.

All large arrays are allocated during the run of application.  map file of Release version contains:

 Timestamp is 64d30a8b (Wed Aug  9 05:39:55 2023)

 Preferred load address is 0000000140000000

 Start         Length     Name                   Class
 0001:00000000 00da8140H .text                   CODE
 0001:00da8140 0003cc40H .text$mn                CODE
 0001:00de4d80 00000036H .text$mn$00             CODE
 0001:00de4db6 00000036H .text$x                 CODE
 0002:00000000 00001868H .idata$5                DATA
 0002:00001868 00000038H .00cfg                  DATA
 0002:000018a0 00000008H .CRT$XCA                DATA
 0002:000018a8 00000c40H .CRT$XCA00000           DATA
 0002:000024e8 00000008H .CRT$XCAA               DATA
 0002:000024f0 00000c40H .CRT$XCT00500           DATA
 0002:00003130 00000008H .CRT$XCU                DATA
 0002:00003138 00000008H .CRT$XCZ                DATA
 0002:00003140 00000008H .CRT$XIA                DATA
 0002:00003148 00000008H .CRT$XIAA               DATA
 0002:00003150 00000008H .CRT$XIAC               DATA
 0002:00003158 00000008H .CRT$XIC                DATA
 0002:00003160 00000008H .CRT$XIZ                DATA
 0002:00003168 00000008H .CRT$XPA                DATA
 0002:00003170 00000008H .CRT$XPZ                DATA
 0002:00003178 00000008H .CRT$XTA                DATA
 0002:00003180 00000020H .CRT$XTZ                DATA
 0002:00003188 00000000H .gehcont$y              DATA
 0002:00003188 00000000H .gfids$y                DATA
 0002:000031a0 00164360H .rdata                  DATA
 0002:00167500 00000080H .rdata$CastGuardVftablesA DATA
 0002:00167580 00000080H .rdata$CastGuardVftablesC DATA
 0002:00167600 000000a8H .rdata$voltmd           DATA
 0002:001676a8 000003d0H .rdata$zzzdbg           DATA
 0002:00167a78 00000008H .rtc$IAA                DATA
 0002:00167a80 00000008H .rtc$IZZ                DATA
 0002:00167a88 00000008H .rtc$TAA                DATA
 0002:00167a90 00000008H .rtc$TZZ                DATA
 0002:00167a98 00029cf8H .xdata                  DATA
 0002:00191790 00006f88H .edata                  DATA
 0002:00198718 000002a8H .idata$2                DATA
 0002:001989c0 00000018H .idata$3                DATA
 0002:001989d8 00001868H .idata$4                DATA
 0002:0019a240 000032f6H .idata$6                DATA
 0003:00000000 00053a40H .data                   DATA
 0003:00053a40 01b54a08H .bss                    DATA
 0004:00000000 00014f88H .pdata                  DATA
 0005:00000000 000c7f7aH .trace                  DATA
 0006:00000000 00001200H _RDATA                  DATA
 0007:00000000 000027a0H .rsrc$01                DATA
 0007:000027a0 00027c38H .rsrc$02                DATA

Then the individual items follow.


Jakub Zlámal

0 Kudos
Honored Contributor III

Try building with the /Zi option (add to Command Line > Additional Options for Fortran). This should cause the debug symbol information to be written to a separate PDB file. I'm uncertain if this will help in the end, but clearly the extensive debug information is filling up the static data space. As an alternative, disable debugging info for parts of the program you're not looking at.

0 Kudos
Honored Contributor III
0 Kudos
Honored Contributor III

@jimdempseyatthecove wrote:

You might also try: -mcmodel=medium


That's a Linux thing, not supported on Windows.

0 Kudos
Honored Contributor III

>>only Linux



Intel: On Windows, -mcmodel=medium (or some other option, e.g. -psect=part1) could be implemented to place the generated code into a separately named text segment. On 64-bit systems, this would permit the code to be distributed into multiple segments.


Jim Dempsey

0 Kudos
New Contributor III

Thanks for advices

1. suggested switch /Zi did not help.

2. -mcmodel=medium unfortunately do not work on Windows


I tried the following to investigate problem:

I created copy of Release configuration (which is compiled and linked) and started to change settings from Release

1. Switched on Full debug (full debug + optimizations + nondebug libraries) - linked

compiler parameters: /nologo /debug:full /O2 /QaxCORE-AVX2 /assume:buffered_io /heap-arrays100 /DTHREADED=0 /assume:recursion /reentrancy:threaded /Qdiag-error-limit:500 /Qauto /align:sequence /names:uppercase /traceback /check:none /libs:dll /threads /winapp /Qmkl:parallel /c

2. Switched on Full debug and debug dll libraries (full debug + optimizations + debug libraries) - linked

compiler parameters: /nologo /debug:full /O2 /QaxCORE-AVX2 /assume:buffered_io /heap-arrays100 /DTHREADED=0 /assume:recursion /reentrancy:threaded /Qdiag-error-limit:500 /Qauto /align:sequence /names:uppercase /traceback /check:none /libs:dll /threads /dbglibs /winapp /Qmkl:parallel /c

3. Switched off optimizations (full debug + no optimizations + debug libraries) - not linked with error LNK1248

compiler parameters: /nologo /debug:full /Od /QaxCORE-AVX2 /assume:buffered_io /heap-arrays100 /DTHREADED=0 /assume:recursion /reentrancy:threaded /Qdiag-error-limit:500 /Qauto /align:sequence /names:uppercase /traceback /check:none /libs:dll /threads /dbglibs /winapp /Qmkl:parallel /c


My tests revealed that disabling optimization leads to link error. Is there any reason for this behavior?


Jakub Zlámal

0 Kudos
Honored Contributor III

>>/O2 /QaxCORE-AVX2

This will generate code with two code paths

a) "generic" optimized code

b) additional AVX2 optimized code


IIF you are certain the system will support AVX2 (Your Debug system apparently does) then use

  /O2 /QxCORE-AVX2


IOW omit the "a"


For distribution (Release mode) you could use the /Qax...


Note, for debugging, you would also want to test "/O2" without the AVX2 code path to assure potential issues are not related to ISA.


Jim Dempsey

New Contributor III

Even compiling without generating additional code path - without /QaxCORE-AVX2  did not succeeded.

compiler parameters: /nologo /debug:full /Od /assume:buffered_io /heap-arrays100 /DTHREADED=0 /assume:recursion /reentrancy:threaded /Qdiag-error-limit:500 /Qauto /align:sequence /names:uppercase /traceback /check:none /libs:dll /threads /dbglibs /winapp /Qmkl:parallel /c

0 Kudos
Honored Contributor III

The problem on Windows is that static code and data (and stack) is limited to 2GB total, even on 64-bit. This is due to Microsoft not extending the PE (EXE) format for 64-bit. Separate text sections won't help.

Looking at the address map posted above, there's an awful lot of code and data, including a huge .bss section (zero-initialized data - blank COMMON?).  Disabling optimization means more code.

Honored Contributor III

OK then....


DLL's ought to be loadable above the 2GB Virtual Address. IOW make some of the executable parts as DLL's.


Jim Dempsey

0 Kudos
Honored Contributor III

Would be nice, but no. Only data above 2GB. There is a 3GB linker option that sometimes works but requires that the code be "large address aware".

0 Kudos
Honored Contributor III

Time to bring back overlays.


FWIW back in the 1970's I had a very large program to fit into relatively small memory. The basic system capability permitted overlays, yet that wasn't sufficient. I therefore had to add in the ability to permit the overlay to have overlays. IOW a 3-tier system.




If you are in the position of having all the runtime checks (in particular array bounds checking, and uninitialized variable usage), as mentioned earlier (by Steve and me), it is quite easy to segment the files as to those with and those without runtime checks. The easiest way is to make two static libraries, e.g. withrtc.lib and withoutrtc.lib and simply copy the files from one lib project to the other. No need to have runtime checks as an all or nothing. As a side benefit, the restricted Debug build will run faster.


Jim Dempsey

0 Kudos
New Contributor III

Steve and Jim,

thank you for your valuable comments. I am now better educated about code generation and exe linking.

I finally ended with compiling debug version of my code using IFX with /O1 switch instead of /Od.

compiler parameters: /nologo /debug:full /O1 /assume:buffered_io /heap-arrays100 /DTHREADED=0 /assume:recursion /reentrancy:threaded /Qdiag-error-limit:500 /Qauto /align:sequence /names:uppercase /traceback /check:none /libs:dll /threads /dbglibs /winapp /Qmkl:parallel /c

The disadvantage is that runtime error checking cannot be turned on.

0 Kudos