Re: including cray pointers in fortran modules

On Jun 11, 8:49 am, "James Van Buskirk" <not_va...@xxxxxxxxxxx> wrote:
<execra...@xxxxxxxxx> wrote in message

news:2939c297-1859-4f40-892a-579515edc68b@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



What I'm trying to do is update some fortran 77 code written for a
proprietary compiler (to use cray pointers) to fortran 95 code that
can be compiled with gfortran.  The code has some include files where
cray pointers are declared and used in multiple source files.  I am
having trouble converting these include files to fortran modules and
can't find a good answer as to why searching online.
! testmod.f95
module test
 integer ipt, x
 pointer (ipt, x)
end module
! test.f95
program
 use test
 integer x
 x = 2
 print *,x
end

Everybody who looks at this code seems to see different errors.
The first layer is with the declaration of ipt and that PROGRAM
statement:

C:\gfortran\clf\cray_example>type cray_example1.f90
! testmod.f95
module test
 integer ipt, x
 pointer (ipt, x)
end module

! test.f95
program
 use test
 integer x
 x = 2
 print *,x
end

C:\gfortran\clf\cray_example>gfortran -fcray-pointer
cray_example1.f90 -ocray_ex
ample1
cray_example1.f90:4.13:

 pointer (ipt, x)
            1
Warning: Cray pointer at (1) has 4 bytes of precision; memory addresses
require
8 bytes
cray_example1.f90:9.7:

program
      1
Error: Invalid form of PROGRAM statement at (1)

C:\gfortran\clf\cray_example>ifort cray_example1.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9..1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

cray_example1.f90(4) : Warning: An integer pointer variable has been
explicitly
given a data type that is not the integer type and kind for an address on
the cu
rrent platform.   [IPT]
 pointer (ipt, x)
----------^
cray_example1.f90(9) : Error: Syntax error, found END-OF-STATEMENT when
expectin
g one of: <IDENTIFIER>
program
-------^
compilation aborted for cray_example1.f90 (code 1)

The PROGRAM statement is easily fixed; the declaration of ipt is a
little more problematic.  You need to provide a declaration that
will be 4 bytes wide on 32-bit platforms and 8 bytes wide on 64-bit
platforms.  DVF/CVF/IFORT introduced the INT_PTR_KIND() extension
for this purpose:

C:\gfortran\clf\cray_example>type cray_example2a.f90
! testmod.f95
module test
   implicit none
   integer x
   integer(INT_PTR_KIND()) ipt
   pointer (ipt, x)
end module

! test.f95
program main
   use test
   integer x
   x = 2
   print *,x
end

C:\gfortran\clf\cray_example>ifort cray_example2a.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9..1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

cray_example2a.f90(13) : Error: The attributes of this name conflict with
those
made accessible by a USE statement.   [X]
   integer x
-----------^
compilation aborted for cray_example2a.f90 (code 1)

But most vendors didn't follow suit, AFAIK.  F03, through its C
interoperability features, gets a named constant called C_INTPTR_T
which does the trick:

C:\gfortran\clf\cray_example>type cray_example2.f90
! testmod.f95
module test
   use ISO_C_BINDING
   implicit none
   integer x
   integer(C_INTPTR_T) ipt
   pointer (ipt, x)
end module

! test.f90
program main
   use test
   integer x
   x = 2
   print *,x
end

C:\gfortran\clf\cray_example>gfortran -fcray-pointer
cray_example2.f90 -ocray_ex
ample2

C:\gfortran\clf\cray_example>cray_example2

C:\gfortran\clf\cray_example>

The last example above is PR36497.  I was not aware that it
was even possible to declare the type of the cray pointer ipt
separately.  The POINTER declaration statement already does
this for you.  It turns out that the rule is that you may
provide a redundant declaration of the pointer as an integer
of hte appropriate kind, but as you may have gathered from the
above sequence it's so much of a PITA that it's generally not
done this way and in further examples we shall omit the
redundant declaration.

Now you have another problem that ifort detected: you are declaring
another copy of x in your main program.  If x were host associated
this would be OK and would override the host declaration of x:

module stuff
   integer x
   contains
      subroutine sub
         real x ! OK, overrides host-associated x
      end subroutine sub
end module stuff

But unfortunately for you, x is USE associated (through the
statement

   use test

in program main).  Use association can't be overridden in most
cases, so your program is in error.  What to do?  Well, I presume
that you want the USE associated x in any case, so we simply leave
it in place.  Now, we want to do some cray pointer stuff.  Since
x has benn declared to be a cray pointee, it doesn't actually get
allocated any memory at program start.  The only way it gets life
is if the associated pointer, ipt, is pointed at some memory,
either preexisting or allocated by some mechanism.  Here we shall
create an example using preexisting memory:

C:\gfortran\clf\cray_example>type cray_example3.f90
! testmod.f95
module test
   implicit none
   integer x
   pointer (ipt, x)
end module

! test.f90
program main
   use test
   integer, target :: y, z
   y = 2
   z = 3
   ipt = LOC(y)
   print *,x
   ipt = LOC(z)
   print *,x
end

C:\gfortran\clf\cray_example>gfortran -fcray-pointer
cray_example3.f90 -ocray_ex
ample3

C:\gfortran\clf\cray_example>cray_example3
           2
           3

C:\gfortran\clf\cray_example>ifort cray_example3.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9..1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 8.00.40310.39
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:cray_example3.exe
-subsystem:console
cray_example3.obj

C:\gfortran\clf\cray_example>cray_example3
           2
           3

See how the pointer ipt was first pointed at y so that printing
out its associated pointee printed out the current value of y.
Later pointing it at z printed out z's value through x.

F03 provides a standard way to replace cray pointers with
type(C_PTR) and Fortran pointers.  In many instances, Fortran
pointers alone suffice (hence f90 is good enough) but you can
do some things with type(C_PTR) that you can't with solely by
Fortran pointers, so ourr final example uses type(C_PTR):

C:\gfortran\clf\cray_example>type cray_example4.f90
! testmod.f95
module test
   use ISO_C_BINDING
   implicit none
   integer, pointer :: x
   type(C_PTR) ipt
end module

! test.f90
program main
   use test
   integer, target :: y, z
   y = 2
   z = 3
   ipt = C_LOC(y)
   call C_F_POINTER(ipt,x)
   print *,x
   ipt = C_LOC(z)
   call C_F_POINTER(ipt,x)
   print *,x
end

C:\gfortran\clf\cray_example>gfortran cray_example4.f90 -ocray_example4

C:\gfortran\clf\cray_example>cray_example4
           2
           3

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


Wow, thanks for the thorough answer. It's obviously been a little
while since I've looked at this problem.

"Since
x has benn declared to be a cray pointee, it doesn't actually get
allocated any memory at program start. The only way it gets life
is if the associated pointer, ipt, is pointed at some memory,
either preexisting or allocated by some mechanism."

This was my problem, I wasn't aware no memory was allocated for during
the 'integer x' declaration in the module.

I had read about it being better to not declare ipt before the cray
statement. The reason it was in there was because I was trying to
declare ipt in the module, and put the cray pointer declaration in the
main program. The reason for this is in the program I wanted to
update had a header file with pointer variables (ipt) and separate
subroutine files that included it and declared cray pointers (an old
memory management technique?). When I tried this, however, the
compiler complained that I couldn't use a 'USE' associated variable as
a pointer. The only thing I could think of was to move all the cray
pointer declarations into the module itself. If anyone has a better
idea, I would appreciate it :)

Thanks again for the response.

.

Relevant Pages

  • on topic to clc [Was: Banks and economy]
    ... pointer type - which I think is correct for "arrays", ... Since, as a formal parameter, char cptr[]; ... pointer to the 'completing' declaration, ...   tentative definition. ...
    (comp.lang.c)
  • RE: MIDL2039: interface does not conform to [oleautomation] attribute
    ... > compatible BSTR pointer. ... the IDL declaration produces the following warning: ... > component is that this one is passed as a pointer. ...
    (microsoft.public.win32.programmer.ole)
  • Re: const qualifier and VC6.0
    ... > emphasis is on types, while in C the emphasis is on expressions. ... When declaring pointer and reference variables, ... int &p; ... For example, the following declaration ...
    (comp.lang.cpp)
  • Re: Highly efficient string reversal code
    ...    One more than the address of an object ... Hold on - I still dont hold with the other version from cbf. ... "...If both the pointer operand and the result point ... considering it is not used anymore? ...
    (comp.lang.c)
  • Re: Designing an item system
    ...   happy either as it is unwieldy for inventory and store management. ... then be cleaned up as soon as the pointer goes out of scope). ... contains probability tables for all item types and options. ... I haven't been able to force it into a fix memory structure yet. ...
    (rec.games.roguelike.development)