Problem in upgrading IVF complier from 12.1 to 15.0

[Yogesh_A_]

Dear All,

I have a fortran file "compile.for" which I am able to compile on Intel Visual Fortran compiler version 12.1.

But if I try to compile this same file on Intel Visual Fortran compiler 15.0 it start giving compilation error "Fatal compilation error: Out of memory asking for 1560584".

Please suggest any way to solve it as I have already tried many compiler options.

Thanks In Advance

[andrew_4619]

Just some guesses....

It sound like you have a single source file, how big is it? Have you considered breaking it into several files if it is big to see if it is any partticular routine that causes the error.

Do sample files compile OK or simple hello world applications?

[jimdempseyatthecove]

I no longer have the 15.0 documentation on hand... (I cannot verify this).

Around 15.0, the IVF compiler introduced more aggressive Inter-Procedural Optimization (IPO).

Before you breakup your one large program, you might experiment with disabling IPO.

If this works for you, then you will have to decide if any additional performance benefit with IPO is worth the effort to partition your program (Andrew's suggestion).

Jim Dempsey

[Steven_L_Intel1]

First, if you are on  a 64-bit Windows system, try switching to the x64 (Intel64) configuration as dynamic memory limits are much higher there. You should also see if a debug configuration (optimization disabled) still gets the error - if not, then it's probably optimizer-related. Why did you choose 15.0 instead of the current 16.0? The suggestion of splitting large source files is a good one.

[Yogesh_A_]

Thanks for the reply  :)

This is first time I am working with fortran compiler so things are little unknown to me.

Basically the fortran file I have is generated by some third party software. Till date we use to generate an obj file using IVF compiler 12.1 (32 bit) and it work fine every time even if it is of more than few MB.

We can't build fortran file using 64 bit compiler as we have some other obj file which are build in 32 bit environment and when we try to link all obj files together it gives error "fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'".

But recently one of our client bought IVF 16.0 (I have tried on 15.0 as we have license of IVF 15.0). But now I have also tried on IVF 16.0 on client machine.

Fortran file compiles using IVF 16.0 with 64 bit compiler (But in our case we are unable to link this compiled obj with other obj files (32 bit)).

But it is giving error "Fatal compilation error: Out of memory asking for 1560584" if I try to compile using 32 bit compiler.

We can not split fortran file as it is generated by third party software every time.

attached are two files generated from two different time by two modules.

[andrew_4619]

One would strongly suspect the 92000 lines of blockdata will be the problem......

[mecej4]

You left out the include file compile.inc from the attachments to #5.

[andrew_4619]

Can really make any test on that source file without the COMPILE.inc include file. If splitting the file helps you could have a pre-processing stage to automatically do this if the third party can't/won't change anything

[Arjen_Markus]

You could split up the file using an editing tool - or a small dedicated Fortran program. If you split it at the first subroutine, somewhere half way, then it might be possible to compile the two files.

[mecej4]

Since most of the generated code consists of nothing other than EQUIVALENCE and DATA statements, some consideration should be given to an alternative method: putting the generated data into a file and then reading the file as needed.

[LRaim]

Very interesting. New fortran compilers can be faster but are undoubtedly weaker 

[andrew_4619]

Luigi R. wrote:
Very interesting. New fortran compilers can be faster but are undoubtedly weaker 

New features == new bugs to fix but without change we would still be coding F77. The code example that fails to compile is a pretty extreme case IMO. It a continuous block (90,000+ lines) of data statements and other obsolete language features and looks like a product of 1980s thinking.

In this case is it really a bug? Out of memory could just mean the computer is not up to the task at hand.