--------------------------------prog.f---------------------------------
PROGRAM MAIN
INTEGER X
X = 2
BLOCK
X = X + 1
DATA X/0/
PRINT *, X
END BLOCK
PRINT *, X
END
-----------------------------------------------------------------------

I would like to know what results various
compilers produce for the program shown
above. The compilers need to be of recent
vintage as the BLOCK construct was new
in Fortran 2008.

I am sorry, but my news agent removed all leading
blanks from the program after I hit post. For fixed
form compilation, add six blanks to the start of
each line.

Robert Corbett <robertpaulcorbett@gmail.com> schrieb:
> --------------------------------prog.f---------------------------------
> PROGRAM MAIN
> INTEGER X
> X = 2
> BLOCK
> X = X + 1
> DATA X/0/
> PRINT *, X
> END BLOCK
> PRINT *, X
> END
> -----------------------------------------------------------------------
>
> I would like to know what results various
> compilers produce for the program shown
> above.

Both gfortran and nagfor reject it:

$ gfortran x.f
x.f:6:16:

6 | DATA X/0/
| 1
Error: Host associated variable ‘x’ may not be in the DATA statement at (1)
$ nagfor x.f
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
Error: x.f, line 6: Invalid redeclaration of host symbol X
detected at DATA@X
[NAG Fortran Compiler pass 1 error termination, 1 error]

Thank you.

The reason gfortran gives for rejecting the program
is misleading. The 'x' in the BLOCK construct is not
host-associated with the 'x' in the scoping unit of
MAIN. The BLOCK construct is in the inclusive
scope of MAIN, and therefore, the 'x' in the BLOCK
construct is either in the scope of the 'x' in the scoping
unit of MAIN or 'x' identifies separate and
unassociated entities in the two contexts.

The NAG compiler is treating the DATA statement as
an explicit declaration. There is something missing
in the standard, and so the program is not standard
conforming because the standard does not
establish a meaning for the program. That hole in
the standard is what prompted me to ask the
question.

On Sunday, July 17, 2022 at 3:06:02 AM UTC-7, Thomas Koenig wrote:
> Robert Corbett <robertpa...@gmail.com> schrieb:
> > --------------------------------prog.f---------------------------------
> > PROGRAM MAIN
> > INTEGER X
> > X = 2
> > BLOCK
> > X = X + 1
> > DATA X/0/
> > PRINT *, X
> > END BLOCK
> > PRINT *, X
> > END
> > -----------------------------------------------------------------------
> >
> > I would like to know what results various
> > compilers produce for the program shown
> > above.
> Both gfortran and nagfor reject it:
>
> $ gfortran x.f
> x.f:6:16:
>
> 6 | DATA X/0/
> | 1
> Error: Host associated variable ‘x’ may not be in the DATA statement at (1)
> $ nagfor x.f
> NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
> Error: x.f, line 6: Invalid redeclaration of host symbol X
> detected at DATA@X
> [NAG Fortran Compiler pass 1 error termination, 1 error]

On Sunday, July 17, 2022 at 5:29:55 AM UTC-4, Robert Corbett wrote:
> ..
> I would like to know what results various
> compilers produce for the program shown
> above. ..

Intel Fortran compiler gives a similar response as gfortran:

C:\temp>ifort /c /standard-semantics p.f
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.6.0 Build 20220226_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.

p.f(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 p.f (code 1)

On Sunday, July 17, 2022 at 6:45:36 AM UTC-4, Robert Corbett wrote:
> .. There is something missing
> in the standard, and so the program is not standard
> conforming because the standard does not
> establish a meaning for the program. That hole in
> the standard is what prompted me to ask the
> question...

Bob,

It will be interesting to learn more from you re: the hole in the standard. Currently I fail to find any such hole, but I am surely overlooking something that you are not.

Is your understanding the standard as written currently permits the code you show in the original to get reduced *effectively* to the following whereas the processors are somehow following some unstated semantics to detect and report nonconformance but which the standard has not made clear?

INTEGER X
X = 3
DATA X/0/
PRINT *, X
END

By the way, I had presumed "DATA statement among executables" was now deleted from the standard: actually it is not! It is still supported, though it is marked as obsolescent.

The issue is involved, but it has boiled down missing restrictions
on DATA statements in BLOCK constructs. The objects in a DATA
statement must have their rank known and their type and type
parameter values known before they can appear. That is all OK
here, so I see nothing in the standard that makes the program I
provided nonconforming. I do not doubt that it is intended to be
nonconforming, but I do not think the standard makes it
nonconforming.

There is a statement in subclause 19.4 that seems to require the
DATA statement to appear in the specification part of the BLOCK
construct, but the statement in 19.4 is overridden by a more general
statement in the description of the BLOCK construct.

I have since constructed a new example where the DATA
statement appears in the specification part of the BLOCK
construct and the problem still occurs. Getting it right does not
seem easy, and the feature is of little consequence.

If the standard requires this case to be conforming, it will add
pain for compiler writers for little practical benefit to programmers.

The feature of DATA statements among executable statements
was made obsolescent in Fortran 90.

On Sunday, July 17, 2022 at 8:02:34 AM UTC-7, FortranFan wrote:
> On Sunday, July 17, 2022 at 6:45:36 AM UTC-4, Robert Corbett wrote:
> > .. There is something missing
> > in the standard, and so the program is not standard
> > conforming because the standard does not
> > establish a meaning for the program. That hole in
> > the standard is what prompted me to ask the
> > question...
>
> Bob,
>
> It will be interesting to learn more from you re: the hole in the standard. Currently I fail to find any such hole, but I am surely overlooking something that you are not.
>
> Is your understanding the standard as written currently permits the code you show in the original to get reduced *effectively* to the following whereas the processors are somehow following some unstated semantics to detect and report nonconformance but which the standard has not made clear?
>
> INTEGER X
> X = 3
> DATA X/0/
> PRINT *, X
> END
> By the way, I had presumed "DATA statement among executables" was now deleted from the standard: actually it is not! It is still supported, though it is marked as obsolescent.

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

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

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.

On Monday, July 18, 2022 at 9:42:21 AM UTC-7, Ron Shepard wrote:

(snip)

> 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.
I suspect that there are a lot of things that a programmer should never
do, but that the standard allows. For one, some programs are generated
by other programs, not by programmers.

That sometimes results in constructs that programmers wouldn't use,
but the logic requires.

One program I used to use generated a comment like:

C THIS WAS WRITTEN BY A PROGRAM, AND IS NOT MEANT TO BE UNDERSTOOD BY HUMANS

On Monday, July 18, 2022 at 4:46:46 PM UTC-7, John wrote:

(snip)

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

When I was first learning Fortran, first year of high school, I tended to do the opposite.
(And in driving, I have a tendency to go the path I haven't before, for variety or
to see new scenery.)

So, I was better than average at finding bugs in compilers, and other systems.

On Tuesday, July 19, 2022 at 2:20:48 PM UTC+10, gah4 wrote:
> On Monday, July 18, 2022 at 4:46:46 PM UTC-7, John wrote:
>
> > 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.
>
> When I was first learning Fortran, first year of high school, I tended to do the opposite.
> (And in driving, I have a tendency to go the path I haven't before, for variety or
> to see new scenery.)
>
> So, I was better than average at finding bugs in compilers, and other systems.
>
In the old days, you didn't need to find bugs, they found you.
From IBM's Release 13 there were hundreds of bugs.
We installed R13, but after a short time reverted (upgraded?) to Release 11.
The Fortran 4E compiler didn't work at all.
The next release we installed, I think R15, IBM had fixed 1,100 bugs.

On 7/17/2022 5:29 AM, Robert Corbett wrote:
Snip
>
> I would like to know what results various
> compilers produce for the program shown
> above. The compilers need to be of recent
> vintage as the BLOCK construct was new
> in Fortran 2008.

A paper, triggered by Robert's question, was passed at the
just-concluded J3 meeting. The answer was that this example is
non-conforming (it is equivalent to example "bad" in the paper), and
edits were provided to clarify this. As there will be no more
interpretations published for Fortran 2018 (a Corrigendum 2 is in
process), this change will go into Fortran 2023. See
https://j3-fortran.org/doc/year/22/22-179r2.txt for more.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

I offer thanks to everyone who provided information
about how compilers handle my example. That
information resulted in changes to the upcoming
edition of the standard. The changes are
described in papers 22-158r1 and 22-179r2.

The committee decided that my example program
conforms to the Fortran 2008 and 2018 standards,
but that that was not intended. No major compiler
accepted the program. One implementor said his
compiler would handle my example program once
it is complete.

The program is not hard to handle. A compiler
that can handle an ASSOCIATE construct must
have mechanisms that could be used to handle
my example. Nonetheless, no one (including me)
thought it was worth making compilers change to
handle my example, so the standard was changed
so that they would not need to handle my example.

Some people claimed that the problem would
disappear once DATA statements among
executable statements, an obsolescent feature,
were disallowed. That claim is false. The
program can be modified to demonstrate the
same problem without using obsolescent features.
The modified program will still be non-conformant
because of the edits in paper 22-179r2.

The edits provided in paper 22-158r1 are not ideal.
A better fix is possible, but it would involve more
extensive edits. Given the current timeline for the
next edition of the standard, the smaller change
seems safer.

Thank you again,
Bob Corbett