public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/54302] New: Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one
@ 2012-08-17 16:41 burnus at gcc dot gnu.org
2012-08-19 17:01 ` [Bug fortran/54302] " tkoenig at gcc dot gnu.org
0 siblings, 1 reply; 2+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-08-17 16:41 UTC (permalink / raw)
To: gcc-bugs
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 e\vorts 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.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug fortran/54302] Add optional warning when declaring a identifier in a nested scope, which matches on otherwise available one
2012-08-17 16:41 [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
@ 2012-08-19 17:01 ` tkoenig at gcc dot gnu.org
0 siblings, 0 replies; 2+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-08-19 17:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54302
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-08-19
Ever Confirmed|0 |1
--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-08-19 17:01:37 UTC ---
In other words, implement -Wshadow in gfortran. Makes sense.
Confirmed.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-08-19 17:01 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-17 16:41 [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
2012-08-19 17:01 ` [Bug fortran/54302] " tkoenig at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).