[PATCH, gfortran] Re: Cray Pointers

Asher Langton langton2@llnl.gov
Sat Aug 13 03:56:00 GMT 2005


Okay, here's an update patch.  I've fixed a bug regarding pointees in 
modules, added some documentation, and rearranged the parsing.  Some 
comments follow:

At 11:38 AM +0200 8/12/05, Tobias Schlüter wrote:
>Asher Langton wrote:
>>  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.

Yes, good point.  I''ve changed that.

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

Dynamic memory allocation is the one place where all of the compiler 
vendors differ.  Some have malloc, or alloc, or allocate(x), etc.  I 
think a malloc intrinsic would be more useful than allocate(), since 
malloc + loc can useful without Cray pointers.

>>>  > +   /* 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.

The main reason to have that fake upper bound is to avoid have a null 
pointer in the array spec.  Since the array specs seem to get handled 
a lot, I think it's safer not to have a part of it in an unexpected 
(null) state.  It can probably be made to work either way, though.

-Asher


2005-08-12  Asher Langton  <langton2@llnl.gov>

	PR fortran/17031
	PR fortran/22282
	* check.c (gfc_check_loc) : New function

	* decl.c (variable_decl): New variables cp_as and sym.  Added 
a check for variables that
	have already been declared as Cray Pointers, so we can get 
the necessary attributes
	without adding a new symbol.
	(attr_decl1):  Added code to catch pointee symbols and "fix" 
their array specs
	(cray_pointer_decl): New method
	(gfc_match_pointer): Added Cray pointer parsing code
	(gfc_mod_pointee_as): New method

	* expr.c (gfc_check_assign): added a check to catch 
vector-type assignments
  	to pointees with an unspecified final dimension.

	* gfortran.h: (GFC_ISYM_LOC): New
	(symbol_attribute): Added cray_pointer and cray_pointee bits
	(gfc_array_spec): Added cray_pointee and cp_was_assumed bools
	(gfc_symbol): Added gfc_symbol *cp_pointer
	(gfc_option): Added flag_cray_pointer
	(gfc_add_cray_pointee): Declare
	(gfc_add_cray_pointer ): Declare
	(gfc_mod_pointee_as): Declare

	*gfortran.texi: Added section on Cray pointers, removed Cray 
pointers from list of proposed
	extensions

	* intrinsic.c (add_functions): add code for loc() intrinsic

	* intrinsic.h (gfc_check_loc): Declare
	(gfc_resolve_loc): Declare

	* intrinsic.texi: Added documentation for loc intrinsic

	* invoke.texi: Documented -fcray-pointer flag

	* iresolve.c (gfc_resolve_loc): New

	* lang.opt: Added fcray-pointer flag

	* options.c (gfc_init_options): Intialized 
gfc_match_option.flag_cray_pointer
	(gfc_handle_option): deal with -fcray-pointer

	* parse.c: Added do...while(0) and braces around match() 
macro to avoid the if/else
	ambiguity
	(resolve_equivalence): Added code prohibiting Cray pointees 
in equivalence statements.

	* resolve.c (resolve_array_ref): added code to prevent bounds 
checking for Cray
  	Pointee arrays.

	* symbol.c (check_conflict): Added Cray pointer/pointee 
attribute checking
	(gfc_add_cray_pointer): New
	(gfc_add_cray_pointee): New
	(gfc_copy_attr): New code for Cray pointers and pointees

	* trans-array.c (gfc_trans_auto_array_allocation): added code 
to prevent space from
  	being allocated for pointees
	(gfc_conv_array_parameter): added code to catch pointees and
  	correctly set their base address.

	* trans-decl.c (gfc_finish_var_decl):  added code to prevent 
pointee declarations from making
	it to the back end.
	(gfc_create_module_variable):  same

	* trans-expr.c (gfc_conv_variable): added code to detect and 
translate pointees
	(gfc_conv_cray_pointee): New

	* trans-intrinsic.c (gfc_conv_intrinsic_loc): New
	(gfc_conv_intrinsic_function): added entry point for loc translation

	* trans.h (gfc_conv_cray_pointee): Declare

2005-08-12  Asher Langton  <langton2@llnl.gov>

	PR fortran/17031
	PR fortran/22282
	*gfortran.dg/cray_pointers_1.f90: New
	*gfortran.dg/cray_pointers_2.f90: New
	*gfortran.dg/cray_pointers_3.f90: New
	*gfortran.dg/loc_1.f90: New
	*gfortran.dg/loc_2.f90: New

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cp_patch_8_12a.diff
Type: application/octet-stream
Size: 41767 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cray_pointers_1.f90
Type: application/octet-stream
Size: 87296 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cray_pointers_2.f90
Type: application/octet-stream
Size: 128 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cray_pointers_3.f90
Type: application/octet-stream
Size: 1950 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loc_1.f90
Type: application/octet-stream
Size: 2901 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: loc_2.f90
Type: application/octet-stream
Size: 436 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20050813/01930f56/attachment-0005.obj>


More information about the Fortran mailing list