[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #8 from Tobias Burnus 2012-08-20 19:49:53 UTC --- Author: burnus Date: Mon Aug 20 19:49:46 2012 New Revision: 190542 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190542 Log: 2012-08-20 Tobias Burnus PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when a pointer, which is a function result, might outlive its target. 2012-08-20 Tobias Burnus PR fortran/54301 * gfortran.dg/warn_target_lifetime_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Tobias Burnus 2012-08-20 05:52:31 UTC --- FIXED on the 4.8 trunk.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #6 from Tobias Burnus 2012-08-20 05:47:55 UTC --- Author: burnus Date: Mon Aug 20 05:47:46 2012 New Revision: 190522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190522 Log: 2012-08-20 Tobias Burnus PR fortran/54301 * expr.c (gfc_check_pointer_assign): Warn when the pointer might outlive its target. * gfortran.h (struct gfc_option_t): Add warn_target_lifetime. * options.c (gfc_init_options, set_wall, gfc_handle_option): handle it. * invoke.texi (-Wtarget-lifetime): Document it. (-Wall): Implied it. * lang.opt (-Wtarget-lifetime): New flag. 2012-08-20 Tobias Burnus PR fortran/54301 * gfortran.dg/warn_target_lifetime_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/warn_target_lifetime_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #5 from Tobias Burnus 2012-08-19 17:27:14 UTC --- (In reply to comment #4) > (In reply to comment #3) > If the target has the SAVE attribute or is allocatable, we shouldn't warn. Why shouldn't one warn for ALLOCATABLE? See first example in comment 2 for a code for which I would like to warn! Submitted patch: http://gcc.gnu.org/ml/fortran/2012-08/msg00094.html
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-19 Ever Confirmed|0 |1 --- Comment #4 from Thomas Koenig 2012-08-19 17:10:28 UTC --- (In reply to comment #3) > 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. If the target has the SAVE attribute or is allocatable, we shouldn't warn. > The other question is whether the warning should be enabled by -Wall or not. > (I > would enable it with -Wall.) At least. Because the behavior is very likely to lead to difficult to detect bugs, I would even consider warning by default.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 --- Comment #3 from Tobias Burnus 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 de ned 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.)
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2012-08-17 18:29:28 UTC --- (In reply to comment #1) > a) I don't see what prevents a function from returning a short lived > pointer Nothing - except that it is bad if the pointer target is gone at the instance of returning. Example: function f () result (ptr) integer, pointer :: ptr(:) integer, allocatable, target :: a(:) allocate(a(5)) ptr => a a = [1,2,3,4,5] end function (There is some closed as INVALID PR which used such a code; the code above is perfectly valid, one just may not dereference the returned function result.) Here, "ptr" is a perfectly valid pointer within "f", however, "f" returns as function result an "undefined" pointer. The program is perfectly valid, except, one may not access the returned function result – which is a bit pointless. Of course, the code works, if one reassociates "ptr" with some other target which lives longer; still it is a bad programming style and asks for trouble. That's the idea of the warning: Warn for questionable code. Similarly for (c): subroutine foo() integer, pointer :: ptr(:) ... call bar () ... contains subroutine bar () integer, target :: tgt(5) ptr => tgt end subroutine bar ... end subroutine foo That's perfectly valid, but a dangerous way of programming. It becomes more reliably if "tgt" has the SAVE attribute – but I believe that it is still invalid to access "tgt" outside of "bar". Note: I only talked about a local nonpointer target on the RHS for which one should warn. For instance: function foo(tgt) integer, target :: tgt integer, pointer :: foo foo => tgt end function is perfectly valid and sensible if the actual argument is either a pointer or a target. (It is also valid if the nonpointer actual argument has no target attribute, but then the function result is an undefined pointer.) Hence, we cannot warn for this case.
[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54301 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin 2012-08-17 16:58:54 UTC --- As always, that's a nice to have feature, but without a thorough control flow/value range/whatever analysis, it would either give a warning in trivial cases only or have many false positives. A warning for b) makes sense to me; for the others: a) I don't see what prevents a function from returning a short lived pointer c) d) The pointer is globally accessible, so I'm not so sure how it could be nullified or re-associated.
