Re: [PATCH, gfortran] Re: Cray Pointers

[Paul Brook <paul at codesourcery dot com>]

> >POINTER (p,d)
> >DOUBLE PRECISION d, e(5)
> >
> >p = loc(e(1)) + 1
> >
> >Will this point to e(2)?  The portland group compiler and your
> >implementation think otherwise (they will make p point to the byte
> >following e(1) instead of e(2)), which I wouldn't expect form the
> >documentation I've read in other places.  From what I've read, I would
> >expect this to make p point either to the byte 4 bytes behind e(1) or to
> >e(2) (which lies 8 bytes after e(1)).  If the convention is really to use
> >byte-sized increments, the documentation should definitely make this
> >explicit.
>
> 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.

> 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.

I would expect accessing pointees that do not match the pointed-to object type 
to break aliasing rules. You say that pointees may not alias pointed to 
objects. What about two different pointees?

I'm fairly sure the current optimizers will assume that pointees of different 
types do not alias.

Is it really legal to declare two pointees with the same pointer? It seems a 
strange thing to do.

I'd really like to have as much of this covered as possible so we can say what 
is expected to work, what is explicitly not supported (ie. the user should 
expect the world to end if they do that), and what is not really supported 
but should work if you disable optimization.

> So there's no way to know the size of the data type pointed to by a
> Cray pointer.

There's no foolproof way of knowing, but if you assume all arithmetic is done 
on the pointer directly it should be possible to implement type-size 
arithmetic. In fact you could implement cray pointers internally as C 
pointers rather than as integers.

However this is something that can be implemented as a followup if there is 
demand for it.

> + tree
> + gfc_conv_cray_pointee(gfc_symbol *sym)
> + {

This function needs a comment. So does the if statement it contains. It's not 
clear what the two different cases are for.

<in loc1.f90>
> ! (This was originally in craytest.f90, but was put in a separate file

This comment can be removed. craytest.f90 never existed in CVS either.


Have you tested cray pointers and pointees in modules?
If this is hard to implement it may be acceptable to simply prohibit mixing 
cray pointers and modules.

Paul