3.1.1. Pragmas

The ARM compiler recognizes pragmas of the following form:


#pragma [no_]feature-name

Note

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

Pragma nameDefaultReference
anon_unionsOffPragmas controlling anonymous structures and unions
armPragmas controlling code generation
arm sectionOffPragmas controlling code generation
thumbPragmas controlling code generation
diag_defaultPragmas controlling diagnostic messages
diag_errorPragmas controlling diagnostic messages
diag_remarkPragmas controlling diagnostic messages
diag_suppressPragmas controlling diagnostic messages
diag_warningPragmas controlling diagnostic messages
[no_]exceptions_unwindPragmas controlling code generation
hdrstopPragmas controlling PCH processing
importPragmas controlling code generation
no_pchPragmas controlling PCH processing
oncePragmas controlling code generation
OnumPragmas controlling multiple optimizations
OspacePragmas controlling multiple optimizations
OtimePragmas controlling multiple optimizations
popPragmas for saving and restoring the pragma state
pushPragmas for saving and restoring the pragma state
[no_]softfp_linkageOffPragmas controlling code generation

Pragmas for saving and restoring the pragma state

The following pragmas enable you to save and restore the pragma state:

push

Saves the current pragma state.

pop

Restores the previously saved pragma state.

Pragmas controlling multiple optimizations

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):

Onum

Changes optimization level. The value of num is 0, 1, 2 or 3.

Ospace

Optimizes for space.

Otime

Optimizes for time.

Pragmas controlling code generation

The following pragmas control how code is generated (other code generation options are available from the compiler command line, see Controlling code generation):

arm

Switches code generation to the ARM instruction set. This pragma overrides the --thumb compiler option.

thumb

Switches 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_unwind

Enables or disables function unwinding at runtime. See Function unwinding at runtime for more details.

once

When 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 symbol_name. This is the same as the assembler directive:


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_list

Specifies 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 name is the name to use for the section, and sort_type is one of:

  • code

  • rodata

  • rwdata

  • zidata.

If sort_type is specified but name is not, the section name for sort_type is reset to the default value. Enter #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).

Pragmas controlling PCH processing

The following pragmas control PCH processing:

hdrstop

Enables 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_pch

Suppresses PCH processing for a given source file.

See Precompiled header files for a detailed description of PCH files.

Pragmas controlling anonymous structures and unions

The following pragma controls the use of anonymous structures and unions:

anon_unions

Enables support for anonymous structures and unions. See Anonymous classes, structures and unions for more details.

Pragmas controlling diagnostic messages

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).

Copyright © 2002-2006 ARM Limited. All rights reserved.ARM DUI 0205G
Non-Confidential