Re: Scope of implied-do index

In article <44F6657A.9020609@xxxxxxxxxxxxxxxxxx>,
Brooks Moses <bmoses-nospam@xxxxxxxxxxxxxxxxxx> writes:
Steven G. Kargl wrote:
ISTR reading in the F95 standard that the scope of the index
of an implied-do is limited to the implied-do. I can't locate
where I would have gotten that impression, so a pointer to
the F95 text would be much appreciated.

In particular, I interested in what the standard says about

integer i
real x(10)
do i = 1, 10
x = (/ (i, i=1, 10) /)
end do

I spent about 15 minutes tracking down why that was illegal,

I vaguely recalled that it was legal, but after 30 minutes of reading
the F95 standard on a computer screen (my printed copy was in
the office) I gave up and asked here.

and then came across section 14.1.3, which caused me to change my
opinion and consider it to be legal:

"The name of a variable that appears as the DO variable of an implied-DO
in a DATA statement or an array constructor has the scope of the
implied-DO list. It is a scalar variable that has the type and type
parameters that it would have if it were the name of a variable in the
scoping unit that includes the DATA statement or array constructor, and
this type shall be integer type."

As usual, I found the above 15 minutes after posting my question. :)

(A bunch of stuff removed)

gfortran has an interesting bug with the code I posted. Consider

integer, parameter :: n = SOME_CONSTANT
double precision x(n)
integer i
do i = 1,1
x = (/ (i, i=1, n) /)
end do
end

If SOME_CONSTANT <= 65535, then everything works as expected because
the implied-do is expanded at compile time. For larger values, say
1000000, gfortran is effectively doing

do i = 1,1
do i = 1, n
x(i) = i
end do
end do

(You really don't want to put 1000000 constant values into the binary
at compiler time.)

This is done in the backend, which is well beyond parsing and
symbol resolution. It appears that gfortran needs to mangle the
do-variable of the implied-do.


I further conclude that this distinction between types of implied-do
loops and different rules for them is an extremely fine hair for the
standard to be splitting, and I wish to register my sense of "Eeew!" at it!

Seconded.

--
Steve
http://troutmask.apl.washington.edu/~kargl/
.

Relevant Pages

  • Re: NAG, Sun, Compaq possible f95 bug
    ... >> there is no standard way to find out how many were actually read in. ... You can *NOT* assume that hitting an EOF ... Some compilers might do something like decode the values to ... the implied-DO variables in the statement become undefined.... ...
    (comp.lang.fortran)
  • Re: Illegal internal write?
    ... Fortran 2003 standard). ... Five f95 compilers that I tried accepted the program at compile time. ... However, one (gfortran) printed ... END PROGRAM testnoforall3 ...
    (comp.lang.fortran)
  • Re: I really did get burned today [LONG]
    ... "The evaluation of a function reference shall neither affect ... I claim that the evaluation of your function reference both affects ... things in the standard that you aren't violating either. ... > of the implied-DO variables in the statement become undefined ...
    (comp.lang.fortran)