[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #7 from anlauf at gcc dot gnu.org --- Created attachment 61582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61582&action=edit Exploratory patch This patch tries to improve upon the determination of whether a symbol is host-associated or not. It works in some situations, but does not in others. Particularly, if "this" is used in the body of the function, it gets attr.use_assoc set. I haven't figured out yet how to handle this. On the positive side, it (still) regtests fine... :-)
[Bug fortran/119994] Valid specification expression in block rejected
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.
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #5 from anlauf at gcc dot gnu.org --- The thread on the J3 ML starts here: https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #4 from Neil Carlson --- (In reply to kargls from comment #3) > Note, Neil has asked on the J3 mailing list for clarification as there > seems to be a conflict on the requirements of a restricted expression. I think the list given in 10.11.1 needs to be understood as an "or" of items so I don't think of (2) and (4) as conflicting. The basic issue in my mind now is how to understand "accessed by host association" in (4). In the case of the internal subroutine I think it's very clearly host association. But it's less clear to me that the standard views access to entities outside a block as "host association". I look forward to what the folks on J3 have to say, especially Malcolm.
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--- Comment #3 from kargls at comcast dot net ---
(In reply to anlauf from comment #2)
> Confirmed.
>
> The following patch fixes both cases:
>
> diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
> index 07e9bac37a1..46ca7874603 100644
> --- a/gcc/fortran/expr.cc
> +++ b/gcc/fortran/expr.cc
> @@ -3550,7 +3664,7 @@ check_restricted (gfc_expr *e)
> break;
> }
>
> - if (sym->attr.intent == INTENT_OUT)
> + if (sym->attr.intent == INTENT_OUT && sym->ns == gfc_current_ns)
> {
> gfc_error ("Dummy argument %qs at %L cannot be INTENT(OUT)",
>sym->name, &e->where);
>
>
> Needs further testing.
Note, Neil has asked on the J3 mailing list for clarification as there
seems to be a conflict on the requirements of a restricted expression.
F2023, 10.1.11
...
A restricted expression is an expression in which each operation is
intrinsic or defined by a specification function and each primary is
...
(2) an object designator with a base object that is a dummy argument
that has neither the OPTIONAL nor the INTENT(OUT) attribute,
...
(4) an object designator with a base object that is made accessible
by use or host association,
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-04-29
Status|UNCONFIRMED |NEW
--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.
The following patch fixes both cases:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index 07e9bac37a1..46ca7874603 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -3550,7 +3664,7 @@ check_restricted (gfc_expr *e)
break;
}
- if (sym->attr.intent == INTENT_OUT)
+ if (sym->attr.intent == INTENT_OUT && sym->ns == gfc_current_ns)
{
gfc_error ("Dummy argument %qs at %L cannot be INTENT(OUT)",
sym->name, &e->where);
Needs further testing.
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #1 from Neil Carlson --- Here's a similar example using an internal subroutine. The rejected specification expression is also valid, as again THIS is accessible by host association. module foo type :: bar integer :: n end type contains subroutine init(this, n) type(bar), intent(out) :: this integer, intent(in) :: n this%n = n call sub contains subroutine sub real :: array(this%n) end subroutine end subroutine end module
