This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: "attempt to modify loop index" check in
- To: toon at moene dot indiv dot nluug dot nl
- Subject: Re: "attempt to modify loop index" check in
- From: Craig Burley <burley at gnu dot org>
- Date: Thu, 30 Jul 1998 05:35:01 -0400 (EDT)
- Cc: Luca dot Bottura at cern dot ch, egcs-bugs at cygnus dot com
- Cc: burley at gnu dot org
>Yes, it looks like the tests whether a I/O statement modifies a do
>loop index is correctly applied in case of a read statement (it
>should also complain if you just write "read(5,*) i") but not in
>case of a write statement. This might be due to an oversight: As
>far as I know this - albeit illegal - is the only way to _set_
>something using a write statement.
Well, it's not generally illegal to set things using WRITE when they
aren't loop-control vars, implied-DO vars being a pertinent example.
And, given WRITE (...), FOO(I), I'm not entirely sure it's forbidden
for the FOO *function* to define its argument offhand. (Even if it
is forbidden, in most implementations, it'll probably "work" just fine.)
What *is* probably the case with this is that I ends up officially
"undefined" after the call to FOO, because, in theory at least, the
"processor" can determine the value of the expression without actually
calling the function (and thus without performing side effects)...though
at this point we get into fairly-well-charted-but-strongly-disagreed-
over waters vis-a-vis the interpretation(s) of the FORTRAN 77 and
Fortran 90 standards.
There's also IOSTAT=, of course. Haven't tried that vis-a-vis whether
g77 warns if you use it to set a "live" loop-control variable, though.
tq vm, (burley)