Re: [Patch, Fortran, 4.5 Regression] PR 40822: Internal compiler error when Fortran intrinsic LEN referenced before explicit declaration

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Thu, Jul 23, 2009 at 10:31:37PM +0200, Janus Weil wrote:
> 2009/7/23 Steve Kargl <sgk@troutmask.apl.washington.edu>:
> > On Thu, Jul 23, 2009 at 05:53:37PM +0200, Janus Weil wrote:
> >> 2009/7/23 Tobias Burnus <burnus@net-b.de>:
> >> > Janus Weil wrote:
> >> >> here is a close-to-obvious two-line patch, fixing a regression which
> >> >> was introduced by one of my earlier ProcPtr patches.
> >> > I have not fully thought about the patch. But if I read
> >> >
> >> > + ? ? ?if (formal_arg->sym->ts.type == BT_CHARACTER)
> >> > + ? ? ? formal_arg->sym->ts.cl = gfc_get_charlen ();
> >> > +
> >> >
> >> >
> >> > I wonder whether this does not just allocate space for the character
> >> > length data, without actually properly initializing the struct.
> >>
> >> I guess the cl structure here is at least initialized in the sense
> >> that it is zeroed, and there is no junk data in there.
> >>
> >> The reason that I don't initialize cl->length is that
> >> "cl->length==NULL" is equivalent to an assumed-length string, right?
> >
> > I believe that you're correct. ?But, with the deferred type
> > parameter patch that I've been work on, cl->length==NULL
> > also means the CHARACTER(len=:) entity hasn't been allocated
> > (or assigned to).
> 
> Thanks for the remark. However, I think in this special case there
> should be no ambiguity (wrt assumed length vs deferred type
> parameter), since my patch only applies to formal args of intrinsic
> functions.
> 
> [ In general: How do you distinguish the two, if both come with
> cl->length==NULL? Is attr.dummy enough? ]
> 

My patch is a WIP that has stalled with the translation to trees.
But, the design so far has added a 'bool deferred_charlen' to 
the gfc_typespec structure and a 'struct gfc_expr *deferred_length'
to the gfc_charlen structure.  A combination of these two added
structure members allows one to determine the state of a string.

   program str
1  character(len=:) str
2  allocate(character(len=9) :: str)
3  allocate(character(len=7) :: str)
   end program

Parsing 1 sets deferred_charlen to true.

Parsing 2 performs some constraints checking, and if length is NULL
then deferred_length is set to 9 and length is left alone.  When
2 is translated to tree-ssa form, length will be set to 3.
   
Parsing 3 fails because length is no longer NULL (can't allocated
an already allocated entity) due to the previous allocate statement.

But, it gets more interesting. 

   program str
4  character(len=:) str
5  str = 'janus'
6  str = 'steve'
7  str = 'sgk'
   end program

Parsing 4 sets deferred_charlen to true.

Translating 5 should find that str has both deferred_length
and length set to NULL.  Both are set to 5 and memory is
implicitly allocated for the string.

Translating 6 should find that str has both deferred_length
and length set to 5 from the previous assignment.  The length
of the rhs expression is 5, so simply do the assignment.

Translating 7 finds str has both deferred_length and length
set to 5.  The length of the rhs expression is 3.  So, implicitly
deallocate the current string, allocate a new string, and set
deferred_length and length to 3.

Hopefully, this has helped explained where I'm at on this feature.

-- 
Steve