Terminology¶

Front end, parser, backend, preprocessor, undefined behavior, diagnostic, optimizer

Basic Usage¶

Intro to how to use a C compiler for newbies.

compile + link compile then link debug info enabling optimizations picking a language to use, defaults to C11 by default. Autosenses based on extension. using a makefile

Options to Control Error and Warning Messages¶

-Werror¶

Turn warnings into errors.

-Werror=foo

Turn warning “foo” into an error.

-Wno-error=foo¶

Turn warning “foo” into a warning even if -Werror is specified.

-Wfoo¶

Enable warning “foo”. See the diagnostics reference for a complete list of the warning flags that can be specified in this way.

-Wno-foo¶

Disable warning “foo”.

-w¶

Disable all diagnostics.

-Weverything¶

Enable all diagnostics.

-pedantic¶

Warn on language extensions.

-pedantic-errors¶

Error on language extensions.

-Wsystem-headers¶

Enable warnings from system headers.

-ferror-limit=123¶

Stop emitting diagnostics after 123 errors have been produced. The default is 20, and the error limit can be disabled with -ferror-limit=0.

-ftemplate-backtrace-limit=123¶

Only emit up to 123 template instantiation notes within the template instantiation backtrace for a single warning or error. The default is 10, and the limit can be disabled with -ftemplate-backtrace-limit=0.

Options to Control Clang Crash Diagnostics¶

As unbelievable as it may sound, Clang does crash from time to time. Generally, this only occurs to those living on the bleeding edge. Clang goes to great lengths to assist you in filing a bug report. Specifically, Clang generates preprocessed source file(s) and associated run script(s) upon a crash. These files should be attached to a bug report to ease reproducibility of the failure. Below are the command line options to control the crash diagnostics.

-fno-crash-diagnostics¶

Disable auto-generation of preprocessed source files during a clang crash.

The -fno-crash-diagnostics flag can be helpful for speeding the process of generating a delta reduced test case.

Clang is also capable of generating preprocessed source file(s) and associated run script(s) even without a crash. This is specially useful when trying to generate a reproducer for warnings or errors while using modules.

-gen-reproducer¶

Generates preprocessed source files, a reproducer script and if relevant, a cache containing: built module pcm’s and all headers needed to rebuilt the same modules.

Options to Emit Optimization Reports¶

Optimization reports trace, at a high-level, all the major decisions done by compiler transformations. For instance, when the inliner decides to inline function foo() into bar(), or the loop unroller decides to unroll a loop N times, or the vectorizer decides to vectorize a loop body.

Clang offers a family of flags which the optimizers can use to emit a diagnostic in three cases:

1. When the pass makes a transformation (-Rpass).
2. When the pass fails to make a transformation (-Rpass-missed).
3. When the pass determines whether or not to make a transformation (-Rpass-analysis).

NOTE: Although the discussion below focuses on -Rpass, the exact same options apply to -Rpass-missed and -Rpass-analysis.

Since there are dozens of passes inside the compiler, each of these flags take a regular expression that identifies the name of the pass which should emit the associated diagnostic. For example, to get a report from the inliner, compile the code with:

$ clang -O2 -Rpass=inline code.cc -o code
code.cc:4:25: remark: foo inlined into bar [-Rpass=inline]
int bar(int j) { return foo(j, j - 2); }
                        ^

Note that remarks from the inliner are identified with [-Rpass=inline]. To request a report from every optimization pass, you should use -Rpass=.* (in fact, you can use any valid POSIX regular expression). However, do not expect a report from every transformation made by the compiler. Optimization remarks do not really make sense outside of the major transformations (e.g., inlining, vectorization, loop optimizations) and not every optimization pass supports this feature.

Note that when using profile-guided optimization information, profile hotness information can be included in the remarks (see -fdiagnostics-show-hotness).

Other Options¶

Clang options that don’t fit neatly into other categories.

-MV¶

When emitting a dependency file, use formatting conventions appropriate for NMake or Jom. Ignored unless another option causes Clang to emit a dependency file.

When Clang emits a dependency file (e.g., you supplied the -M option) most filenames can be written to the file without any special formatting. Different Make tools will treat different sets of characters as “special” and use different conventions for telling the Make tool that the character is actually part of the filename. Normally Clang uses backslash to “escape” a special character, which is the convention used by GNU Make. The -MV option tells Clang to put double-quotes around the entire filename, which is the convention used by NMake and Jom.

Configuration files¶

Configuration files group command-line options and allow all of them to be specified just by referencing the configuration file. They may be used, for example, to collect options required to tune compilation for particular target, such as -L, -I, -l, –sysroot, codegen options, etc.

The command line option –config can be used to specify configuration file in a Clang invocation. For example:

clang --config /home/user/cfgs/testing.txt
clang --config debug.cfg

If the provided argument contains a directory separator, it is considered as a file path, and options are read from that file. Otherwise the argument is treated as a file name and is searched for sequentially in the directories:

• user directory,
• system directory,
• the directory where Clang executable resides.

Both user and system directories for configuration files are specified during clang build using CMake parameters, CLANG_CONFIG_FILE_USER_DIR and CLANG_CONFIG_FILE_SYSTEM_DIR respectively. The first file found is used. It is an error if the required file cannot be found.

Another way to specify a configuration file is to encode it in executable name. For example, if the Clang executable is named armv7l-clang (it may be a symbolic link to clang), then Clang will search for file armv7l.cfg in the directory where Clang resides.

If a driver mode is specified in invocation, Clang tries to find a file specific for the specified mode. For example, if the executable file is named x86_64-clang-cl, Clang first looks for x86_64-cl.cfg and if it is not found, looks for x86_64.cfg.

If the command line contains options that effectively change target architecture (these are -m32, -EL, and some others) and the configuration file starts with an architecture name, Clang tries to load the configuration file for the effective architecture. For example, invocation:

x86_64-clang -m32 abc.c

causes Clang search for a file i368.cfg first, and if no such file is found, Clang looks for the file x86_64.cfg.

The configuration file consists of command-line options specified on one or more lines. Lines composed of whitespace characters only are ignored as well as lines in which the first non-blank character is #. Long options may be split between several lines by a trailing backslash. Here is example of a configuration file:

# Several options on line
-c --target=x86_64-unknown-linux-gnu

# Long option split between lines
-I/usr/lib/gcc/x86_64-linux-gnu/5.4.0/../../../../\
include/c++/5.4.0

# other config files may be included
@linux.options

Files included by @file directives in configuration files are resolved relative to the including file. For example, if a configuration file ~/.llvm/target.cfg contains the directive @os/linux.opts, the file linux.opts is searched for in the directory ~/.llvm/os.

Controlling Errors and Warnings¶

Clang provides a number of ways to control which code constructs cause it to emit errors and warning messages, and how they are displayed to the console.

#pragma GCC diagnostic ignored "-Wall"

#if foo
#endif foo // warning: extra tokens at end of #endif directive

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wextra-tokens"

#if foo
#endif foo // no warning

#pragma clang diagnostic pop

// The following will produce warning messages
#pragma message "some diagnostic message"
#pragma GCC warning "TODO: replace deprecated feature"

// The following will produce an error message
#pragma GCC error "Not supported"

#define STR(X) #X
#define DEFER(M,...) M(__VA_ARGS__)
#define CUSTOM_ERROR(X) _Pragma(STR(GCC error(X " at line " DEFER(STR,__LINE__))))

CUSTOM_ERROR("Feature not available");

#if foo
#endif foo // warning: extra tokens at end of #endif directive

#pragma clang system_header

#if foo
#endif foo // no warning

$ clang -Ifoo -isystem bar --system-header-prefix=x/ \
    --no-system-header-prefix=x/y/

Precompiled Headers¶

Precompiled headers are a general approach employed by many compilers to reduce compilation time. The underlying motivation of the approach is that it is common for the same (and often large) header files to be included by multiple source files. Consequently, compile times can often be greatly improved by caching some of the (redundant) work done by a compiler to process headers. Precompiled header files, which represent one of many ways to implement this optimization, are literally files that represent an on-disk cache that contains the vital information necessary to reduce some of the work needed to process a corresponding header file. While details of precompiled headers vary between compilers, precompiled headers have been shown to be highly effective at speeding up program compilation on systems with very large system headers (e.g., Mac OS X).

$ gcc -x c-header test.h -o test.h.gch
$ clang -x c-header test.h -o test.h.pch

$ clang -include test.h test.c -o test

$ clang -x c-header test.h -o test.h.pch
$ cat test.c
#include "test.h"
$ clang test.c -o test

# clang -x c-header --relocatable-pch -isysroot /path/to/build /path/to/build/mylib.h mylib.h.pch

Controlling Code Generation¶

Clang provides a number of ways to control code generation. The options are listed below.

-f[no-]sanitize=check1,check2,…

Turn on runtime checks for various forms of undefined or suspicious behavior.

This option controls whether Clang adds runtime checks for various forms of undefined or suspicious behavior, and is disabled by default. If a check fails, a diagnostic message is produced at runtime explaining the problem. The main checks are:

• -fsanitize=address: AddressSanitizer, a memory error detector.

• -fsanitize=thread: ThreadSanitizer, a data race detector.

• -fsanitize=memory: MemorySanitizer, a detector of uninitialized reads. Requires instrumentation of all program code.

• -fsanitize=undefined: UndefinedBehaviorSanitizer, a fast and compatible undefined behavior checker.

• -fsanitize=dataflow: DataFlowSanitizer, a general data flow analysis.
• -fsanitize=cfi: control flow integrity checks. Requires -flto.
• -fsanitize=safe-stack: safe stack protection against stack-based memory corruption errors.

There are more fine-grained checks available: see the list of specific kinds of undefined behavior that can be detected and the list of control flow integrity schemes.

The -fsanitize= argument must also be provided when linking, in order to link to the appropriate runtime library.

It is not possible to combine more than one of the -fsanitize=address, -fsanitize=thread, and -fsanitize=memory checkers in the same program.

-f[no-]sanitize-recover=check1,check2,…

-f[no-]sanitize-recover=all

Controls which checks enabled by -fsanitize= flag are non-fatal. If the check is fatal, program will halt after the first error of this kind is detected and error report is printed.

By default, non-fatal checks are those enabled by UndefinedBehaviorSanitizer, except for -fsanitize=return and -fsanitize=unreachable. Some sanitizers may not support recovery (or not support it by default e.g. AddressSanitizer), and always crash the program after the issue is detected.

Note that the -fsanitize-trap flag has precedence over this flag. This means that if a check has been configured to trap elsewhere on the command line, or if the check traps by default, this flag will not have any effect unless that sanitizer’s trapping behavior is disabled with -fno-sanitize-trap.

For example, if a command line contains the flags -fsanitize=undefined -fsanitize-trap=undefined, the flag -fsanitize-recover=alignment will have no effect on its own; it will need to be accompanied by -fno-sanitize-trap=alignment.

-f[no-]sanitize-trap=check1,check2,…

Controls which checks enabled by the -fsanitize= flag trap. This option is intended for use in cases where the sanitizer runtime cannot be used (for instance, when building libc or a kernel module), or where the binary size increase caused by the sanitizer runtime is a concern.

This flag is only compatible with control flow integrity schemes and UndefinedBehaviorSanitizer checks other than vptr. If this flag is supplied together with -fsanitize=undefined, the vptr sanitizer will be implicitly disabled.

This flag is enabled by default for sanitizers in the cfi group.

-fsanitize-blacklist=/path/to/blacklist/file¶

Disable or modify sanitizer checks for objects (source files, functions, variables, types) listed in the file. See Sanitizer special case list for file format description.

-fno-sanitize-blacklist¶

Don’t use blacklist file, if it was specified earlier in the command line.

-f[no-]sanitize-coverage=[type,features,…]

Enable simple code coverage in addition to certain sanitizers. See SanitizerCoverage for more details.

-f[no-]sanitize-stats

Enable simple statistics gathering for the enabled sanitizers. See SanitizerStats for more details.

-fsanitize-undefined-trap-on-error¶

Deprecated alias for -fsanitize-trap=undefined.

-fsanitize-cfi-cross-dso¶

Enable cross-DSO control flow integrity checks. This flag modifies the behavior of sanitizers in the cfi group to allow checking of cross-DSO virtual and indirect calls.

-fsanitize-cfi-icall-generalize-pointers¶

Generalize pointers in return and argument types in function type signatures checked by Control Flow Integrity indirect call checking. See Control Flow Integrity for more details.

-fstrict-vtable-pointers¶

Enable optimizations based on the strict rules for overwriting polymorphic C++ objects, i.e. the vptr is invariant during an object’s lifetime. This enables better devirtualization. Turned off by default, because it is still experimental.

-ffast-math¶

Enable fast-math mode. This defines the __FAST_MATH__ preprocessor macro, and lets the compiler make aggressive, potentially-lossy assumptions about floating-point math. These include:

• Floating-point math obeys regular algebraic rules for real numbers (e.g. + and * are associative, x/y == x * (1/y), and (a + b) * c == a * c + b * c),
• operands to floating-point operations are not equal to NaN and Inf, and
• +0 and -0 are interchangeable.

-fdenormal-fp-math=[values]¶

Select which denormal numbers the code is permitted to require.

Valid values are: ieee, preserve-sign, and positive-zero, which correspond to IEEE 754 denormal numbers, the sign of a flushed-to-zero number is preserved in the sign of 0, denormals are flushed to positive zero, respectively.

-fwhole-program-vtables¶

Enable whole-program vtable optimizations, such as single-implementation devirtualization and virtual constant propagation, for classes with hidden LTO visibility. Requires -flto.

-fno-assume-sane-operator-new¶

Don’t assume that the C++’s new operator is sane.

This option tells the compiler to do not assume that C++’s global new operator will always return a pointer that does not alias any other pointer when the function returns.

-ftrap-function=[name]¶

Instruct code generator to emit a function call to the specified function name for __builtin_trap().

LLVM code generator translates __builtin_trap() to a trap instruction if it is supported by the target ISA. Otherwise, the builtin is translated into a call to abort. If this option is set, then the code generator will always lower the builtin to a call to the specified function regardless of whether the target ISA has a trap instruction. This option is useful for environments (e.g. deeply embedded) where a trap cannot be properly handled, or when some custom behavior is desired.

-ftls-model=[model]¶

Select which TLS model to use.

Valid values are: global-dynamic, local-dynamic, initial-exec and local-exec. The default value is global-dynamic. The compiler may use a different model if the selected model is not supported by the target, or if a more efficient model can be used. The TLS model can be overridden per variable using the tls_model attribute.

-femulated-tls¶

Select emulated TLS model, which overrides all -ftls-model choices.

In emulated TLS mode, all access to TLS variables are converted to calls to __emutls_get_address in the runtime library.

-mhwdiv=[values]¶

Select the ARM modes (arm or thumb) that support hardware division instructions.

Valid values are: arm, thumb and arm,thumb. This option is used to indicate which mode (arm or thumb) supports hardware division instructions. This only applies to the ARM architecture.

-m[no-]crc¶

Enable or disable CRC instructions.

This option is used to indicate whether CRC instructions are to be generated. This only applies to the ARM architecture.

CRC instructions are enabled by default on ARMv8.

-mgeneral-regs-only¶

Generate code which only uses the general purpose registers.

This option restricts the generated code to use general registers only. This only applies to the AArch64 architecture.

-mcompact-branches=[values]¶

Control the usage of compact branches for MIPSR6.

Valid values are: never, optimal and always. The default value is optimal which generates compact branches when a delay slot cannot be filled. never disables the usage of compact branches and always generates compact branches whenever possible.

-f[no-]max-type-align=[number]

Instruct the code generator to not enforce a higher alignment than the given number (of bytes) when accessing memory via an opaque pointer or reference. This cap is ignored when directly accessing a variable or when the pointee type has an explicit “aligned” attribute.

The value should usually be determined by the properties of the system allocator. Some builtin types, especially vector types, have very high natural alignments; when working with values of those types, Clang usually wants to use instructions that take advantage of that alignment. However, many system allocators do not promise to return memory that is more than 8-byte or 16-byte-aligned. Use this option to limit the alignment that the compiler can assume for an arbitrary pointer, which may point onto the heap.

This option does not affect the ABI alignment of types; the layout of structs and unions and the value returned by the alignof operator remain the same.

This option can be overridden on a case-by-case basis by putting an explicit “aligned” alignment on a struct, union, or typedef. For example:

#include <immintrin.h>
// Make an aligned typedef of the AVX-512 16-int vector type.
typedef __v16si __aligned_v16si __attribute__((aligned(64)));

void initialize_vector(__aligned_v16si *v) {
  // The compiler may assume that ‘v’ is 64-byte aligned, regardless of the
  // value of -fmax-type-align.
}

Profile Guided Optimization¶

Profile information enables better optimization. For example, knowing that a branch is taken very frequently helps the compiler make better decisions when ordering basic blocks. Knowing that a function foo is called more frequently than another function bar helps the inliner.

Clang supports profile guided optimization with two different kinds of profiling. A sampling profiler can generate a profile with very low runtime overhead, or you can build an instrumented version of the code that collects more detailed profile information. Both kinds of profiles can provide execution counts for instructions in the code and information on branches taken and function invocation.

Regardless of which kind of profiling you use, be careful to collect profiles by running your code with inputs that are representative of the typical behavior. Code that is not exercised in the profile will be optimized as if it is unimportant, and the compiler may make poor optimization choices for code that is disproportionately used while profiling.

function1:total_samples:total_head_samples
 offset1[.discriminator]: number_of_samples [fn1:num fn2:num ... ]
 offset2[.discriminator]: number_of_samples [fn3:num fn4:num ... ]
 ...
 offsetN[.discriminator]: number_of_samples [fn5:num fn6:num ... ]
 offsetA[.discriminator]: fnA:num_of_total_samples
  offsetA1[.discriminator]: number_of_samples [fn7:num fn8:num ... ]
  offsetA1[.discriminator]: number_of_samples [fn9:num fn10:num ... ]
  offsetB[.discriminator]: fnB:num_of_total_samples
   offsetB1[.discriminator]: number_of_samples [fn11:num fn12:num ... ]

main:35504:0
1: _Z3foov:35504
  2: _Z32bari:31977
  1.1: 31977
2: 0

Controlling Debug Information¶

Comment Parsing Options¶

Clang parses Doxygen and non-Doxygen style documentation comments and attaches them to the appropriate declaration nodes. By default, it only parses Doxygen-style comments and ignores ordinary comments starting with // and /*.

-Wdocumentation¶

Emit warnings about use of documentation comments. This warning group is off by default.

This includes checking that \param commands name parameters that actually present in the function signature, checking that \returns is used only on functions that actually return a value etc.

-Wno-documentation-unknown-command¶

Don’t warn when encountering an unknown Doxygen command.

-fparse-all-comments¶

Parse all comments as documentation comments (including ordinary comments starting with // and /*).

-fcomment-block-commands=[commands]¶

Define custom documentation commands as block commands. This allows Clang to construct the correct AST for these custom commands, and silences warnings about unknown commands. Several commands must be separated by a comma without trailing space; e.g. -fcomment-block-commands=foo,bar defines custom commands \foo and \bar.

It is also possible to use -fcomment-block-commands several times; e.g. -fcomment-block-commands=foo -fcomment-block-commands=bar does the same as above.

Extensions supported by clang¶

See Clang Language Extensions.

Differences between various standard modes¶

clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c94, c99, gnu99, c11, gnu11, and various aliases for those modes. If no -std option is specified, clang defaults to gnu11 mode. Many C99 and C11 features are supported in earlier modes as a conforming extension, with a warning. Use -pedantic-errors to request an error if a feature from a later standard revision is used in an earlier mode.

Differences between all c* and gnu* modes:

• c* modes define “__STRICT_ANSI__”.
• Target-specific defines not prefixed by underscores, like “linux”, are defined in gnu* modes.
• Trigraphs default to being off in gnu* modes; they can be enabled by the -trigraphs option.
• The parser recognizes “asm” and “typeof” as keywords in gnu* modes; the variants “__asm__” and “__typeof__” are recognized in all modes.
• The Apple “blocks” extension is recognized by default in gnu* modes on some platforms; it can be enabled in any mode with the “-fblocks” option.
• Arrays that are VLA’s according to the standard, but which can be constant folded by the frontend are treated as fixed size arrays. This occurs for things like “int X[(1, 2)];”, which is technically a VLA. c* modes are strictly compliant and treat these as VLAs.

Differences between *89 and *99 modes:

• The *99 modes default to implementing “inline” as specified in C99, while the *89 modes implement the GNU version. This can be overridden for individual functions with the __gnu_inline__ attribute.
• Digraphs are not recognized in c89 mode.
• The scope of names defined inside a “for”, “if”, “switch”, “while”, or “do” statement is different. (example: “if ((struct x {int x;}*)0) {}”.)
• __STDC_VERSION__ is not defined in *89 modes.
• “inline” is not recognized as a keyword in c89 mode.
• “restrict” is not recognized as a keyword in *89 modes.
• Commas are allowed in integer constant expressions in *99 modes.
• Arrays which are not lvalues are not implicitly promoted to pointers in *89 modes.
• Some warnings are different.

Differences between *99 and *11 modes:

• Warnings for use of C11 features are disabled.
• __STDC_VERSION__ is defined to 201112L rather than 199901L.

c94 mode is identical to c89 mode except that digraphs are enabled in c94 mode (FIXME: And __STDC_VERSION__ should be defined!).

GCC extensions not implemented yet¶

clang tries to be compatible with gcc as much as possible, but some gcc extensions are not implemented yet:

• clang does not support decimal floating point types (_Decimal32 and friends) or fixed-point types (_Fract and friends); nobody has expressed interest in these features yet, so it’s hard to say when they will be implemented.

• clang does not support nested functions; this is a complex feature which is infrequently used, so it is unlikely to be implemented anytime soon. In C++11 it can be emulated by assigning lambda functions to local variables, e.g:

  auto const local_function = [&](int parameter) {
    // Do something
  };
  ...
  local_function(1);
  

• clang only supports global register variables when the register specified is non-allocatable (e.g. the stack pointer). Support for general global register variables is unlikely to be implemented soon because it requires additional LLVM backend support.

• clang does not support static initialization of flexible array members. This appears to be a rarely used extension, but could be implemented pending user demand.

• clang does not support __builtin_va_arg_pack/__builtin_va_arg_pack_len. This is used rarely, but in some potentially interesting places, like the glibc headers, so it may be implemented pending user demand. Note that because clang pretends to be like GCC 4.2, and this extension was introduced in 4.3, the glibc headers will not try to use this extension with clang at the moment.

• clang does not support the gcc extension for forward-declaring function parameters; this has not shown up in any real-world code yet, though, so it might never be implemented.

This is not a complete list; if you find an unsupported extension missing from this list, please send an e-mail to cfe-dev. This list currently excludes C++; see C++ Language Features. Also, this list does not include bugs in mostly-implemented features; please see the bug tracker for known existing bugs (FIXME: Is there a section for bug-reporting guidelines somewhere?).

Intentionally unsupported GCC extensions¶

• clang does not support the gcc extension that allows variable-length arrays in structures. This is for a few reasons: one, it is tricky to implement, two, the extension is completely undocumented, and three, the extension appears to be rarely used. Note that clang does support flexible array members (arrays with a zero or unspecified size at the end of a structure).
• clang does not have an equivalent to gcc’s “fold”; this means that clang doesn’t accept some constructs gcc might accept in contexts where a constant expression is required, like “x-x” where x is a variable.
• clang does not support __builtin_apply and friends; this extension is extremely obscure and difficult to implement reliably.

Microsoft extensions¶

clang has support for many extensions from Microsoft Visual C++. To enable these extensions, use the -fms-extensions command-line option. This is the default for Windows targets. Clang does not implement every pragma or declspec provided by MSVC, but the popular ones, such as __declspec(dllexport) and #pragma comment(lib) are well supported.

clang has a -fms-compatibility flag that makes clang accept enough invalid C++ to be able to parse most Microsoft headers. For example, it allows unqualified lookup of dependent base class members, which is a common compatibility issue with clang. This flag is enabled by default for Windows targets.

-fdelayed-template-parsing lets clang delay parsing of function template definitions until the end of a translation unit. This flag is enabled by default for Windows targets.

For compatibility with existing code that compiles with MSVC, clang defines the _MSC_VER and _MSC_FULL_VER macros. These default to the values of 1800 and 180000000 respectively, making clang look like an early release of Visual C++ 2013. The -fms-compatibility-version= flag overrides these values. It accepts a dotted version tuple, such as 19.00.23506. Changing the MSVC compatibility version makes clang behave more like that version of MSVC. For example, -fms-compatibility-version=19 will enable C++14 features and define char16_t and char32_t as builtin types.

Controlling implementation limits¶

-fbracket-depth=N¶

Sets the limit for nested parentheses, brackets, and braces to N. The default is 256.

-fconstexpr-depth=N¶

Sets the limit for recursive constexpr function invocations to N. The default is 512.

-ftemplate-depth=N¶

Sets the limit for recursively nested template instantiations to N. The default is 256.

-foperator-arrow-depth=N¶

Sets the limit for iterative calls to ‘operator->’ functions to N. The default is 256.

Controlling implementation limits¶

-fopenmp-use-tls¶

Controls code generation for OpenMP threadprivate variables. In presence of this option all threadprivate variables are generated the same way as thread local variables, using TLS support. If -fno-openmp-use-tls is provided or target does not support TLS, code generation for threadprivate variables relies on OpenMP runtime library.

OpenCL Specific Options¶

Most of the OpenCL build options from the specification v2.0 section 5.8.4 are available.

Examples:

$ clang -cl-std=CL2.0 -cl-single-precision-constant test.cl

Some extra options are available to support special OpenCL features.

-finclude-default-header¶

Loads standard includes during compilations. By default OpenCL headers are not loaded and therefore standard library includes are not available. To load them automatically a flag has been added to the frontend (see also the section on the OpenCL Header):

$ clang -Xclang -finclude-default-header test.cl

Alternatively -include or -I followed by the path to the header location can be given manually.

$ clang -I<path to clang>/lib/Headers/opencl-c.h test.cl

In this case the kernel code should contain #include <opencl-c.h> just as a regular C include.

-cl-ext¶

Disables support of OpenCL extensions. All OpenCL targets provide a list of extensions that they support. Clang allows to amend this using the -cl-ext flag with a comma-separated list of extensions prefixed with '+' or '-'. The syntax: -cl-ext=<(['-'|'+']<extension>[,])+>, where extensions can be either one of the OpenCL specification extensions or any known vendor extension. Alternatively, 'all' can be used to enable or disable all known extensions. Example disabling double support for the 64-bit SPIR target:

$ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl

Enabling all extensions except double support in R600 AMD GPU can be done using:

$ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl

-ffake-address-space-map¶

Overrides the target address space map with a fake map. This allows adding explicit address space IDs to the bitcode for non-segmented memory architectures that don’t have separate IDs for each of the OpenCL logical address spaces by default. Passing -ffake-address-space-map will add/override address spaces of the target compiled for with the following values: 1-global, 2-constant, 3-local, 4-generic. The private address space is represented by the absence of an address space attribute in the IR (see also the section on the address space attribute).

$ clang -ffake-address-space-map test.cl

Some other flags used for the compilation for C can also be passed while compiling for OpenCL, examples: -c, -O<1-4|s>, -o, -emit-llvm, etc.

OpenCL Targets¶

OpenCL targets are derived from the regular Clang target classes. The OpenCL specific parts of the target representation provide address space mapping as well as a set of supported extensions.

OpenCL Header¶

By default Clang will not include standard headers and therefore OpenCL builtin functions and some types (i.e. vectors) are unknown. The default CL header is, however, provided in the Clang installation and can be enabled by passing the -finclude-default-header flag to the Clang frontend.

$ echo "bool is_wg_uniform(int i){return get_enqueued_local_size(i)==get_local_size(i);}" > test.cl
$ clang -Xclang -finclude-default-header -cl-std=CL2.0 test.cl

Because the header is very large and long to parse, PCH (Precompiled Header and Modules Internals) and modules (Modules) are used internally to improve the compilation speed.

To enable modules for OpenCL:

$ clang -target spir-unknown-unknown -c -emit-llvm -Xclang -finclude-default-header -fmodules -fimplicit-module-maps -fmodules-cache-path=<path to the generated module> test.cl

OpenCL Extensions¶

All of the cl_khr_* extensions from the official OpenCL specification up to and including version 2.0 are available and set per target depending on the support available in the specific architecture.

It is possible to alter the default extensions setting per target using -cl-ext flag. (See flags description for more details).

Vendor extensions can be added flexibly by declaring the list of types and functions associated with each extensions enclosed within the following compiler pragma directives:

#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end

For example, parsing the following code adds my_t type and my_func function to the custom my_ext extension.

#pragma OPENCL EXTENSION my_ext : begin
typedef struct{
  int a;
}my_t;
void my_func(my_t);
#pragma OPENCL EXTENSION my_ext : end

Declaring the same types in different vendor extensions is disallowed.

OpenCL Metadata¶

Clang uses metadata to provide additional OpenCL semantics in IR needed for backends and OpenCL runtime.

Each kernel will have function metadata attached to it, specifying the arguments. Kernel argument metadata is used to provide source level information for querying at runtime, for example using the clGetKernelArgInfo call.

Note that -cl-kernel-arg-info enables more information about the original CL code to be added e.g. kernel parameter names will appear in the OpenCL metadata along with other information.

The IDs used to encode the OpenCL’s logical address spaces in the argument info metadata follows the SPIR address space mapping as defined in the SPIR specification section 2.2

OpenCL-Specific Attributes¶

OpenCL support in Clang contains a set of attribute taken directly from the specification as well as additional attributes.

See also Attributes in Clang.

OpenCL builtins¶

There are some standard OpenCL functions that are implemented as Clang builtins:

• All pipe functions from section 6.13.16.2/6.13.16.3 of the OpenCL v2.0 kernel language specification. `
• Address space qualifier conversion functions to_global/to_local/to_private from section 6.13.9.
• All the enqueue_kernel functions from section 6.13.17.1 and enqueue query functions from section 6.13.17.5.

CPU Architectures Features and Limitations¶

Operating System Features and Limitations¶

Command-Line Options¶

To be compatible with cl.exe, clang-cl supports most of the same command-line options. Those options can start with either / or -. It also supports some of Clang’s core options, such as the -W options.

Options that are known to clang-cl, but not currently supported, are ignored with a warning. For example:

clang-cl.exe: warning: argument unused during compilation: '/AI'

To suppress warnings about unused arguments, use the -Qunused-arguments option.

Options that are not known to clang-cl will be ignored by default. Use the -Werror=unknown-argument option in order to treat them as errors. If these options are spelled with a leading /, they will be mistaken for a filename:

clang-cl.exe: error: no such file or directory: '/foobar'

Please file a bug for any valid cl.exe flags that clang-cl does not understand.

Execute clang-cl /? to see a list of supported options:

CL.EXE COMPATIBILITY OPTIONS:
  /?                      Display available options
  /arch:<value>           Set architecture for code generation
  /Brepro-                Emit an object file which cannot be reproduced over time
  /Brepro                 Emit an object file which can be reproduced over time
  /C                      Don't discard comments when preprocessing
  /c                      Compile only
  /d1reportAllClassLayout Dump record layout information
  /diagnostics:caret      Enable caret and column diagnostics (on by default)
  /diagnostics:classic    Disable column and caret diagnostics
  /diagnostics:column     Disable caret diagnostics but keep column info
  /D <macro[=value]>      Define macro
  /EH<value>              Exception handling model
  /EP                     Disable linemarker output and preprocess to stdout
  /execution-charset:<value>
                          Runtime encoding, supports only UTF-8
  /E                      Preprocess to stdout
  /fallback               Fall back to cl.exe if clang-cl fails to compile
  /FA                     Output assembly code file during compilation
  /Fa<file or directory>  Output assembly code to this file during compilation (with /FA)
  /Fe<file or directory>  Set output executable file or directory (ends in / or \)
  /FI <value>             Include file before parsing
  /Fi<file>               Set preprocess output file name (with /P)
  /Fo<file or directory>  Set output object file, or directory (ends in / or \) (with /c)
  /fp:except-
  /fp:except
  /fp:fast
  /fp:precise
  /fp:strict
  /Fp<filename>           Set pch filename (with /Yc and /Yu)
  /GA                     Assume thread-local variables are defined in the executable
  /Gd                     Set __cdecl as a default calling convention
  /GF-                    Disable string pooling
  /GR-                    Disable emission of RTTI data
  /Gregcall               Set __regcall as a default calling convention
  /GR                     Enable emission of RTTI data
  /Gr                     Set __fastcall as a default calling convention
  /GS-                    Disable buffer security check
  /GS                     Enable buffer security check
  /Gs<value>              Set stack probe size
  /Gv                     Set __vectorcall as a default calling convention
  /Gw-                    Don't put each data item in its own section
  /Gw                     Put each data item in its own section
  /GX-                    Enable exception handling
  /GX                     Enable exception handling
  /Gy-                    Don't put each function in its own section
  /Gy                     Put each function in its own section
  /Gz                     Set __stdcall as a default calling convention
  /help                   Display available options
  /imsvc <dir>            Add directory to system include search path, as if part of %INCLUDE%
  /I <dir>                Add directory to include search path
  /J                      Make char type unsigned
  /LDd                    Create debug DLL
  /LD                     Create DLL
  /link <options>         Forward options to the linker
  /MDd                    Use DLL debug run-time
  /MD                     Use DLL run-time
  /MTd                    Use static debug run-time
  /MT                     Use static run-time
  /Od                     Disable optimization
  /Oi-                    Disable use of builtin functions
  /Oi                     Enable use of builtin functions
  /Os                     Optimize for size
  /Ot                     Optimize for speed
  /O<value>               Optimization level
  /o <file or directory>  Set output file or directory (ends in / or \)
  /P                      Preprocess to file
  /Qvec-                  Disable the loop vectorization passes
  /Qvec                   Enable the loop vectorization passes
  /showIncludes           Print info about included files to stderr
  /source-charset:<value> Source encoding, supports only UTF-8
  /std:<value>            Language standard to compile for
  /TC                     Treat all source files as C
  /Tc <filename>          Specify a C source file
  /TP                     Treat all source files as C++
  /Tp <filename>          Specify a C++ source file
  /utf-8                  Set source and runtime encoding to UTF-8 (default)
  /U <macro>              Undefine macro
  /vd<value>              Control vtordisp placement
  /vmb                    Use a best-case representation method for member pointers
  /vmg                    Use a most-general representation for member pointers
  /vmm                    Set the default most-general representation to multiple inheritance
  /vms                    Set the default most-general representation to single inheritance
  /vmv                    Set the default most-general representation to virtual inheritance
  /volatile:iso           Volatile loads and stores have standard semantics
  /volatile:ms            Volatile loads and stores have acquire and release semantics
  /W0                     Disable all warnings
  /W1                     Enable -Wall
  /W2                     Enable -Wall
  /W3                     Enable -Wall
  /W4                     Enable -Wall and -Wextra
  /Wall                   Enable -Weverything
  /WX-                    Do not treat warnings as errors
  /WX                     Treat warnings as errors
  /w                      Disable all warnings
  /Y-                     Disable precompiled headers, overrides /Yc and /Yu
  /Yc<filename>           Generate a pch file for all code up to and including <filename>
  /Yu<filename>           Load a pch file and use it instead of all code up to and including <filename>
  /Z7                     Enable CodeView debug information in object files
  /Zc:sizedDealloc-       Disable C++14 sized global deallocation functions
  /Zc:sizedDealloc        Enable C++14 sized global deallocation functions
  /Zc:strictStrings       Treat string literals as const
  /Zc:threadSafeInit-     Disable thread-safe initialization of static variables
  /Zc:threadSafeInit      Enable thread-safe initialization of static variables
  /Zc:trigraphs-          Disable trigraphs (default)
  /Zc:trigraphs           Enable trigraphs
  /Zc:twoPhase-           Disable two-phase name lookup in templates
  /Zc:twoPhase            Enable two-phase name lookup in templates
  /Zd                     Emit debug line number tables only
  /Zi                     Alias for /Z7. Does not produce PDBs.
  /Zl                     Don't mention any default libraries in the object file
  /Zp                     Set the default maximum struct packing alignment to 1
  /Zp<value>              Specify the default maximum struct packing alignment
  /Zs                     Syntax-check only

OPTIONS:
  -###                    Print (but do not run) the commands to run for this compilation
  --analyze               Run the static analyzer
  -fansi-escape-codes     Use ANSI escape codes for diagnostics
  -fcolor-diagnostics     Use colors in diagnostics
  -fdebug-macro           Emit macro debug information
  -fdelayed-template-parsing
                          Parse templated function definitions at the end of the translation unit
  -fdiagnostics-absolute-paths
                          Print absolute paths in diagnostics
  -fdiagnostics-parseable-fixits
                          Print fix-its in machine parseable form
  -flto=<value>           Set LTO mode to either 'full' or 'thin'
  -flto                   Enable LTO in 'full' mode
  -fms-compatibility-version=<value>
                          Dot-separated value representing the Microsoft compiler version
                          number to report in _MSC_VER (0 = don't define it (default))
  -fms-compatibility      Enable full Microsoft Visual C++ compatibility
  -fms-extensions         Accept some non-standard constructs supported by the Microsoft compiler
  -fmsc-version=<value>   Microsoft compiler version number to report in _MSC_VER
                          (0 = don't define it (default))
  -fno-debug-macro        Do not emit macro debug information
  -fno-delayed-template-parsing
                          Disable delayed template parsing
  -fno-sanitize-address-use-after-scope
                          Disable use-after-scope detection in AddressSanitizer
  -fno-sanitize-blacklist Don't use blacklist file for sanitizers
  -fno-sanitize-cfi-cross-dso
                          Disable control flow integrity (CFI) checks for cross-DSO calls.
  -fno-sanitize-coverage=<value>
                          Disable specified features of coverage instrumentation for Sanitizers
  -fno-sanitize-memory-track-origins
                          Disable origins tracking in MemorySanitizer
  -fno-sanitize-memory-use-after-dtor
                          Disable use-after-destroy detection in MemorySanitizer
  -fno-sanitize-recover=<value>
                          Disable recovery for specified sanitizers
  -fno-sanitize-stats     Disable sanitizer statistics gathering.
  -fno-sanitize-thread-atomics
                          Disable atomic operations instrumentation in ThreadSanitizer
  -fno-sanitize-thread-func-entry-exit
                          Disable function entry/exit instrumentation in ThreadSanitizer
  -fno-sanitize-thread-memory-access
                          Disable memory access instrumentation in ThreadSanitizer
  -fno-sanitize-trap=<value>
                          Disable trapping for specified sanitizers
  -fno-standalone-debug   Limit debug information produced to reduce size of debug binary
  -fprofile-instr-generate=<file>
                          Generate instrumented code to collect execution counts into <file>
                          (overridden by LLVM_PROFILE_FILE env var)
  -fprofile-instr-generate
                          Generate instrumented code to collect execution counts into default.profraw file
                          (overridden by '=' form of option or LLVM_PROFILE_FILE env var)
  -fprofile-instr-use=<value>
                          Use instrumentation data for profile-guided optimization
  -fsanitize-address-field-padding=<value>
                          Level of field padding for AddressSanitizer
  -fsanitize-address-globals-dead-stripping
                          Enable linker dead stripping of globals in AddressSanitizer
  -fsanitize-address-use-after-scope
                          Enable use-after-scope detection in AddressSanitizer
  -fsanitize-blacklist=<value>
                          Path to blacklist file for sanitizers
  -fsanitize-cfi-cross-dso
                          Enable control flow integrity (CFI) checks for cross-DSO calls.
  -fsanitize-cfi-icall-generalize-pointers
                          Generalize pointers in CFI indirect call type signature checks
  -fsanitize-coverage=<value>
                          Specify the type of coverage instrumentation for Sanitizers
  -fsanitize-memory-track-origins=<value>
                          Enable origins tracking in MemorySanitizer
  -fsanitize-memory-track-origins
                          Enable origins tracking in MemorySanitizer
  -fsanitize-memory-use-after-dtor
                          Enable use-after-destroy detection in MemorySanitizer
  -fsanitize-recover=<value>
                          Enable recovery for specified sanitizers
  -fsanitize-stats        Enable sanitizer statistics gathering.
  -fsanitize-thread-atomics
                          Enable atomic operations instrumentation in ThreadSanitizer (default)
  -fsanitize-thread-func-entry-exit
                          Enable function entry/exit instrumentation in ThreadSanitizer (default)
  -fsanitize-thread-memory-access
                          Enable memory access instrumentation in ThreadSanitizer (default)
  -fsanitize-trap=<value> Enable trapping for specified sanitizers
  -fsanitize-undefined-strip-path-components=<number>
                          Strip (or keep only, if negative) a given number of path components when emitting check metadata.
  -fsanitize=<check>      Turn on runtime checks for various forms of undefined or suspicious
                          behavior. See user manual for available checks
  -fstandalone-debug      Emit full debug info for all types used by the program
  -fwhole-program-vtables Enables whole-program vtable optimization. Requires -flto
  -gcodeview              Generate CodeView debug information
  -gline-tables-only      Emit debug line number tables only
  -miamcu                 Use Intel MCU ABI
  -mllvm <value>          Additional arguments to forward to LLVM's option processing
  -nobuiltininc           Disable builtin #include directories
  -Qunused-arguments      Don't emit warning for unused driver arguments
  -R<remark>              Enable the specified remark
  --target=<value>        Generate code for the given target
  --version               Print version information
  -v                      Show commands to run and use verbose output
  -W<warning>             Enable the specified warning
  -Xclang <arg>           Pass <arg> to the clang compiler