[Bug fortran/30146] New: Redefining do-variable in excecution cycle

[burnus at gcc dot gnu dot org]

I think the following program is wrong as one uses a passes a do variable to an
intent(inout) (or intent(out) subroutine).

However, neither g95, sunf95 nor NAG f95 complain at compile time. Using nagf95
-C=all I get at run time:
Actual argument for INTENT(INOUT) dummy argument I is an expression
(I get this whether or not I set "i" in the suboutine.)

Am I missing something?

>From the standard ("8.1.6.4.2 The execution cycle"):
"Except for the incrementation of the DO variable that occurs in step (3), the
DO variable shall neither be redefined nor become undefined while the DO
construct is active."

Once could implement this by setting a flag to the do-variable on for the
excecution cycle, and removing the flag on exit. Then one could check the
result in resolve.c. Or look at gfc_check_do_variable in parse.c.


I don't know whether the output should be a warning or an error, but the
following program runs "2 4 6" with nagf95, ifort and sunf95, "2 4 6 8 10" with
g95 and "2 4 ... 142434 ..." with gfortran.


program main
  implicit none
  integer :: i
  do i  = 1,5,1
    call mysub(i)
    print *, i
  end do
contains
  subroutine mysub(i)
   integer,intent(inout) :: i
   i = i + 1
  end subroutine mysub
end program main


-- 
           Summary: Redefining do-variable in excecution cycle
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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