NoteThe options in this group enable you to control the computation of stacks and variables in the compiler generated code.
-auto
The -auto option specifies that locally declared variables are allocated to the run-time stack rather than static storage. If variables defined in a procedure appear in an AUTOMATIC statement, or if the procedure is recursive and the variables 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 is the same as -automatic and -nosave.
-auto 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.
If you specify -recursive or -openmp, the default is -auto.
The -auto_scalar option causes 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.
-auto_scalar 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, which causes all local variables to be allocated on the stack. The difference is that -auto_scalar allocates only scalar variables of the stated above intrinsic types to the stack.
-auto_scalar enables the compiler to make better choices about which variables should be kept in registers during program execution.
The -save option is opposite of -auto: the -save 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 terminated. This may cause a performance degradation and may change the output of your program for floating-point values as it forces operations to be carried out in memory rather than in registers, which in turn causes more frequent rounding of your results. -save is the same as -noauto.
The -[no]zero 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. The default is -nozero.
There are three choices for allocating variables: -save, -auto, and -auto_scalar. Only one of these three can be specified. The correlation among them is as follows:
-save disables -auto, sets -noautomatic, and allocates all variables not marked AUTOMATIC to static memory.
-auto disables -save, sets -automatic, and allocates all variables—scalars and arrays of all types—not marked SAVE to the stack.
-auto_scalar:
It makes local scalars of intrinsic types INTEGER, REAL, COMPLEX, and LOGICAL automatic.
This is the default; there is no -noauto_scalar; however, -recursive or -openmp disables -auto_scalar and makes -auto the default.
The -fpstkchk option (IA-32 only) 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.
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 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 overflow.
The overflow of the stack results in two undesirable situations:
a NAN value gets involved in the floating-point calculations
the program results become unpredicatble; the point where the program starts making errors can be arbitrarily far away from the point of the actual error.
The -fpstkchk option marks the incorrect call and makes it easy to find the error.
NoteThis 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.
The -common_args option assumes that the "by-reference" subprogram arguments may have aliases of one another.
Option -safe_cray_ptr specifies that the CRAY* pointers do not alias with other variables. The default is OFF.
Consider the following example.
|
pointer (pb, b) |
When -safe_cray_ptr is not specified (default), 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 option produces incorrect result. For the code example below, -safe_cray_ptr should not be used.
|
pb = loc(a(2)) |
The -ansi_alias[-] enables (default) or disables 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:
Arrays are not accessed out of arrays' bounds.
Pointers are not cast to non-pointer types and vice-versa.
References to objects of two different scalar types cannot alias. For example, an object of type integer cannot alias with an object of type real or an object of type real cannot alias with an object of type double precision.
If your program satisfies the above conditions, setting the -ansi_alias 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.
The synonym of -ansi_alias is -assume [no]dummy_aliases.