This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 17 Aug 2012 18:50:53 +0000
- Subject: [Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
- Auto-submitted: auto-generated
- References: <bug-54301-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-08-17 18:50:53 UTC ---
F2008, 16.5.2.5:
"The association status of a pointer becomes undefined when
...
"(5) completion of execution of an instance of a subprogram causes the
pointer's target to become undefined (item (3) of 16.6.6),
"(6) completion of execution of a BLOCK construct causes the pointer's target
to become undefined (item (22) of 16.6.6),"
F2008, 16.6.6:
"(3) When execution of an instance of a subprogram completes,
(a) its unsaved local variables become undefined,
(b) unsaved variables in a named common block that appears in the
subprogram become undefined if they have been dened or redefined,
unless
another active scoping unit is referencing the common block, and
(c) a variable of type C PTR whose value is the C address of an unsaved
local variable of the subprogram becomes undefined."
...
"(22) When a BLOCK construct completes execution, its unsaved local variables
become undefined, and a variable of type C PTR whose value is the C address of
an unsaved local variable of the BLOCK construct becomes undefined."
Given the potential badness, I still think one should warn for (a) to (d).
Though, one probably should think of not warning if the target has the SAVE
attribute.
The other question is whether the warning should be enabled by -Wall or not. (I
would enable it with -Wall.)