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

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

ITUB
Beginner
1,665 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
1,620 Views
0 Kudos
10 Replies
Arjen_Markus
Honored Contributor I
1,657 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.

0 Kudos
mecej4
Honored Contributor III
1,642 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.

0 Kudos
Steve_Lionel
Honored Contributor III
1,642 Views

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

0 Kudos
Ron_Green
Moderator
1,621 Views

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

0 Kudos
DavidWhite
Valued Contributor II
1,543 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.

0 Kudos
ITUB
Beginner
1,614 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!

0 Kudos
Ron_Green
Moderator
1,583 Views

Bug ID CMPLRLLVM-34887


0 Kudos
Steve_Lionel
Honored Contributor III
1,521 Views

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

0 Kudos
Devorah_H_Intel
Moderator
1,233 Views

The fix is in the upcoming oneAPI 2022.3 release. 

0 Kudos
Reply