-F considered harmful

Accelerated Computing HPC Compilers Legacy PGI Compilers
1

Consider a trivial program:

program foo
print*, MACRO
end program foo

compile

pgfortran -DMACRO=“‘Hello World’” trivial.F90 && ./a.out

This compiles and executes as expected

pgfortran -E translates as expected

pgfortran -F destroys the file.

Understandable because .F90 and .f90 will be treated by MacOS as the same name (although it begs the question of why it works without -F … other compilers in other environments don’t).

Since the FreePGI for MacOS X is mac specific, seems like the driver ought to “know” that MacOS filesystems of the default kind will fail this way, and protect the user.

Or am I missing something from the documentation?

2

Hi khbkhb,

The “-F” flag is working as documented where a “.F90” file will get preprocessed and saved into a “.f90” file. You are correct that this can be an issue on case-insensitive file systems.

I added a problem report (TPR#22236) and sent it to our engineers to see what can be done.

Best regards,
Mat

3

Thanks, I appreciate that it “works as intended” however, for the Mac OS X version of the product, that pretty much leaves the -F as unusable (to be honest, I’m pretty surprised that the macro processing works … on, say, Windows hosting Linux via VirtualBox and the Linux system unwisely having been configured to use the “shared folder” feature, the Linux system thinks the FS is case sensitive, but windows arranges otherwise … and the mere act of compiling clobbers .F90 files with several compilers ;<

But for a MacOS X specific product, it seems to me that an alternative should be selected by default (perhaps F90 ->f9x ;>)

4

Have you tried the “-Mpreprocess” flag? This enables C style macro preprocessing on your file no matter the extension. It does not create an intermediary file and does not stop after preprocessing.

5

Sorry if I was imprecise.

I specifically wanted the processed Fortran output, hence my use of -F. On Mac OSX that is failing, unsurprising given the case insensitivity.

pgfortran IS working (that is foo.F90 generates code correctly, despite the MacOS X filesystem). This IS surprising.

Various Linux based Fortrans fail when run inside a VirtualBox Linux environment hosted by Windows, and using a “shared folder”. This is only of interest to illustrate the underlying issue shouldn’t be surprising; however given a release designed for MacOS X a change from the traditional processing/naming flow should strongly be considered ;>

Obviously, I could simply use the fpp from netlib (contributed by Sun) and handle all the details external to the compilation system, but that would be missing the point.