[Bug fortran/50556] New: cannot save namelist group name

[Bug fortran/50556] New: cannot save namelist group name

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

             Bug #: 50556
           Summary: cannot save namelist group name
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: zeccav@gmail.com


! cannot save namelist group name 
      namelist /i/ ii
      save i
      end

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-10-28 05:21:48 UTC ---
The patch at the end of this note will issue an error for the test code.
I, however, cannot find any text concerning namelist in the F2008 standard
that prohibits the code.  One might argue that a "SAVE namelist-group-name"
should mean that all namelist-group-objects associate this 
namelist-group-name gets the SAVE attribute.  If this interpretation
was correct, then one would expect that text in the Standard would 
make this clear.


laptop:kargl[231] gfc4x -c foo.f90
foo.f90:2.12:

      save i
            1
Error: Namelist group name at (1) cannot appear in a SAVE statement


Index: decl.c
===================================================================
--- decl.c      (revision 180567)
+++ decl.c      (working copy)
@@ -6831,6 +6831,14 @@ gfc_match_save (void)
          if (gfc_add_save (&sym->attr, SAVE_EXPLICIT, sym->name,
                            &gfc_current_locus) == FAILURE)
            return MATCH_ERROR;
+
+         if (sym->attr.flavor == FL_NAMELIST)
+           {
+             gfc_error ("Namelist group name at %C cannot appear in a "
+                        "SAVE statement");
+             return MATCH_ERROR;
+           }
+
          goto next_item;

        case MATCH_NO:
l

[Bug fortran/50556] cannot save namelist group name

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-29 14:47:52 UTC ---
> One might argue that a "SAVE namelist-group-name" should mean that all
> namelist-group-objects associate this namelist-group-name gets the SAVE
> attribute.  If this interpretation was correct, then one would expect that
> text in the Standard would make this clear.

Well, I see in the standard:

"C553   An entity with the SAVE attribute shall be a common block, variable, or
procedure pointer."

And I would argue that a namelist-group-name is neither a common block, a
variable nor a procedure pointer.

Thus, I believe that the code in comment 0 is invalid.

Regarding the patch in comment 1: I think it will not work if one swaps the
order of NAMELIST and SAVE.

Untested patch:

--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -441,6 +441,7 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
          case FL_LABEL:
          case FL_DERIVED:
          case FL_PARAMETER:
+         case FL_NAMELIST:
             a1 = gfc_code2string (flavors, attr->flavor);
             a2 = save;
            goto conflict;
@@ -449,7 +450,6 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
            /* Conflicts between SAVE and PROCEDURE will be checked at
               resolution stage, see "resolve_fl_procedure".  */
          case FL_VARIABLE:
-         case FL_NAMELIST:
          default:
            break;
        }

[Bug fortran/50556] cannot save namelist group name

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-29 15:17:19 UTC ---
(In reply to comment #2)
> Well, I see in the standard:
[Fortran 2008]
> "C553   An entity with the SAVE attribute shall be a common block, variable, or
> procedure pointer."
> 
> And I would argue that a namelist-group-name is neither a common block, a
> variable nor a procedure pointer.

See also
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/07da50d1aaf3870d
- there, the argument seems to be the same, though the reference is R544.

 * * *

>From c.l.f:
> Unfortunately, I also found that gfortran has interpreted something like
>      namelist /cmd/ i, j, k
>      save cmd
> to mean
>     namelist /cmd/ i, j, k
>     save i, j, k

The question is whether one needs to allow it.

g95 and gfortran allow the code
ifort, NAG f95, g77 (!), pathf95/openf95/crayftn reject it.
PGI warns "Symbol, i, appears illegally in a SAVE statement"

Thus, I wouldn't mind breaking the backward compatibility.

[Bug fortran/50556] cannot save namelist group name

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-10-29 16:49:38 UTC ---
On Sat, Oct 29, 2011 at 02:47:52PM +0000, burnus at gcc dot gnu.org wrote:
> > One might argue that a "SAVE namelist-group-name" should mean that all
> > namelist-group-objects associate this namelist-group-name gets the SAVE
> > attribute.  If this interpretation was correct, then one would expect that
> > text in the Standard would make this clear.
> 
> Well, I see in the standard:
> 
> "C553   An entity with the SAVE attribute shall be a common block,
>         variable, or procedure pointer."
> 
> And I would argue that a namelist-group-name is neither a common block, a
> variable nor a procedure pointer.

Well, spotted.  I was scanning the standards for 'namelist-group',
so missed C553.

> Thus, I believe that the code in comment 0 is invalid.
> 
> Regarding the patch in comment 1: I think it will not work if one swaps the
> order of NAMELIST and SAVE.

Confirmed.

> Untested patch:
> 
> --- a/gcc/fortran/symbol.c
> +++ b/gcc/fortran/symbol.c
> @@ -441,6 +441,7 @@ check_conflict (symbol_attribute *attr, const char *name,
> locus *where)
>           case FL_LABEL:
>           case FL_DERIVED:
>           case FL_PARAMETER:
> +         case FL_NAMELIST:
>              a1 = gfc_code2string (flavors, attr->flavor);
>              a2 = save;
>             goto conflict;
> @@ -449,7 +450,6 @@ check_conflict (symbol_attribute *attr, const char *name,
> locus *where)
>             /* Conflicts between SAVE and PROCEDURE will be checked at
>                resolution stage, see "resolve_fl_procedure".  */
>           case FL_VARIABLE:
> -         case FL_NAMELIST:
>           default:
>             break;
>         }

I tested the above.  It catches both examples of invalid code
(namelist before save and save before namelist).  However, the
error message is a bit strange:

ab.f90:2.12:

      save i
            1
Error: NAMELIST attribute conflicts with SAVE attribute in 'i' at (1)

NAMELIST is not an attribute.  With the attached patch, I get

laptop:kargl[239] gfc4x -c namelist_74.f90
namelist_74.f90:5.15:

   namelist /i/ ii    ! { dg-error "cannot have a SAVE attribute" }
               1
Error: Namelist group name at (1) cannot have a SAVE attribute
namelist_74.f90:9.9:

   save i             ! { dg-error "cannot have a SAVE attribute" }
         1
Error: Namelist group name at (1) cannot have a SAVE attribute

[Bug fortran/50556] cannot save namelist group name

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-10-29 16:51:10 UTC ---
On Sat, Oct 29, 2011 at 03:17:19PM +0000, burnus at gcc dot gnu.org wrote:
> >From c.l.f:
> > Unfortunately, I also found that gfortran has interpreted something like
> >      namelist /cmd/ i, j, k
> >      save cmd
> > to mean
> >     namelist /cmd/ i, j, k
> >     save i, j, k
> 
> The question is whether one needs to allow it.
> 
> g95 and gfortran allow the code
> ifort, NAG f95, g77 (!), pathf95/openf95/crayftn reject it.
> PGI warns "Symbol, i, appears illegally in a SAVE statement"
> 
> Thus, I wouldn't mind breaking the backward compatibility.

I vote that gfortran should follow the majority and simply
issue an error.

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

--- Comment #6 from kargl at gcc dot gnu.org 2012-01-21 17:32:15 UTC ---
Author: kargl
Date: Sat Jan 21 17:32:12 2012
New Revision: 183370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183370
Log:
2012-01-21  Tobias Burnus  <burnus@net-b.de>
        Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/50556
    * symbol.c (check_conflict): namelist-group-name cannot have the SAVE
    attribure.

2012-01-21  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/50556
    * gfortran.dg/namelist_74.f90: New test.
    * gfortran.dg/namelist_59.f90: Remove SAVE attribute.

Added:
    trunk/gcc/testsuite/gfortran.dg/namelist_74.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/namelist_59.f90

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

--- Comment #7 from kargl at gcc dot gnu.org 2012-01-21 17:37:40 UTC ---
Fixed on trunk.  Thanks for the bug reports.

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from kargl at gcc dot gnu.org 2012-01-23 18:48:44 UTC ---
Seems I forgot to close this one after committing the fix.
Close now.