------- 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
