This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
PR fortran/17031 PR fortran/22282 * check.c (gfc_check_loc) : New function
* 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
* intrinsic.h (gfc_check_loc): Declare (gfc_resolve_loc): Declare
* trans-intrinsic.c (gfc_conv_intrinsic_loc): New (gfc_conv_intrinsic_function): added entry point for loc translation
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
Attachment:
cp_patch_8_12a.diff
Description: Binary data
Attachment:
cray_pointers_1.f90
Description: Binary data
Attachment:
cray_pointers_2.f90
Description: Binary data
Attachment:
cray_pointers_3.f90
Description: Binary data
Attachment:
loc_1.f90
Description: Binary data
Attachment:
loc_2.f90
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |