This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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]

Re: [gfortran] Fix PR 15211


On Monday 14 June 2004 17:39, Tobias Schlüter wrote:
> Paul Brook wrote:
> > On Monday 31 May 2004 19:54, Tobias Schlüter wrote:
> >>Looking again at the code in gfc_conv_intrinsic_len it occurred to me
> >>that all strings in an array must be of the same length. Therefor this
> >>one line fix should do the trick. The test for arg->ref == NULL is
> >>clearly meant to separate the case of arg->ref == REF_SUBSTRING, but is
> >>meaningless in the case of REF_ARRAY or REF_COMPONENT (which I will look
> >>into after this is approved).
> >>
> >>2004-05-31  Tobias Schlueter  <tobias.schlueter@physik.uni-muenchen.de>
> >>
> >>	* trans-intrinsic.c (gfc_conv_intrinsic_len): Deal with arrays
> >>	of strings.
> >
> > You need to iterate over all the refs. You can have an substring (or
> > component ref) of an arrayref.
>
> So, to make sure I understand correctly, checking (arg->ref == NULL ||
> (arg->ref->next == NULL && arg->ref->type == REF_ARRAY)) should fix the

Yes, that would work. Patch approved with that change.

I imagine we'll want to end up with something like:

/* (1) */
if ( arg->expr_type == EXPR_VARIABLE)
  {
  gfc_ref *ref = arg->ref;
  while (ref && we_have_magic_for_this_ref (ref))
  {
    switch (ref->type)
    {
    case SUBSTRING_REF:
      <Evaluate the bounds of the substring and return that.>
    case COMPONENT_REF:
      <Find the component decl>
    case ARRAY_REF:
      <nop>
    }
    ref = ref->next;
  }
  if (!ref)
    {
    <pull the length out of the appropriate decl >
    return <...>;
    } 
}

/* (2) */
val = evaluate_arbirary_expression(arg)
return string_length(val)
}

This would allow us to traverse multiple component/array/substring refs.

> PR, but leave us with a problem in the case of something like
>   a(5)(1:3)
> or
>   a(5)%string
> ?
>
> I can submit a patch with the revised check, but I don't think I can fix
> the other two examples, as my insight into the scalarizer is close to
> non-existant.

I see these as two separate issues:
1) Special casing known expressions. This includes your patch.
2) Teaching the general case how to evaluate array expressions. This involves 
either using the existing function argument evaluation routines, or talking 
to the scalarizer directly.

It's possible that (2) may be unnecessary if (1) is sufficiently complete.

Paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]