[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e

["mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mikael at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
The full typespec is copied from the associate target (x) to the associate
symbol (y) at parse.cc:4925.  This includes the character length object, which
starting from there is shared between x and y.  None of the various conditions
are met in resolve_assoc_var to overwrite the character length object.  So when
we create the length decl (.y) for y and store it in its character length
object, it also appears in that of x at the same time.  And from there it is
added to both functions along a path that I have lost.

Draft patch:

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..266e41e25b1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9227,7 +9227,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
        sym->ts.u.cl = target->ts.u.cl;

       if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
-         && target->symtree->n.sym->attr.dummy
          && sym->ts.u.cl == target->ts.u.cl)
        {
          sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);