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

-auto (Linux*) and /Qauto (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.

-auto (Linux*) or /Qauto (Windows*) is the same as -nosave (Linux) or /automatic (Windows).

-auto (Linux) or /Qauto (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*) 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) 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 /Qauto (Windows) which causes all local variables to be allocated on the stack. The difference is that -auto-scalar (Linux) 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 -auto-scalar (Linux) or /Qauto-scalar (Windows), you would have to have more than 32K bytes of local scalar variables before you incurred the performance penalty.

-auto-scalar (Linux) 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*) or /Qsave, /Qzero[-] (Windows*)

The -save (Linux) or /Qsave (Windows) option is opposite of -auto (Linux) or /Qauto (Windows). The -save (Linux) 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 (Linux) or /Qsave (Windows) 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: -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) 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) 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 the Floating-point Stack State

When an application calls a function that returns a floating-point value, the returned floating-point value is supposed to be on the top of the floating-point stack. If the return value is not used, the compiler must pop the value off of the floating-point stack in order to keep the floating-point stack in correct state.

If the application calls a function, either without defining or incorrectly defining the function's prototype, the compiler does not know whether the function must return a floating-point value, and the return value is not popped off of the floating-point stack if it is not used. This can cause the floating-point stack to overflow.

The overflow of the stack results in two undesirable situations:

For IA-32 and Intel® EM64T systems, the -fpstkchk (Linux) or /Qfpstkchk (Windows) option checks whether a program makes a correct call to a function that should return a floating-point value. If an incorrect call is detected, the option places a code that marks the incorrect call in the program. The -fpstkchk (Linux) or /Qfpstkchk (Windows) option marks the incorrect call and makes it easy to find the error.

Note

This option causes significant code generation after every function/subroutine call to insure a proper state of a floating-point stack and slows down compilation. It is meant only as a debugging aid for finding floating point stack underflow/overflow problems, which can be otherwise hard to find.

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) or /Qcommon-args (Windows) option assumes that the "by-reference" subprogram arguments may have aliases of one another.

Preventing CRAY* Pointer Aliasing

Option -safe-cray-ptr (Linux) 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) 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

See common-args in Compiler Options.

Cross Platform

The -ansi-alias (Linux) 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: