• What does this do?

    From Robert Corbett@21:1/5 to All on Sun Jul 17 02:29:53 2022
    --------------------------------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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Corbett@21:1/5 to All on Sun Jul 17 02:35:35 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Robert Corbett on Sun Jul 17 10:05:58 2022
    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]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Corbett@21:1/5 to Thomas Koenig on Sun Jul 17 03:45:33 2022
    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]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Robert Corbett on Sun Jul 17 07:42:27 2022
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Robert Corbett on Sun Jul 17 08:02:32 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Corbett@21:1/5 to FortranFan on Sun Jul 17 14:01:07 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to All on Sun Jul 17 15:06:20 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to John on Mon Jul 18 11:42:17 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Mon Jul 18 16:53:32 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John@21:1/5 to Ron Shepard on Mon Jul 18 16:46:44 2022
    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)
  • From gah4@21:1/5 to John on Mon Jul 18 21:20:46 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Tue Jul 19 00:05:05 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to Robert Corbett on Sun Jul 24 14:38:10 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Corbett@21:1/5 to All on Wed Aug 3 04:58:25 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)