Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
27432 Discussions

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

ITUB
Beginner
913 Views

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.

Labels (2)
0 Kudos
1 Solution
Ron_Green
Moderator
868 Views
10 Replies
Arjen_Markus
Honored Contributor I
905 Views

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
Black Belt
890 Views

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
Black Belt Retired Employee
890 Views

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

Ron_Green
Moderator
869 Views

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

DavidWhite
Black Belt
791 Views

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.

ITUB
Beginner
862 Views

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
Moderator
831 Views

Bug ID CMPLRLLVM-34887


Steve_Lionel
Black Belt Retired Employee
769 Views

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

Devorah_H_Intel
Moderator
481 Views

The fix is in the upcoming oneAPI 2022.3 release. 

Reply