problem with cray pointers, common blocks, and block data

I have an old fortran 77 code that was written to compile with pgif77. On our test machines we have pgi version 4.0, and it compiles the code fine, but on our cluster we have pgi version 6.2 and I am running into a problem. When a cray pointer variable is declared (as an integer) in a common block and then other variables in that common block are initialized in a data block, using that pointer in a POINTER (x,y) declaration produces an error.

The following example produces the error (on 6.2 but not 4.0):

!       test.f
        block data test
        integer a,b
        common  /area/ a,b
        data a/5/
        end

        program main
        common /area/ a,b
        integer x,a,b
        pointer (b, x)

        print a,b,x

        end

and the error produced is (pgf77 -c test.f):
PGFTN-S-0168-Incompatible size of common block area (test.f)

Is this a bug? I don’t see what could be changing the size of the common block. Even stranger is that the code will compile if the “data a/5/” statement is commented out. It will also compile if the “pointer (b, x)” is commented out, but that is needed.

Hi ephq,

The issue is that a POINTER in 64-bits is an INTEGER8 not an INTEGER4 (which is the default when you use INTEGER). The quick fix is to either compile in 32-bits or add “-i8” to your 64-bit compilation. However, adding “-i8” can be dangerous if other parts of your program is expecting the default integer to be INTEGER4. The ideal solution would be to explicitly declare the integers as integer8.

Example:

% % cat test.f
!       test.f
        block data test
#ifdef USE_64BIT
        integer*8 a,b
#else
        integer a,b
#endif
        common  /area/ a,b
        data a/5/
        end

        program main
        common /area/ a,b
#ifdef USE_64BIT
        integer*8 x,a,b
#else
        integer x,a,b
#endif
        pointer (b, x)

        print a,b,x

        end

% pgf77 -Mpreprocess test.f
PGFTN-S-0168-Incompatible size of common block area (test.f)
  0 inform,   0 warnings,   1 severes, 0 fatal for main
% pgf77 -Mpreprocess test.f -DUSE_64BIT
% pgf77 -Mpreprocess test.f -i8
% pgf77 -Mpreprocess test.f -tp k8-32

Hope this helps,
Mat

Ah, thanks mkcolg.

I thought that was the problem, but I didn’t know what to do about it. The code is rather large and complex (i didn’t write it) so I think compiling it in 32 bit would be the best option. -tp k8-32 is an AMD processor flag right? The cluster I am trying to use is full of Xeons, will the k8-32 flag produce a compatible executable or do I need to use an intel target?

Hi ephq,

“-tp k8-32” does target a 32-bit AMD Opteron. It should run ok on a Xeon, but may give sub-optimal performance. Instead, you can use “-tp core2” for a Core2 Xeon. Later versions of the compilers also support the “-tp penryn” option for Core2 Quad Xeons. Also, you can set your PATH to the 32-bit compilers (by default located in /opt/pgi/linux86//bin) which will then select the correct 32-bit target, assuming you’re compiling on the same type of system that you’ll be running.

  • Mat