This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran] Improved dependency analysis of pointer variables
- From: Roger Sayle <roger at eyesopen dot com>
- To: François-Xavier Coudert <fxcoudert at gmail dot com>
- Cc: Toon Moene <moene at knmi dot nl>, <fortran at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 16 Mar 2006 07:55:05 -0700 (MST)
- Subject: Re: Fortran] Improved dependency analysis of pointer variables
On Thu, 16 Mar 2006, [ISO-8859-1] François-Xavier Coudert wrote:
> >> Of course, looking closer there
> >> couldn't possibly be a dependency using type-based aliasing, as Grid
> >> points to an array of integers and Y points to an array of reals.
> >
> > But a far better argument would be that Y isn't a TARGET, and therefore
> > cannot be pointed to by *any* pointer.
>
> I think you (Toon) are talking about Fortran pointers, while Roger is
> talking about "C pointers in the generated code". At least that's how
> I read it...
Hmm. I was actually talking about FORTRAN variables with the pointer
attribute. My reading of the "pointer assignment" sections of the
F95 and F2003 standards is that a pointer may only be associated with
a target object, when their types are compatible. Hence an array of
real*4 can't be assigned via "=>" to a pointer to real*4. This rule/
constraint conveniently provides pointer-type semantics (like in C),
but without the void*/char* exceptions. i.e. FORTRAN pointers are
strongly typed.
What I didn't read from this sections was the definition of "target"
objects. Many thanks to Toon for pointing out that FORTRAN also has
a mechanism for maintaining an attribute from which objects may be
pointed to. I've not looked into it yet, but this may supplement
my proposed type-based alias resolution, when the types match.
Roger
--