[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #16 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7. Thanks for the report. Closing.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #15 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 18:09:19 2018 New Revision: 267354 URL: https://gcc.gnu.org/viewcvs?rev=267354&root=gcc&view=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_2.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/module.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #14 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 17:53:00 2018 New Revision: 267353 URL: https://gcc.gnu.org/viewcvs?rev=267353&root=gcc&view=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_2.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/module.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #13 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 22 17:26:12 2018 New Revision: 267351 URL: https://gcc.gnu.org/viewcvs?rev=267351&root=gcc&view=rev Log: 2018-12-21 Steven G. Kargl PR fortran/88169 * module.c (mio_namelist): Remove an error condition/message that is contrary to the Fortran standard. 2018-12-21 Steven G. Kargl PR fortran/88169 * gfortran.dg/pr88169_1.f90: new test. * gfortran.dg/pr88169_2.f90: Ditto. * gfortran.dg/pr88169_3.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pr88169_1.f90 trunk/gcc/testsuite/gfortran.dg/pr88169_2.f90 trunk/gcc/testsuite/gfortran.dg/pr88169_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 kargl at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org --- Comment #12 from kargl at gcc dot gnu.org --- A patch has been submitted. https://gcc.gnu.org/ml/fortran/2018-12/msg00139.html
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #11 from kargl at gcc dot gnu.org --- (In reply to Neil Carlson from comment #9) > Actually I think the usage in comment 8 is an intentional extension. There > is a test in the dg test suite that does exactly this if I remember > correctly. The test was namelist_use.f90. I was told that gfortran will give > an error if compiled with something like -std=f95. See > https://github.com/nncarlson/gfortran.dg/issues/3 Yep. Just found the code in gfc_match_namelist.c that indeed accepts the code (-std=gnu is the default standard) in comment 8. A quick test with -std=f2003 gives gfcx -o z -std=f2003 a.f90 && ./z a.f90:11:17: 11 |namelist /foo/ i | 1 Error: GNU Extension: Namelist group name 'foo' at (1) already is USE associated and cannot be respecified. So, AFAICT, the patch in comment 7 fixes the issue.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #10 from Neil Carlson --- Also a remark about the output of comment 7 just in case someone is thinking it ought to say "&BAR" (like I was expecting/hoping when I started experimenting with the original example). 13.11.3.1 says 1 Input for a namelist input statement consists of (2) the character & followed immediately by the namelist-group-name as specified in the NAMELIST statement, and 13.11.4.1 says 1 The form of the output produced by intrinsic namelist output shall be suitable for input, [...] So "&FOO" is correct (and what Intel and NAG both do as well).
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #9 from Neil Carlson --- Actually I think the usage in comment 8 is an intentional extension. There is a test in the dg test suite that does exactly this if I remember correctly. The test was namelist_use.f90. I was told that gfortran will give an error if compiled with something like -std=f95. See https://github.com/nncarlson/gfortran.dg/issues/3
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #8 from kargl at gcc dot gnu.org --- As expected, the following invalid code via C8102 in F2018 compiles and executes module foo_nml implicit none real :: x namelist /foo/ x end module program main use foo_nml implicit none integer i namelist /foo/ i ! Invalid via F18:C8102 i = 42 x = 42 write(*,nml=foo) end program % gfcx -o z a.f90 && ./z &FOO X= 42.000, I=42 , /
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> (In reply to Neil Carlson from comment #5)
> > Stated a bit more clearly, the question is, whether in
> >
> > The namelist-group-name shall not be a name accessed by use association.
> >
> > the name (in the scope of the declaration) is accessed by use association,
> > or the name is accessed in another scope by use association.
>
> I've asked on the J3 mailing list for clairfication. 14.2.2
> say ", identifiers, and namelist groups in a module." Namelist
> groups is a bit vague, here. Does this mean namelist group names
> or namelist group objects. My current thinking is C8102 is to
> prevent
>
> module foo
>
> namelist /bar/ ...
> end module
>
> program bah
> use foo
> real x
> namelist /bar/x
> ...
> end program bah
>
> where program bar is trying to extend the namelist-group-object-list.
So, I've asked on J3 mailing list (and after a rather condescending reply),
it is definitely a bug in gfortran. Constraint c8102 from F2018 applies
to a namelist-group-name in the scoping unit that USEs the module. Thus,
in the above code, using 'bar' in program 'bah' as a namelist-group-name is
invalid as 'bar' has been made available via USE association.
This patch allows a slightly modify version of Neil's code to compile and
run (x in main is implicitly defined local variable, which is different
than the x in module foo).
Index: module.c
===
--- module.c(revision 266386)
+++ module.c(working copy)
@@ -3711,7 +3711,6 @@ static void
mio_namelist (gfc_symbol *sym)
{
gfc_namelist *n, *m;
- const char *check_name;
mio_lparen ();
@@ -3722,17 +3721,6 @@ mio_namelist (gfc_symbol *sym)
}
else
{
- /* This departure from the standard is flagged as an error.
-It does, in fact, work correctly. TODO: Allow it
-conditionally? */
- if (sym->attr.flavor == FL_NAMELIST)
- {
- check_name = find_use_name (sym->name, false);
- if (check_name && strcmp (check_name, sym->name) != 0)
- gfc_error ("Namelist %s cannot be renamed by USE "
- "association to %s", sym->name, check_name);
- }
-
m = NULL;
while (peek_atom () != ATOM_RPAREN)
{
% cat a.f90
module foo_nml
implicit none
real :: x
namelist /foo/ x
end module
program main
use foo_nml, only: bar => foo, x
implicit none
x = 42
write(*,nml=bar)
end program
% gfcx -o z a.f90 && ./z
&FOO
X= 42.000,
/
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Neil Carlson from comment #5) > Stated a bit more clearly, the question is, whether in > > The namelist-group-name shall not be a name accessed by use association. > > the name (in the scope of the declaration) is accessed by use association, > or the name is accessed in another scope by use association. I've asked on the J3 mailing list for clairfication. 14.2.2 say ", identifiers, and namelist groups in a module." Namelist groups is a bit vague, here. Does this mean namelist group names or namelist group objects. My current thinking is C8102 is to prevent module foo namelist /bar/ ... end module program bah use foo real x namelist /bar/x ... end program bah where program bar is trying to extend the namelist-group-object-list.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #5 from Neil Carlson --- Stated a bit more clearly, the question is, whether in The namelist-group-name shall not be a name accessed by use association. the name (in the scope of the declaration) is accessed by use association, or the name is accessed in another scope by use association.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #4 from Neil Carlson --- I think the intent of C8102 (R868) The namelist-group-name shall not be a name accessed by use association. is to say you can't define a namelist with a name accessed by use association. That seems to fit best with the Note that references it. However, I suppose it could be taken to mean that a namelist-group cannot be accessed via use association. But that flies in the face of 14.2.2 The USE statement provides the means by which a scoping unit accesses named data objects, derived types, procedures, abstract interfaces, generic identifiers, and namelist groups in a module. which clearly indicates namelist groups can be accessed by use association.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > Fortran 95 contains > > NOTE 11.8 > > The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name > from appearing as a common-block-object in a COMMON statement, an > equivalence- > object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST > statement, respectively. There is no prohibition against the local-name > appearing as a common-block-name or a namelist-object. > > This appears to prohibit > > program main > use foo_nml, only: bar => foo > namelist /bah/ bar ! <-- Invalid Upon further reflection, the Note seems to prohibit namelist /bar/x ! Local name is namelist-group-name, adding x to group. > x = 42 > write(*,nml=bar) But, the constraints make foo inaccess from the get-go.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Fortran 95 contains
>
> NOTE 11.8
>
> The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name
> from appearing as a common-block-object in a COMMON statement, an
> equivalence-
> object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST
> statement, respectively. There is no prohibition against the local-name
> appearing as a common-block-name or a namelist-object.
>
> This appears to prohibit
>
> program main
> use foo_nml, only: bar => foo
> namelist /bah/ bar ! <-- Invalid
> x = 42
> write(*,nml=bar)
> end program
>
> So, I do believe you are correct. Your code is conforming.
Hmmm, upon further reading of F95 and checking the code, one finds
/* This departure from the standard is flagged as an error.
It does, in fact, work correctly. TODO: Allow it
conditionally? */
if (sym->attr.flavor == FL_NAMELIST)
{
check_name = find_use_name (sym->name, false);
if (check_name && strcmp (check_name, sym->name) != 0)
gfc_error ("Namelist %s cannot be renamed by USE "
"association to %s", sym->name, check_name);
}
F95 contains
Constraint: The namelist-group-name shall not be a name made
accessible by use association.
The code is definitely non-conforming by this constraint. Note 11.8
is a red herring. It deals with a namelist-group-objects not a
namelist-group-name.
Now, looking at F2018, one has
C8102 (R868) The namelist-group-name shall not be a name accessed by use
association.
Your code is invalid. What does ifort and NAG report if you request
strict adherence to the Fortran standard.
I suppose that one could argue that the renaming of the namelist
group name 'foo' to 'bar' prevents 'foo' from being accessible,
but 'foo' had to be accessible to permit the renaming to occur.
[Bug fortran/88169] Rejects USE rename of namelist group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-23 Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Fortran 95 contains NOTE 11.8 The constraints in sections 5.5.1, 5.5.2, and 5.4 prohibit the local-name from appearing as a common-block-object in a COMMON statement, an equivalence- object in an EQUIVALENCE statement, or a namelist-group-name in a NAMELIST statement, respectively. There is no prohibition against the local-name appearing as a common-block-name or a namelist-object. This appears to prohibit program main use foo_nml, only: bar => foo namelist /bah/ bar ! <-- Invalid x = 42 write(*,nml=bar) end program So, I do believe you are correct. Your code is conforming.
