TABLE 17

–xcache Values

Value

Meaning

generic

Define the cache properties for good performance on most

processors without any major performance degradation.

This is the default.

native

Define the cache properties for good performance on this

host platform.

s1/l1/a1[/t1]

Define level 1 cache properties.

s1/l1/a1[/t1]:s2/l2/a2[/t2]

Define levels 1 and 2 cache properties.

s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]

Define levels 1, 2, and 3 cache properties

The si/li/ai/ti fields are defined as follows:

si

The size of the data cache at level i, in kilobytes

li

The line size of the data cache at level i, in bytes

ai

The associativity of the data cache at level i

ti

The number of hardware threads sharing the cache at level i (optional)

keyword

Feature

stkovf[action]

Generate code to detect stack overflow errors at runtime, optionally specifying an

action to be taken when a stack overflow error is detected.

A stack overflow error occurs when a thread's stack pointer is set beyond the thread's

allocated stack bounds. The error may not be detected if the new top of stack address is

writable.

A stack overflow error is detected if a memory access violation occurs as a direct result

of the error, raising an associated signal (usually SIGSEGV). The signal thus raised is

said to be associated with the error.

keyword

Feature

If -xcheck=stkovf[action] is specified, the compiler generates code to detect stack

overflow errors in cases involving stack frames larger than the system page size. The

code includes a library call to force a memory access violation instead of setting the

stack pointer to an invalid but potentially mapped address (see _stack_grow(3C)).

The optional action, if specified, must be either :detect or :diagnose.

If action is :detect, a detected stack overflow error is handled by executing the signal

handler normally associated with the error.

On Oracle Solaris SPARC, -xcheck=stkovf:detect is enabled by default. This

prevents silent corruption of the stack due to stack overflow. It can be disabled by

specifying -xcheck=no%stkovf.

If action is :diagnose, a detected stack overflow error is handled by catching the

associated signal and calling stack_violation(3C) to diagnose the error. This is the

default behavior if no action is specified.

If a memory access violation is diagnosed as a stack overflow error, the following

message is printed to stderr:

ERROR: stack overflow detected: pc=<inst_addr>, sp=<sp_addr>

where <inst_addr> is the address of the instruction where the error was detected, and

<sp_addr> is the value of the stack pointer at the time that the error was detected. After

checking for stack overflow and printing the above message if appropriate, control

passes to the signal handler normally associated with the error.

-xcheck=stkovf:detect adds a stack bounds check on entry to routines with stack

frames larger than system page size (see _stack_grow(3C)). The relative cost of the

additional bounds check should be negligible in most applications.

-xcheck=stkovf:diagnose adds a system call to thread creation (see sigaltstack(2)).

The relative cost of the additional system call depends on how frequently the

application creates and destroys new threads.

-xcheck=stkovf is supported only on Oracle Solaris. The C runtime library on Oracle

Linux does not support stack overflow detection.

no%stkovf

Disable runtime checking for stack overflow.

init_local

Perform special initialization of local variables.

The compiler initializes local variables to a value that is likely to cause an arithmetic

exception if it is used by the program before it is assigned. Memory allocated by the

ALLOCATE statement will also be initialized in this manner.

Module variables, STATIC and SAVE local variables, and variables in COMMON blocks are

not initialized.

Exercise caution when using -xcheck with a large amount of local data, such as arrays

with more than 10,000 elements. This can cause the compiler's internal representation

of the program to become very large when that local date is initialized, which can result

in significantly longer compilation times, especially when combined with optimization

levels greater than -02.

Chapter 3 • Fortran Compiler Options

113