A P P E N D I X  B

Pragmas

This appendix describes the C++ compiler pragmas. A pragma is a compiler directive that allows you to provide additional information to the compiler. This information can change compilation details that are not otherwise under your control. For example, the pack pragma affects the layout of data within a structure. Compiler pragmas are also called directives.

The preprocessor keyword pragma is part of the C++ standard, but the form, content, and meaning of pragmas is different for every compiler. No pragmas are defined by the C++ standard.



Note - Code that depends on pragmas is not portable.




B.1 Pragma Forms

The various forms of a C++ compiler pragma are:


#pragma keyword
#pragma keyword ( a [ , a ] ...) [ , keyword ( a [ , a ] ...) ] ,... 
#pragma sun keyword

The variable keyword identifies the specific directive; a indicates an argument.

B.1.1 Overloaded Functions as Pragma Arguments

Several pragmas listed in this appendix take function names as arguments. In the event that the function is overloaded, the pragma uses the function declaration immediately preceding the pragma as its argument. Consider the following example:


int bar(int);
int foo(int);
int foo(double);
#pragma does_not_read_global_data(foo, bar)

In this example, foo means foo(double), the declaration of foo immediately preceding the pragma, and bar means bar(int), the only declared bar. Now, consider this following example in which foo is again overloaded:


int foo(int);
int foo(double);
int bar(int);
#pragma does_not_read_global_data(foo, bar)

In this example, bar means bar(int), the only declared bar.However, the pragma will not know which version of foo to use. To correct this problem, you must place the pragma immediately following the definition of foo that you want the pragma to use.

The following pragmas use the selection method described in this section:


B.2 Pragma Reference

This section describes the pragma keywords that are recognized by the C++ compiler.

Makes the parameter variables memory-aligned to a specified number of bytes, overriding the default.

Asserts that the specified list of functions do not read global data directly or indirectly.

Asserts to the compiler that the calls to the specified functions will not return.

Asserts that the specified list of functions do not write global data directly or indirectly.

Provides information regarding the use of macros in code.

Marks the end of a dump_macros pragma.

Marks a specified function as a finalization function.

Identifies the end of the viable source prefix for precompiled headers.

Places a specified string in the .comment section of the executable.

Marks a specified function as an initialization function.

Indicates that a function does not change any persistent state.

Controls the layout of structure offsets. The value of n is a number--0, 1, 2, 4, or 8--that specifies the worst-case alignment desired for any structure member.

Indicates to the compiler that the specified functions are rarely called.

Asserts that each named function returns the address of newly allocated memory and that the pointer does not alias with any other pointer.

Specifies a list of routines that violate the usual control flow properties of procedure calls.

Defines weak symbol bindings.

B.2.1 #pragma align


#pragma align integer(variable [,variable...])

Use align to make the listed variables memory-aligned to integer bytes, overriding the default. The following limitations apply:

When #pragma align is used inside a namespace, mangled names must be used. For example, in the following code, the #pragma align statement will have no effect. To correct the problem, replace a, b, and c in the #pragma align statement with their mangled names.


namespace foo {
    #pragma align 8 (a, b, c)
    static char a;
    static char b;
    static char c;
}

B.2.2 #pragma does_not_read_global_data


#pragma does_not_read_global_data(funcname [, funcname])

This pragma asserts that the specified routines do not read global data directly or indirectly. This allows for better optimization of code around calls to such routines. In particular, assignment statements or stores could be moved around such calls.

This pragma is permitted only after the prototype for the specified functions are declared. If the assertion about global access is not true, then the behavior of the program is undefined.

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.3 #pragma does_not_return


#pragma does_not_return(funcname [, funcname])

This pragma is an assertion to the compiler that the calls to the specified routines will not return. This allows the compiler to perform optimizations consistent with that assumption. For example, register life-times terminate at the call sites which in turn allows more optimizations.

If the specified function does return, then the behavior of the program is undefined.

This pragma is permitted only after the prototype for the specified functions are declared as the following example shows:


extern void exit(int);
#pragma does_not_return(exit)
 
extern void __assert(int);
#pragma does_not_return(__assert)

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.4 #pragma does_not_write_global_data


#pragma does_not_write_global_data(funcname [, funcname])

This pragma asserts that the specified list of routines do not write global data directly or indirectly. This allows for better optimization of code around calls to such routines. In particular, assignment statements or stores could be moved around such calls.

This pragma is permitted only after the prototype for the specified functions are declared. If the assertion about global access is not true, then the behavior of the program is undefined.

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.5 #pragma dumpmacros


#pragma dumpmacros (value[,value...])

Use this pragma when you want to see how macros are behaving in your program. This pragma provides information such as macro defines, undefines, and instances of usage. It prints output to the standard error (stderr) based on the order macros are processed. The dumpmacros pragma is in effect through the end of the file or until it reaches a #pragma end_dumpmacro. See Section B.2.6, #pragma end_dumpmacros. You can substitute the following arguments in place of value:


Value

Meaning

defs

Print all macro defines

undefs

Print all macro undefines

use

Print information about the macros used

loc

Print location (path name and line number) also for defs, undefs, and use

conds

Print use information for macros used in conditional directives

sys

Print all macros defines, undefines, and use information for macros in system header files




Note - The sub-options loc, conds, and sys are qualifiers for defs, undefs and use options. By themselves,loc, conds, and sys have no effect. For example, #pragma dumpmacros=loc,conds,sys has no effect.



The dumpmacros pragma has the same effect as the command line option, however, the pragma overrides the command line option. See Section A.2.118, -xdumpmacros[=value[,value...]].

The dumpmacros pragma does not nest so the following lines of code stop printing macro information when the #pragma end_dumpmacros is processed:


#pragma dumpmacros (defs, undefs)
#pragma dumpmacros (defs, undefs)
...
#pragma end_dumpmacros

The effect of the dumpmacros pragma is cumulative. The following lines


#pragma dumpmacros(defs, undefs)
#pragma dumpmacros(loc)

have the same effect as


#pragma dumpmacros(defs, undefs, loc)

If you use the option #pragma dumpmacros=use,no%loc, the name of each macro that is used is printed only once. If you use the option #pragma dumpmacros=use,loc the location and macro name is printed every time a macro is used.

B.2.6 #pragma end_dumpmacros


#pragma end_dumpmacros

This pragma marks the end of a dumpmacros pragma and stops printing information about macros. If you do not use an end_dumpmacros pragma after a dumpmacros pragma, the dumpmacros pragma continues to generate output through the end of the file.

B.2.7 #pragma fini


#pragma fini (identifier[,identifier...]) 

Use fini to mark identifier as a finalization function. Such functions are expected to be of type void, to accept no arguments, and to be called either when a program terminates under program control or when the containing shared object is removed from memory. As with initialization functions, finalization functions are executed in the order processed by the link editor.

In a source file, the functions specified in #pragma fini are executed after the static destructors in that file. You must declare the identifiers before using them in the pragma.

B.2.8 #pragma hdrstop

Embed the hdrstop pragma in your source-file headers to identify the end of the viable source prefix. For example, consider the following files:


example% cat a.cc
#include "a.h"
#include "b.h"
#include "c.h"
#include <stdio.h>
#include "d.h"
.
.
.
example% cat b.cc
#include "a.h"
#include "b.h"
#include "c.h"

The viable source prefix ends at c.h so you would insert a #pragma hdrstop after c.h in each file.

#pragma hdrstop must only appear at the end of the viable prefix of a source file that is specified with the CC command. Do not specify #pragma hdrstop in any include file.

See Section A.2.150, -xpch=v and Section A.2.151, -xpchstop=file.

B.2.9 #pragma ident


#pragma ident string 

Use ident to place string in the .comment section of the executable.

B.2.10 #pragma init


#pragma init(identifier[,identifier...])

Use init to mark identifier as an initialization function. Such functions are expected to be of type void, to accept no arguments, and to be called while constructing the memory image of the program at the start of execution. Initializers in a shared object are executed during the operation that brings the shared object into memory, either at program start up or during some dynamic loading operation, such as dlopen(). The only ordering of calls to initialization functions is the order in which they are processed by the link editors, both static and dynamic.

Within a source file, the functions specified in #pragma init are executed after the static constructors in that file. You must declare the identifiers before using them in the pragma.

B.2.11 #pragma no_side_effect


#pragma no_side_effect(name[,name...])

Use no_side_effect to indicate that a function does not change any persistent state. The pragma declares that the named functions have no side effects of any kind. This means that the functions return result values that depend on the passed arguments only. In addition, the functions and their called descendants:

The compiler can use this information when doing optimizations.

If the function does have side effects, the results of executing a program which calls this function are undefined.

The name argument specifies the name of a function within the current translation unit. The pragma must be in the same scope as the function and must appear after the function declaration. The pragma must be before the function definition.

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.12 #pragma opt


#pragma opt level (funcname[, funcname])

funcname specifies the name of a function defined within the current translation unit. The value of level specifies the optimization level for the named function. You can assign optimization levels 0, 1, 2, 3, 4, 5. You can turn off optimization by setting level to 0. The functions must be declared with a prototype or empty parameter list prior to the pragma. The pragma must proceed the definitions of the functions to be optimized.

The level of optimization for any function listed in the pragma is reduced to the value of -xmaxopt. The pragma is ignored when -xmaxopt=off.

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.13 #pragma pack(n)


#pragma pack([n]) 

Use pack to affect the packing of structure members.

If present, n must be 0 or a power of 2. A value of other than 0 instructs the compiler to use the smaller of n-byte alignment and the platform's natural alignment for the data type. For example, the following directive causes the members of all structures defined after the directive (and before subsequent pack directives) to be aligned no more strictly than on 2-byte boundaries, even if the normal alignment would be on 4- or 8-byte boundaries.


#pragma pack(2)

When n is 0 or omitted, the member alignment reverts to the natural alignment values.

If the value of n is the same as or greater than the strictest alignment on the platform, the directive has the effect of natural alignment. The following table shows the strictest alignment for each platform.


TABLE B-1 Strictest Alignment by Platform

Platform

Strictest Alignment

x86

4

SPARC generic, V7, V8, V8a, V8plus, V8plusa, V8plusb

8

SPARC V9, V9a, V9b

16


A pack directive applies to all structure definitions which follow it, until the next pack directive. If the same structure is defined in different translation units with different packing, your program may fail in unpredictable ways. In particular, you should not use a pack directive prior to including a header defining the interface of a precompiled library. The recommended usage is to place the pack directive in your program code, immediately before the structure to be packed, and to place #pragma pack() immediately after the structure.

When using #pragma pack on a SPARC platform to pack denser than the type's default alignment, the -misalign option must be specified for both the compilation and the linking of the application. The following table shows the storage sizes and default alignments of the integral data types.


TABLE B-2 Storage Sizes and Default Alignments in Bytes

Type

SPARC V8

Size, Alignment

SPARC V9

Size, Alignment

x86

Size, Alignment

bool

1, 1

1, 1

1, 1

char

1, 1

1, 1

1, 1

short

2, 2

2, 2

2, 2

wchar_t

4, 4

4, 4

4, 4

int

4, 4

4, 4

4, 4

long

4, 4

8, 8

4, 4

float

4, 4

4, 4

4, 4

double

8, 8

8, 8

8, 4

long double

16, 8

16, 16

12, 4

pointer to data

4, 4

8, 8

4, 4

pointer to function

4, 4

8, 8

4, 4

pointer to member data

4, 4

8, 8

4, 4

pointer to member function

8, 4

16, 8

8, 4


B.2.14 #pragma rarely_called


#pragms rarely_called(funcname[, funcname])

This pragma provides a hint to the compiler that the specified functions are called infrequently. This allows the compiler to perform profile-feedback style optimizations on the call-sites of such routines without the overhead of a profile-collections phase. Since this pragma is a suggestion, the compiler may not perform any optimizations based on this pragma.

The #pragma rarely_called preprocessor directive is only permitted after the prototype for the specified functions are declares. The following is an example of #pragma rarely_called:


extern void error (char *message);
#pragma rarely_called(error)

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.15 #pragma returns_new_memory


#pragma returns_new_memory(name[,name...])

This pragma asserts that each named function returns the address of newly allocated memory and that the pointer does not alias with any other pointer. This information allows the optimizer to better track pointer values and to clarify memory location. This results in improved scheduling and pipelining.

If the assertion is false, the results of executing a program which calls this function are undefined.

The name argument specifies the name of a function within the current translation unit. The pragma must be in the same scope as the function and must appear after the function declaration. The pragma must be before the function definition.

For a more detailed explanation of how the pragma treats overloaded function names as arguments, see Section B.1.1, Overloaded Functions as Pragma Arguments.

B.2.16 #pragma unknown_control_flow


#pragma unknown_control_flow(name[,name...]) 

Use unknown_control_flow to specify a list of routines that violate the usual control flow properties of procedure calls. For example, the statement following a call to setjmp() can be reached from an arbitrary call to any other routine. The statement is reached by a call to longjmp().

Because such routines render standard flowgraph analysis invalid, routines that call them cannot be safely optimized; hence, they are compiled with the optimizer disabled.

If the function name is overloaded, the most recently declared function is chosen.

B.2.17 #pragma weak


#pragma weak name1 [= name2]

Use weak to define a weak global symbol. This pragma is used mainly in source files for building libraries. The linker does not warn you if it cannot resolve a weak symbol.

The weak pragma can specify symbols in one of two forms:

#pragma weak name

In the form #pragma weak name, the directive makes name a weak symbol. The linker will not complain if it does not find a symbol definition for name. It also does not complain about multiple weak definitions of the symbol. The linker simply takes the first one it encounters.

If another compilation unit has a strong definition for the function or variable, name will be linked to that. If there is no strong definition for name, the linker symbol will have a value of 0.

The following directive defines ping to be a weak symbol. No error messages are generated if the linker cannot find a definition for a symbol named ping.


#pragma weak ping

#pragma weak name1 = name2

In the form #pragma weak name1 = name2, the symbol name1 becomes a weak reference to name2. If name1 is not defined elsewhere, name1 will have the value name2. If name1 is defined elsewhere, the linker uses that definition and ignores the weak reference to name2. The following directive instructs the linker to resolve any references to bar if it is defined anywhere in the program, and to foo otherwise.


#pragma weak bar = foo

In the identifier form, name2 must be declared and defined within the current compilation unit. For example:


extern void bar(int) {...}
extern void _bar(int);
#pragma weak _bar=bar

When you use the string form, the symbol does not need to be previously declared. If both _bar and bar in the following example are extern "C", the functions do not need to be declared. However, bar must be defined in the same object.


extern "C" void bar(int) {...}
#pragma weak "_bar" = "bar"

Overloading Functions

When you use the identifier form, there must be exactly one function with the specified name in scope at the pragma location. Attempting to use the identifier form of #pragma weak with an overloaded function is an error. For example:


int bar(int);
float bar(float);
#pragma weak bar        // error, ambiguous function name

To avoid the error, use the string form, as shown in the following example.


int bar(int);
float bar(float);
#pragma weak "__1cDbar6Fi_i_" // make float bar(int) weak

See the Solaris Linker and Libraries Guide for more information.