2.8. Pragmas¶
The following pragmas are supported by the tiarmclang compiler:
2.8.1. clang attribute push/pop¶
The clang attribute push and clang attribute pop pragmas apply an attribute to multiple declarations. An attribute can be pushed to or popped from the scope of the specified declarations. The scopes can be nested using multiple push directives.
Syntax
#pragma clang attribute push (__attribute__((<attribute_name>)), apply_to = <match_scope>)
#pragma clang attribute pop
Example
The following use of the clang attribute push and clang attribute pop pragmas causes the enclosed variables to have the noinit attribute.
#pragma clang attribute push([[used]], apply_to = any(record, enum, function))
enum myEnum { ABC, XYZ }; // The enum has the used attribute
struct myRecord { }; // The struct has the used attribute
void myFunction(); // The function has the used attribute
#pragma clang attribute pop
enum otherEnum { LMN, OPQ }; // The enum does not have the used attribute
See Specifying an attribute for multiple declarations in the Clang documentation for details and examples, including a list of supported match scopes and how to use a namespace to distinguish the push directive to which a pop directive applies.
2.8.2. clang diagnostic¶
The clang diagnostic pragma provides run-time control over which diagnostics are enabled and their severity levels. See Diagnostic Options for diagnostic-related command-line options that can be controlled with this pragma.
You can nest diagnostic behavior with the clang diagnostic push and clang diagnostic pop pragmas, but these pragmas must be used in pairs.
The GCC diagnostic pragma is functionally a synonym for the clang diagnostic pragma when using the tiarmclang compiler.
Syntax
#pragma clang diagnostic ignored "-W<option>"
#pragma clang diagnostic warning "-W<option>"
#pragma clang diagnostic error "-W<option>"
#pragma clang diagnostic fatal "-W<option>"
#pragma clang diagnostic push
#pragma clang diagnostic pop
Example
The following clang diagnostic ignored pragma causes warnings about extra tokens in a preprocessor directive to be ignored.
#pragma clang diagnostic ignored "-Wextra-tokens"
The following clang diagnostic warning pragma changes errors about implicit function declarations to warnings.
#pragma clang diagnostic warning "-Wimplicit-function-declaration"
See Controlling Diagnostics via Pragmas in the Clang documentation for further details and examples.
2.8.3. clang section text¶
The clang section text pragma places enclosed functions within a named section, which can then be placed with the linker using a linker command file.
Syntax
#pragma clang section text=”scn_name”
The setting is reset to the default section name using
#pragma clang section text=””
Example
The following use of the clang section text pragma causes the enclosed function to be included in a section called .text.functions
#include <stdio.h>
#pragma clang section text=".text.functions"
int main() {
emit_msg();
emit_msg();
emit_msg();
}
#pragma clang section text=""
2.8.4. clang section data¶
The clang section data pragma places enclosed variables within a named section, which can then be placed with the linker using a linker command file.
Syntax
#pragma clang section data=”scn_name”
The setting is reset to the default section name using
#pragma clang section data=””
Example
The following use of the clang section data pragma causes the enclosed variables to be included in a section called .data.variables
#include <stdio.h>
#pragma clang section data=".data.variables"
int var1 = 39;
char *myString = "this is a test";
#pragma clang section data=""
extern void func(int, char*);
int main() {
func(var1, myString);
}
Note
Variables that are not initialized with a constant expression are not defined in .data
For example, in the above example, if either of the var1 or myString definitions were uninitialized, then they would not be defined in .data.variables. They would instead be defined in .bss.var1 and/or .bss.myString”.
2.8.5. clang section bss¶
The clang section bss pragma places enclosed variables within a named section, which can then be placed with the linker using a linker command file.
Syntax
#pragma clang section bss=”scn_name”
The setting is reset to the default section name using
#pragma clang section bss=””
Example
The following use of the clang section bss pragma causes the definition of myString to be included in a section called .bss.variables
#include <stdio.h>
#pragma clang section bss=".bss.variables"
int var1 = 39;
char *myString;
#pragma clang section bss=""
extern void init_myString(const char*);
extern void func(int, char*);
int main() {
init_myString("hello world");
func(var1, myString);
}
Note
Variables that are initialized with a constant expression are not defined in .bss
For example, in the above example, myString is defined in .bss.variables, but var1 is defined in .data.var1 since it is initialized with a constant expression.
2.8.6. clang section rodata¶
The clang section rodata pragma places enclosed variables within a named section, which can then be placed with the linker using a linker command file.
Syntax
#pragma clang section rodata=”scn_name”
The setting is reset to the default section name using
#pragma clang section rodata=””
Example
The following use of the clang section rodata pragma causes the enclosed const qualified data object definitions to be included in a section called MyRodata
#include <stdio.h>
#pragma clang section rodata="MyRodata"
const int var1 = 39;
const char *myString = "this is a test";
#pragma clang section rodata=""
extern void func(const int, const char*);
int main() {
func(var1, myString);
}
Note
A General Note About clang section Pragmas
In general, only variable definitions that match the type of the preceding #pragma clang section <type>=”scn_name” are affected by that clang section pragma.
You can specify more than one section type in a clang section pragma. For example,
#pragma clang section bss="myBSS" data="myData" rodata="myRodata"
int x2 = 5; // Goes in myData section.
int y2; // Goes in myBss section.
const int z2 = 42; // Goes in myRodata section.
If you were to turn off the clang section rodata between definitions of const qualified data objects:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata"
int x2 = 5; // Goes in myData section.
int y2; // Goes in myBss section.
const int z2 = 42; // Goes in myRodata section.
#pragma clang section rodata="" // Use default name for rodata section.
int x3 = 5; // Goes in myData section.
int y3; // Goes in myBss section.
const int z3 = 42; // Goes in .rodata section
Note that z3 is not defined in myBSS or myData because it does not match the bss or data type specified in the first clang section pragma.
2.8.7. clang deprecated¶
The clang deprecated pragma identifies a macro as deprecated and provides a message to be output when compiling code that uses the deprecated macro.
Syntax
#pragma clang deprecated(MACRO, “message”)
Example
The following use of the clang deprecated pragma causes the specified error message to be output when compiling.
#define X 0
#define NEW_X 1
#pragma clang deprecated(X, "Macro X deprecated, use NEW_X instead")
int foo() { return NEW_X; } // This use of NEW_X is fine
int main() { return X + foo(); } // This use of X is deprecated
See deprecated for an example that uses the deprecated attribute to mark a variable as deprecated.