|
Use a #pragma directive to control the actions of the compiler in
a particular portion of a translation unit without affecting the
translation unit as a whole.
Put pragmas in your C++ source code where you want them to take effect. Unless otherwise noted below, a pragma is in effect from the point where it is included until the end of the translation unit or until another pragma changes its status.
Note:
This section discusses the following topics: |
||||
| Pragma Syntax | ||||
|
#pragma pragma-string pragma-string can be one of the following instructions to the compiler with any required parameters:
See Also: Pragmas for Improving Shared Library Performance
|
||||
| Initialization and Termination Pragmas | ||||
|
This section describes the INIT and FINI pragmas. These pragmas allow the user
to set up functions which are called when a load module (a shared library or
executable) is loaded (initializer) or unloaded (terminator).
For example, when a program begins execution, its initializers get called before any other user code gets called. This allows some set up work to take place. In addition, when the user’s program ends, the terminators can do some clean up. When a shared library is loaded or unloaded, its initializers and terminators are also executed at the appropriate time. INIT Pragma #pragma INIT string Use #pragma INIT to specify an initialization function. The function takes no arguments and returns nothing. The function specified by the INIT pragma is called before the program starts or when a shared library is loaded. Example:
#pragma INIT "my_init"
FINI Pragma #pragma FINI "string" Use #pragma FINI to specify a termination function. The function specified by the FINI pragma is called after the program terminates by either calling the libc exit() function, returning from the main() or _start() functions, or when the shared library, which contains the FINI is unloaded from memory. Like the function called by the INIT pragma, the termination function takes no arguments and returns nothing. Example:
#pragma FINI "my_fini"
|
||||
| Copyright Notice and Identification Pragmas | ||||
| The following pragmas can be used to insert strings in code.
COPYRIGHT Pragma #pragma COPYRIGHT "string" string is a set of characters included in the copyright message in the object file. COPYRIGHT pragma specifies a string to include in the copyright message and puts the copyright message into the object file. If no date is specified (using #pragma COPYRIGHT_DATE), the current year is used in the copyright message. For example, assuming the year is 2006, the directive #pragma COPYRIGHT "Acme Software" places the following string in the object code: (C) Copyright Acme Software, 2006. All rights reserved. No part of this program may be photocopied, reproduced, or transmitted without prior written consent of Acme Software. The following pragmas #pragma COPYRIGHT_DATE "1990-2006" #pragma COPYRIGHT "Brand X Software" place the following string in the object code: (C) Copyright Brand X Software, 1990-2006. All rights reserved. No part of this program may be photocopied, reproduced, or transmitted without prior written consent of Brand X Software.
COPYRIGHT_DATE Pragma #pragma COPYRIGHT_DATE string string is a date string used by the COPYRIGHT pragma. Specifies a date string to be included in the copyright message. Use the COPYRIGHT pragma to put the copyright message into the object file.
Example: #pragma COPYRIGHT_DATE "1988-1992" Places the string "1988-1992" in the copyright message. NOTE:To see the COPYRIGHT_DATE string as well as any other strings in the object file, use the strings(1) command with the -a option. For example: strings -a ObjectFileName.o LOCALITY Pragma #pragma LOCALITY "string" string specifies a name to be used for a code section. The LOCALITY pragma specifies a name to be associated with the code written to a relocatable object module. The string is forced to be upper case in C. All code following the LOCALITY pragma is associated with the name specified in string. Code that is not headed by a LOCALITY pragma is associated with the name .text. The smallest scope of a unique LOCALITY pragma is a function. For example, the directive, #pragma LOCALITY "MINE" builds the name .text.MINE and associates all code following this pragma with this name, unless another LOCALITY pragma is encountered.
LOCALITY_ALL Pragma #pragma LOCALITY_ALL string The LOCALITY_ALL pragma specifies a name to be associated with the linker procedures and global variables that should be grouped together at program binding or load time. These are written to a relocatable object module. All procedures and global variables following the LOCALITY_ALL pragma are associated with the name specified in the string.
VERSIONID Pragma #pragma VERSIONID "string" string is a string of characters that HP aC++ places in the object file. The VERSIONID pragma specifies a version string to be associated with a particular piece of code. The string is placed into the object file produced when the code is compiled. For example, the directive #pragma VERSIONID "Software Product, Version 12345.A.01.05" places the following characters into the object file. Software Product, Version 12345.A.01.05
|
||||
| Data Alignment Pragmas | ||||
|
This section discusses the following data alignment pragmas and their various arguments
available on the HP-UX systems to control alignment across platforms.
ALIGN Pragma #pragma align N N is a number raised to the power of 2. HP aC++ supports user specified alignment for global data. The pragma takes effect on next declaration. If the ALIGN pragma declaration is not in the global scope or if it is not a data declaration, the compiler displays a warning message. If the specified alignment is lesser than the original alignment of data, a warning message is displayed, and the pragma is ignored. Example: #pragma align 2 char c; // "c" is at least aligned on 2 byte boundary. #pragma align 64 int i, a[10]; // "i" and array "a" are at least aligned 64 byte boundary. // the size of "a" is still 10*sizeof(int) PACK Pragma #pragma PACK [n] n can be 1, 2, 4, 8, or 16 bytes. If n is not specified, maximum alignment is set to the default value. This file-scoped pragma allows you to specify the maximum alignment of class fields having non-class types. The alignment of the whole class is then computed as usual, to the alignment of the most aligned field in the class.
Note: The result of applying #pragma pack n to constructs other than class definitions (including struct definitions) is undefined and not supported. Example:
#pragma pack 1
int global_var; // Undefined behavior: not a class definition
void foo() { // Also undefined
}
The pack pragma may be useful when porting code between different
architectures where data type alignment and storage differences are of concern.
Refer to the following examples:
Basic Example The following example illustrates the pack pragma and shows that it has no effect on class fields unless the class itself was defined under the pragma.
struct S1 {
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S1)==12, alignment 4
#pragma pack 1
struct S2 {
char c1; // Offset 0, no padding
int i; // Offset 1, no padding
char c2; // Offset 5, no padding
}; // sizeof(S2)==6, alignment 1
// S3 and S4 show that the pragma does not affect class fields
// unless the class itself was defined under the pragma.
struct S3 {
char c1; // Offset 0, 3 bytes padding
S1 s; // Offset 4, no padding
char c2; // Offset 16, 3 bytes padding
}; // sizeof(S3)==20, alignment 4
struct S4 {
char c1; // Offset 0, no padding
S2 s; // Offset 1, no padding
char c2; // Offset 7, no padding
}; // sizeof(S4)==8, alignment 1
#pragma pack
struct S5 { // Same as S1
char c1; // Offset 0, 3 bytes padding
int i; // Offset 4, no padding
char c2; // Offset 8, 3 bytes padding
}; // sizeof(S5)==12, alignment 4
Template Example If the pragma is applied to a class template, every instantiation of that class is influenced by the pragma value in effect when the template was defined.
Note: The alignment of specializations and partial specializations of templates is undefined and unsupported if either the primary template or the specialization is under the influence of a #pragma pack directive.
#pragma pack 1
template<class T>
struct ST1 {
char c1;
T x;
char c2;
};
#pragma pack
ST1<int> obj; // Same layout as S2 in the prior example
template <> // Explicit specialization
struct ST1<void> {
char c1;
char c2;
}; // Undefined (unsupported) behavior
// ST1 was defined under a #pragma pack 1
// directive.
Handling Unaligned Data Direct access to unaligned class fields is handled automatically by HP aC++. However, this results in slower access times than for aligned data. Indirect access (through pointers and references) to unaligned class fields is also handled automatically. Note: If you take the address of a data field and assign it to a pointer, it is not handled automatically and is likely to result in premature termination of the program if not handled appropriately. Example:
#include <stdio.h>
#pragma pack 1
struct S1 {
char c1;
int i;
char c2;
};
#pragma pack
int main() {
S1 s;
S1 *p = &s;
printf("%d\n", s.i); // OK
printf("%d\n", p->i); // OK
int *ip = &p->i; // Undefined behavior
// Likely Abort unless compiled with +u1
// The address of a reference (*ip) is
// assigned to an int pointer.
printf("%d\n", *ip);
}
To enable indirect access to unaligned data that has been assigned to another type, use the following:
Implicit Access to Unaligned Data Calls to non-static member functions require that an implicit this pointer be passed to these functions, which can then indirectly access data through this implicit parameter. If such an access is to unaligned data, the situation in the prior Example 3 occurs. Furthermore, virtual function calls often require indirect access to a hidden field of a class that could be unaligned under the influence of the #pragma pack directive. If passing the address of a field to other code, consider the following example. Unless compiled with -DRECOVER on the command line and linked with -lhppa, hte following example is likely to prematurely terminate with a bus error. Example:
#include <stdio.h>
#ifdef RECOVER
extern "C" void allow_unaligned_data_access();
#endif
#pragma pack 1
struct PS1 {
PS1();
~PS1();
private:
char c;
int a;
};
#pragma pack
PS1::PS1(): a(1) { // There appears to be no pointer, but there
// is an unaligned access, possibly through "this."
printf("In constructor.\n");
}
PS1::~PS1() {
a = 0; // Misaligned access, possibly though "this"
printf("In destructor.\n");
}
int main() {
#if defined(RECOVER)
allow_unaligned_data_access();
#endif
PS1 s;
}
UNALIGN Pragma
#pragma unalign [1|2|4|8|16] T1 and T2 have the same size and layout, but with specified alignment requirements. HP aC++ supports misaligned data access using the UNALIGN pragma. The unalign pragma can be applied on typedef to define a type with special alignment. The unalign pragma takes effect only on next declaration. If the unalign pragma declaration is not in the global scope or if it is not a typedef, compiler displays a warning message. If the specified alignment is greater than the original alignment of the declaration, then an error message is displayed, and the pragma is ignored. Example:
#pragma unalign 1
typedef int ua_int; // ua_int is of int type with 1 byte alignment
typedef ua_int *ua_intPtr; // this typedef is not affected by above
// unalign pragma, it defines a pointer type
// which points to 1 byte aligned int
The interaction between pack and unalign pragmas is as follows:
#pragma pack 1
struct S {
char c;
int i;
};
#pragma pack 0
S s;
ua_int *ua_ip = &s.i; // ua_ip points to 1 byte aligned int
*ua_ip = 2; // mis-aligned access to 1 byte aligned int
Note:The HP_ALIGN pragma, which is supported by HP ANSI C compiler, is not supported by aCC. The pack and unalign pragmas can replace most of the HP_ALIGN functionality. VTABLE Pragma
key function's definition is found. The key function is the
first non-inline member function. This saves having to
generate the vtable in each compilation unit where the
class is used. However, in the case a class has no key function (not
uncommon) the vtable is forced to be generated in a The pragma is enabled with There are a number of such classes in the Example: // Use "--DEMIT_SELECTED_VTABLE" once for a set of compilation units
#ifndef EMIT_SELECTED_VTABLE
#pragma vtable OFF_IF_NO_KEY_BEGIN
#endif
class A {
virtual int f_A(); // key function -- vtable will be generated
// where f_a() is defined. pragma has no effect.
};
class B {
virtual int f_B() { return 0; } // not a key function: inline.
// The pragma inhibits generation of a vtable.
};
#ifndef EMIT_SELECTED_VTABLE
#pragma vtable OFF_IF_NO_KEY_END
#endif
CCurrently this pragma needs to explicitly turned by
setting the environment variable
aCC_ENABLE_VTBL_OMISSION to ON.
|
||||
| Optimization Pragmas | ||||
| The following optimization pragmas are supported in HP aC++: OPTIMIZE Pragma
#pragma OPTIMIZE ON This pragma is used to toggle optimization on/off for different sections of source code as these pragmas are encountered in a top to bottom read of a source file. Note: You must specify one of the optimization level options on the aCC command, otherwise this pragma is ignored. This pragma cannot be used within a function. Example:
aCC +O2 prog.C
#pragma OPTIMIZE OFF
void A(){ // Turn off optimization
... // for this function
}
#pragma OPTIMIZE ON
void B(){ // Restore optimization
... // to level 2.
}
OPT_LEVEL Pragma
#pragma OPT_LEVEL 0 The OPT_LEVEL pragma sets the optimization level to 0, 1, 2, 3, or 4. Note: You must specify one of the optimization level options on the aCC command, otherwise this pragma is ignored. This pragma cannot raise the optimization level above the level specified in the command line. This pragma cannot be used within a function. Example:
aCC -O prog.C
#pragma OPT_LEVEL 1
void A(){ // Optimize this function at level 1.
...
}
#pragma OPT_LEVEL 2
void B(){ // Restore optimization to level 2.
...
}
[NO]INLINE Pragma #pragma [NO]INLINE sym[, sym] The [NO]INLINE pragma enables[disables] inlining for all functions or specified functionname(s). Example: To specify inlining of the two subprograms checkstat and getinput, use: #pragma INLINE checkstat, getinput To specify that an infrequently called routine should not be inlined when compiling at optimization level 3 or 4, use: #pragma NOINLINE opendb Note: This pragma is supported in legacy HP C and C++ C-mode only. NO_INLINE Pragma #pragma NO_INLINE This is a synonym for #pragma NOINLINE. The NO_INLINE pragma disables inlining for all functions or specified functionname(s).
NO_SIDE EFFECTS Pragma #pragma NO_SIDE_EFFECTS functionname,..., functionnameN This pragma states that functionname and all the functions that function name calls will not modify any of a program's local or global variables. This pragma provides additional information to the optimizer which results in more efficient code. Example:
#pragma NO_SIDE_EFFECTS foo // where foo the name of a function. | ||||
| Shared Library Performance Pragmas | ||||
The pragmas described here can improve the performance of shared libraries by reducing the overhead of calling shared library routines. All three pragmas should be used together, where applicable, as they depend on one another to a certain extent. You must be very careful in using them because incorrect use can result in incorrect and unpredictable behavior. See the HP-UX Online Linker and Libraries User's Guidee #pragma HP_NO_RELOCATION name1[,name2,...nameN] name11 through nameN are names of functions in shared libraries. Note that C++ mangled names are not supported. Any named function:
Parameter relocation stubs are instructions that move (relocate) floating-point parameters and function return values between floating-point registers and general registers. They are generated for calls to routines in shared libraries. Relocation stubs are generated when passing floating-point parameters or using a floating-point function return in routines in shared libraries. The HP_NO_RELOCATION pragma prevents this unnecessary relocation. Put the HP_NO_RELOCATION pragma in header files of functions that take floating-point parameters or return floating-point data and that will be placed in shared libraries. Putting it in the header file and ensuring all calls reference the header file is one way to ensure that it is specified at the function definition and at all calls.This pragma is automatically supplied by HP aC++ for non-static member functions. NOTE: The HP_NO_RELOCATION pragma must be at the function definition and at all call sites. If the pragma is omitted from the function definition or from any call, the linker will generate parameter relocation code and the application will behave incorrectly since floating-point parameters will not be in expected registers. Do not use the HP_NO_RELOCATION pragma with functions that use the stdarg macros. See the stdargs(5) man page for information on stdargs macros. #pragma HP_LONG_RETURN name1[,name2,...nameN] name1nameN are names of functions in shared libraries. Note that C++ mangled names are not supported. Any named function:
An export stub is a short code segment generated by the linker for a global definition in a shared library. External calls to shared library functions go through the export stub. An export stub is generated by default for each function in a shared library. Each call to the function goes through the export stub. The export stub serves two purposes: to relocate parameters and perform an interspace return. The HP_LONG_RETURN pragma generates a long return sequence in the export stub instead of an interspace branch. If you also use the HP_NO_RELOCATION pragma (for functions taking floating-point parameters), all the code in the export stub is omitted, eliminating the export stub entirely. For functions taking non-floating-point parameters, the HP_LONG_RETURN pragma by itself eliminates the need for export stubs. Put this pragma in header files of functions that will go in shared libraries. Specify it at the function definition and at all calls. For functions with floating-point parameters or returns, use the HP_NO_RELOCATION pragma along with the HP_LONG_RETURN pragma.This pragma is automatically supplied by HP aC++ for non-static member functions. This pragma is not required if you compile on PA-RISC 2.0 or later or with the +DA2.0 option since the effect is the default. That is, if no relocations are generated, export stubs are not generated on PA-RISC 2.0 and later, and a long return instruction sequence is generated by default, so this pragma has no effect. NOTE: The HP_LONG_RETURN pragma must be at the function definition and at all call sites. If the pragma is omitted from the function definition or from any call, the compiler will generate incompatible return code and the application will behave incorrectly and likely abort. These pragmas improve performance of calls to shared library functions from outside the shared library. Therefore do not use this pragma for hidden functions (see the -h and +e linker options) nor for functions called only from within the same shared library linked with the -B symbolic linker option, otherwise this pragma may degrade performance. (See the HP-UX Online Linker and Libraries User's Guidee for information on the above mentioned options.) #pragma hdr_stopWhen you request header caching with the +hdr_cache option, this pragma specifies the end of the prefix header region. In a given source file, this pragma cannot be reset. It only allows the prefix header region to be shortened, not expanded. Also, there is no equivalent hdr_start pragma to alter the beginning of the prefix header region. If the #pragma hdr_stopp as the first line in each such header file. Another example might be useful when only a subset of
headers are undergoing code changes. You could place
these headers at the end of the list of Examples In the following example, using the default prefix header region, changes to any header file will cause a re-compile.#include <vector> // stable headers#include <list> #include <SuperBase> #include <IOBase> #include <Magikal> // headers you are changing #include <Util> // default END of prefix header region void poof();In the next example, by ending the prefix header region prior to the headers you are changing, a re-compile does not occur unless changes are made to a stable header file. #include <vector> // stable headers #include <list> #include <SuperBase> #include <IOBase> #pragma hdr_stop // END the prefix header region // prior to the default #include <Magikal> // headers you are changing #include <Util> void poof(); For More Information: Other Pragmas |
The following is a list of other pragmas in HP aC++: |
EXTERN Pragma #pragma EXTERN [symbol{,symbol}] The specified symbols, or all undefined symbols if no list is provided, are assigned to the default export class. Additionally, the compiler will inline the import stub for calls to these symbols. No compile time binding of these symbols will be done. All references to these symbols will be through the linkage table, so an unnecessary performance penalty will occur if extern is applied to a listed symbol that is resolved in the same load module. This is the pragma equivalent of -Bextern and is global in scope.
HP_DEFINED_EXTERNAL Pragma #pragma HP_DEFINED_EXTERNAL name1[,name2,...nameN] The specified symbols, or all undefined symbols (if no list is provided), are assigned to the default export class. Additionally, the compiler will inline the import stub for calls to these symbols. No compile time binding of these symbols will be done. All references to these symbols will be through the linkage table, so an unnecessary performance penalty will occur if extern is applied to a listed symbol that is resolved in the same load module. This is the pragma equivalent of the -Bextern option and is global in scope. This pragma is equivalent to the #pragma EXTERN.
HP_DEFINED_INTERNAL Pragma #pragma HP_DEFINED_INTERNAL name1[,name2,...nameN] The specified symbols, or all symbols (if no symbols are specified), are assigned the protected export class. That means these symbols will not be preempted by symbols from other load modules, so the compiler may bypass the linkage table for both code and data references and bind them to locally defined code and data symbols. This pragma is equivalent to the -Bprotected option and is global in scope. This pragma is equivalent to #pragma PROTECTED.
RARELY_CALLED Pragma #pragma RARELY_CALLED [symbol{,symbol}] This file-scoped pragma identifies functions that are rarely called within the application. The pragma must be placed prior to any definition of or reference to the named function. If not, the behavior is undefined. RARELY_CALLED pragma is independent of +Oprofile=use
UNROLL_FACTOR Pragma #pragma UNROLL_FACTOR n This block-scoped pragma applies the unroll factor for a loop containing the current block. You can apply an unroll factor, which you think is best for the given loop or apply no unroll factor to the loop. If this pragma is not specified, compiler uses its own heuristics to determine the best unroll factor for the inner loop. A user specified unroll factor will override the default unroll factor applied by the compiler. Specifying n=1 will prevent the compiler from unrolling the loop so as to form n copies of the original body. Specifying n=0 allows the compiler to use its own heuristics to apply the unroll factor. Note: UNROLL_FACTOR pragma will be ignored if it is placed in a loop other than the innermost loop. OMP ATOMIC Pragma
#pragma omp atomic where expression stmt must have one of the following forms:
OMP BARRIER Pragma #pragma omp barrier The barrier pragma synchronizes all the threads in a team. When encountered, each thread waits until all the threads in the team have reached that point. The smallest statement to contain a barrier must be a block or a compound statement. barrier is valid only inside a parallel region and outside the scope of for, section, sections, critical, ordered, and master.
OMP CRITICAL Pragma
#pragma omp critical [(name)] The critical pragma identifies a construct that restricts the execution of the associated structured block to one thread at a time. The name parameter is optional. All unnamed critical sections map to the same name.
OMP FOR Pragma
#pragma omp for [clause11,clause2, ...] [clause1, clause2, ...] indicates that the clauses are optional. There can be zero or more clauses. clause may be one of the following:
OMP FLUSH Pragma #pragma omp flush [(listt)] (list) names the variables that will be synchronized. The flush pragma, whether explicit or implied, specifies a cross-thread sequence point at which the implementation is required to ensure that all the threads in a team have a consistent view of certain objects in the memory. A flush directive without a list is implied for the following directives: T
Note:nowait clause is present.
OMP MASTER Pragma
#pragma omp master The master pragma directs that the structured block following it should be executed by the master thread (thread 00) of the team. Other threads in the team do not execute the associated block.
OMP ORDERED Pragma
#pragma omp ordered structured-block The ordered pragma indicates that the following structured block should be executed in the same order in which iterations will be executed in a sequential loop. An ordered directive must be within the dynamic extent of a for or a parallel for construct that has an ordered clause. When the ordered clause is used with schedule which has a chunksize, then the chunksize is ignored by the compiler.
OMP PARALLEL Pragma
#pragma omp parallel [clause11, clause2,...] [clause1, clause2, ...]private(list) See OpenMP Clauses for more information..
OMP PARALLEL FOR Pragma
#pragma omp parallel for [clause1, clause2, ... ] [clause1, clause2, ...] indicates that the clauses are optional. There can be zero or more clauses. The parallel for pragma is a shortcut for a parallel region that contains a single for pragma. parallel for admits all the allowable clauses of the parallel pragma and the for pragma except for the nowait clause.
OMP PARALLEL SECTIONS Pragma
#pragma omp parallel sections [clause1, clause2, ...]
{
[#pragma omp section ]
structured-block
[#pragma omp section
structured-block ]]
. . .
}
[clause1, clause2, ...] indicates that the clauses are optional. There can be zero or more clauses.
The
parallel sections admits all the allowable clauses of the parallel pragma and the sections pragma except for the nowait clause.
[clause1, clause2, ...] indicates that the clauses are optional. There can be zero or more clauses.
clause may be one of the following:
See OpenMP Clauses for more information.
#pragma omp single [clause1, clause2, . . .]
[clause1, clause2, ...] indicates that the clauses are optional.
There can be zero or more clauses.
clause may be one of the following: See OpenMP Clauses for more information.
#pragma omp threadprivate (list)
(list)) is a comma-separated list of variables that do not have an incomplete type.
The threadprivate
OpenMP Clauses |
Clauses on directives may be repeated as needed, subject to the restrictions
listed in the description of each clause. The order in which clauses appear in
directives is not significant. If variable-list appears in a clause, it must
specify only variables. |
The following is the list of clauses in OpenMP directives:
private private(list) The private clause declares the variables in the list to be private to each thread in a team. A new object with automatic storage duration is allocated within the associated structured block for each thread in the team.
firstprivate firstprivate(list) The firstprivate clause provides a superset of the functionality provided by the private clause. Variables specified in the list have private clause semantics described earlier. The new private object is initialized, as if there is an implied declaration inside the structured block and the initializer is the value of the original object.
lastprivate lastprivate(list) When lastprivate clause is specified in a loop or section, the value of the lastprivate variable from either the sequentially last iteration of the associated loop, or the lexically last section directive is assigned to the variable's original object. The lastprivate clause provides a superset of the functionality provided by the private clause. Variables specified in the list have private clause semantics described earlier.
copyprivate copyprivate(list) The copyprivate clause can be used to broadcast values acquired by a single thread directly to all instances of the privatee variables in the other threads. Note: The copyprivate clause can only appear on the single directive. if if(scalar-expression) The associated block of code will be executed in parallel if the scalar-expression evaluates to a non-zero value. Otherwise no parallelization happens and it is executed sequentially. Example:
#pragma omp parallel private(x) if (a>b) reduction(+:p)
{
// code to be parallelized only when a is greater than b
}
default default(shared|none) Specifying default(shared) clause is equivalent to explicitly listing each currently visible variable in a shared clause unless it is threadprivate or const-qualified. A variable referenced in the scope of default(none) should be explicitly qualified by a private or shared clause.
shared shared(list) The shared copyin copyin(list) The copyin clause copies the value of master thread's copy of a threadprivate variable to all other threads at the beginning of the parallel region. This clause can only be used with the parallel directive.
reduction reduction(op:list) The reduction clause performs a reduction on the scalar variables that appear in the list, with the operator op.
nowait nowait The nowait clause removes the implicit barrier synchronization at the end of a for or sections construct.
ordered ordered The ordered clause must be present when ordered directives bind to the for construct.
schedule(kind[,chunksize]) The schedule clause specifies how iterations of the for loop are divided among threads of the team. The kind of schedule can be any of:
num_threads num_threads(integer-expression) The num_threads clause allows a user to request a specific number of threads for a parallel construct. If the num_threads clause is present, then the value of integer-expressionn is the number of threads requested.
|