cray pointer declaration issue with gfortran
ronan.v...@gmail.com
previously working on other platforms and compilers (xlf, ifort,
pathf90) but I am having trouble to make it work with gfortran. It
seems to be a cray pointer declaration issue but I cannot tell if I
made a mistake which had not been noticed by the other f90 compilers
or if it is a gfortran bug. Here is an example :
subroutine test(nnode)
implicit none
integer n,nnode
pointer(ip_tab, tab)
integer , dimension(1:nnode) :: tab
do n=1,nnode
tab(n) = 0
enddo
end subroutine test
If I compile this, using 'gfortran -c -fcray-pointer', I get this
error message :
bash-3.2$ gfortran -c -fcray-pointer test.f
test.f:7.72:
tab(n) =
0
1
Error: Unexpected STATEMENT FUNCTION statement at (1)
I found several ways to solve this :
1/ By permuting the pointer and the array declaration :
subroutine test(nnode)
implicit none
integer n,nnode
integer , dimension(1:nnode) :: tab
pointer(ip_tab, tab)
do n=1,nnode
tab(n) = 0
enddo
end subroutine test
2/ By specifying the array size in the pointer declaration :
subroutine test(nnode)
implicit none
integer n,nnode
pointer(ip_tab, tab(1:nnode))
integer :: tab
do n=1,nnode
tab(n) = 0
enddo
end subroutine test
You could say I found my solution by using one of these corrections,
however I do not want to modify my sources since I would have to do a
lot of changes (this is only an example) and it was working with other
compilers. Moreover I read in many cray pointer tutorials that the
pointer declaration , the pointee declaration and the array
specification can be done in any order. As I had to change this order
for my program to work, I do not understand why my first example
failed to compile.
Has anyone an idea ?
Thanks a lot.
Dan Nagle
On 2008-08-06 05:44:06 -0400, ronan.v...@gmail.com said:
> You could say I found my solution by using one of these corrections,
> however I do not want to modify my sources since I would have to do a
> lot of changes (this is only an example) and it was working with other
> compilers. Moreover I read in many cray pointer tutorials that the
> pointer declaration , the pointee declaration and the array
> specification can be done in any order. As I had to change this order
> for my program to work, I do not understand why my first example
> failed to compile.
Cray pointers (a/k/a Livermore pointers) are an extension.
The truly wonderful thing about extensions is that
they are a little different on each compiler that supports
them (where supported at all).
So you simply must find the common way of writing it,
that works with the widest range of compilers.
The other bugaboo about cray pointers is that they
may be word-based or byte-based, so just getting your code
to compile doesn't necessarily get you out of the woods.
--
Cheers!
Dan Nagle
fj
I don't see the memory allocation in your test case !
PROGRAM main
CALL test(10)
END PROGRAM
SUBROUTINE test(nnode)
implicit none
integer n,nnode
pointer(ip_tab, tab(1:nnode))
integer :: tab
ip_tab = malloc(4*nnode)
do n=1,nnode
tab(n) = 0
enddo
write(*,*) tab
end subroutine test
Of course, this is much easier with automatic F90 arrays :
SUBROUTINE test(nnode)
implicit none
integer n,nnode,tab(nnode)
tab=0
write(*,*) tab
end subroutine test
fj
Oups, the problem is even a little bit more complicated because the
array tab is declared with its final dimension (=> confusion between
automatic array and array associated to a Cray pointer)
SUBROUTINE test(nnode)
implicit none
integer n,nnode
integer tab(*) ! declare only the shape of the array
pointer(ip_tab, tab)
ip_tab = malloc(4*nnode) ! in assuming integers with 4 bytes
do n=1,nnode
tab(n) = 1
enddo
write(*,*) tab(1:nnode)
end subroutine test
Richard Maine
> Cray pointers (a/k/a Livermore pointers) are an extension.
> The truly wonderful thing about extensions is that
> they are a little different on each compiler that supports
> them (where supported at all).
>
> So you simply must find the common way of writing it,
> that works with the widest range of compilers.
> The other bugaboo about cray pointers is that they
> may be word-based or byte-based, so just getting your code
> to compile doesn't necessarily get you out of the woods.
This I'd suggest using standard Fortran instead. That would be either
Fortran pointers or, as fj suggests, allocatables.
Cray pointers are inherently non-portable. You aren't going to find a
form of Cray pointers that works unchanged with all compilers. There are
major current Fortran compilers that don't support the Cray pointer
extension at all. You might be able to get more compilers with one form
than another, but you aren't going to get them all.
Unfortunately, yes, changing to standard Fortran would require code
changes.
It is hard to definitively call any particular compiler's implementation
of Cray pointers a "bug", because there isn't any formal standard,
regardless of what tutorials you might have found. If you want to argue
with the gFortran developers that their implementation should be
considered a bug, of course, you are free to do that. They might even
agree; I couldn't say.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Tobias Burnus
> I tried to compile some source code on my mac with gfortran. It was
> previously working on other platforms and compilers (xlf, ifort,
> pathf90) but I am having trouble to make it work with gfortran. It
> seems to be a cray pointer declaration issue but I cannot tell if I
> made a mistake which had not been noticed by the other f90 compilers
> or if it is a gfortran bug.
I don't know either, but as it is a vendor extension, the "standard"
is probably what most compiler do and thus it is a bug.
I therefore filled a bugreport at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
(Don't expect that it will be fixed soonish [though it might be by
chance] - several gfortraner seems to be busy with the real life or
with Fortran 2003 features such as type extension (works) or type-
bound procedures (does not yet work). However, it might get fixed in
GCC 4.4's stage3 when only bug fixes are allowed. - Or it might be
even closed as not-a-bug.)
> You could say I found my solution by using one of these corrections,
> however I do not want to modify my sources since I would have to do a
> lot of changes (this is only an example) and it was working with other
> compilers.
If you do not want to change your code, you have only three options:
a) Use another compiler for the interim
b) Fix gfortran (or find someone who does so)
c) Be patient and hope someone fixes it soon.
I therefore would go either for option (a) or would modify the code in
question, flipping two lines in several procedures should be not too
much work, unless your project is really huge.
The real alternative is to use standard Fortran code - as others have
already suggested. Allocatable or pointer of Fortran 90 should be
enough and Fortran 90 compilers should nowadays exist everywhere;
there exist much more Fortran 90+ compilers than compilers supporting
Cray pointers. The only drawback is that is takes longer to convert
the program.
> Moreover I read in many cray pointer tutorials that the
> pointer declaration , the pointee declaration and the array
> specification can be done in any order. As I had to change this order
> for my program to work, I do not understand why my first example
> failed to compile.
>
> Has anyone an idea ?
Two options, choose one:
a) An omission also called bug
b) The Cray pointer implementation was based on a Cray-pointer
documentation/implementation which also did not allow this
As there is no official standard but Cray pointers are vendor
extensions, their syntax is not well defined and varies between
compilers.
The proper way would be to replace the Cray pointers by standard
Fortran code; depending on the code size, the supported Fortran
version of the other compilers,* and other constrains it might become
difficult and/or laborious to do so. (* some usage of cray pointers
can only be mimicked using Fortran 2003 features which only some,
newer compiler have.)
Tobias
GaryScott
We should probably not call them "Cray" pointers unless they behave
exactly as one (probably the most recent) implementation produced by
Cray. If they match an SGI implementation that differs, then they are
"SGI pointers". Intel calls them "integer pointers" (at least
sometimes). Maybe <compiler/vendor> pointers (<Intel> pointers)?? It
would be more clear which one is implemented.
Dan Nagle
On 2008-08-06 16:57:11 -0400, GaryScott <garyl...@sbcglobal.net> said:
>
> We should probably not call them "Cray" pointers unless they behave
> exactly as one (probably the most recent) implementation produced by
> Cray.
Which Cray pointers did you have in mind?
The original is Livermore pointers, which
worked on Cyber 7600s (or was it 6600s? I
can't recall). These were word pointers (60-bits).
The Cray pointer was at first a (64-bit) word pointer
on the Cray-1 series (later, XMP, YMP). (BTW,
what is a word?)
Later, on the T3D and T3E, they were byte pointers,
as befitting the Alpha chips.
The point is, they're not well defined,
no matter what you call them.
--
Cheers!
Dan Nagle
Ron Shepard
<0bd4352b-17df-4019...@25g2000hsx.googlegroups.com>,
Tobias Burnus <bur...@net-b.de> wrote:
> The real alternative is to use standard Fortran code - as others have
> already suggested. Allocatable or pointer of Fortran 90 should be
> enough and Fortran 90 compilers should nowadays exist everywhere;
> there exist much more Fortran 90+ compilers than compilers supporting
> Cray pointers. The only drawback is that is takes longer to convert
> the program.
Furthermore, the time to make such code changes is now while there
are still compilers that support the old, nonstandard, cray pointer
extension. The code can be changed one routine at a time, and final
and intermediate results can be compared. After the nonstandard
extensions is no longer supported, it will be much more difficult to
change the debug the standard version of the code.
Also, there are compiler consistency checks that can be done with
the standard syntax that cannot be done with the nonstandard syntax.
There are many reasons to fix the code, and to fix it now rather
than later.
$.02 -Ron Shepard
GaryScott
>
>
>
> > We should probably not call them "Cray" pointers unless they behave
> > exactly as one (probably the most recent) implementation produced by
> > Cray.
>
> Which Cray pointers did you have in mind?
>
> The original is Livermore pointers, which
> worked on Cyber 7600s (or was it 6600s? I
> can't recall). These were word pointers (60-bits).
>
> The Cray pointer was at first a (64-bit) word pointer
> on the Cray-1 series (later, XMP, YMP). (BTW,
> what is a word?)
>
> Later, on the T3D and T3E, they were byte pointers,
> as befitting the Alpha chips.
>
> The point is, they're not well defined,
> no matter what you call them.
All the more reason to not call them cray pointers. I don't, I almost
always refer to them by including the specific compiler being used.
>
> --
> Cheers!
>
> Dan Nagle
Richard Maine
> All the more reason to not call them cray pointers. I don't, I almost
> always refer to them by including the specific compiler being used.
While I agree in principle, that's what a majority seems to call them,
so I more or less go along. I often wimp out by saying something like
"so-called Cray pointers", but I'm sure you could find places where I
omitted the waffle. There are times when something like "the
<insert-vandor-name-here> implementation of so-called Cray pointers" is
arguably the best term, but I'd quickly get tired of typing that. :-)
I've probably spelled it out like that in occasion when referring to
something like the variant that allows procedure targets (which I think
is unique to CVF/IVF).
My real preference is to have nothing to do with them, and thus to not
call them anything, but I can't always get by with that.
Some people also call them Livermore pointers, which has substantial
justification, or integer pointers.
Then there are the people who just call them pointers without
qualification, most often people who don't know about standard Fortran
90 pointers. That terminology I always try to clarify because it causes
confusion.
Dan Nagle
On 2008-08-06 18:18:24 -0400, Ron Shepard
<ron-s...@NOSPAM.comcast.net> said:
> Furthermore, the time to make such code changes is now while there
> are still compilers that support the old, nonstandard, cray pointer
> extension. The code can be changed one routine at a time, and final
> and intermediate results can be compared. After the nonstandard
> extensions is no longer supported, it will be much more difficult to
> change the debug the standard version of the code.
>
> Also, there are compiler consistency checks that can be done with
> the standard syntax that cannot be done with the nonstandard syntax.
> There are many reasons to fix the code, and to fix it now rather
> than later.
Sage wisdom, every word. (So I'll requote it entirely.) :-)
--
Cheers!
Dan Nagle
Gary Scott
My one and only use so far is to associate an address for a Fortran
buffer with a region of memory allocated by a Win32 API (that type of
thing). When the OS API returns an address and you want to associate a
symbol with it...
>
> Tobias
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Richard Maine
> My one and only use so far is to associate an address for a Fortran
> buffer with a region of memory allocated by a Win32 API (that type of
> thing). When the OS API returns an address and you want to associate a
> symbol with it...
I realize it isn't available everywhere yet, much less in the past when
you presumably did this, but for future reference...
The C interop stuff of f2003 has support for things like that. Namely,
the c_ptr type and the c_f_pointer procedure.
Gary Scott
> Gary Scott <garyl...@sbcglobal.net> wrote:
>
>
>>My one and only use so far is to associate an address for a Fortran
>>buffer with a region of memory allocated by a Win32 API (that type of
>>thing). When the OS API returns an address and you want to associate a
>>symbol with it...
>
>
> I realize it isn't available everywhere yet, much less in the past when
> you presumably did this, but for future reference...
>
> The C interop stuff of f2003 has support for things like that. Namely,
> the c_ptr type and the c_f_pointer procedure.
>