Mat, in another post you said "For the second warning, the utility probably doesn’t know to look in “.cuf” files for modules. Try renaming “cuda_drv.cuf” to “cuda_drv.f90” to see if it takes care of the warning. Since you’re compiling with “-Mcuda”, the suffix doesn’t matter. "
What effect does the suffix have on how the files are compiled? When does one use one suffix and not the other, and vis-a-versa?
I believe that .cuf/.CUF are “auto-recognized” by the compiler such that ‘pgfortran test.cuf’ and ‘pgfortran -Mcuda test.cuf’ are the same thing. When you feed a .cuf into the compiler, it applies the -Mcuda for you. When you use .f90/.F90, the compiler doesn’t a priori know it contains CUDA code and so you need to specify -Mcuda so it can select the right libraries, or whatever magic -Mcuda does. (Similar to how the compiler knows that .F90/.CUF means apply the preprocessor first.)
In the end, though, as Mat said, if you compile with -Mcuda, which suffix doesn’t really matter when it comes to CUDA building.
The suffix tells the compiler what default options to apply to the file. Here’s defaults:
Format Preprocess? Default to usse CUDA?
(-Mfree/-Mfixed) (-Mpreprocess) (-Mcuda)
.F Fixed Yes No
.f Fixed No No
.F90 Free Yes No
.f90 Free No No
.CUF Free Yes Yes
.cuf Free No Yes
The default suffix rules can be overridden with any of the above options. So “pgfortran -Mfree -Mpreprocess -Mcuda myfile.f” uses processing and is a free format CUDA Fortran file, even though the default for a “.f” is the opposite.
I had no idea that the options win like this. Thanks for letting us know this. I imagine sooner or later I’ll make a lax Makefile which will do this and I’d have spent hours trying to figure out what I messed up.
Mat, thanks for filling me in. Should the sentence “So “pgfortran -Mfixed -Mpreprocess -Mcuda myfile.f” uses processing and is a fixed format CUDA Fortran file, even though the default for a “.f” is the opposite.” really say that it is a free format CUDA Fortran file - on account of the -Mfree option?