info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What does this do?
215 views
Skip to first unread message
Robert Corbett
Jul 17, 2022, 5:29:55 AM7/17/22
to
--------------------------------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.
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.
Robert Corbett
Jul 17, 2022, 5:35:37 AM7/17/22
to
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.
blanks from the program after I hit post. For fixed
form compilation, add six blanks to the start of
each line.
Thomas Koenig
Jul 17, 2022, 6:06:02 AM7/17/22
to
Robert Corbett <robertpa...@gmail.com> schrieb:
$ 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]
> --------------------------------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:
> 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.
$ 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]
Robert Corbett
Jul 17, 2022, 6:45:36 AM7/17/22
to
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.
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.
FortranFan
Jul 17, 2022, 10:42:29 AM7/17/22
to
On Sunday, July 17, 2022 at 5:29:55 AM UTC-4, Robert Corbett wrote:
> ..
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)
> ..
> I would like to know what results various
> compilers produce for the program shown
> above. ..
> compilers produce for the program shown
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)
FortranFan
Jul 17, 2022, 11:02:34 AM7/17/22
to
On Sunday, July 17, 2022 at 6:45:36 AM UTC-4, Robert Corbett wrote:
> .. There is something missing
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
> .. 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...
> conforming because the standard does not
> establish a meaning for the program. That hole in
> the standard is what prompted me to ask the
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.
PRINT *, X
END
Robert Corbett
Jul 17, 2022, 5:01:09 PM7/17/22
to
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 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.
John
Jul 17, 2022, 6:06:21 PM7/17/22
to
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
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
Ron Shepard
Jul 18, 2022, 12:42:21 PM7/18/22
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
John
Jul 18, 2022, 7:46:46 PM7/18/22
to
/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
Error: Host associated variable ‘x’ may not be in the DATA statement at (1)
/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
Error: Host associated variable ‘x’ may not be in the DATA statement at (1)
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.
gah4
Jul 18, 2022, 7:53:34 PM7/18/22
to
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
(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.
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
gah4
Jul 19, 2022, 12:20:48 AM7/19/22
to
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.
(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.
(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.
Robin Vowels
Jul 19, 2022, 3:05:07 AM7/19/22
to
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.
Steve Lionel
Jul 24, 2022, 2:38:15 PM7/24/22
to
On 7/17/2022 5:29 AM, Robert Corbett wrote:
Snip
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
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
> 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.
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
Robert Corbett
Aug 3, 2022, 7:58:27 AM8/3/22
to
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
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
0 new messages