Is ifort supposed to recognize all Fortran comment characters?

[Jérôme]

Hello,

I am trying to compile a benchmark suite. I have a lot of errors, because it has old ways to represent comment lines: lines beginning by "c", "C", "*"...

It seems that ifort does not recognizes these characters like the start of a comment line. I tried a lot of options in the command line, as fixed or free form, options to fpp... No matters, ifort does not want to compile it.

Did you ever succeed to compile such source code?

[Kevin_D_Intel]

Please attach one of the source files to this post and we will be able to determine the exact cause.

[mecej4]

I routinely compile sources some of which are in fixed format and some in free format, with plenty of comments in them, and have never run into the problem that you described.

However, and this is may not help you, I note that once in a while I have found myself editing a copy of a source file in one directory while compiling another copy in a different directory, having forgotten that I created a new directory to test some changes...

[TimP]

Quoting Jrme

I am trying to compile a benchmark suite. I have a lot of errors, because it has old ways to represent comment lines: lines beginning by "c", "C", "*"...

Those work only for fixed form source. It's the same with any Fortran compiler. Use the command line option for fixed/f77 form, or use one of the file extensions .f .F .for

Only the "!" comments work the same in fixed f77 or free .f90 source format.

[Jérôme]

Those work only for fixed form source. It's the same with any Fortran compiler. Use the command line option for fixed/f77 form, or use one of the file extensions .f .F .for
Only the "!" comments work the same in fixed f77 or free .f90 source format.

OK, that was my first lead. I did not try to rename in .f or another, as I can not modify the source code. But I tried with a small example, and you're right!

[fortran]! first comment test
c second comment test
C third comment test
* another comment test
d almost last
D last comment test

PROGRAM MAIN
INTEGER I
REAL A(100)
DO I = 1, 100, 1
A(I) = 0.0E0
END DO
END[/fortran]

If I name the file test.f90, it produces a lot of errors (here a summary):

[bash]test.f90(2): error #5082: Syntax error, found IDENTIFIER 'SECOND' when expecting one of: ( % : . = =>
c second comment test
--^
test.f90(3): error #5082: Syntax error, found IDENTIFIER 'THIRD' when expecting one of: ( % : . = =>
C third comment test
--^
test.f90(4): error #5082: Syntax error, found '*' when expecting one of:  ;  BLOCK BLOCKDATA PROGRAM MODULE TYPE COMPLEX BYTE ...
* another comment test
^
[/bash]

But if I rename like test.f, it works!

My question is: is it possible to reproduce the .f behaviour with a .f90 file + some flags during the compilation???

[Kevin_D_Intel]

The answer to your question is, yes, the -fixed option. The option instructs the compiler to parse the input file using fixed-form source rules regardless of parsing implied by the file extension. (e.g. .f90 implies parsing as a free-form source) but it assumes the source file adheres to all fixed-form source rules.

However, that option will not work for the sample you showed. Your sample contains a mixture or free-form source (lines 8-14 start in column 1) and fixed-form comments and debug lines (lines 1-6) so you cannot instruct the compiler to parse the file as one or the other forms because the file contents do not fully comply with all rules for either form, and there's no compiler option I'm aware of to tell the compiler to parse the file as both. How is the compiler supposed to know which form to apply for any given line?

There is not a compiler option to instruct the compiler to accept old-style comments (c, C, *) within free-form source either.

With fixed-form parsing enabled, "d, D" lines can be treated accordingly using -d-lines option.

If this is a benchmark code for which you cannot change the source and it was written using fixed-form comments then one would expect the actual source follows fixed-form rules also, in which case the source files should be named with a file extension that implies parsing as fixed-form source, or compiled with the -fixed option. For fixed-form file extensions, as per the documentation:

"The compiler assumes that files with an extension of .f, .for, .ftn, or .i are fixed-form (or tab-form) files."

Are you certain the benchmark source was written to contain a mixture of source forms like your sample shows?

[Jérôme]

You were right, -fixed option fixed all my issues (plus -extend-source 132...) The guilty source file was hiden in a lot of noise, that's why my previous attemps with -fixed option was unsuccesful.

So this thread is now closed, thanks!