[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