https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Jan 08, 2019 at 09:40:29PM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> 
> Naw, it is is not due to my patch.  Rather my patch has
> exposed or uncovered a bug in gfortran.  gfortran needs
> to check
> 
> F2018:C877 (R839) A data-i-do-object or a variable that appears as a
>    data-stmt-object shall not be an object designator in which a pointer
>    appears other than as the entire rightmost part-ref .
> 
> In decl.c (gfc_match_data), gfortran needs a check for C877.
> I haven't gotten around to fixing this yet, and I likely won't
> for the foreseeable future.
> 

Index: gcc/fortran/decl.c
===================================================================
--- gcc/fortran/decl.c  (revision 267735)
+++ gcc/fortran/decl.c  (working copy)
@@ -655,6 +655,15 @@ gfc_match_data (void)
                         "near %C in DATA statement");
              goto cleanup;
            }
+
+         if (e->symtree->n.sym->ts.type == BT_DERIVED
+             && e->symtree->n.sym->attr.pointer
+             && e->ref->type == REF_COMPONENT)
+           {
+             gfc_error ("part-ref with pointer attribute near %L is not "
+                        "rightmost component of data-stmt-object", &e->where);
+             goto cleanup;
+           }
        }

       m = top_val_list (new_data);

The above is marginally correct.  It may be a starting point for
someone who cares about this bug and wants to fix it.  The patch
checks if the leftmost part-ref has the pointer attribute and 
the variable is a REF_COMPONENT, which means that a part-ref
other than the rightmost component has the pointer attribute.
This is the simple case.  A better patch would need to check
each part-ref for the pointer attribute.  That is none of a, b,
c, d, or e in a%b%c%d%e%i can have a pointer attribute.

Note, this works

program bar
   type a
     integer, pointer :: i
   end type a
   type b
     type(a) j
   end type b
   integer, target, save :: k = 42
   type(b) x
   data x%j%i/k/
   print *, x%j%i
end program bar

This gives an ICE like the one reported in this PR.  'j'
has the pointer attribute and so the program should be
rejected.

program bah
   type a
     integer :: i
   end type a
   type b
     type(a), pointer :: j
   end type b
   integer, target, save :: k = 42
   type(b) x
   data x%j%i /k/
   print *, x%j%i
end program bah

Reply via email to