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 C99 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 an warning even if -Werror is specified.

-Wfoo¶

Enable warning “foo”.

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

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.

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"

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmultichar"

char b = 'df'; // 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");

char a = 'xy'; // warning

#pragma clang system_header

char b = 'ab'; // 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=integer: Enables checks for undefined or suspicious integer behavior.

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

• -fsanitize=memory: MemorySanitizer, an experimental detector of uninitialized reads. Not ready for widespread use.

• -fsanitize=undefined: Fast and compatible undefined behavior checker. Enables the undefined behavior checks that have small runtime cost and no impact on address space layout or ABI. This includes all of the checks listed below other than unsigned-integer-overflow.

• -fsanitize=undefined-trap: This includes all sanitizers included by -fsanitize=undefined, except those that require runtime support. This group of sanitizers is intended to be used in conjunction with the -fsanitize-undefined-trap-on-error flag. This includes all of the checks listed below other than unsigned-integer-overflow and vptr.
• -fsanitize=dataflow: DataFlowSanitizer, a general data flow analysis.

The following more fine-grained checks are also available:

• -fsanitize=alignment: Use of a misaligned pointer or creation of a misaligned reference.
• -fsanitize=bool: Load of a bool value which is neither true nor false.
• -fsanitize=bounds: Out of bounds array indexing, in cases where the array bound can be statically determined.
• -fsanitize=enum: Load of a value of an enumerated type which is not in the range of representable values for that enumerated type.
• -fsanitize=float-cast-overflow: Conversion to, from, or between floating-point types which would overflow the destination.
• -fsanitize=float-divide-by-zero: Floating point division by zero.
• -fsanitize=function: Indirect call of a function through a function pointer of the wrong type (Linux, C++ and x86/x86_64 only).
• -fsanitize=integer-divide-by-zero: Integer division by zero.
• -fsanitize=null: Use of a null pointer or creation of a null reference.
• -fsanitize=object-size: An attempt to use bytes which the optimizer can determine are not part of the object being accessed. The sizes of objects are determined using __builtin_object_size, and consequently may be able to detect more problems at higher optimization levels.
• -fsanitize=return: In C++, reaching the end of a value-returning function without returning a value.
• -fsanitize=shift: Shift operators where the amount shifted is greater or equal to the promoted bit-width of the left hand side or less than zero, or where the left hand side is negative. For a signed left shift, also checks for signed overflow in C, and for unsigned overflow in C++.
• -fsanitize=signed-integer-overflow: Signed integer overflow, including all the checks added by -ftrapv, and checking for overflow in signed division (INT_MIN / -1).
• -fsanitize=unreachable: If control flow reaches __builtin_unreachable.
• -fsanitize=unsigned-integer-overflow: Unsigned integer overflows.
• -fsanitize=vla-bound: A variable-length array whose bound does not evaluate to a positive value.
• -fsanitize=vptr: Use of an object whose vptr indicates that it is of the wrong dynamic type, or that its lifetime has not begun or has ended. Incompatible with -fno-rtti.

You can turn off or modify checks for certain source files, functions or even variables by providing a special file:

• -fsanitize-blacklist=/path/to/blacklist/file: disable or modify sanitizer checks for objects 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.

Extra features of MemorySanitizer (require explicit -fsanitize=memory):

• -fsanitize-memory-track-origins[=level]: Enables origin tracking in MemorySanitizer. Adds a second section to MemorySanitizer reports pointing to the heap or stack allocation the uninitialized bits came from. Slows down execution by additional 1.5x-2x.

  Possible values for level are 0 (off), 1 (default), 2. Level 2 adds more sections to MemorySanitizer reports describing the order of memory stores the uninitialized value went through. Beware, this mode may use a lot of extra memory.

Extra features of UndefinedBehaviorSanitizer:

• -fno-sanitize-recover: By default, after a sanitizer diagnoses an issue, it will attempt to continue executing the program if there is a reasonable behavior it can give to the faulting operation. This option causes the program to abort instead.
• -fsanitize-undefined-trap-on-error: Causes traps to be emitted rather than calls to runtime libraries when a problem is detected. This option is intended for use in cases where the sanitizer runtime cannot be used (for instance, when building libc or a kernel module). This is only compatible with the sanitizers in the undefined-trap group.

The -fsanitize= argument must also be provided when linking, in order to link to the appropriate runtime library. When using -fsanitize=vptr (or a group that includes it, such as -fsanitize=undefined) with a C++ program, the link must be performed by clang++, not clang, in order to link against the C++-specific parts of the 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. The -fsanitize=undefined checks can be combined with other sanitizers.

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

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

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

Controlling Size of Debug Information¶

Debug info kind generated by Clang can be set by one of the flags listed below. If multiple flags are present, the last one is used.

-g0¶

Don’t generate any debug info (default).

-gline-tables-only¶

Generate line number tables only.

This kind of debug info allows to obtain stack traces with function names, file names and line numbers (by such tools as gdb or addr2line). It doesn’t contain any other data (e.g. description of local variables or function parameters).

-fstandalone-debug¶

Clang supports a number of optimizations to reduce the size of debug information in the binary. They work based on the assumption that the debug type information can be spread out over multiple compilation units. For instance, Clang will not emit type definitions for types that are not needed by a module and could be replaced with a forward declaration. Further, Clang will only emit type info for a dynamic C++ class in the module that contains the vtable for the class.

The -fstandalone-debug option turns off these optimizations. This is useful when working with 3rd-party libraries that don’t come with debug information. Note that Clang will never emit type information for types that are not referenced at all by the program.

-fno-standalone-debug¶

On Darwin -fstandalone-debug is enabled by default. The -fno-standalone-debug option can be used to get to turn on the vtable-based optimization described above.

-g¶

Generate complete debug info.

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 and various aliases for those modes. If no -std option is specified, clang defaults to gnu99 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.

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 #pragma weak (bug 3679). Due to the uses described in the bug, this is likely to be implemented at some point, at least partially.

• 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 does not support global register variables; this 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 some experimental support for extensions from Microsoft Visual C++; to enable it, use the -fms-extensions command-line option. This is the default for Windows targets. Note that the support is incomplete. Some constructs such as dllexport on classes are ignored with a warning, and others such as Microsoft IDL annotations are silently ignored.

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.

• clang allows setting _MSC_VER with -fmsc-version=. It defaults to 1700 which is the same as Visual C/C++ 2012. Any number is supported and can greatly affect what Windows SDK and c++stdlib headers clang can compile.
• clang does not support the Microsoft extension where anonymous record members can be declared using user defined typedefs.
• clang supports the Microsoft #pragma pack feature for controlling record layout. GCC also contains support for this feature, however where MSVC and GCC are incompatible clang follows the MSVC definition.
• clang supports the Microsoft #pragma comment(lib, "foo.lib") feature for automatically linking against the specified library. Currently this feature only works with the Visual C++ linker.
• clang supports the Microsoft #pragma comment(linker, "/flag:foo") feature for adding linker flags to COFF object files. The user is responsible for ensuring that the linker understands the flags.
• clang defaults to C++11 for Windows targets.

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.

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: '/Zi'

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

Options that are not known to clang-cl will cause errors. If they 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
  /C                     Don't discard comments when preprocessing
  /c                     Compile only
  /D <macro[=value]>     Define macro
  /EH<value>             Exception handling model
  /EP                    Disable linemarker output and preprocess to stdout
  /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
  /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
  /Fo<file or directory> Set output object file, or directory (ends in / or \)
  /GF-                   Disable string pooling
  /GR-                   Disable emission of RTTI data
  /GR                    Enable emission of RTTI data
  /Gw-                   Don't put each data item in its own section
  /Gw                    Put each data item in its own section
  /Gy-                   Don't put each function in its own section
  /Gy                    Put each function in its own section
  /help                  Display available options
  /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
  /Ob0                   Disable inlining
  /Od                    Disable optimization
  /Oi-                   Disable use of builtin functions
  /Oi                    Enable use of builtin functions
  /Os                    Optimize for size
  /Ot                    Optimize for speed
  /Ox                    Maximum optimization
  /Oy-                   Disable frame pointer omission
  /Oy                    Enable frame pointer omission
  /O<n>                  Optimization level
  /P                     Preprocess to file
  /showIncludes          Print info about included files to stderr
  /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
  /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
  /W0                    Disable all warnings
  /W1                    Enable -Wall
  /W2                    Enable -Wall
  /W3                    Enable -Wall
  /W4                    Enable -Wall
  /Wall                  Enable -Wall
  /WX-                   Do not treat warnings as errors
  /WX                    Treat warnings as errors
  /w                     Disable all warnings
  /Zi                    Enable debug information
  /Zs                    Syntax-check only

OPTIONS:
  -###                  Print (but do not run) the commands to run for this compilation
  -fms-compatibility-version=<value>
                        Dot-separated value representing the Microsoft compiler version
                        number to report in _MSC_VER (0 = don't define it (default))
  -fmsc-version=<value> Microsoft compiler version number to report in _MSC_VER (0 = don't
                        define it (default))
  -fsanitize-blacklist=<value>
                        Path to blacklist file for sanitizers
  -fsanitize=<check>    Enable runtime instrumentation for bug detection: address (memory
                        errors) | thread (race detection) | undefined (miscellaneous
                        undefined behavior)
  -mllvm <value>        Additional arguments to forward to LLVM's option processing
  -Qunused-arguments    Don't emit warning for unused driver arguments
  --target=<value>      Generate code for the given target
  -v                    Show commands to run and use verbose output
  -W<warning>           Enable the specified warning
  -Xclang <arg>         Pass <arg> to the clang compiler