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.