On Monday, July 18, 2022 at 12:42:21 PM UTC-4, Ron Shepard wrote:
On 7/17/22 5:06 PM, John wrote:
Under "8.1.4 BLOCK construct" it states
2 Except for the ASYNCHRONOUS and VOLATILE statements, specifications
in a BLOCK construct declare construct entities whose scope is that
of the BLOCK construct (16.4).
I think that means the restriction is correct, in that the DATA statement is specifying the initial saved valuea. So if the declaration for X is
in the block it would be OK, but not otherwise. This appears to work, which supports that interpretation ...
program main
implicit none
integer :: i
do i=1,3
block
integer x
data x/0/
x = x + 1
print *, x
end block
enddo
end program main
Yes, I think this issue does depend on how implicit typing applies to
the block, and also how implied save applies to the data statment. Is
the x within the block a new implicitly typed variable, or is it the
same one outside the block. The explicit declaration within the block resolves that ambiguity.
I'm still uncertain about the DATA statement in that case. Does the DATA statement within the block change anything regarding the implicit typing?
In any case, this is something that a programmer should never do. Even
if the behavior is, now or in the future, specified by the language,
this is such an obscure corner case that no one should expect other programmers to know what is happening.
$.02 -Ron Shepard
test1)$ gfortran /tmp/x2.f90
/tmp/x2.f90:7:7:
7 | data x/0/
| 1
Error: Host associated variable ‘x’ may not be in the DATA statement at (1) (test1)$ ifort /tmp/x2.f90
/tmp/x2.f90(7): error #6239: This is an invalid DATA statement object. [X] data x/0/
-----^
/tmp/x2.f90(7): error #6404: This name does not have a type, and must have an explicit type. [X]
data x/0/
-----^
compilation aborted for /tmp/x2.f90 (code 1)
(test1)$ nvfortran /tmp/x2.f90
NVFORTRAN-S-0038-Symbol, x, has not been explicitly declared (/tmp/x2.f90)
0 inform, 0 warnings, 1 severes, 0 fatal for main
# remove implicit none
(test1)$ vi /tmp/x2.f90
gfortran /tmp/x2.f90
/tmp/x2.f90:6:7:
6 | data x/0/
| 1
Error: Host associated variable ‘x’ may not be in the DATA statement at (1) (test1) $ !ifort
ifort /tmp/x2.f90
/tmp/x2.f90(6): error #6008: A data-stmt-object must not be an object made accessible through host or use association. [X]
data x/0/
-----^
compilation aborted for /tmp/x2.f90 (code 1)
(test1 !nv
nvfortran /tmp/x2.f90
With three compilers I get an error if I add IMPLICIT NONE at the top, and two compilers get an error but one actually compiles if I remove it.
It is interesting how the message changes.
If I then remove the INTEGER statement and add a WRITE(*,*)X after the loop gfortran and nvfortran run treating the two X variables as distinct and IFORT still will not compile it. Entertaining dusty corner. So the interpretation that makes sense is that
the DATA statement in a block statement can only apply to a variable explicitly declared in the BLOCK but when implicit typing is on two compilers say it is illegal to have the DATA statement set a value for an X declared outside of the block, while the
third one seems to assume that if the DATA statement were outside the block it would define a variable; so it does the same thing in the block and creates a second X whose scope is just the block. I have not found anything so far explicitly saying you
cannot use a DATA statement to declare a variable with scope just in the block. If it is not in there somewhere along with a statement saying a DATA statement only applies to the scope of the block it should. Not saying it does not somewhere for sure,
but could not find it. The near-consistency of three compilers makes me think it is in there somewhere and that at least one of the compilers therefore does have a bug. The question seems to be is a DATA statement in a BLOCK equivalent to a declaration
in the block of "INTEGER :: X=0"? Since I almost never use DATA statements in new code and most older code does not have a BLOCK statement in it; and when I do use a DATA statement in VERY rare occasions I put it in the outer scope before executable
statements I imagine I would never have hit this on my own. My take-away is never put a DATA statement in a BLOCK (too) ! A LONG time ago someone advised me to always take the well worn path when I had a choice unless I liked filing compiler bugs. The
advice still seems to be holding up.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)