Re: [Patch, Fortran] PR71068 - fix ICE on invalid with coindexed DATA

[Tobias Burnus <burnus at net-b dot de>]

Dear Paul,

Paul Richard Thomas wrote:
> Thanks for the patch
Thanks also from my side.

> PS Why, in principle, can data objects not have co-indices?

I think there is no really fundamental reason, but it doesn't make 
really sense. DATA is an explicit initialization, similar to
  "integer :: i = 5"
and (mostly) has implicitly the SAVE attribute. [5.6.7 @ J3/16-007r1] To 
initialize the variable on a remote image feels odd - especially as each 
image initializes it to the same value.

[Side remark, since I just stumbled over it: "The statement ordering 
rules allow DATA statements to appear anywhere in a program unit after 
the specification statements. The ability to position DATA statements 
amongst executable statements is very rarely used, unnecessary, and a 
potential source of error." (B.3.5 in the section of obsolescent 
features in F2015 (J3/16-007r1).)]

Cheers,

Tobias

> On 21 June 2016 at 16:15, Tobias Burnus
> <tobias.burnus@physik.fu-berlin.de> wrote:
> > Dear all,
> >
> > the problem comes up with:
> >     data a(1)[1] /1/
> > which is invalid. In resolve.c's check_data_variable(), one has:
> >
> >    if (!gfc_resolve_expr (var->expr))
> >      return false;
> > ...
> >    e = var->expr;
> >
> >    if (e->expr_type != EXPR_VARIABLE)
> >      gfc_internal_error ("check_data_variable(): Bad expression");
> >
> > which triggers as resolve_variable() has:
> >
> >    if (t && flag_coarray == GFC_FCOARRAY_LIB && gfc_is_coindexed (e))
> >      add_caf_get_intrinsic (e);
> >
> >
> > The solution is either not to decorate the DATA variable with
> > caf_get() - or to strip it off for testing. The latter has been
> > done in this patch. It's not really beautify, but works.
> >
> > Additionally, I had to add the argument-handling short cut
> > as otherwise, more and more caf_get() could be added around the
> > argument, which is both pointless and causes the strip off to
> > fail.
> >
> >
> > Build and regtested on x86-64-gnu-linux.
> > OK for the trunk? Or do you see a more beautiful approach?
> >
> > Tobias