PVF is integrated with Microsoft Visual Studio 2015. Throughout this document, "PGI Visual Fortran" refers to PVF integrated with VS 2015. Similarly, "Microsoft Visual Studio" refers to Visual Studio 2015. When it is necessary to distinguish further, the document does so.

Single-user node-locked and multi-user network floating license options are available for both products. When a node-locked license is used, one user at a time can use PVF on the single system where it is installed. When a network floating license is used, a system is selected as the server and it controls the licensing, and users from any of the client machines connected to the license server can use PVF. Thus multiple users can simultaneously use PVF, up to the maximum number of users allowed by the license.

PVF provides a complete Fortran development environment fully integrated with Microsoft Visual Studio. It includes a custom Fortran Build Engine that automatically derives build dependencies, Fortran extensions to the Visual Studio editor, a custom PGI Debug Engine integrated with the Visual Studio debugger, PGI Fortran compilers, and PVF-specific property pages to control the configuration of all of these.

Release 2018 of PGI Visual Fortran includes the following components:

• PGFORTRAN OpenMP and auto-parallelizing Fortran 2003 compiler.
• PGF77 OpenMP and auto-parallelizing FORTRAN 77 compiler.
• PVF Visual Studio integration components.
• OpenACC and CUDA Fortran tools and libraries necessary to build executables for Accelerator GPUs, when the user’s license supports these optional features.
• PVF documentation.

If you do not already have Microsoft Visual Studio on your system, be sure to get the PVF installation package that contains the Visual Studio 2015 shell.

PVF on all Windows systems includes Microsoft Open Tools. These files are required in addition to the files Microsoft provides in the Windows SDK.

This document contains a number of terms and definitions with which you may or may not be familiar. If you encounter an unfamiliar term in these notes, please refer to the PGI online glossary.

These two terms are used throughout the documentation to reflect groups of processors:

Intel 64

A 64-bit Intel Architecture processor with Extended Memory 64-bit Technology extensions designed to be binary compatible with AMD64 processors. This includes Intel Pentium 4, Intel Xeon, Intel Core 2, Intel Core 2 Duo (Penryn), Intel Core (i3, i5, i7), both first generation (Nehalem) and second generation (Sandy Bridge) processors, as well as Ivy Bridge, Haswell, Broadwell, and Skylake processors.

AMD64

A 64-bit processor from AMD™ incorporating features such as additional registers and 64-bit addressing support for improved performance and greatly increased memory range. This term includes the AMD Athlon64™, AMD Opteron™, AMD Turion™, AMD Barcelona, AMD Shanghai, AMD Istanbul, AMD Bulldozer, AMD Piledriver, and AMD Zen processors.

Release 2018 supports new and updated command line options and keyword suboptions.

Added the following options:

• -⁠cpp is now an alias for -⁠Mpreprocess.
• [dis]allows variadic macros.

Changed the following -⁠Minline sub-options:

• Added totalsize:n to limit inlining to the total size of n.
• maxsize:n replaces size:n to prevent inlining of functions bigger than n. The compilers silently convert the previous size:n to maxsize:n.
• Removed levels:n which limited inlining to n levels of functions. The compilers silently ignore levels:n.

The PGI compilers use NVIDIA's CUDA Toolkit when building programs for execution on an NVIDIA GPU. Every PGI installation packages puts the required CUDA Toolkit components into a PGI installation directory called 2018/cuda.

An NVIDIA CUDA driver must be installed on a system with a GPU before you can run a program compiled for the GPU on that system. PGI products do not contain CUDA Drivers. You must download and install the appropriate CUDA Driver from NVIDIA. The CUDA Driver version must be at least as new as the version of the CUDA Toolkit with which you compiled your code.

The PGI tool pgaccelinfo prints the driver version as its first line of output. Use it if you are unsure which version of the CUDA Driver is installed on your system.

By default, the PGI compilers use the CUDA Toolkit components installed with the PGI compilers and in fact most users do not need to use any other CUDA Toolkit installation than those provided with PGI. Developers working with pre-release CUDA software may occasionally need to test with a CUDA Toolkit version not included in a PGI release. Conversely, some developers might find a need to compile with a CUDA Toolkit older than the oldest CUDA Toolkit installed with a PGI release. For these users, PGI compilers can interoperate with components from a CUDA Toolkit installed outside of the PGI installation directories.

PGI tests extensively using the co-installed versions of the CUDA Toolkits and fully supports their use. Use of CUDA Toolkit components not included with a PGI install is done with your understanding that functionality differences may exist.

To use a CUDA toolkit that is not installed with a PGI release, such as CUDA 7.5 with PGI 18.1, there are three options:

• Use the rcfile variable DEFAULT_CUDA_HOME to override the base default

  set DEFAULT_CUDA_HOME = /opt/cuda-7.5;

• Set the environment variable CUDA_HOME

  export CUDA_HOME=/opt/cuda-7.5

• Use the compiler compilation line assignment CUDA_HOME=

  pgfortran CUDA_HOME=/opt/cuda-7.5

The PGI compilers use the following order of precedence when determining which version of the CUDA Toolkit to use.

• In the absence of any other specification, the CUDA Toolkit located in the PGI installation directory 2018/cuda will be used.
• The rcfile variable DEFAULT_CUDA_HOME will override the base default.
• The environment variable CUDA_HOME will override all of the above defaults.
• A user-specified cudaX.Y sub-option to -⁠Mcuda and -⁠ta=tesla will override all of the above defaults and the CUDA Toolkit located in the PGI installation directory 2018/cuda will be used.
• The compiler compilation line assignment CUDA_HOME= will override all of the above defaults (including the cudaX.Y sub-option).
• The environment variable PGI_CUDA_HOME overrides all of the above; reserve PGI_CUDA_HOME for advanced use.

PGI 2018 supports runtime library routines associated with the PGI Accelerator compilers. For more information, refer to Using an Accelerator in the PGI Compiler User's Guide.

To use a different compiler release for a single project, you use the compiler flag -⁠V<ver> to target the compiler with version <ver>. This method is the recommended way to target a different compiler release.

For example, -⁠V13.8 causes the compiler driver to invoke the 13.8 version of the PGI compilers if these are installed.

To use this option within a PVF project, add it to the Additional options section of the Fortran | Command Line and Linker | Command Line property pages.

You can use a different compiler release for all projects.

The Tools | Options dialog within PVF contains entries that can be changed to use a previous version of the PGI compilers. Under Projects and Solutions | PVF Directories, there are entries for Executable Directories, Include and Module Directories, and Library Directories.

• For the x64 platform, each of these entries includes a line containing $(PGIToolsDir). To change the compilers used for the x64 platform, change each of the lines containing $(PGIToolsDir) to contain the path to the desired bin, include, and lib directories.

Programs built with PGI compilers may depend on runtime library files. These library files must be distributed with such programs to enable them to execute on systems where the PGI compilers are not installed. There are PGI redistributable files for Linux and Windows. On Windows, PGI also supplies Microsoft redistributable files.

The issues in this section are related to IDE limitations.

The following limitations apply to PVF debugging:

• Take extra care when using -⁠Mprof with PVF runtime library DLLs. To build an executable for profiling, use of the static libraries is recommended. The static libraries are used by default in the absence of -⁠Bdynamic.
• Using -⁠Mpfi and -⁠mp together is not supported. The -⁠Mpfi flag disables -⁠mp at compile time, which can cause runtime errors in programs that depend on interpretation of OpenMP directives or pragmas. Programs that do not depend on OpenMP processing for correctness can still use profile feedback. Using the -⁠Mpfo flag does not disable OpenMP processing.

This section includes known limitations in PGI's support for OpenACC directives. PGI plans to support these features in a future release.