[Bug fortran/51589] New: Modification of loop index variable by intent(out) or intent(inout) procedures

[Bug fortran/51589] New: Modification of loop index variable by intent(out) or intent(inout) procedures

[w6ws at earthlink dot net]

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

             Bug #: 51589
           Summary: Modification of loop index variable by intent(out) or
                    intent(inout) procedures
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: w6ws@earthlink.net


In the following snippet of code, the loop index variable is passed to
procedures via either intent(out) or intent(inout) dummy arguments.  In the
first of these cases, intent(out), gfortran should give a "Variable 'i' at (1)
cannot be redefined inside loop" error but does not.  Even with --pedantic.  It
is arguable whether the second should give the same error, or just a warning.

Note that Intel 12.1 gives warnings for both usages.  The resulting code only
runs for one iteration.  With gfortran, it ends up in an infinite loop.

wws@w6ws-4:~/fortran/intents$ cat intents.f90
program intents
  implicit none

  integer :: i

  do, i=1,10
    call sub1 (i)
    print *, i
    call sub2 (i)
    print *, i
  end do

contains

  subroutine sub1 (idx)
    integer, intent(inout) :: idx

    idx = 42

  end subroutine

  subroutine sub2 (idx)
    integer, intent(out) :: idx

    idx = 11

  end subroutine

end program
wws@w6ws-4:~/fortran/intents$ gfortran --pedantic intents.f90
wws@w6ws-4:~/fortran/intents$ gfortran --version
GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

wws@w6ws-4:~/fortran/intents$

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[w6ws at earthlink dot net]

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

--- Comment #1 from Walter Spector <w6ws at earthlink dot net> 2011-12-16 21:32:55 UTC ---
Sorry - my description is backwards from the test case.  The first is
intent(inout), and should probably give a warning.  The second is intent(out)
and should give an error.

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[w6ws at earthlink dot net]

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

--- Comment #2 from Walter Spector <w6ws at earthlink dot net> 2011-12-16 22:37:44 UTC ---
No error messages from Absoft (v9), g95, or PGI (v11.10).  All print the
revised version of i, but only perform 10 iterations.

NAG (5.2 edit 721) considers the intent(out) to be an error.  No warning for
the intent(inout).

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> 2011-12-16 22:55:06 UTC ---
(In reply to comment #2)
> No error messages from Absoft (v9), g95, or PGI (v11.10).  All print the
> revised version of i, but only perform 10 iterations.
> 
> NAG (5.2 edit 721) considers the intent(out) to be an error.  No warning for
> the intent(inout).

Current trunk (4.7) and also 4.6.0 both give an error at runtime
when compiling with "-fcheck=all" :

          42
          11
At line 6 of file pr51589.f90
Fortran runtime error: Loop variable has been modified

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-17 09:15:44 UTC ---
As Harald already mentioned, GCC 4.5 (or later) support -fcheck=do to find
modifications to the DO variables at run time.

 * * *

Currently, the do-variable check is done only at parse time via
"gfc_check_do_variable"; it uses gfc_state_stack to save the information about
the do variables [gfc_state_stack(->previous...)->do_variable], but this
information is lost at resolution time - on the other hand, the INTENT_OUT is
often not known at parse time.

One possibility is to generate a stack of do variables and save a link to it,
e.g., in gfc_code. Something like:

struct gfc_do_var_list {
 struct gfc_do_var_list *previous;
 gfc_symbol *do_var;
}
struct gfc_do_var_list *gfc_current_do_var = NULL;

The gfc_current_do_var is saved in gfc_code; every time a new DO loop is
started, a new item is generated and assigned to gfc_current_do_var - after the
DO loop, one sets gfc_current_do_var = gfc_current_do_var->previous. That will
generate a tree-like structure, which looks like a stack. (One probably needs
another linked list to store the gfc_current_do_var - as chain not as tree -
for freeing the list.)

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[w6ws at earthlink dot net]

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

--- Comment #5 from Walter Spector <w6ws at earthlink dot net> 2011-12-17 19:04:12 UTC ---
It seems like intent information should be available when the procedures are
USE associated, as opposed to the internal procedures.  However gfortran does
not diagnose that case either.  Here is an expanded test case:

module intent_mod
  implicit none

contains

  subroutine submod1 (idx)
    integer, intent(inout) :: idx

    idx = 42

  end subroutine

  subroutine submod2 (idx)
    integer, intent(out) :: idx

    idx = 11

  end subroutine

end module

program intents
  use intent_mod
  implicit none

  integer :: i

  do, i=1,10
    call sub1 (i)
    print *, i
    call sub2 (i)
    print *, i
    call submod1 (i)
    print *, i
    call submod2 (i)
    print *, i
  end do

contains

  subroutine sub1 (idx)
    integer, intent(inout) :: idx

    idx = 42

  end subroutine

  subroutine sub2 (idx)
    integer, intent(out) :: idx

    idx = 11

  end subroutine

end program

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-18
                 CC|                            |tkoenig at gcc dot gnu.org
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-12-18 10:20:44 UTC ---
Confirmed, would be nice to have.

[Bug fortran/51589] Modification of loop index variable by intent(out) or intent(inout) procedures

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

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

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-12-01 10:37:43 UTC ---
Fixed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193793 
which sailed under the flag of PR 30146.