This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [gfortran] Fix PR 15211
- From: Paul Brook <paul at codesourcery dot com>
- To: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- Cc: fortran at gcc dot gnu dot org, patch <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 14 Jun 2004 18:24:58 +0100
- Subject: Re: [gfortran] Fix PR 15211
- Organization: CodeSourcery
- References: <40BB7F67.70007@physik.uni-muenchen.de> <200406121218.05746.paul@codesourcery.com> <40CDD4D2.8040000@physik.uni-muenchen.de>
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