Error #5520 A common block or variable may not exceed 2147483647 bytes

[Annegarn__Paul]

I get an Fortran compiler error #5520: "a common block or variable may not exceed 2-gig bytes.". It happens using a package from a vendor, so no source available. The package did compile with parallel composer 2016. However it does not with 2017 and 2018. I guess the error is not really about a too-big structure as it compiles with the 2016-version. The package is from an obsolete vendor (no support available anymore) named Canaima and gives access to an Oracle database.

Would be happy with a solution/workaround.

[Lorri_M_Intel]

I'm a tiny bit confused; you say you get this error message compiling, but you have no source code? 

Which target architecture are you building your application for?  IA-32 or Intel64?   If it is Intel64, then you shouldn't see this message.   If you are building for IA-32 (which is the default in Visual Studio, by the way) then yes, it's not unexpected.

Finally, is there a chance you've changed the compile-time options between PSXE 2016 and a newer version?  Are you expanding the size of REAL or INTEGER data?

                       --Lorri

[Annegarn__Paul]

Hello Lorri, I understand your remark upon the 32 bit architecture. Please note that we used this Canaima module a long time with 32 bit architecture using the 2016 compiler. So everything should fit in 32bit. I have no inside information about the module. We only have a Canaima\Lib directory, containing lib-files (binaries) and a Canaima\Include directory holding some mod-files (also binaries). The Include\ holds one f90 file which contains all kind of parameter definitions.

I guess, that files that are mentioned in a Use statement should have a binary interface file present for the compiler.

[mecej4]

Several years ago, Steve Lionel built .MOD files to enable Fortran client apps to be built with F90SQL-lite (from Canaima Software) to be built using Intel Fortran:

     https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/275275

Paul and Lorrie: this is a shot-in-the-dark: I recollect that the compiler proper (FORTCOM.EXE) was provided in 32 and 64 bit versions with Intel 2016 and earlier, whereas current versions of IFort no longer include a 32-bit Fortcom.exe. Could this explain Paul's observations?

[Steve_Lionel]

Please read Memory Limits for Applications on Windows. There you will see that, even on 64-bit Windows, the aggregate limit on code and static data is 2GB. So the 32 or 64 bit difference is irrelevant.

In the past, the compiler did not catch when a single COMMON block exceeded 2GB, relying on the linker to do it. But sometimes the linker doesn't catch this (and the results can be VERY confusing!) At some point a check for this was added to the compiler.

That said, I am very doubtful that the f90SQL module source has any COMMON declarations in it at all. (I suppose I should know as I created this module and know what's in it.)  I would like to see the actual and complete error message, not just a retyping of it, and the source line or name of COMMON it identifies.

[Annegarn__Paul]

Hello Steve,

Sorry for the layout, but below is the screen shot for the 1st error. There are more of the same kind in some other files. It says line 1 but I think that is not relevant.

One of the files which did not compile is attached. I removed all code that was not needed to get this issue.

Severity    Code    Description    Project    File    Line
Error        Compilation Aborted (code 1)        C:\PaulA\F\Projects\Reactor\Source\Mod_Oracle_small.f90    1
Error        error #5520: A common block or variable may not exceed 2147483647 bytes        C:\PaulA\F\Projects\Reactor\Source\Mod_Oracle_small.f90    1
Error        error #10298: problem during post processing of parallel object compilation        ifort    

[mecej4]

Ifort 18.0 - 32 bit compiles Mod_oracle_small.f90 with no error messages if the f90SQL\include directory is named with the /I option.

There are no common blocks in your source file, nor in the Fortran source files in the f90SQL\Include directory. Do you have any large arrays declared in the actual source code that caused the error message to be issued?

[Annegarn__Paul]

Hi mecej4,

Your response sounds promising. Can you explain where you put the "/I" option? I use Visual Studio 2015 to start the compiler. The result of all settings is (also attached as file for readability):

/nologo /debug:full /MP /Od /I"..\..\..\Libraries\Canaima\Include" /I"..\..\..\Libraries\Xeffort\IVF\Debug" /I"..\..\..\Libraries\General\Debug" /I"C:\PaulA\F\Libraries\General\Debug" /DREACTOR /Qdiag-error-limit:100 /debug-parameters:all /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:uncalled /Qopt-report:5 /Qsave /align:commons /iface:cvf /module:"C:\Temp\_Reactor\Debug/" /object:"C:\Temp\_Reactor\Debug/" /Fd"C:\Temp\_Reactor\Debug\vc150.pdb" /traceback /check:pointer /check:bounds /check:uninit /check:stack /libs:static /threads /dbglibs /c

Note that I can't edit this line directly. It is a summarize of the dialog-settings.

[mecej4]

I compiled in a 32-bit IFort command window, working in the f90SQL created by extracting Steve Lionel's Zip file (dated 2006, link in #4 above, using the command

ifort /Od /I.\include /c Mod_Oracle_small.f90

I now tried with your longer list of options, trimmed to remove paths to directories that I do not have:

ifort /nologo /debug:full /MP /Od /I".\Include" /DREACTOR /Qdiag-error-limit:100 /debug-parameters:all /warn:declarations /warn:unused /warn:ignore_loc /warn:truncated_source /warn:uncalled /Qopt-report:5 /Qsave /align:commons /iface:cvf /traceback /check:pointer /check:bounds /check:uninit /check:stack /libs:static /threads /dbglibs /c Mod_Oracle_small.f90

With this longer list of options, the compiler responded:

ifort: remark #10397: optimization reports are generated in *.optrpt files in the output location

However, I don't think that the problem that you are seeing has anything to do with include directories (which are specified in your Visual Studio project properties). Had there been a problem with that, the compiler would have complained about not finding the USEd module files. My suggestion at this point is to create a new working directory, into which you place only the source file Mod_Oracle_small.f90 and the three module files from f90SQL, and attempt to compile.

[Steve_Lionel]

At this point, please attach a ZIP of an entire project that reproduces the error. Include the sources of all modules and include files you are using.

[Annegarn__Paul]

Hello Steve,

I made a project as small as possible, still having this issue. Please see the attached file.

Paul

[mecej4]

I suspect that the problem is caused by the module file f90sql.mod. If I use the version of that file that is in Steve's Zip file, or if I first generate a new module file by compiling the source file f90sql.f90 from the same Zip file (after correcting the DEC$ OBJCOMMENT line by placing single quotes around the library name), I am able to compile Mod_Oracle_small.f90 using Ifort 18.0.3 (32-bit) without any errors. I do see the error if I use the module file that you provided.

I think that Steve will advise as to the resolution of this issue; in the meantime, can you provide any information as to how you obtained your version of f90sql.mod? Did you compile a source file to generate it, or did you obtain the file along with the f90SQL package from some vendor?

[Annegarn__Paul]

The Canaima package is used by my company already for a long time. I don't think we ever compiled it because we don't have any source of it.

My concern is: is Steve's zip file 100% compatible with our modules? Can I just replace f90SQL.f90? Maybe Steve can explore on this?

My f90SQL.lib has a size of 251140k while Steve's has 186324.

[andrew_4619]

Paul, From a quick look the F90SQL.f90 is just a module of interfaces so as long as those interfaces are all consistent with what is in your lib recompiling that source file should not be an issue IMO, why not just try it and run some tests. 

[mecej4]

Compiler vendors try to keep *.MOD and *.LIB files backward compatible with their compilers. Once in a while, a compiler revision may make it necessary to require recompilation of interface files such as f90SQL.f90. The source file f90SQL.f90 was probably provided by Canaima for this very purpose. I agree with Andrew's comments.

Question for Intel compiler team: Could the compiler be fixed to say "Module file is out of date and needs to be rebuilt..." instead of "A common block or variable may not exceed 2147483647 bytes" ?

[Steve_Lionel]

It seems clear that Paul's copies of the .mod files were compiled at some later time. I have long since lost my info on how to suss out the compiler version and date from .mod files, but I can see that the headers are very different. It's possible that the compiler used at the time created a bad .mod file. With few exceptions, .mod files are indeed upward compatible (within Intel Fortran). That the compiler gave such an odd error is probably due to a corrupted entry in one of the .mod files. I'm hoping Lorri sees this and takes a peek at it.

I agree that it makes more sense to use the originals I provided, but you could certainly try recompiling with a version no later than the oldest version you want to support.

[mecej4 · Accepted solution]

At byte 0x24 of the .MOD file we can see a character string that matches the compiler version. The MOD files in Steve's Zip file show the version number as 9.0. The ones in Paul's Zip file have only null characters in those bytes.

The LIB file that is in Paul's Zip shows 47 symbols that are not present in the LIB file in Steve's Zip (presumably, these are what the full f90SQL contained in addition to what was in the -lite version). If Paul's application calls many of these 47 symbols, there will be a tough problem to solve, unless he has the matching source file f90SQL.f90.

[Annegarn__Paul]

All,

I compiled the 2 projects that we have, which use the Canaima package, using the f90SQL-lite from Steve. There were no errors during compilation. Also a run of the most complex program using the ODBC link to Oracle did show correct reading and writing.

So, it seems that the light package will do for my situation. Of course the best was to correct the 'error' in our original package but I think we can live with the light version.

Thanks to Steve and mecej4 for the support. It felt very good to get such help on a daily base.

[jimdempseyatthecove]

Please return the favor when you have the answers to others questions/problems/issues. Those of us that do not have (Intel) after their name/handle are end users, or retired Intel employees such as Steve with (Ret.) after his name. The forum has more community support replies than Intel employee replies.

Jim Dempsey

[mecej4]

Paul, it would probably be a good idea for you to save Steve's modified F90SQL.f90, in which he has added the necessary !DEC$ ATTRIBUTES directives for all the ODBC routines contained in F90SQL.LIB (and F90SQL.DLL).

Whenever you update your Intel compiler, particularly if you run into errors such as the one that you reported, you can recompile that file to generate a fresh F90SQL.MOD file for use with the new compiler.

[Annegarn__Paul]

Thanks for the tips, both Jim and mecej4.