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

[dfranke at gcc dot gnu dot org]

------- Comment #5 from dfranke at gcc dot gnu dot org  2009-04-09 16:03 -------
(In reply to comment #4)
> This of cause fails if you change i. As the program is invalid and as I don't
> see any possibility to fix this in gfortran, I regard the problem of comment 3
> as INVALID/WONTFIX.

In the meantime we got -fwhole-file to check for interface mismatches. The
subroutine sub() in #3 does not specify INTENT for its dummy argument 'i', so
it's INOUT by default. Thus, if this code is compiled with -fwhole-file,
gfortran can/should raise an error?!

 * * *

I'm unsure how to implement this. The check for assignments to the
loop-variable, e.g.
  DO i = 1, ...
    i = <expr>
  END DO
is done during matching, using gfc_state_stack (see parse.c,
gfc_check_do_variable). This is by far too early for argument checking.

Generally, checks for INTENTs are done in interface.c(check_intents), called by
interface.c (gfc_procedure_use). This seems to be the place to add the check
for loop-variables. However, as it is valid to use the same variable as a
loop-variable and not, e.g.
  INTEGER :: i
  CALL set(i, 3)         ! valid
  DO i = ...
    CALL set(i, 3)       ! invalid
  END DO
  CALL set(i, 3)         ! valid
  CONTAINS
    SUBROUTINE set(j, n)
      INTEGER, INTENT(out) :: j
      INTEGER, INTENT(in)  :: n
      j = n
    END SUBROUTINE

we can not unconditionally add an attribute, say, is_loop_variable, to the
symbol of 'i' as it sometimes is not. One could temporarily flag the symbol as
loop-variable in resolve.c (gfc_resolve_iterator), but I'm lost where/how to
reset this flag afterwards.

Thoughts? Pointers?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


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