Image size too big in debug

[emonette123]

We make extensive use of pointer statements and "on-purpose" define all dummy array related to pointers to have big dimensions. Meaning:

INTEGER MYARRAY(1000000000)
POINTER(MYPNTR, MYARRAY)

We use a big value for the array to make sure we will trap a forgotten pointer statement.

In Release, everything is fine, but in debug mode, the compiler takes the size of the array into account, giving an enormous size for the .bss section and ultimately the image size is too big error at link time.

Is there any compiler option we missed? We would like to keep the array size to a big number, this prooved more useful than problematic.

[Steven_L_Intel1]

Use (*) instead.

[emonette123]

Thanks for the answer, but this is not a workable solution. We use a PARAMETER definition for this, it looks like:

INTEGER NOMINAL
PARAMETER(NOMINAL=100000000)

then

INCLUDE 'nominal.h'
.
.
.
INTEGER MYARRAY(NOMINAL)
POINTER(PNTR_MYARRAY,MYARRAY)

I can change this NOMINAL value to be 1 in debug mode (which in turn I did). Using (*) would means changing thousands of lines in hundred of files... Anyway, using (*) will only work if you have a dummy argument with many other compilers and our code must compile on multiple platforms, not only with Intel Fortran.

So here is my question again: using a big value for NOMINAL works in released mode, but not in debug. Is there a compiler switch we missing for Intel Fortran Compiler?

[jimdempseyatthecove]

How do you universally expect the pseudo large array to reliablytrap on missing pointer assignment? Are you not using implicit none?

As is, if you forget the pointer assignment in your code, the (defective) code may also include references to MYARRAY directly instead of via the pointer (MYPNTR). The as-is codewould inhibit you from relying on runtime array bounds checking from catching a buffer overrun condition.

Jim

[Steven_L_Intel1]

Use of (*) works with the integer POINTER extension, which is what you are using. I would be surprised if other compilers that supported this extension did not also allow (*) as bounds.

What compiler version are you using? I recall reading about this issue some time ago and it had something to do with the "big" array having storage allocated for it even though it was not used, and the storage removed by optimization.

You may as well use (1) for the value of NOMINAL. It accomplishes the same thing.

[emonette123]

Alas no, the implicit none statement is not used in many source files. We are dealing with pretty old code here, hard core Fortran 77. The initial code was using static memory, it was before the pointer extension era. Code has slowly been moved towards dynamic allocation and this big NOMINAL trick was useful at that time, I guess it is a lot less useful now, but habits are tough to change...

Our problem is only Intel Fortran is not behaving correctly with this in debug mode.

Etienne Monette

[Steven_L_Intel1]

I just tried an example in version 10.1 and it worked fine. The number shown in the original post is a bit too big - 10 billion - but if I make it 1 billion it works. Which compiler version are you using?

[emonette123]

Steve,

You are right about the (*) and pointer statement, it works fine on all platforms. My mistake. Still, replacing all (NOMINAL) by (*) is not a workable solution, and the other compilers deal correctly with big NOMINAL size in debug mode.

We are using version 9.1 of Intel Fortran compiler. Here is the banner:

Intel Fortran Compiler for 32-bit applications, Version 9.1 Build 20060323
Z Package ID: W_FC_P_9.1.024

Do you remember if the issue about big array having storage allocated was fixed, or on which thread it was? Were there any workaround?

Thanks,
Etienne

[emonette123]

Steve,

Guess what... People here did not know about using (*) with POINTER statements. So all this developed NOMINAL thing was quite useless: indeed, with (*), if you forget the pointer statement, it does not even compile, while with the NOMINAL trick, you will only see your error at link time.

So for ongoing development, I will gladly replace all the NOMINAL by (*), too bad for the frozen code, but anyway, we will not use Intel Fortran compiler with these frozen versions.

There is still this issue with the fact version 9.1 considers the size of an array associated with a pointer in debug mode, but it looks like it was fixed in 10, did it?

Thanks a lot for your help,

Etienne

[Steven_L_Intel1]

Right - as I said, we fixed this a while ago. I don't remember exactly when, but it would be in 10.0 at least. Current version is 10.1.