Re: [PATCH, gfortran] Re: Cray Pointers

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Asher Langton wrote:
> Thanks for the review.  I've made most of the changes you requested; 
> the exceptions are noted below.   (I've also added some new tests.)

Thanks.  I'll only reply to a few points you make, but keep the final review
for the weekend.

>>(First, do we really want to allow this extension in cases that are not
>>Fortran 77 + Cray pointers, IOW pointees of user-defined types?
> 
> 
> I don't think it hurts.   Most commercial compilers support them, at 
> least to some extent.  The only compiler I've found with no support 
> at all for derived type pointees is Pathscale.

Ok, I guess we're losing nothing.

>>Please leave a blank line between variable declarations and the function's
>>code.  Also, please check for the opening parenthesis inside the matcher
>>function, the same way this is handled for the parameter statement.
> 
> 
> The reason I check for the opening parenthesis early is to 
> distinguish Cray pointer declarations from Fortran 90 pointer 
> declarations.

Yes, but you can easily distinguish the two inside gfc_match_pointer.  Just do:
match
gfc_match_pointer ()
{
   if (gfc_peek_char () == '(')
       /* match Cray Pointer declaration */
   else
       /* match POINTER attribute */
}

I believe this is better because this way one doesn't have to look at parse.c
to find out what the syntax of a Cray Pointer is, and how we handle them.

> 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:
> 
> integer(4) buffer(1024)
> real(8) rarray(512)
> integer(4) iarray(1024)
> pointer (ipt, rarray)
> pointer (ipt, iarray)
> ipt = loc (buffer)
> 
> So there's no way to know the size of the data type pointed to by a 
> Cray pointer.
> 
> I've added a paragraph about Cray pointer arithmetic to the documentation.

Ok.  I've just checked pgf's documentation to see if they refer to these
objects as "Cray pointers" because I was worrying if there might be trademark
issues if we use that name (they do call the statement "POINTER (Cray)" and
then refer to it simply as POINTER statement in the following, so I think
we're safe, but I'd appreciate input from other people).  Anyway, looking over
the examples they gave, I found that they allow the following:
   POINTER (p,x(5))
   ALLOCATE (x)
(which is of of course doing the obvious allocation.).  I think we should add
this as well.

>> > +   /* Skip checks for Cray Pointee arrays */
>> > +   if (as->cray_pointee)
>> > +       return SUCCESS;
>> > +
>>
>>Please move that check into compare_spec_to_ref (or maybe even
>>resolve_array_ref?  That way you could also do away with setting the fake
>>value for the upper bound in the highest dimension, I haven't yet checked
>>which checks are needed, and I want to finish this first run, before I
>>have to return to my polylogarithms).
> 
> 
> I've moved the code, but so far, the fake upper bound is needed. 
> Leaving it null results in an error in  spec_dimen_size (in array.c)

Ok, I will think about this some more.  I think lieing is worse than adding
additional checks in a few places, but we should definitely find all places
that need fixing.

Thanks,
- Tobi