Request to issue an error with a deleted/removed feature when /warn:stderrors compiler option is in effect.

[FortranFan]

Starting with FORTRAN 77 (ANSI X3.9 1978), the so-called "extended range of a DO loop" feature has been removed.  However when an example code involving this feature is compiled using Intel Fortran with /warn:stderrors but no /f66 option, no error is issued.  Can the Intel Fortran team consider a change where an error will be issued under such a circumstance?

C Example: "Extended range of a DO Loop"
C
      INTEGER I
      INTEGER J
      J = 0
C Simulate a DO loop with "extended range" feature from
C ANSI X3.9-1966 FORTRAN
      DO 10 I = 1, 3
         PRINT *, "J = ", J
         GO TO 20
   10 CONTINUE
C Done with DO loop; control transferred to statement 99
      GO TO 99
C Simulate a collection of sequences that "extend" the DO
C Then return the control to the DO loop
   20 J = I + 1
      GO TO 10
C
   99 CONTINUE
      STOP
      END

Upon compilation,

C:Fortran>ifort /c /warn:all /warn:stderrors /stand p.for
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 17.0.1.143 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

p.for(1): warning #7373: Fixed form source is an obsolescent feature in Fortran
2008.
C Example: "Extended range of a DO Loop"
^
p.for(17): warning #6371: A jump into a block from outside the block may have oc
curred.   [10]
      GO TO 10
------------^

Please note with gfortran for the same code, one gets:

    10 CONTINUE
     1
C:Fortran\p.for:11:72:
       GO TO 10
       2
Error: Legacy Extension: Label at (1) is not in the same block as the GOTO statement at (2)

Thanks,

[Kevin_D_Intel]

Thank you FortranFan. A feature enhancement has been submitted.

(Internal tracking id: CMPLRS-43260)

[FortranFan]

Kevin D (Intel) wrote:

Thank you FortranFan. A feature enhancement has been submitted.

(Internal tracking id: CMPLRS-43260)

Thanks, Kevin, for your followup.

Here's another suggestion if you can take it all the way up with Intel team who manage Intel Parallel Studio customers: for those customers whose license and support renewal terms extend to Online Service Center support (i.e., Intel Premium Support previously), please provide them with VISIBILITY, perhaps even on a read-only basis following the initial submission, to Intel's tracking system for CMPLRS.  This may even provide motivation for the customers to sign up for support renewal routinely.

Note customers need greatly improved visibility into tracking incidents and at least be able to study the compiler teams' analyses and monitor progress by themselves, first by being able to locate ithe ncidents the customers have initiated either at OSC directly or via this forum in a manner that is easy-to-use and which works as fast as a Google search.

[FortranFan]

Kevin D (Intel) wrote:

Thank you FortranFan. A feature enhancement has been submitted.

(Internal tracking id: CMPLRS-43260)

Kevin,

It will be very helpful if you can also loop back with Intel Fortran team during any one of your Fortran compiler product reviews on the following aspect too - the documentation on Intel Fortran has a subsection on "Extended Range" under Execution Control and DO constructs: https://software.intel.com/en-us/node/678613.  No color coding is included and unsuspecting readers will view it as standard Fortran.  However please note ANSI(R) X3.9-1978 aka FORTRAN 77 has the following section in Appendix A2 which deals with the changes it introduced relative to FORTRAN 66: 

A2. Conflicts with ANSI X3.9-1966 
An extremely important consideration in the preparation of this standard was the
minimization of conflicts with the previous standard, ANSI X3.9-1966. This standard
includes changes that create conflicts with ANSI X3.9-1966 only when such changes
were necessary to correct an error in the previous standard or to  add to the power of
the FORTRAN language in a significant manner. The following is a list of known conflicts: 
.. 
(7) This standard does not permit a transfer of control into the range of a DO loop from
outside the range. The range of a DO-loop may be entered only by the execution of a
DO statement. ANSI X3.9-1966 permitted transfer of control into the range of a
DO-loop under certain conditions. This involved the concept referred to as
"extended range of a DO." 
.. 

And a similar blurb about "transfer of control into the range of a DO loop from outside the range" not being permitted is present in every subsequent standard revision, including the one under works WD 1539-1 ISO/IEC JTC 1/SC 22/WG5/N2118 29th December 2016 toward Fortran 2015 that has in section 11.1.2 on Rules governing Blocks:

11.1.2.1 Control flow in blocks 
1 Transfer of control to the interior of a block from outside the block is prohibited,
 except for the return from a procedure invoked within the block. Transfers within
 a block and transfers from the interior of a block to outside the block may occur. 

Based on above, the Intel Fortran documentation on "Extended Range", which in my opinion refers to the FORTRAN 66 feature, should get flagged somehow as non-standard, at least when /F66 compiler option is not in effect.

Thanks,

[TimP]

The intel documentation of extended range do certainly should note that the feature was obsoleted from f77 on.  I suppose it may be impractical to introduce useful compiler diagnoses to distinguish correct f66 usage from other forms of jump into do loop.

[FortranFan]

Tim P. wrote:

The intel documentation of extended range do certainly should note that the feature was obsoleted from f77 on.  I suppose it may be impractical to introduce useful compiler diagnoses to distinguish correct f66 usage from other forms of jump into do loop.

@Tim P. and Intel team,

I agree, so please note I am not requesting any improvement in terms of diagnostics when /F66 is in effect, that is up to Intel and their other customers.

Or more broadly speaking, I'm not even delving into any aspect about what Intel Fortran team wants to do with their compiler with the default or any other compiler setting, I understand and appreciate the legacy usage and the impact on existing customer base.  What I am requesting in the original post is the least amount of consideration that when /warn:stderrors option is applied, an error be issued.

By the way, "extended range of a do" from ANSI X3.9 1966 was DELETED, not simply made obsolescent in the subsequent revision and all the following ones.

[Kevin_D_Intel]

I captured/passed on the latest feedback on tracking incident visibility and "Extended Range". Thank you.