[Bug fortran/30973] New: undetected name conflict: variables may be named like modules

[Bug fortran/30973] New: undetected name conflict: variables may be named like modules

[dfranke at gcc dot gnu dot org]

$> cat foo.f90
MODULE foo
END MODULE

PROGRAM test_foo
  USE foo, ONLY:
  INTEGER :: foo
  foo = 1
END PROGRAM

$> gfortran-svn -g -Wall foo.f90 && echo ok
ok

$> gfortran-svn -v
gcc version 4.3.0 20070220 (experimental)

If ", ONLY:" is removed in the USE, gfortran gives:
foo.f90:6.16:

  INTEGER :: foo
               1
Error: Symbol 'foo' at (1) cannot have a type


-- 
           Summary: undetected name conflict: variables may be named like
                    modules
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dfranke at gcc dot gnu dot org


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-02-26 16:47 -------
I checked: "  USE foo, ONLY:" is syntactically correct.

The problem is that "only_flag = 1;" and no symbol is in the only-list.

I think one needs to modify module.c's "read_module", but I fail quickly to see
were the symbol "foo" is not added/deleted from the symbol tree.

All other compilers I tried (g95,ifort,nagf95,sunf95) gave an error.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |accepts-invalid
   Last reconfirmed|0000-00-00 00:00:00         |2007-02-26 16:47:56
               date|                            |


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[dfranke at gcc dot gnu dot org]

------- Comment #2 from dfranke at gcc dot gnu dot org  2007-02-26 16:54 -------
Tobias, the same happens if the MODULE foo contains anything and the ONLY part
actually lists something. I omitted this to keep the testcase short.

Same problem here:

$> cat foo2.f90
MODULE foo
INTEGER :: x
END MODULE

PROGRAM test_foo
  USE foo, ONLY: x
  INTEGER :: foo
  foo = 1
END PROGRAM


-- 


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2007-02-26 21:36 -------
> Tobias, the same happens if the MODULE foo contains anything and the ONLY part
> actually lists something. I omitted this to keep the testcase short.

Good news. That means that indicates that my patch does the right thing and is
not too kludgy.

In read_module, p = find_use_name_n (name, &j);  is used to find renamed
symbols. If a symbol is not in in the only list, p == NULL. Since the module
name is never in the only list, we have "p = NULL".

Index: module.c
===================================================================
--- module.c    (Revision 122328)
+++ module.c
@@ -3438,6 +3438,9 @@
          /* Get the jth local name for this symbol.  */
          p = find_use_name_n (name, &j);

+         if (p == NULL && strcmp (name, module_name) == 0)
+           p = name;
+
          /* Skip symtree nodes not in an ONLY clause, unless there
             is an existing symtree loaded from another USE
             statement.  */


Another related bug: "use foo, only: foo" gives no error.
------------- test case -------
MODULE foo
  integer :: i
END MODULE

PROGRAM test_foo
  use foo, only: foo  ! { dg-error "been used as an external module name" }
  USE foo, ONLY: i => foo! { dg-error "been used as an external module name" }
  USE foo, ONLY: foo => i! { dg-error "been used as an external module name" }
END PROGRAM
--------------------------

Possible patch below; note: Even with the patch
  use bar, only foo => j
  use foo
is possible. But as soon as one accesses foo, e.g. "foo = 5", an error is
given.
This is in the line with other compilers.

Index: module.c
===================================================================
*** module.c    (revision 122328)
--- module.c    (working copy)
*************** gfc_match_use (void)
*** 619,624 ****
--- 619,632 ----
                goto cleanup;
            }

+         if (strcmp (new->use_name, module_name) == 0
+             || strcmp (new->local_name, module_name) == 0)
+           {
+             gfc_error ("The name '%s' at %C has already been used as "
+                        "an external module name.", module_name);
+             goto cleanup;
+           }
+
          break;

        case INTERFACE_USER_OP:


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2007-02-27 17:44 -------
Patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |burnus at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2007-02-26 16:47:56         |2007-02-27 17:44:15
               date|                            |


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[patchapp at dberlin dot org]

------- Comment #5 from patchapp at dberlin dot org  2007-02-27 17:46 -------
Subject: Bug number PR30973

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg02134.html


-- 


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

[Bug fortran/30973] undetected name conflict: variables may be named like modules

[burnus at gcc dot gnu dot org]

------- Comment #6 from burnus at gcc dot gnu dot org  2007-03-08 12:31 -------
Subject: Bug 30973

Author: burnus
Date: Thu Mar  8 12:30:58 2007
New Revision: 122696

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122696
Log:
2007-03-08  Tobias Burnus  <burnus@net-b.de>

        PR fortran/30973
        * module.c (read_module): Always import module name as symbol.
        (gfc_match_use): Disallow module name in the only clause of
        a use statement.

2007-03-08  Tobias Burnus  <burnus@net-b.de>

        PR fortran/30973
        * gfortran.dg/use_4.f90: New test.
        * gfortran.dg/used_dummy_types_7.f90: Correct ambiguous symbol.


Added:
    trunk/gcc/testsuite/gfortran.dg/use_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/module.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/used_dummy_types_7.f90


-- 


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

[Bug fortran/30973] [4.1, 4.2 only] undetected name conflict: variables may be named like modules

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-03-31 23:05 -------
No regression, no serious bug -> won't fix in 4.2 -> close.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|                            |4.2.0 4.1.2
      Known to work|                            |4.3.0
         Resolution|                            |FIXED


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