Stacks: Automatic Allocation and Checking

The options in this group enable you to control the computation of stacks and variables in the compiler generated code.

Automatic Allocation of Variables

-automatic (Linux*and Mac OS* X) and /automatic (Windows*)

These options specify that locally declared variables are allocated to the run-time stack rather than static storage. If variables defined in a procedure do not have the SAVE or ALLOCATABLE attribute, they are allocated to the stack. It does not affect variables that appear in an EQUIVALENCE or SAVE statement, or those that are in COMMON.

-automatic (Linux and Mac OS X) or /automatic (Windows) may provide a performance gain for your program, but if your program depends on variables having the same value as the last time the routine was invoked, your program may not function properly. Variables that need to retain their values across routine calls should appear in a SAVE statement.

Note

Linux: If you specify -recursive or -openmp, the default is -auto.

Windows: The Windows NT* system imposes a performance penalty for addressing a stack frame that is too large. This penalty may be incurred with /Qauto because arrays are allocated on the stack along with scalars.

-auto-scalar (Linux and Mac OS X) or /Qauto-scalar (Windows)

These options cause allocation of local scalar variables of intrinsic type INTEGER, REAL, COMPLEX, or LOGICAL to the stack. This option does not affect variables that appear in an EQUIVALENCE or SAVE statement, or those that are in COMMON.

The -auto-scalar (Linux and Mac OS X) or /Qauto-scalar (Windows) option may provide a performance gain for your program, but if your program depends on variables having the same value as the last time the routine was invoked, your program may not function properly. Variables that need to retain their values across subroutine calls should appear in a SAVE statement. This option is similar to -auto (Linux and Mac OS X) and /Qauto (Windows) which causes all local variables to be allocated on the stack. The difference is that -auto-scalar (Linux and Mac OS X) or /Qauto-scalar (Windows) allocates only scalar variables of the stated above intrinsic types to the stack.

Note

Windows: Windows NT* imposes a performance penalty for addressing a stack frame that is too large. This penalty may be incurred with /Qauto because arrays are allocated on the stack along with scalars. However, with /Qauto-scalar, you would have to have more than 32K bytes of local scalar variables before you incurred the performance penalty.

-auto-scalar (Linux and Mac OS X) or /Qauto-scalar (Windows) enables the compiler to make better choices about which variables should be kept in registers during program execution.

-save, -zero[-] (Linux and Mac OS X) or /Qsave, /Qzero[-] (Windows)

The -save (Linux and Mac OS X) or /Qsave (Windows) option is opposite of -auto (Linux) or /Qauto (Windows). The -save (Linux and Mac OS X) or /Qsave (Windows) option saves all variables in static allocation except local variables within a recursive routine.

If a routine is invoked more than once, this option forces the local variables to retain their values from the last invocation. The save option ensures that the final results on the exit of the routine is saved on memory and can be reused at the next occurrence of that routine. This may cause some performance degradation as it causes more frequent rounding of the results.

Note

Linux and Mac OS X: -save is the same as -noauto.

Windows: /Qsave is the same as /save, and /noautomatic.

When the compiler optimizes the code, the results are stored in registers.  

The -zero[-] (Linux and Mac OS X) or /Qzero[-] (Windows) option initializes to zero all local scalar variables of intrinsic type INTEGER, REAL, COMPLEX, or LOGICAL, which are saved and not initialized yet. Used in conjunction with SAVE.

Summary

There are three options for allocating variables: -save (Linux and Mac OS X) or /Qsave (Windows), -auto (Linux) or /Qauto (Windows) and -auto-scalar (Linux) or /Qauto-scalar (Windows). Only one of these three can be specified.

The correlation among them is as follows:

Checking and Setting Space

The following options perform checking and setting space for stacks (these options are supported on Windows only):

Aliases

The -common-args (Linux and Mac OS X) or /Qcommon-args (Windows) option assumes that the by-reference subprogram arguments may have aliases of one another.

It is recommended that you use the -assume dummy_aliases (Linux and Mac OS X) or /assume:dummy_aliases (Windows) option instead of the common-args option.

For more information about using the preferred option, see the following topic:

Preventing CRAY* Pointer Aliasing

Option -safe-cray-ptr (Linux and Mac OS X) or /Qsafe-cray-ptr (Windows) specifies that the CRAY* pointers do not alias with other variables. Consider the following example.

Example

pointer (pb, b)

pb = getstorage()

do i = 1, n

  b(i) = a(i) + 1

enddo

When the option is not specified, the compiler assumes that b and a are aliased. To prevent such an assumption, specify this option, and the compiler will treat b(i) and a(i) as independent of each other.

However, if the variables are intended to be aliased with CRAY pointers, using the -safe-cray-ptr (Linux and Mac OS X) or /Qsafe-cray-ptr (Windows) option produces incorrect result. For the code example below, the option should not be used.

Example

pb = loc(a(2))

do i=1, n

  b(i) = a(i) +1

enddo

Cross Platform

The -ansi-alias (Linux and Mac OS X) or /Qansi-alias (Windows) option enables or disables the function of the compiler to assume that the program adheres to the ANSI Fortran type aliasablility rules.

For example, an object of type real cannot be accessed as an integer. You should see the ANSI standard for the complete set of rules.

The option directs the compiler to assume the following:

If your program satisfies the above conditions, setting this option will help the compiler better optimize the program. However, if your program may not satisfy one of the above conditions, the option must be disabled, as it can lead the compiler to generate incorrect code.

For more information, see the following topic: