Problem compiling fortran 77 when there is stop in the name of a variable

[FabriceB]

HI We are unable to compile demon I had made a minimal code to narrow the problem PROGRAM ESSAI DOUBLE PRECISION STOPTR(15,15) STOPTR(:,:)=0 END Compilation with ifort 2021.5.0 fails essai.f(4): error #5082: Syntax error, found '=' when expecting one of: :: ) , : * ; . % (/ + - ] /) . ' ** / // > ... No problem if the variable is named SOPTR... Is it a known bug ? Can someone help me ? Thanks Fabrice (Works with gfortran and older version of intel compiler)

[Arjen_Markus]

Actually, it is a known issue, see this thread: https://community.intel.com/t5/Intel-Fortran-Compiler/Can-t-use-2D-arrays-that-start-with-quot-stop-quot/m-p/1356353

The problem is in the parsing of fixed-form source code (where spaces are irrelevant). As you found, names starting with STOP are treated as if they were STOP statements. Renaming is one solution, another is to use the free-form for the source code instead.

[Ron_Green · Accepted solution]

already reported, bug ID CMPLRLLVM-34887

[FabriceB]

Thanks for the answers. There are many lines to change, so I will have to wait until the bug is solved.

[GVautier]

Have you think about using multiple file change/replace function like in Notepad+?

If you shorten the name, side effects will be unlikely.

[FabriceB]

It is not our own software, but a modified version of http://www.demon-software.com/public_html/index.html

The version we are using has 227 957 lines of fortran in 1789 files

There are many array begining with stop.

I could use sed to modify all the files, array by array, but

 . there is  a big risk of mistakes (may be there are some include files somewhere or preorpocessing, or ...)

. the diff with the original version will be huge, if we wan to apply our modifications to the latest deMon2k version it will be really difficult

[jimdempseyatthecove]

>>There are many array beginning with stop.

You could relatively quickly, and non-destructively, make the "edits" using FPP. 

Jim Dempsey

[Ron_Green]

@FabriceB if it helps in your decision making, the next compiler release in oneAPI will be coming late this month, we hope.  BUT this release will NOT have this fixed - we freeze code months ahead of our releases and this bug did not make it into the branch in time.  And after this release the next oneAPI release will be late June or early July.   I wish I had better news but I thought you should know.

[Devorah_H_Intel]

The fix is in the next ifx 2022.2 release.