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

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #5)
> The thread on the J3 ML starts here:
> 
> https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html

While John Reid thinks the code is valid F2018, Robert Corbett points
to clarifications in F2023 19.3.1 regarding scope:

The example in comment#0 is invalid, as "this" is a local identifier,
and using it in a BLOCK construct does not make it host-associated.

The example in comment#1 is valid, as the use of "this" in the internal
subroutine makes it host-associated.

I hope I summarized this properly.

Now after looking at how we treat host-association, I stumbled over the
following snippet in resolve_variable:

  /* If a symbol has been host_associated mark it.  This is used latter,
     to identify if aliasing is possible via host association.  */
  if (sym->attr.flavor == FL_VARIABLE
      && (!sym->ns->code || sym->ns->code->op != EXEC_BLOCK
          || !sym->ns->code->ext.block.assoc)
      && gfc_current_ns->parent
      && (gfc_current_ns->parent == sym->ns
          || (gfc_current_ns->parent->parent
              && gfc_current_ns->parent->parent == sym->ns)))
    sym->attr.host_assoc = 1;


This part sets sym->attr.host_assoc for both testcases, but according to
the discussion it should not for the case in comment#0.

Reply via email to