[PATCH, gfortran] Re: Cray Pointers

[Asher Langton]

At 2:02 PM +0100 8/12/05, Paul Brook wrote:
>  > > > The convention is to use byte-size increments.  I don't think it's
>>  > > possible to do anything else.  For example, the following is valid:
>>  >
>>  > My understanding was this this depended which machine you were using. I'm
>>  > sure I read that the original cray implementation used word (ie. type
>>  > size) addressing, but later implementations use byte addressing.
>>
>>  That is because the first cray could not address bytes. Later versions of
>>  the compiler generated code to mask and shift words in the Cray to allow
>>  byte addressing. Even when the hardware didn't support it directly.
>
>Ok.

Just to clarify this point, here's a short program and the output 
from all of the Fortran compilers to which I have access:

program ex2
   real var(10)
   real pointee(10)
   pointer (ipt, pointee)
   ipt = loc(var)

   print *,ipt
   ipt = ipt + 1
   print *,ipt
   ipt = loc(var(2))
   print *,ipt
end program ex2

===Intel (Linux x86_64)
% ifort ex2.f90
% ./a.out
                5591932
                5591933
                5591936

===gfortran (Linux x86_64)
% gfortran -fcray-pointer ex2.f90
% ./a.out
          548682068800
          548682068801
          548682068804

===Pathscale (Linux x86)
% pathf90 ex2.f90
% ./a.out
  -1073744828
  -1073744827
  -1073744824

===IBM (AIX)
% xlf90 -qsuffix=f=f90 ex2.f90
** ex2   === End of Compilation 1 ===
1501-510  Compilation successful for file ex2.f90.
% ./a.out
  1152921504606844008
  1152921504606844009
  1152921504606844012

===Portland (Linux x86)
% pgf90 ex2.f90
% ./a.out
     134661000
     134661001
     134661004

===Compaq (Tru64, Alpha)
% f90 ex2.f90
% ./a.out
             5368709624
             5368709625
             5368709628


>  > > > integer(4) buffer(1024)
>>  > > real(8) rarray(512)
>>  > > integer(4) iarray(1024)
>>  > > pointer (ipt, rarray)
>>  > > pointer (ipt, iarray)
>>  > > ipt = loc (buffer)
>>  >
>>  > Really? On many machines buffer might only have 4-byte alignment, so
>>  > accessing it as an 8-byte float will cause alignment faults.
>>
>>  It's safer to change the first line of the previous example to read:
>>  integer(8) buffer(512)
>
>But you still can't use both to access the same object, right? ie. the
>optimizers can assume that the two pointees don't alias.
>
>It would seem rather strange if two pointees can alias but a pointee and a
>real object can't.


There's no prohibition on pointees aliasing real objects or other 
pointees.  Both are common, in fact.  The trouble occurs when a 
pointee and an object that it aliases are both used in the same part 
of the program.  The optimizer isn't aware of the aliasing and things 
might break.  It's a sid effect a user must be aware of when using 
Cray pointers.  Here's an example of some legal (but fragile) code 
using Cray pointers, and the results of running that code:

program ex1
   implicit none
   integer iarray(2)
   integer pointee(2)
   pointer (ipt, pointee)
   ipt = loc(iarray)
   call parmptr(ipt,iarray,2)
end program ex1

subroutine parmptr(ipointer,intarr,n)
   implicit none
   integer :: n,i
   integer intarr(n)
   pointer (ipointer,newpte)
   integer newpte(n)
   do, i=1,n
      ! Mixing pointees with their targets will break things!
      newpte(i) = i
      intarr(i) = -newpte(i)
      if (newpte(i).ne.intarr(i)) then
         print *,"Optimizer broke the code."
      else
         print *,"Optimizer didn't break the code."
      endif
   end do
end subroutine parmptr

===Intel (Linux x86_64)
% ifort -O0 ex1.f90
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% ifort ex1.f90
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.

===gfortran (Linux x86_64)
% gfortran -fcray-pointer ex1.f90
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% gfortran -fcray-pointer -O4 ex1.f90
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.

===Pathscale (Linux x86)
% pathf90 -O0 ex1.f90
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% pathf90 ex1.f90
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.

===IBM (AIX)
% xlf90 -qsuffix=f=f90 ex1.f90
** ex1   === End of Compilation 1 ===
** parmptr   === End of Compilation 2 ===
1501-510  Compilation successful for file ex1.f90.
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% xlf90 -qsuffix=f=f90 -O4 ex1.f90
** ex1   === End of Compilation 1 ===
** parmptr   === End of Compilation 2 ===
1501-510  Compilation successful for file ex1.f90.
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.

===Portland (Linux x86)
% pgf90 -O0 ex1.f90
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% pgf90 ex1.f90
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.

===Compaq (Tru64, Alpha)
% f90 -O0 ex1.f90
% ./a.out
  Optimizer didn't break the code.
  Optimizer didn't break the code.
% f90 ex1.f90
% ./a.out
  Optimizer broke the code.
  Optimizer broke the code.



-Asher