Is there any limitation for the Fortran compiler compile long code into X64 obj?

[Bao__Jie]

Hi,

I am using Intel Fortran compiler 2017 in Visual Studio 2015 in Windows 7.

I have a code contains both Fortran and C++ codes. All the Fortran code is compiled into one lib file. The C++ code is then link to this lib file. For compiling to Win32, it is completely good.

However, for compiling to x64, there is an issue. The Fortran compiler can compile all the Fortran code into one lib without error, but when link the C++ code to this lib, it shows "error LNK1223 invalid or corrupt file; file contains invalid .pdata contributions" in this lib file, and refers to a obj file. I check the corresponding Fortran code file. I noticed that if the Fortran code file is too long (may be over 2000 lines), this error occurs. If I randomly delete some lines in the long Fortran code (around 1000 lines), then the error for this Fortran code file gone, and refers to another long Fortran code file. I cannot keep deleting lines for all the long Fortran code files. The Fortran code is in old style (F77).

Is there any limitation for the Fortran compiler compile long code file into X64 obj? Or there is other issue such as compiling flag or environment configuration?

Thanks,

Jie

[andrew_4619]

I do not know of any limitation. 2000 lines is not many lines, I found on a previous compiler modules in a file about say 15,000 lines started to get slower to compile and compile the same source split in two files was quicker.  It is more likly there is a problem in the source leading  or a compiler bug dealing with your source.

[Bao__Jie]

Hi Andrew,

Thank you for the comments. Do you have any experience with the error LNK1223? It looks like the Fortran compiled lib cannot be corrected read by the link. I check the LNK1223 error on VS document, it is supposed to be happen when compile for RISC platforms, but it is not my case.

Thanks,

Jie

[Steve_Lionel]

I will make a guess and suggest that the problem is code and static data that exceeds 2GB total. Even on x64, you're limited to 2GB code and static data. If you have large COMMON arrays, switch them to ALLOCATABLE (in modules.) The length of the source file has no relevance whatsoever.

[Bao__Jie]

Hi Steve,

Thank you for the suggestions.

The reason why I want to compile it into X64 is the memory usage issue. On Windows platform, the exe (compiled to win32) keeps occupying memory till around 2GB, and the system kill it silently. (It is a fuel cell simulation program. If I run it for a smaller fuel cell stack, the simulation can complete before it use more than 2GB memory, and results are good). If I compile the code on Linux by g++ and gfortran, the code still keeps occupying memory, but no memory usage limitation, and use more than 20GB for complex simulation cases, and the running results are good.

Do you mean when compiling the Fortran part to X64, the static data is larger than 2GB, but win32 does not? and this causes the Fortran compiled lib cannot be linked to C++ part for X64?

Thanks,

Jie

[jimdempseyatthecove]

Compilers produce object files, linker produces executable (or library/DLL). The object file format provides for 32-bit (signed) segment offsets. Therefore your .data segment (and the others) are limited to 2GB, the sum is not. Make the large arrays in your static data allocatable and have an init routine that runs to allocate the arrays from the heap.

Jim Dempsey

[Steve_Lionel]

Both 32-bit and 64-bit Windows have a 2GB limit on static code and data, along with a 1GB limit on the stack. The difference is for dynamically allocated data, where 32-bit limits you to 2GB (including static code and data as well as the stack), but 64-bit allows much more dynamic allocation (how much more depends on system configuration). The programming language used does not matter.

If you exceed 2GB static code and data, the results can vary. If you're lucky, you'll get a link-time error. But I have also seen "corrupted file" errors.

It may be that your problem has nothing to do with memory usage. Can you ZIP the projects (after doing a Build > Clean) and attach them here?

[Bao__Jie]

Thank you for the detailed explanation. I will ask my manager to see if the projects/code can be uploaded.

By the way, with purchasing the compiler, it has 1 year support. This kind of problem can be covered by technical support?

Thanks,

Jie

[jimdempseyatthecove]

Steve,

You may have historical knowledge of this. Why didn't (doesn't) IVF support something like:

!DIR$ DSECT(1) ! place following variables into section ".data1" as supported in ELF as initialized data

!DIR$ DSECT("bss") ! place the following variables into section ".bss" as supported in ELF as uninitialized data

and/or

!DIR$ DSECT("anyName") ! place following data into section ".anyName"

I am aware, and document can clearly state, that only .data and .data1 can hold initialized data, whereas any other user defined section (not conflicting with pre-defined section names).

Jim Dempsey

[Steve_Lionel]

Intel technical support is intended for dealing with product issues (compiler bugs, etc.)  From what you have shown so far, the evidence points to a usage problem instead, and that's where the forum tends to work best. You may, of course, choose to submit the issue to Intel support, but I'd predict you'll get the help you need here, sooner. That said, if you're unable or unwilling to post the whole program here, then Intel support is probably your best bet.