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

Fortran Preprocessor and compiler directive !DIR$ FREEFORM

Jobie
Beginner
4,066 Views

I have some Fortran source code in free source form. Our in-house procedures expect .F for a Fortran source file suffix and are not set up to deal with free source form, so adding the -free flag would be a special case for my source code. I'm trying to use the compiler directive !DIR$ FREEFORM to use free source form, but I haven't figured out how to make this work correctly with fpp. 

Here is an example that demonstrates:

test.F

!DIR$ FREEFORM
subroutine test
                                                                  real :: E1
real :: E2
end 

 

[~/git/] % ifort -v
ifort version 19.0.3.199
[~/git/] % ifort -save-temps -c test.F
test.F(3): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: BLOCK DO FORALL SELECT SELECTCASE SELECTTYPE WHERE ASSOCIATE CRITICAL IF
                                                                  real :
------------------------------------------------------------------------^
test.F(5): error #5082: Syntax error, found '*' when expecting one of: <LABEL> <END-OF-STATEMENT> ; <IDENTIFIER> TYPE MODULE ELEMENTAL IMPURE NON_RECURSIVE ...
     *:
-----^
test.F(3): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of: ( : % [ . = =>
 E1
---^
test.F(3): error #6218: This statement is positioned incorrectly and/or has syntax errors.
 E1
-^
compilation aborted for test.F (code 1)
[~/git/] % cat test.i
# 1 "test.F"
!DIR$ FREEFORM
subroutine test
                                                                  real :

     *:

# 3
 E1
real :: E2
end 

So fpp has tried to convert the source to fixed form, though it looks like something went wrong with the continuation in the declaration for E1.  fpp leaves !DIR$ FREEFORM and the compiler is expecting free source form. 

Removing :: from the E1 declaration:

!DIR$ FREEFORM
subroutine test
                                                                  real E1
real :: E2
end 

 and fpp will get the reformatting to fixed source form correct, but still leaves !DIR$ FREEFORM in the processed file which causes a format conflict at compile.

[~/git/] % ifort -save-temps -c test.F
test.F(4): error #5082: Syntax error, found '*' when expecting one of: <LABEL> <END-OF-STATEMENT> ; <IDENTIFIER> TYPE MODULE ELEMENTAL IMPURE NON_RECURSIVE ...
     *1
-----^
test.F(6): error #6236: A specification statement cannot appear in the executable section.
real :: E2
^
test.F(4): error #6052: This label has not been defined as a FORMAT label.   [1]
     *1
------^
compilation aborted for test.F (code 1)
[~/git/] % cat test.i
# 1 "test.F"
!DIR$ FREEFORM
subroutine test
                                                                  real E
     *1

real :: E2
end 

Removing !DIR$ FREEFORM causes fpp to truncate lines at 72 characters.

So I can see that fpp behaves differently based on !DIR$ FREEFORM, but it doesn't look like there is any way to make fpp generate legal Fortran code with this compiler directive.

Is there any way to use free source form in a source file with .F suffix without adding the -free flag?

0 Kudos
10 Replies
mecej4
Honored Contributor III
4,057 Views

It would be useful for you to attach a zip (or .tar.gz file) containing test.F to your reply. Having the actual unmodified file available is almost necessary when tabs, carriage returns, free-fixed form conversions, etc., are at play.

0 Kudos
Jobie
Beginner
4,044 Views

Thanks for your attention. Attached is a gzipped test.F. Let me know if another format is preferable. 

0 Kudos
jimdempseyatthecove
Honored Contributor III
4,047 Views

Have you considered using a config file to supply the -free?

Default ifort.cfg or specified by environment variable IFORTCFG

Or use environment variable __INTEL_PRE_FLAGS for additional compiler flags.

See: https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-developer-guide-and-reference/top/compilation/supported-environment-variables.html

Jim Dempsey

0 Kudos
Jobie
Beginner
4,034 Views

@jimdempseyatthecove wrote:

Have you considered using a config file to supply the -free?

Default ifort.cfg or specified by environment variable IFORTCFG

Or use environment variable __INTEL_PRE_FLAGS for additional compiler flags.

See: https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-developer-guide-and-reference/top/compilation/supported-environment-variables.html

Jim Dempsey


These will be a few source files in a large repository. All the other Fortran files are in fixed source form with a .F suffix. So I'm trying to change to free source form only for my files while still using fpp.

Changing the file naming or compile procedure for these files is possible, but I'm trying to avoid it by using !DIR$ FREEFORM.

0 Kudos
andrew_4619
Honored Contributor III
4,029 Views

"Our in-house procedures expect .F", yes it can be very frustrating when you have to get your source files processed to make punch cards  so you can load the cards to make the source file.

But I guess the problem is you need also an fpp directive to set freeform (if there is such a thing) that comes before the compiler directive.

0 Kudos
andrew_4619
Honored Contributor III
4,025 Views

fpp and have the -free option to overide the .f file being fixed form.

0 Kudos
Jobie
Beginner
4,022 Views

@andrew_4619 wrote:

fpp and have the -free option to overide the .f file being fixed form.


Maybe this is the only solution, but it's easier for me if I can contain these options directly in the source file with !DIR$ FREEFORM.

0 Kudos
mecej4
Honored Contributor III
3,988 Views

The Windows Ifort 19.1 compiler gave no error messages compiling your test source with the command

     ifort /c test.F

This leads me to ask whether the source file name and format conventions are somewhat different for the Linux version of Ifort. 

On a whim, I tested the old CVF 6.6C compiler on your source, and found that I had to change !DIR$ to !DEC$ in the source, after which there were no problems.

That said, I have to express reservations about what OP is doing. Linux Fortran compilers from other vendors many completely ignore embedded directives and issue a ton of error messages when given your source with !DIR$ directives. Please don't make a religion out of your "house habits" and give posterity a headache. Spend the slight amount of time needed to convert your sources to free format (*.f90) files. A number of tools are available to help you in doing that.

0 Kudos
Jobie
Beginner
3,974 Views

What happened to quoting the original message on a reply? It worked yesterday. I'll try to be clear with copy-paste quoting.

"The Windows Ifort 19.1 compiler gave no error messages compiling your test source with the command

     ifort /c test.F

"

Per the Intel doc on interpretation of input file extensions, the capitalization of the source file extension is only significant on Linux. On Linux, capitalized extensions generally mean preprocess with fpp then compile. On Windows, .f and .F are treated the same and sent directly to the compiler. 

"On a whim, I tested the old CVF 6.6C compiler on your source, and found that I had to change !DIR$ to !DEC$ in the source, after which there were no problems."

With my current compiler version (Intel Fortran version 19.0.3.199) the behavior is the same for !DIR$ FREEFORM and !DEC$ FREEFORM.

"That said, I have to express reservations about what OP is doing. Linux Fortran compilers from other vendors many completely ignore embedded directives and issue a ton of error messages when given your source with !DIR$ directives. Please don't make a religion out of your "house habits" and give posterity a headache. Spend the slight amount of time needed to convert your sources to free format (*.f90) files. A number of tools are available to help you in doing that."

Agreed, but the software build procedures are not my own and changing either the procedures or my source files has a cascade of effects.

0 Kudos
Jobie
Beginner
4,024 Views

@andrew_4619 wrote:

But I guess the problem is you need also an fpp directive to set freeform (if there is such a thing) that comes before the compiler directive.


Yes. I looked for a fpp preprocessor directive that does the same as !DIR$ FREEFORM for fpp, but I didn't find anything. fpp is trying to do something with !DIR$ FREEFORM, but the result isn't proper Fortran.

0 Kudos
Reply