* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
@ 2023-10-12 10:16 ` mikael at gcc dot gnu.org
2023-10-21 14:01 ` mikael at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-10-12 10:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords| |patch
CC| |mikael at gcc dot gnu.org
Last reconfirmed| |2023-10-12
--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
Confirmed.
This should fix it:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 1042b8c18e8..e2e0fc8eba3 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -285,6 +285,7 @@ gfc_resolve_formal_arglist (gfc_symbol *proc)
sym->attr.always_explicit = 1;
}
+ bool saved_formal_arg_flag = formal_arg_flag;
formal_arg_flag = true;
for (f = proc->formal; f; f = f->next)
@@ -533,7 +534,7 @@ gfc_resolve_formal_arglist (gfc_symbol *proc)
}
}
}
- formal_arg_flag = false;
+ formal_arg_flag = saved_formal_arg_flag;
}
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
2023-10-12 10:16 ` [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument mikael at gcc dot gnu.org
@ 2023-10-21 14:01 ` mikael at gcc dot gnu.org
2023-10-21 16:37 ` mikael at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-10-21 14:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org
--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> ---
I'm on it.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
2023-10-12 10:16 ` [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument mikael at gcc dot gnu.org
2023-10-21 14:01 ` mikael at gcc dot gnu.org
@ 2023-10-21 16:37 ` mikael at gcc dot gnu.org
2024-02-06 18:19 ` anlauf at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2023-10-21 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
I'm trying to remove the formal_arg_flag global variables, which seem to just
disable all the checks on dummy arguments.
Unfortunately, it regresses a bit, say pr101026.f for example can be simplified
to this:
SUBROUTINE PASSB4 (CC,CH)
DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
END
which gives:
pr101026.f:4:19:
4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
| 1
Error: Variable ‘ido’ cannot appear in the expression at (1)
pr101026.f:4:33:
4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
| 1
Error: Variable ‘ido’ cannot appear in the expression at (1)
pr101026.f:4:25:
4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
| 1
Error: Variable ‘l1’ cannot appear in the expression at (1)
pr101026.f:4:37:
4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
| 1
Error: Variable ‘l1’ cannot appear in the expression at (1)
What I don't see is what makes the IDO and L1 variables acceptable in a
specification expression. It seems to me the errors above are valid.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (2 preceding siblings ...)
2023-10-21 16:37 ` mikael at gcc dot gnu.org
@ 2024-02-06 18:19 ` anlauf at gcc dot gnu.org
2024-02-28 18:25 ` anlauf at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: anlauf at gcc dot gnu.org @ 2024-02-06 18:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #3)
> Unfortunately, it regresses a bit, say pr101026.f for example can be
> simplified to this:
>
> SUBROUTINE PASSB4 (CC,CH)
> DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
> END
>
> which gives:
>
> pr101026.f:4:19:
>
> 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
> | 1
> Error: Variable ‘ido’ cannot appear in the expression at (1)
> pr101026.f:4:33:
>
> 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
> | 1
> Error: Variable ‘ido’ cannot appear in the expression at (1)
> pr101026.f:4:25:
>
> 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
> | 1
> Error: Variable ‘l1’ cannot appear in the expression at (1)
> pr101026.f:4:37:
>
> 4 | DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
> | 1
> Error: Variable ‘l1’ cannot appear in the expression at (1)
>
>
> What I don't see is what makes the IDO and L1 variables acceptable in a
> specification expression. It seems to me the errors above are valid.
FWIW, NAG and Intel agree with you. With the original pr101026.f I get:
NAG:
Error: pr101026.f, line 4: IDO is not permitted in a specification expression
Error: pr101026.f, line 4: L1 is not permitted in a specification expression
Error: pr101026.f, line 4: IDO is not permitted in a specification expression
Error: pr101026.f, line 4: L1 is not permitted in a specification expression
Intel:
pr101026.f(4): error #6219: This variable, used in a specification expression,
must be a dummy argument, a COMMON block object, or an object accessible
through host or use association. [IDO]
DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
-------------------^
pr101026.f(4): error #6219: This variable, used in a specification expression,
must be a dummy argument, a COMMON block object, or an object accessible
through host or use association. [L1]
DIMENSION CC(IDO,4,L1), CH(IDO,L1,*)
-------------------------^
Thus I suggest to fix the testcase by one of the options suggested above.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (3 preceding siblings ...)
2024-02-06 18:19 ` anlauf at gcc dot gnu.org
@ 2024-02-28 18:25 ` anlauf at gcc dot gnu.org
2024-02-28 19:38 ` mikael at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: anlauf at gcc dot gnu.org @ 2024-02-28 18:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> Thus I suggest to fix the testcase by one of the options suggested above.
Testcase gfortran.dg/pr101026.f is corrected at r14-9220.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (4 preceding siblings ...)
2024-02-28 18:25 ` anlauf at gcc dot gnu.org
@ 2024-02-28 19:38 ` mikael at gcc dot gnu.org
2024-03-15 19:37 ` mikael at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2024-02-28 19:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 57571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571&action=edit
Tentative patch
(In reply to anlauf from comment #5)
> (In reply to anlauf from comment #4)
> > Thus I suggest to fix the testcase by one of the options suggested above.
>
> Testcase gfortran.dg/pr101026.f is corrected at r14-9220.
Ah, yes, thanks.
I attach above the tentative patch that I tried before.
I need to reevaluate it; there were other regressions if I remember correctly.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (5 preceding siblings ...)
2024-02-28 19:38 ` mikael at gcc dot gnu.org
@ 2024-03-15 19:37 ` mikael at gcc dot gnu.org
2024-03-15 19:57 ` anlauf at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2024-03-15 19:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #7 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #6)
> I need to reevaluate it; there were other regressions if I remember
> correctly.
The changes are these:
PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/pr78061.f -O (test for excess errors)
PASS->FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors)
PASS->FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors)
PASS->FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors)
FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr79315.f90:18:18: Error:
Variable 'ims' cannot appear in the expression at (1)
FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:19: Error:
Variable 'ime' cannot appear in the expression at (1)
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:24: Error:
Variable 'in' cannot appear in the expression at (1)
FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:19: Error:
Variable 'ime' cannot appear in the expression at (1)
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:24: Error:
Variable 'in' cannot appear in the expression at (1)
FAIL: gfortran.dg/pr78061.f -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr78061.f:4:13: Error:
Variable 'ldc' cannot appear in the expression at (1)
FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr98016.f90:16:16: Error:
Variable 'n' cannot appear in the expression at (1)
FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/graphite/pr107865.f90:7:18:
Error: Variable 'n' cannot appear in the expression at (1)
FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr90681.f:5:19: Error:
Variable 'norbs' cannot appear in the expression at (1)
FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr97761.f90:11:36: Error:
Variable 'inout' cannot appear in the expression at (1)
FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors)
Excess errors:
/home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr99746.f90:6:21: Error:
Variable 'lda' cannot appear in the expression at (1)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (6 preceding siblings ...)
2024-03-15 19:37 ` mikael at gcc dot gnu.org
@ 2024-03-15 19:57 ` anlauf at gcc dot gnu.org
2024-03-15 20:25 ` mikael at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: anlauf at gcc dot gnu.org @ 2024-03-15 19:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #7)
> The changes are these:
>
> PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr78061.f -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors)
> PASS->FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors)
> PASS->FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors)
>
>
> FAIL: gfortran.dg/pr79315.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr79315.f90:18:18: Error:
> Variable 'ims' cannot appear in the expression at (1)
Confirmed by Intel.
> FAIL: gfortran.dg/pr101267.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:19: Error:
> Variable 'ime' cannot appear in the expression at (1)
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr101267.f90:5:24: Error:
> Variable 'in' cannot appear in the expression at (1)
Likewise.
> FAIL: gfortran.dg/pr112404.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:19: Error:
> Variable 'ime' cannot appear in the expression at (1)
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr112404.f90:5:24: Error:
> Variable 'in' cannot appear in the expression at (1)
Likewise.
> FAIL: gfortran.dg/pr78061.f -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr78061.f:4:13: Error:
> Variable 'ldc' cannot appear in the expression at (1)
Likewise.
> FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr98016.f90:16:16: Error:
> Variable 'n' cannot appear in the expression at (1)
This is wrong: the testcase looks valid to me.
> FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/graphite/pr107865.f90:7:18:
> Error: Variable 'n' cannot appear in the expression at (1)
Hmmm, not diagnosed by Intel.
> FAIL: gfortran.dg/vect/pr90681.f -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr90681.f:5:19: Error:
> Variable 'norbs' cannot appear in the expression at (1)
Detected by Intel.
> FAIL: gfortran.dg/vect/pr97761.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr97761.f90:11:36:
> Error: Variable 'inout' cannot appear in the expression at (1)
Funny:
type (quad_inductor), dimension(inout) :: ps
Intel's message is also confusing in that case.
> FAIL: gfortran.dg/vect/pr99746.f90 -O (test for excess errors)
> Excess errors:
> /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/vect/pr99746.f90:6:21:
> Error: Variable 'lda' cannot appear in the expression at (1)
Detected by Intel.
We obviously have several invalid testcases in the testsuite...
Probably just bad reductions.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (7 preceding siblings ...)
2024-03-15 19:57 ` anlauf at gcc dot gnu.org
@ 2024-03-15 20:25 ` mikael at gcc dot gnu.org
2024-03-22 12:07 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2024-03-15 20:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to anlauf from comment #8)
> (In reply to Mikael Morin from comment #7)
> > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> > Excess errors:
> > /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/pr98016.f90:16:16: Error:
> > Variable 'n' cannot appear in the expression at (1)
>
> This is wrong: the testcase looks valid to me.
>
Yes, to me as well.
So the patch needs more work. :-(
> > FAIL: gfortran.dg/graphite/pr107865.f90 -O (test for excess errors)
> > Excess errors:
> > /home/mik/gcc/gccx/src/gcc/testsuite/gfortran.dg/graphite/pr107865.f90:7:18:
> > Error: Variable 'n' cannot appear in the expression at (1)
>
> Hmmm, not diagnosed by Intel.
>
Strange that it is able to diagnose the other, but not this one.
>
> We obviously have several invalid testcases in the testsuite...
> Probably just bad reductions.
Yes, variables named inout especially look like dubious (but valid) reductions.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (8 preceding siblings ...)
2024-03-15 20:25 ` mikael at gcc dot gnu.org
@ 2024-03-22 12:07 ` cvs-commit at gcc dot gnu.org
2024-03-28 10:40 ` cvs-commit at gcc dot gnu.org
2024-04-02 13:15 ` mikael at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-22 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:
https://gcc.gnu.org/g:44c0398e65347def316700911a51ca8b4ec0a411
commit r14-9618-g44c0398e65347def316700911a51ca8b4ec0a411
Author: Mikael Morin <mikael@gcc.gnu.org>
Date: Fri Mar 22 12:32:34 2024 +0100
fortran: Fix specification expression error with dummy procedures
[PR111781]
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next was using a global variable previously improperly
restored to false (instead of restoring it to its initial value). The
latter happened on the testcase because one dummy argument was a procedure,
and checking that argument what causing a check of all its arguments with
the (improper) reset of the flag at the end, and that preceded the check of
the next argument.
For the first bug, the wrong result of is_parent_of_current_ns is fixed by
correcting the namespaces that function deals with, both the one passed
as argument and the current one tracked in the gfc_current_ns global. Two
new functions are introduced to select the right namespace.
Regarding the second bug, the problematic condition is removed, together
with the formal_arg_flag associated with it. Indeed, that condition was
(wrongly) allowing local variables to be used in array bounds of dummy
arguments.
PR fortran/111781
gcc/fortran/ChangeLog:
* symbol.cc (gfc_get_procedure_ns, gfc_get_spec_ns): New functions.
* gfortran.h (gfc_get_procedure_ns, gfc_get_spec ns): Declare them.
(gfc_is_formal_arg): Remove.
* expr.cc (check_restricted): Remove special case allowing local
variable in dummy argument bound expressions. Use gfc_get_spec_ns
to get the right namespace.
* resolve.cc (gfc_is_formal_arg, formal_arg_flag): Remove.
(gfc_resolve_formal_arglist): Set gfc_current_ns. Quit loop and
restore gfc_current_ns instead of early returning.
(resolve_symbol): Factor common array spec resolution code to...
(resolve_symbol_array_spec): ... this new function. Additionnally
set and restore gfc_current_ns.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_8.f90: New test.
* gfortran.dg/spec_expr_9.f90: New test.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (9 preceding siblings ...)
2024-03-22 12:07 ` cvs-commit at gcc dot gnu.org
@ 2024-03-28 10:40 ` cvs-commit at gcc dot gnu.org
2024-04-02 13:15 ` mikael at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-28 10:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #11 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Mikael Morin <mikael@gcc.gnu.org>:
https://gcc.gnu.org/g:7f233feafd657250340be3b3500d2697948ae3ed
commit r14-9703-g7f233feafd657250340be3b3500d2697948ae3ed
Author: Mikael Morin <mikael@gcc.gnu.org>
Date: Wed Mar 27 16:30:42 2024 +0100
fortran: Fix specification expression check in submodules [PR114475]
The patch fixing PR111781 made the check of specification expressions more
restrictive, disallowing local variables in specification expressions of
dummy arguments. PR114475 showed an example where that change regressed,
disallowing in submodules expressions that had been allowed in the parent
module. In submodules indeed, the hierarchy of namespaces inherited from
the parent module is not reproduced so the host-association of symbols
can't be recognized by checking the nesting of namespaces.
This change fixes the problem by allowing in specification expressions
all the symbols in a submodule that are inherited from the parent module.
PR fortran/111781
PR fortran/114475
gcc/fortran/ChangeLog:
* expr.cc (check_restricted): In submodules, allow variables host-
associated from the parent module.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_10.f90: New test.
Co-authored-by: Harald Anlauf <anlauf@gmx.de>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
2023-10-12 9:06 [Bug fortran/111781] New: Compiler error on valid code rasmus.vikhamar-sandberg at uit dot no
` (10 preceding siblings ...)
2024-03-28 10:40 ` cvs-commit at gcc dot gnu.org
@ 2024-04-02 13:15 ` mikael at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu.org @ 2024-04-02 13:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for gfortran 14.1.
Closing.
^ permalink raw reply [flat|nested] 13+ messages in thread