This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gfortran,patch] PR 15809, part 1
- From: Paul Brook <paul at codesourcery dot com>
- To: fortran at gcc dot gnu dot org
- Cc: Erik Edelmann <eedelman at acclab dot helsinki dot fi>,gcc-patches at gcc dot gnu dot org
- Date: Thu, 8 Sep 2005 17:23:51 +0100
- Subject: Re: [gfortran,patch] PR 15809, part 1
- References: <20050831191313.GA933@acclab.helsinki.fi> <20050901125605.GA5501@acclab.helsinki.fi>
On Thursday 01 September 2005 13:56, Erik Edelmann wrote:
> eedelman@acclab.helsinki.fi wrote:
> > :ADDPATCH <fortran>:
> >
> > The attached patch fixes one of the two bugs in 15809.
> >
> > The cause of the bug is that in trans-array.c/gfc_trans_deferred_array()
> > we require that TREE_CODE (sym->backend_decl) == VAR_DECL.
> > For dummy variables, however, TREE_CODE (sym->backend_decl) is
> > PARM_DECL. We need to accept that as well.
> >
> > Bubblestrapped & reg. tested on 4.0 and mainline (Linux/x86).
> > Please commit if OK.
>
> Don't commit yet. While I still think the patch is correct in
> the sense that it fixes the bug and doesn't break anything, I
> also think that there might be a better way to fix the bug.
>
> The reasons why I think this:
>
> 1) gfc_trans_deferred_array() doesn't do anything special for
> dummy arguments.
>
> 2) gfc_trans_deferred_array() seems to not be called for any
> other type of dummies than
> CHARACTER(len=<expression_involving_other_dummy_var>).
It's only called for variables that have a non-constant length.
For constant length variables we already know the length so don't have to do
anything. For non-constant length we need to evaluate the string length
expression.
Deferred shape arguments are a special case because the standard requires that
the actual length be the same as the dummy length, so evaluating the len=
expression is optional (we could use the passed length directly). It'd be
nice if we could add checking code to enforce this when -fbounds-check.
> The better solution I'm thinking of is to just avoid calling
> gfc_trans_deferred_array() for (any kind of) dummy arguments.
Possibly. This may end up being more hassle than just ignoring the ones where
we don't have to do anything.
Paul