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

lld-link: error: section larger than 4 GiB

JulieMarieC
Novice
12 060 Visites

Hello,

I was using ifort compiler, but i have seen the message that it will be deprecated, so I'm trying to use ifx instead, but I get this error:

lld-link: error: section larger than 4 GiB: .data

Do you have any suggestions?

 

Best regards,

 

Julie

Étiquettes (2)
0 Compliments
24 Réponses
Steve_Lionel
Contributeur émérite III
11 282 Visites

Do you really have a static variable (COMMON, most likely) larger than 4GB?

This isn't a compiler issue - add -mcmodel medium to the compiler options.

JulieMarieC
Novice
11 191 Visites

It seems that '-mcmodel medium' is not recognized by ifx compiler.

0 Compliments
Barbara_P_Intel
Employé
11 167 Visites

On Linux the syntax is "-mcmodel=medium". There is no equivalent option for Windows. See this section in the Fortran Developer Guide and Reference.

 

JulieMarieC
Novice
11 148 Visites

Thanks for your answer. I will in the next few months, maybe there will be an update that will allow this option for Windows.

 

0 Compliments
Steve_Lionel
Contributeur émérite III
11 136 Visites

No, there won't - Windows has a hard limit of 2GB static code and data, due to the design of the executable format. Use ALLOCATABLE arrays instead of very large static arrays.

JulieMarieC
Novice
11 133 Visites

Ok, thanks for this precision.

So I don't know why it works with ifort but not with ifx: maybe it is linked to the fact that with ifort, our code is compiled for win32, but we have to compile for x64 with ifx?

 

0 Compliments
Steve_Lionel
Contributeur émérite III
11 089 Visites

It doesn't work with 64-bit ifort either. 

0 Compliments
OldeMan
Novice
9 696 Visites

@Steve_Lionel wrote:

It doesn't work with 64-bit ifort either. 


I'm getting the same message when compiling with "ifx".  This is on code that we've been compiling for years on "ifort" as both 32 and 64 bit, and as executables and DLLs.  This is F77 code that compiles into 20~30MB executables and/or DLLs.  I assure you, there is no way anything in its static data structure approaches 4GB.  (Unfortunately, the code is export restricted... so I can't share.)

 

Interestingly, I only get this message when I use "ifx" to create a "DLL".  There are no complaints when I build various forms of executable.

 

How do I get information about the ".data" constituents?  I'd like to see what ballooned to over 4GB.

 

0 Compliments
jimdempseyatthecove
Contributeur émérite III
8 362 Visites

>>How do I get information about the ".data" constituents?  I'd like to see what ballooned to over 4GB.

On Windows, assuming you are interested in the .data section, for each object file use dumpbin /section:.data yourfile.obj

C:\test\Console21\Console21\x64\Release>dumpbin /section:.data console21.obj
Microsoft (R) COFF/PE Dumper Version 14.38.33130.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file console21.obj

File Type: COFF OBJECT

SECTION HEADER #2
   .data name
       0 physical address
       0 virtual address
      E8 size of raw data
     6A3 file pointer to raw data (000006A3 to 0000078A)
       0 file pointer to relocation table
       0 file pointer to line numbers
       0 number of relocations
       0 number of line numbers
C0500040 flags
         Initialized Data
         16 byte align
         Read Write

  Summary

          E8 .data

C:\test\Console21\Console21\x64\Release>

Use the programmers calculator to convert hex to decimal.

Once you find the file with the copious data section, you can investigate further.

The issue may not be in the .data section. You can use dumpbin without /section:... to get a summary of all the sections.

C:\test\Console21\Console21\x64\Release>dumpbin console21.obj
Microsoft (R) COFF/PE Dumper Version 14.38.33130.0
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file console21.obj

File Type: COFF OBJECT

  Summary

           0 .bss
          E8 .data
          B9 .drectve
           C .pdata
           8 .rdata
         36F .text
           C .xdata

Jim Dempsey

0 Compliments
jimdempseyatthecove
Contributeur émérite III
8 358 Visites

For the offending file, to get additional information, try:

 

dumpbin /all /rawdata:none YourFile.obj

 

Jim Dempsey

0 Compliments
JohnDrohan
Novice
6 137 Visites

Hi Jim - thanks again for these additional diagnostics.

Unfortunately, in my case, none of my object files when processed through the dumpbin binary indicate any true size issues. I've examined both the .data and the .bss sections.

Some other data:

IFORT compiler: sum of size of all .obj files: 39.2 MB

IFX compiler: sum of size of all .obj files: 42.8 MB

IFORT compiler: .map file - looks like it gets completely written to disk.

IFX compiler: .map file - looks like it fails to get completely written to disk, failing in section 3 with what does appear to be a memory address beyond a 4GB limit: 

"0003:fdcb9690 GTDATA_7FA$ISIGN 000000027ec7c690 gtdata_7fa.obj"

 

Is there anything I could send that would help with further diagnosing this issue? In the meantime, I have some possible refactoring ideas I could implement, but they would take time, and I'd likely just be guessing.

 

Thanks,

John

0 Compliments
PaulG1
Débutant
1 661 Visites

OLDEMAN, I am in exactly the same scenario as you.  I can compile, and have, an executable with no issues at all (IFX) but trying to make the DLL generates this error and, for years, I have had no issues at all.  I am reading through this thread but what, if I may ask, was your fix?  I typically make 32 and 64 bit DLLs depending upon the customer's needs.

 

Thanks.

Paul

0 Compliments
OldeMan
Novice
741 Visites

I'm sorry Paul... I don't have a good answer for you.

I wrestled with this for an unreasonable amount of time... and gave up.  I had to get back to work... so I reverted to "ifort" for DLL builds and resumed business-as-usual.  That means things like code changes, Visual Studio updates, Intel Updates, compiler option changes... you know... the stuff of life.

Before answering your question, I decided I'd better re-test an "ifx" build of a DLL ... just to make sure it was still broken.

Guess what?  It works for me now.  Sorry -- I have no idea what change I made that turned the corner.

Good luck!  Hey... try again in a few months... maybe it'll fix itself for you too.

0 Compliments
jimdempseyatthecove
Contributeur émérite III
477 Visites

As a (temporary) hack, can you divide your DLL in two (or more) pieces?

Jim Dempsey

0 Compliments
JohnDrohan
Novice
9 005 Visites

Was there ever any solution suggested for this issue? I am in the exact same boat as @OldeMan - export controlled restricted code that has compiled successfully for years in 32/64-bit IFORT into a dll 30-ish megabytes in size.  

Everything compiles, but upon link get the exact same error: section larger than 4 GiB: .data

We are still working with 2024.2.0.635 compiler due to needing to support 32-bit binaries going forward.

0 Compliments
Steve_Lionel
Contributeur émérite III
8 968 Visites

I'm going to take a guess and suggest that it's the same issue as I describe here - you have an include file that declares one or more COMMON blocks and you initialize the COMMON in that same include file. This is not allowed in Fortran, but it seems the ifort compiler handles it in a different way than ifx. The result is that with ifx, your initializations are repeated in every object file where the COMMON is included.

See my linked post for the solution to that.

0 Compliments
OldeMan
Novice
8 959 Visites

@Steve_Lionel  - I'm guessing you didn't mean to post a link to a politico article describing staff cuts as NASA?

0 Compliments
OldeMan
Novice
8 948 Visites

Steve, I was intrigued by your description of the potential (likely?) problem:  #includes that include declarations of COMMON(s) and initialization of same.  Nope .. I checked our several hundred #include'd header files .. and none are guilty of this.

Also ... we only get this weird "section larger than 4 GiB: .data" when compiling our code in DLL form.  When compiling (essentially) the same code as an EXE ... it works fine with "ifx".  I don't think that fits your guess at the cause?

0 Compliments
Steve_Lionel
Contributeur émérite III
8 926 Visites

Link fixed - sigh.

The other thread also involves a DLL, but the original poster found a different solution. At this point I don't know what's going on.

0 Compliments
JohnDrohan
Novice
8 360 Visites

I can also confirm that our code base has no common declarations in our include files. In fact, we converted 90+% of our .inc files to modules and have only 2 small ones remaining. From the other thread, I will examine our .map file and compare the IFORT/IFX versions of each to see if there is a similar difference/issue.

0 Compliments
Répondre