In a project I am trying to work around an ICE that appears at -O2 but not at -O1 or -O0. But using a common set of flags in the Makefile and reducing optimization for a single file is unnecessarily cumbersome:
% nvfortran -V -O2 -O1
nvfortran-Info-Switch -Mvect forces -O2
nvfortran 21.9-0 64-bit target on x86-64 Linux -tp haswell
It would be great if this could be made to work the same as for other compilers.
It seems the problem still persists in the NVHPC 24.11:
$ nvfortran --version
nvfortran 24.11-0 64-bit target on x86-64 Linux -tp sapphirerapids
NVIDIA Compilers and Tools
Copyright (c) 2024, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
$ nvfortran -O2 -O0
nvfortran-Info-Switch -Mvect forces -O2
nvfortran-Warning-No files to process
$ nvfortran -O2 -Mnovect -O0
nvfortran-Info-Switch -Mvect forces -O2
nvfortran-Warning-No files to process
$
This is really annoying since it makes too difficult or impossible the manual reduction of optimizations for particular source files when using big cmake-based build systems. Is there any workaround for this?
In Fortran !pgi$r opt 0 reduces optimization to O0 for a specific function or file.
The pragma should still work, please give it a try.
In CMake you should be able to change properties of specific files ( but this was just from a quick search, I personally stay away from CMake when possible): set_source_files_properties( file.f90 file2.f90 PROPERTIES COMPILE_FLAGS "-O0" )
As for cmake, I also try to avoid this system, but for many projects it is inevitable. The set_source_files_properties AFAIK simply adds the -O0 to already constructed command line, but when the existing line already contains -O2, this trick doesn’t work. In general, inventing cmake workarounds is a pain, so if the nvfortran conflicting options resolution worked as documented, that would have been rather universal solution of droping to -O0 in many cases.
I took a look at TPR #30743 and don’t see any activity on it, so I doubt we’ll change the behavior in the current nvfortran.
I did check the new LLVM based Fortran compiler which is in development and will eventually replace the current nvfortran, and there “-O0” takes precedence, giving the expected behavior. I can’t guarantee that things don’t change before release (no ETA as of yet), but unlikely.