https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721

markeggleston at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markeggleston at gcc dot 
gnu.org

--- Comment #10 from markeggleston at gcc dot gnu.org ---
Using the bare minimum:

integer :: b
character(len(c)) :: b
end

I consistently get:

    2 | character(len(c)) :: b
      |                      1
Error: Symbol ‘b’ at (1) already has basic type of INTEGER
pr82721temp.f90:2:14:

    2 | character(len(c)) :: b
      |              1
Error: Statement function ‘’ at (1) is not allowed as an actual argument

The second error pops out when the following code in resolve_types (resolve.c)
is executed:

  for (cl = ns->cl_list; cl; cl = cl->next)
    resolve_charlen (cl);

The list of character lengths is corrupt, the first item points to an
expression of type EXPR_FUNCTION however its symtree has the name "end" instead
of "len" it had when it was first added to the character lengths list.

When reject_statement is called for "character(len(c)) :: b" the symtree
structure for "len" is deleted, unfortunately the reference to the deleted
symtree structure remains untouched in the expression representing the
character length.

Later a symtree is created for "end" which matches the symtree referenced by
the character length expression thus the name is changed to "end" and the
symtree points to symbol.

As an experiment using a nasty dirty hack I prevent the symtree being deleted
if it was referenced by the expression pointed to by the length field of the
charlen structure. It had not affect on the reported errors.

I have since discovered that the expression that is the first argument of the
"len" function also has a symtree that is deleted which the reference remains
as is.

Note: the comment preceding reject_statement says:

/* Undo anything tentative that has been built for the current statement,
   except if a gfc_charlen structure has been added to current namespace's
   list of gfc_charlen structure.  */

Clearly this is not the case as items referenced indirectly from the
gfc_charlen structure are deleted without references being touched.

Further investigation is in progress.

Reply via email to