| |||
| Home > ARM Compiler Reference > Compiler-specific features > Pragmas | |||
The ARM compiler recognizes pragmas of the following form:
#pragma [no_]feature-name
Pragmas override related command-line options. For example, #pragma
arm overrides the --thumb command-line
option.
Table 3.1 lists the ARM compiler pragmas. The following sections describe these pragmas in more detail.
Table 3.1. Pragmas recognized by the ARM compiler
The following pragmas enable you to save and restore the pragma state:
pushSaves the current pragma state.
popRestores the previously saved pragma state.
These pragmas enable you to assign multiple optimizations on individual functions. The pragmas must be placed outside of a function, and you cannot apply more than one of these optimizations on a function. The following pragmas control these optimizations (see Multi-optimization options for more information):
OnumChanges optimization level. The value of is 0, 1, 2 or
3.num
OspaceOptimizes for space.
OtimeOptimizes for time.
The following pragmas control how code is generated (other code generation options are available from the compiler command line, see Controlling code generation):
armSwitches code generation to the ARM instruction
set. This pragma overrides the --thumb compiler
option.
thumbSwitches code generation to the Thumb® instruction set. This
pragma overrides the --arm compiler option.
If you are compiling code for a pre-Thumb-2 processor and using VFP, any function containing floating-point operations is compiled for ARM.
exceptions_unwind no_exceptions_unwindEnables or disables function unwinding at runtime. See Function unwinding at runtime for more details.
onceWhen this is placed at the beginning of a header file, it indicates that the header file has been written in a way that including it several times has the same effect as including it once. Therefore, the compiler skips any subsequent includes of that file.
Typically, you place a #ifndef guard around
the body of the file, with a #define of the guard
variable after the #ifndef, for example:
#ifndef FILE_H
#define FILE_H
#pragma once // optional
... body of the header file ...
#endif
The #pragma once is marked as optional
in this example. This is because the compiler recognizes the #ifndef header
guard coding and skips subsequent includes even if #pragma
once is absent.
#pragma once is accepted for compatibility
with other compilers, and enables you to use other forms of header
guard coding. However, it is preferable to use #ifndef and #define coding
because this is more portable.
softfp_linkage no_softfp_linkage#pragma softfp_linkage asserts
that all function declarations up to the next #pragma no_softfp_linkage describe
functions that use software floating-point linkage. The __softfp keyword
has the same effect (see Function keywords). The pragma form can be useful when applied
to an entire interface specification (header file) without altering that
file.
import(symbol_name)Generates an importing reference to .
This is the same as the assembler directive:symbol_name
IMPORT symbol_name
The symbol name is placed in the symbol table of the image as an external symbol. It is otherwise unused. You must not define the symbol or make a reference to it.
You can use this pragma to select certain features of the C library, such as the heap implementation or real-time division. If a feature described in this book requires a symbol reference to be imported, the required symbol is specified. For an example, see Avoiding semihosting.
arm section section_sort_listSpecifies that the Code or Data section name is used for subsequent functions or objects. This includes definitions of anonymous objects the compiler creates for initializations. The option has no effect on:
inline functions (and their local static variables)
template instantiations (and their local static variables)
elimination of unused variables and functions. (Although,
using #pragma arm section might enable the linker
to eliminate a function or variable that would otherwise be kept
because it is in the same section as a used function or variable.)
the order that definitions are written to the object file.
The full syntax for the pragma is:
#pragma arm section [sort_type[[=]"name"]] [,sort_type="name"]*
Where is
the name to use for the section, and name is
one of:sort_type
code
rodata
rwdata
zidata.
If is
specified but sort_type is
not, the section name for name is reset
to the default value. Enter sort_type#pragma arm section on
its own to restore the names of all object sections to their defaults (see Example 3.1).
Example 3.1. Section naming
int x1 = 5; // in .data (default)
int y1[100]; // in .bss (default)
int const z1[3] = {1,2,3}; // in .constdata (default)
#pragma arm section rwdata = "foo", rodata = "bar"
int x2 = 5; // in foo (data part of region)
int y2[100]; // in .bss
int const z2[3] = {1,2,3}; // in bar
char *s2 = "abc"; // s2 in foo, "abc" in .conststring
#pragma arm section rodata
int x3 = 5; // in foo
int y3[100]; // in .bss
int const z3[3] = {1,2,3}; // in .constdata
char *s3 = "abc"; // s3 in foo, "abc" in .conststring
#pragma arm section code = "foo"
int add1(int x) // in foo (code part of region)
{
return x+1;
}
#pragma arm section code
As an alternative to #pragma arm section,
use GNU __attribute__((section(..))) for functions
or variables, as described in Function attributes.
Use a scatter-loading description file with the ARM linker to control how to place a named section at a particular address in memory (see the chapter Using Scatter-loading description files in RealView Compilation Tools v3.0 Linker and Utilities Guide).
The following pragmas control PCH processing:
hdrstopEnables you to specify where the set of header files subject to precompilation ends.
This must appear before the first token that does not belong to a preprocessing directive.
no_pchSuppresses PCH processing for a given source file.
See Precompiled header files for a detailed description of PCH files.
The following pragma controls the use of anonymous structures and unions:
anon_unionsEnables support for anonymous structures and unions. See Anonymous classes, structures and unions for more details.
The following pragmas control the output of the diagnostic
messages that have a -D postfix in the message
number:
diag_default tag[, tag,
...]Returns the severity of a diagnostic message to the one that was in effect before any pragmas were issued (that is, the normal severity of the message as modified by any command-line options).
diag_error tag[, tag,
...]Sets the diagnostic messages that have the specified tag(s) to Error severity.
diag_remark tag[, tag,
...]Sets the diagnostic messages that have the specified tag(s) to Remark severity.
diag_suppress tag[, tag,
...]Disables all diagnostic messages that have the specified tag(s).
diag_warning tag[, tag,
...]Sets the diagnostic messages that have the specified tag(s) to Warning severity.
For example, a Warning message might be displayed:
Warning: #550-D: variable "b" was set but never used
If you want to lower this warning to a remark, specify:
#pragma diag_remark 550
By default, the compiler does not display remarks. To see
the remark messages, use the --remarks compiler
option (see Controlling the output
of diagnostic messages).