[Bug fortran/54302] New: Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

             Bug #: 54302
           Summary: Add optional warning when declaring a identifier in a
                    nested scope, which matches on otherwise available one
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: tkoenig@gcc.gnu.org


Suggested by ISO/IEC Project 22.24772 "Guidance for Avoiding Vulnerabilities
through Language Selection and Use"  (see links at
http://gcc.gnu.org/wiki/GFortranStandards)

From the Fortran appendix (draft at
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1929.pdf)

At the end there is the suggestion:

"Fortran.58.1 Implications for Standardization"
"Future standardization eorts should consider:"
...
"Requiring that processors have the ability to detect and report the occurrence
within a submitted program unit of the reuse of a name within a nested scope."


This suggestion it about cases like host association:

  integer :: i
contains
  subroutine foo()
    integer :: i
  end subroutine
end

And in BLOCK:

subroutine bar()
  integer :: i
  block
    integer :: i
  end block
end subroutine bar



However, given that one cannot disable host association (contrary to USE
association and IMPORT, where one can selectively import certain variables),
one could consider also warn when accessing a host-associated variable. Often
one wants to access some host variables, but often one doesn't.

Best would be some standard support ("noimport" / "import :: list" / "import"),
which could then be enforced via "-fnoimport" similarly to "-fintent-none".
However, until that's in the standard, one could consider providing a warning.
(Or one waits for that one until something like (no)import has emerged for the
next revision of the standard.)

(Such a functionality has been requested several times - and it is also
mentioned in the same Fortran.58 section of the draft Fortran appendix to
TR24772.)


I think both warning are probably not suitable for -Wall, but they can be
helpful.