f77 POINTER on 64-bit system

I’m starting to work on a 64-bit compilation of some mixed f77 and C code.

It seems that since the default size of an INTEGER is 4 and a f77 POINTER is an INTEGER, then without using the -i8 compilation switch, the POINTER is 4 bytes… I’d rather not use -i8, so is there another way to force a POINTER to be 8 bytes?

Hi Jim,

A F77 Cray Pointer should be 8 bytes in 64-bits. Are you seeing something different?

  • Mat

Yes, it seems like it should be 64 bits when using -tp k8-64 regardless of the size of an INTEGER data type.

On the FORTRAN side, the pointer is declared:
pointer (pImg, fImg)
real*4 fImg(1)

Then memory is malloc’d, and the pointer is passed to a C function.

When NOT specifying -i8, from FORTRAN, the pointer looks like:
pImg pointer: -17889452272 (printed with write(,) 'pImg pointer: ', pImg

From the C function, the pointer looks like:
CFuncL pointer is 0xffffffff96972010 (printed with 0x%p)

When I compile the FORTRAN with -i8, I get:
From the FORTRAN side:
pImg pointer: 182894141456

From the C side:
CFunc: pointer is 0x2a98172010

and everything works (with -i8). So, it leads me to think that the Cray pointer is being created as the size of an INTEGER, which is 4 bytes unless -i8 is specified.

Is this a bug, or am I doing something else wrong?

Hi Jim,

You might need to give us a little more information. What compiler release are you using? Here is an example that works the same for us whether compiled with -i8 or not:

program test

real*4 d
pointer (p, d)

d = 1.0e0

write(6,100) p, d
100 format(’ ',z16.16,f15.8)

call xxx§


xxx_(long *p)
printf(“C: pointer… 0x%p\n”,*p);

You’re right, I can’t get that to fail either, except when I modify the first element in the C function, then try to access it to print it after it returns to Fortran… I get a segfault.

Anyway, I think I’ve found the root cause of my issue. This (legacy) code was including a local (old) copy of lib3f.h to provide definitions for common libc functions. Low and behold, it was declaring malloc as an “integer”, so that accounts for the difference between compiling with and without -i8. It wasn’t the pointer, it was how the pointer was being assigned by malloc()… I’m going to have to reorganize some things to properly get these external libc functions declared.

Thanks for your help, guys.

Oh, this is pgf77 6.0-5 on x86-64 Linux (CentOS). Sorry, broke the cardinal rule of getting Forum help!

Just another followup comment…

When I compiled my code specifically for the Opteron, I got about a 36% performance increase over compiling for generic x86.

I like that! Thanks PGI; Thanks AMD!