error#8093 ，error#6511，编写代码遇到这两个错误请问怎么解决

菜鸟萌新

* q9 c# n! T6 h# N  B

描述错误＃8093：DO主体内的do变量不应出现在变量定义上下文中。 [I]
( T  Q/ S, U9 ?9 }: H+ V' U! `描述错误＃6511：此DO变量已在同一嵌套结构中用作外部DO变量。 [I]
9 L' b1 o' y$ t: d  y$ U

5 M4 b+ M. \1 G5 h2 @/ ~3 I* L以上描述是用谷歌翻译，如有错误请指正。
截图中代码是用来冒泡排序。
- U( B0 `0 m$ ~  e' _3 K
个人理解是双循环中的变量I用了两次，出现在下一个do循环中，但就fortran语法来说这是允许的，不知道如何解决。也有可能是我对错误的描述理解出现偏差

菜鸟萌新

  w$ s, F* ?0 |1 r9 B: v
' O7 O* ?  \' Chttps://software.intel.com/en-us ... c-os-x/topic/559950
2 A7 b2 k: m. _0 M1 j7 n
8 ?" i! x1 ]  OThe interesting (to me, anyway) part of this question is that the do-variable in an io-implied-do does NOT have "statement scope" the way a DATA implied-do or array constructor implied-do variable do.  With statement scope, the implied-do variable is a new, different variable that inherits only the type of any outer-scope variable (but that type must be integer.)The "i" in the I/O implied DO is the same variable as the line 1 DO control variable and ifort is absolutely correct in complaining about this., pgf90 could support this as an extension, but would need to have the ability to diagnose it (perhaps through a standards checking switch), or else risk being a nonconforming implementation.

& w+ V; h  g4 s- O2 N8 ]8 DThe other interesting part is that we do, sort-of, allow changing DO variables, as an extension, but you have to do it by passing the variable to a procedure which then changes it. ifort recognizes the possibility and generates an explicit test rather than a loop count if it sees this.
1 ?# t  K& y$ H' E$ t# i6 w
这个问题的有趣（对我来说，无论如何）部分是io声明的do中的do的变量没有DATA声明的方式或者数组构造函数声明-do变量的方式。 对于语句范围，声明do变量是一个新的，不同的变量，它只继承任何外部作用域变量的类型（但该类型必须是整数。）I / O暗示DO中的“i”是相同的变量 作为第1行DO控制变量和ifort在抱怨这一点时绝对正确。，pgf90可以支持这作为扩展，但是需要能够诊断它（可能通过标准检查开关），否则冒险成为 不合格的实施。
# X9 e* _* ^  h: N1 h; y
3 j3 {7 |/ Y$ X) ]; i: O( k另一个有趣的部分是我们这样做，排序，允许更改DO变量，作为扩展，但你必须通过将变量传递给一个程序然后更改它来完成它。 如果它看到这个，ifort会识别出这种可能性并生成一个显式测试而不是一个循环计数。
2 V6 Y& c% t* m+ ~1 y: d

菜鸟萌新

https://software.intel.com/en-us ... c-os-x/topic/559950
, _9 D2 d! J# q& J$ Z6 F4 [
The interesting (to me, anyway) part of this question is that the do-variable in an io-implied-do does NOT have "statement scope" the way a DATA implied-do or array constructor implied-do variable do.  With statement scope, the implied-do variable is a new, different variable that inherits only the type of any outer-scope variable (but that type must be integer.)The "i" in the I/O implied DO is the same variable as the line 1 DO control variable and ifort is absolutely correct in complaining about this., pgf90 could support this as an extension, but would need to have the ability to diagnose it (perhaps through a standards checking switch), or else risk being a nonconforming implementation.
' I9 W* G0 T3 d5 q
The other interesting part is that we do, sort-of, allow changing DO variables, as an extension, but you have to do it by passing the variable to a procedure which then changes it. ifort recognizes the possibility and generates an explicit test rather than a loop count if it sees this.

2 R2 o* K  L; T' A( G2 g
# p" ^3 l0 t$ I5 V  s6 R( M这个问题的有趣（对我来说，无论如何）部分是io-implied-do中的do-variable没有DATA隐含的方式或者数组构造函数暗示-do变量的方式。 对于语句范围，implied-do变量是一个新的，不同的变量，它只继承任何外部作用域变量的类型（但该类型必须是整数。）I / O暗示DO中的“i”是相同的变量 作为第1行DO控制变量和ifort在抱怨这一点时绝对正确。，pgf90可以支持这作为扩展，但是需要能够诊断它（可能通过标准检查开关），否则冒险成为 不合格的实施。
$ F9 V. w1 \. K4 T7 ~7 J
: i* u2 X8 V, K5 H另一个有趣的部分是我们这样做，排序，允许更改DO变量，作为扩展，但你必须通过将变量传递给一个程序然后更改它来完成它。 如果它看到这个，ifort会识别出这种可能性并生成一个显式测试而不是一个循环计数。

菜鸟萌新

% D5 ]5 h5 Q$ K. \! n
9 _4 T# `- i5 M9 B' x" a0 C7 t# W  N已找到问题， 是另外一个模块do循环没有加终结语结束循环，i 的值被篡改，因为我的循环语句用的是i 作为变量，对所有的循环语句都造成了干扰
! o. h  ^2 }, P/ Q; n- M- Q