Can't use 2D arrays that start with "stop"

[ITUB]

I was trying to build old code with ifort version 2021.5.0 and got a strange syntax error. Here it is reduced to a minimal example:

program example
implicit none
integer stopfoo(1,1)
stopfoo(1,1) = 1
end

  When I try to compile it,

$ ifort example.f
example.f(4): error #5082: Syntax error, found '=' when expecting one of: :: ) , : * <END-OF-STATEMENT> ; . % (/ + - ] /) . ' ** / // > ...
      stopfoo(1,1) = 1
-------------------^
example.f(4): error #6404: This name does not have a type, and must have an explicit type. [FOO]
      stopfoo(1,1) = 1
----------^
example.f(4): error #6259: This array or function or substring is invalid in constant expressions. [FOO]
      stopfoo(1,1) = 1
----------^
compilation aborted for example.f (code 1)

 So it seems that the statement was parsed as a stop statement, that is stop foo(1,1) = 1, which is illegal.

Note that this example compiles without complaint with ifort version 17.0.1, the error doesn't happen for a 1D array, and other keywords don't seem to trigger the error, for example, iffoo(1,1) = 1 is OK (I haven't tried every keyword yet, though). I don't know if this is a bug, or if the new compiler started to enforce some obscure edge case of Fortran parsing.

[Arjen_Markus]

Your source file seems to be fixed form - or is interpreted as fixed form - judging from the extension .f. That means that spaces outside strings are considered irrelevant. It is therefore quite possible that the compiler sees a STOP statement instead of an assignment. Clearly an error in the compiler. You could use free form instead to avoid the problem.

[mecej4]

I suspect that the forum software stripped leading blanks from the lines of the source code. I added six leading blanks to each line, retaining the file name with a ".f" suffix, and the OneAPI compilers displayed the errors reported by the OP.

I think that this is a parsing error in the latest version of the compiler (Ifort and Ifx). Ifort 19.1.3.311 on Windows compiled the example code without complaints.

[Steve_Lionel]

It would not astonish me if this bug was introduced when ifort added support for Fortran 2018's changes to STOP.

[Ron_Green · Accepted solution]

Agreed.  I'll open a bug report on this.

[DavidWhite]

I don't know how .f files are meant to be processed (never used them), but it appears that the file is being assumed to be a fixed format (.for) file.

Changing the name to .f90 extension compiles properly, as expected for a free format code.

[GVautier]

Take a look here https://community.intel.com/t5/Intel-Fortran-Compiler/Is-StopPoint-a-reserved-keyword/m-p/1290166

[ITUB]

Thanks, everyone for the quick replies! Yes, my code was indented six spaces but they were stripped when pasting into the forum, sorry about the confusion.

I have also confirmed that I don't see this issue with free form. Another incentive to modernize this legacy code, perhaps!

[Ron_Green]

Bug ID CMPLRLLVM-34887

[Steve_Lionel]

.f and .for are assumed to be fixed-format.

[Devorah_H_Intel]

The fix is in the upcoming oneAPI 2022.3 release.