fortran common block addresses

[lmc]

Why are the addresses of the fortran common blocks so high ? The common block that I am looking at has a address of 0x104e41c0.

I allocate memory in c code using malloc and then pass it back to the calling subroutine (in fortran) relative to the common block. On every other system, the common blocks are loaded low and the allocated memory is high. Here my allocated memory has a address of 0x00c72e20. So, the address offset is negative which does not work !

Is there a way to force the common blocks to load low in memory ?

Thanks,
Lynn McGuire

[Steven_L_Intel1]

I don't see this behavior. I suggest you get a link map (under Link properties) and see what is laid out where. The linker decides where to put statically allocated things.

[lmc]

Here is my map:

0003:0012b080 _GLOBALFILENAMES 104e4080
0003:0012bc80 _GLOBAL1 104e4c80
0003:0012bd00 _VDYN 104e4d00

The common block in question is VDYN. That address given is the one that I see, 104e4d00.

I have this common block declared in my c code as:

/* vdyn common block */
extern struct vdyn_common_block
{
int ierr;
int l8w7k1;
double vdy;
} VDYN;

Lynn

[Jugoslav_Dujic]

I admit I didn't read the thread too carefully, but 0x104e4d00 doesn't surprise me too much if the Fortran code is in Dll -- they're typically loaded at around 0x10000000.

Jugoslav

[lmc]

I wonder why I dont see this behavior on Open Watcom F77 and C ? The common blocks there are loaded at very low addresses. Same on Sun and HP unix boxes. Virtual memory is much higher than staticly loaded common blocks.

I have directed towards the VirtualAlloc function on the MS boards to use instead of malloc. I will report what my results are.

Thanks,
Lynn

[Steven_L_Intel1]

Typical programs do not see this behavior.Tell us more about the structure of your code and whether you are building DLLs. Also, the link map has more information than what you posted. What compile and link options are you using?

[lmc]

I have three project in my solution right now:

1. A c Win32 static library with 5 files and about 10,000 lines of code.

2. A f77 Win32 DLL with about 1200 files and 100,000 lines of code.

3. A f77 Win32 console exe with one file that just does argument processing and calls the DLL.

There are some 100+ common blocks.

I dynamically allocate memory using malloc and free from the base point on a common block. This is a old memory management system called DYNOSOR that was designed back in the early 1970s to allocate memory using a 64K common block.

BTW, the VirtualAlloc worked ! I am on to the next hurdle.

When and if I get this program running, I will add another DLL with 3,500 files and 350,000 lines of code and three more EXE files.

Thanks,
Lynn

[lmc]

I forgot, here is the map file, zipped up.

Thanks,
Lynn

[lmc]

OK, I just figured out that I can use malloc after all. Since I turned off the array bounds check in debug mode, negative pointers to the common block arrayed variable work just fine now. I.E. vdy(num1 + 1) = 1 works ok even when num1 = -3000000 as long as the allocated memory is there. Funky looking but OK.

Thanks,
Lynn