[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, for normal derived types resolve_symbol calls
resolve_fl_derived -> resolve_fl_derived0 -> add_dt_to_dt_list
which ensures that the derived type eventually makes it into ns->derived_types
and then gfc_get_derived_type will do:
  /* The derived types from an earlier namespace can be used as the
     canonical type.  */
  if (derived->backend_decl == NULL
      && !derived->attr.use_assoc
      && !derived->attr.used_in_submodule
      && gfc_global_ns_list)
    {
      for (ns = gfc_global_ns_list;
           ns->translated && !got_canonical;
           ns = ns->sibling)
        {
          if (ns->derived_types)
            {
              for (gfc_symbol *dt = ns->derived_types; dt && !got_canonical;
                   dt = dt->dt_next)
                {
                  gfc_copy_dt_decls_ifequal (dt, derived, true);
                  if (derived->backend_decl)
                    got_canonical = true;
                  if (dt->dt_next == ns->derived_types)
                    break;
                }
            }
        }
    }
(ugh, linear walk of all namespaces and all derived types in them!  A hash
table would be much better) will find matching derived type in some other
namespace
and if it has backend_decl, will use it as TYPE_CANONICAL.
All of resolve_symbol and resolve_fl_derived and resolve_fl_derived0 have an
early exit for sym->attr.unlimited_polymorphic,
so add_dt_to_dt_list isn't done for it but that isn't a big deal because
gfc_get_derived_type for derived->attr.unlimited_polymorphic just returns
ptr_type_node (the same in all namespaces).

But __class__STAR_p symbol isn't unlimited_polymorphic, but in
resolve_fl_derive we trigger:
  if (sym->attr.is_class && sym->ts.u.derived == NULL)
    {
      /* Fix up incomplete CLASS symbols.  */
      gfc_component *data = gfc_find_component (sym, "_data", true, true,
NULL);
      gfc_component *vptr = gfc_find_component (sym, "_vptr", true, true,
NULL);

      /* Nothing more to do for unlimited polymorphic entities.  */
      if (data->ts.u.derived->attr.unlimited_polymorphic)
        return true;
and so don't call resolve_fl_derived0, neither for sym nor for vptr, so never
call add_dt_to_dt_list for __class__STAR_p
and so gfc_get_derived_type for those will always set TYPE_CANONICAL to itself,
so each namespace's __class__STAR_p is considered to be private for TBAA
purposes.

--- gcc/fortran/resolve.cc.jj   2022-03-21 11:00:06.447824689 +0100
+++ gcc/fortran/resolve.cc      2022-03-22 12:35:38.381250338 +0100
@@ -15138,7 +15138,10 @@ resolve_fl_derived (gfc_symbol *sym)

       /* Nothing more to do for unlimited polymorphic entities.  */
       if (data->ts.u.derived->attr.unlimited_polymorphic)
-       return true;
+       {
+         add_dt_to_dt_list (sym);
+         return true;
+       }
       else if (vptr->ts.u.derived == NULL)
        {
          gfc_symbol *vtab = gfc_find_derived_vtab (data->ts.u.derived);
doesn't help much though, while it registers __class_STAR_p,
gfc_get_derived_type -> gfc_copy_dt_decls_ifequal -> gfc_compare_derived_types
considers them unequal.