[Bug fortran/54301] New: Add optional warning if pointer assigning a local variable to a nonlocal pointer

[Bug fortran/54301] New: Add optional warning if pointer assigning a local variable to a nonlocal pointer

[burnus at gcc dot gnu.org]

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

             Bug #: 54301
           Summary: Add optional warning if pointer assigning a local
                    variable to a nonlocal pointer
    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 pointer assignment of
a pointer whose lifetime is known to be longer than the lifetime of the
target."


I think can be diagnosed with some -W... warning in the following case: The LHS
of the pointer assignment is

a) A function result variable
b) A dummy argument
c) A host- or use-associated variable
d) A common-block variable

and the RHS is a local variable (local to the procedure or local to a BLOCK) -
but, crucially, RHS variable is not a pointer.

[At least the case (a) I have already seen in some bugreport.]

[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> 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.

[Bug fortran/54301] Add optional warning if pointer assigning a local variable to a nonlocal pointer

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[burnus at gcc dot gnu.org]

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 de\fned 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, \x0fits unsaved local variables
become undefined, and \x0fa 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

[tkoenig at gcc dot gnu.org]

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

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 #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 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

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 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  <burnus@net-b.de>

        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  <burnus@net-b.de>

        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

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 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

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 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  <burnus@net-b.de>

        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  <burnus@net-b.de>

        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