CLANG(1)

📦
version 21.1.8 · 5 versions
, in fedora 44

💅 CLANG — the manual page, bestie edition 🌸

ok so this is the CLANG(1) page, like officially from the Clang section of the manual, and it's long, so hydrate first. We're doing this in parts. Part one is right here. Let's go. ✨

🎀 NAME 🎀

clang — the Clang C, C++, and Objective-C compiler. that's it, that's the whole name section, she's concise and she's iconic.

🦋 SYNOPSIS 🦋

clang [options] filename ...

literally just: you, some options, and one or more *filename*s. the holy trinity. 🫶

🌈 DESCRIPTION 🌈

ok so clang is a C, C++, and Objective-C compiler, and she does everything — preprocessing, parsing, optimization, code generation, assembly, and linking, all in one girl. no cap, the whole pipeline.

Depending on which high-level mode setting you pass, Clang will stop before doing a full link. So like, she can go all the way to a finished program, or she can clock out early if you tell her to. And because Clang is highly integrated (main character energy, she contains multitudes), it's genuinely important to understand the stages of compilation so you know how to invoke her properly. Here are the stages, in order, like a little compiler pipeline tour:

🚗 Driver

The clang executable is actually a small driver which controls the overall execution of other tools such as the compiler, assembler and linker. She's the manager, not the worker, yk? Typically you do not need to interact with the driver, but you transparently use it to run the other tools. so you're always talking to her, but she's delegating. queen behavior.

✂️ Preprocessing

This stage handles tokenization of the input source file, macro expansion, #include expansion and handling of other preprocessor directives. The output of this stage is typically called a ".i" (for C), ".ii" (for C++), ".mi" (for Objective-C), or ".mii" (for Objective-C++) file. yes the file extensions are a whole vibe, they're nesting like russian dolls.

🧠 Parsing and Semantic Analysis

This stage parses the input file, translating preprocessor tokens into a parse tree. Once in the form of a parse tree, it applies semantic analysis to compute types for expressions as well and determine whether the code is well formed. This stage is responsible for generating most of the compiler warnings as well as parse errors. So when your build screams at you? this is her. she's the one doing the screaming. The output of this stage is an "Abstract Syntax Tree" (AST).

⚡ Code Generation and Optimization

This stage translates an AST into low-level intermediate code (known as "LLVM IR") and ultimately to machine code. This phase is responsible for optimizing the generated code and handling target-specific code generation. The output of this stage is typically called a ".s" file or "assembly" file.

Clang also supports the use of an integrated assembler, in which the code generator produces object files directly. This avoids the overhead of generating the ".s" file and of calling the target assembler. efficiency!! she said why make a middleman file when I could simply not. 💅

🔧 Assembler

This stage runs the target assembler to translate the output of the compiler into a target object file. The output of this stage is typically called a ".o" file or "object" file.

🔗 Linker

This stage runs the target linker to merge multiple object files into an executable or dynamic library. The output of this stage is typically called an "a.out", ".dylib" or ".so" file.

🔍 Clang Static Analyzer

The Clang Static Analyzer is a tool that scans source code to try to find bugs through code analysis. This tool uses many parts of Clang and is built into the same driver. Please see <<https://clang-analyzer.llvm.org>> for more details on how to use the static analyzer. she finds bugs before they happen, which is honestly terrifying and also slay.

✨ OPTIONS ✨

🎬 Stage Selection Options

these tell Clang where to stop. pick your stopping point, bestie.

  • -E — Run the preprocessor stage. that's it. she stops right after preprocessing, nothing more.
  • -fsyntax-only — Run the preprocessor, parser and semantic analysis stages. so she checks your vibes (and your types) but produces nothing. pure judgment, no output.
  • -S — Run the previous stages as well as LLVM generation and optimization stages and target-specific code generation, producing an assembly file.
  • -c — Run all of the above, plus the assembler, generating a target ".o" object file.
  • no stage selection option — If no stage selection option is specified, all stages above are run, and the linker is run to combine the results into an executable or shared library. basically: no notes, she does the whole thing, you get a real program. 🔥

🗣️ Language Selection and Mode Options

  • -x <language> — Treat subsequent input files as having type language. like a little name tag for your files.
  • -std= <standard> — Specify the language standard to compile for. this one has lore, so buckle up:

Supported values for the C language are:

  • c89
  • c90
  • iso9899:1990

ISO C 1990

  • iso9899:199409

ISO C 1990 with amendment 1

  • gnu89
  • gnu90

ISO C 1990 with GNU extensions

  • c99
  • iso9899:1999

ISO C 1999

  • gnu99

ISO C 1999 with GNU extensions

  • c11
  • iso9899:2011

ISO C 2011

  • gnu11

ISO C 2011 with GNU extensions

  • c17
  • iso9899:2017

ISO C 2017

  • gnu17

ISO C 2017 with GNU extensions

  • c23
  • iso9899:2024

ISO C 2023

  • gnu23

ISO C 2023 with GNU extensions

  • c2y

ISO C 202y

  • gnu2y

ISO C 202y with GNU extensions

The default C language standard is gnu17, except on PS4, where it is gnu99. (PS4 girlies stay on gnu99, respect.)

Supported values for the C++ language are:

  • c++98
  • c++03

ISO C++ 1998 with amendments

  • gnu++98
  • gnu++03

ISO C++ 1998 with amendments and GNU extensions

  • c++11

ISO C++ 2011 with amendments

  • gnu++11

ISO C++ 2011 with amendments and GNU extensions

  • c++14

ISO C++ 2014 with amendments

  • gnu++14

ISO C++ 2014 with amendments and GNU extensions

  • c++17

ISO C++ 2017 with amendments

  • gnu++17

ISO C++ 2017 with amendments and GNU extensions

  • c++20

ISO C++ 2020 with amendments

  • gnu++20

ISO C++ 2020 with amendments and GNU extensions

  • c++23

ISO C++ 2023 with amendments

  • gnu++23

ISO C++ 2023 with amendments and GNU extensions

  • c++2c

Working draft for C++2c

  • gnu++2c

Working draft for C++2c with GNU extensions

The default C++ language standard is gnu++17.

Supported values for the OpenCL language are:

  • cl1.0

OpenCL 1.0

  • cl1.1

OpenCL 1.1

  • cl1.2

OpenCL 1.2

  • cl2.0

OpenCL 2.0

The default OpenCL language standard is cl1.0.

Supported values for the CUDA language are:

  • cuda

NVIDIA CUDA(tm)

  • -stdlib= <library> — Specify the C++ standard library to use; supported options are libstdc++ and libc++. If not specified, platform default will be used.
  • -rtlib= <library> — Specify the compiler runtime library to use; supported options are libgcc and compiler-rt. If not specified, platform default will be used.
  • -ansi — Same as -std=c89. that's the whole thing. retro queen.
  • -ObjC, -ObjC++ — Treat source input files as Objective-C and Object-C++ inputs respectively.
  • -trigraphs — Enable trigraphs. (yes, those. she's letting them in. 🙈)
  • -ffreestanding — Indicate that the file should be compiled for a freestanding, not a hosted, environment. Note that a freestanding build still requires linking against a C Standard Library which supports the freestanding interfaces for the specified language mode and target environment. This includes functions like memcpy, memmove, and memset. so like, freestanding ≠ no library at all, don't get it twisted.
  • -fno-builtin — Disable special handling and optimizations of well-known library functions, like strlen() and malloc().
  • -fno-builtin- <function> — Disable special handling and optimizations for the specific library function. For example, -fno-builtin-strlen removes any special handling for the strlen() library function.
  • -fno-builtin-std- <function> — Disable special handling and optimizations for the specific C++ standard library function in namespace std. For example, -fno-builtin-std-move_if_noexcept removes any special handling for the std::move_if_noexcept() library function.

For C standard library functions that the C++ standard library also provides in namespace std, use -fno-builtin-<function> instead. (don't use the std- one for those, ok? use the other one. iykyk.)

  • -fmath-errno — Indicate that math functions should be treated as updating errno.
  • -fpascal-strings — Enable support for Pascal-style strings with "\pfoo".
  • -fms-extensions — Enable support for Microsoft extensions.
  • -fmsc-version= — Set _MSC_VER. When on Windows, this defaults to either the same value as the currently installed version of cl.exe, or 1933. Not set otherwise. (yes, the option is literally -fmsc-version= with nothing after it in the page, don't come for me, that's what it says. 💀)
  • -fborland-extensions — Enable support for Borland extensions.
  • -fwritable-strings — Make all string literals default to writable. This disables uniquing of strings and other optimizations. ⚠️ you're giving up optimizations for this, so know what you're doing.
  • -flax-vector-conversions, -flax-vector-conversions= <kind>, -fno-lax-vector-conversions — Allow loose type checking rules for implicit vector conversions. Possible values of <kind>:
    • none: allow no implicit conversions between vectors
    • integer: allow implicit bitcasts between integer vectors of the same overall bit-width
    • all: allow implicit bitcasts between any vectors of the same overall bit-width

<kind> defaults to integer if unspecified.

  • -fblocks — Enable the "Blocks" language feature. blocks girlies rise.
  • -fobjc-abi-version= version — Select the Objective-C ABI version to use. Available versions are 1 (legacy "fragile" ABI), 2 (non-fragile ABI 1), and 3 (non-fragile ABI 2).
  • -fobjc-nonfragile-abi-version= <version> — Select the Objective-C non-fragile ABI version to use by default. This will only be used as the Objective-C ABI when the non-fragile ABI is enabled (either via -fobjc-nonfragile-abi, or because it is the platform default).
  • -fobjc-nonfragile-abi, -fno-objc-nonfragile-abi — Enable use of the Objective-C non-fragile ABI. On platforms for which this is the default ABI, it can be disabled with -fno-objc-nonfragile-abi.

🎯 Target Selection Options

Clang fully supports cross compilation as an inherent part of its design. Depending on how your version of Clang is configured, it may have support for a number of cross compilers, or may only support a native target. she's flexible like that, but like, check your build first bestie 🫶

  • -arch <architecture> — Specify the architecture to build for (Mac OS X specific). mac girlies only for this one.
  • -target <architecture> — Specify the architecture to build for (all platforms). everyone can have this one, it's for the whole group chat.

to be continued… don't go anywhere 💖

  • -mmacos-version-min=<version> — building for macOS? this one tells clang the minimum version your app actually supports. set it, don't guess it 🍎
  • -miphoneos-version-min — same vibe but for iPhone OS: it's the minimum version your app supports on that platform 📱
  • --print-supported-cpus — prints out a whole list of supported processors for whatever target you picked (via --target=<architecture> or -arch <architecture>). no target specified? then it just rolls with the system default target, no big deal ✨
  • -mcpu=?, -mtune=? — literally just an alias for --print-supported-cpus. same energy, different spelling 💅
  • -mcpu=help, -mtune=help — yes bestie, also an alias for --print-supported-cpus. three whole ways to ask the same question 🎀
  • -march=<cpu> — tells Clang to generate code for a specific processor family member and later. like, if you hand it -march=i486, the compiler is fully allowed to emit instructions that are valid on i486 and everything after it — but which might not exist on the earlier ones. so choose your era wisely 👑
  • --print-enabled-extensions — prints the extensions that are enabled for the target you get from combining --target, -march, and -mcpu values. heads up: right now it's only supported on AArch64 and RISC-V. on RISC-V it also prints out the ISA string of the enabled extensions, cute bonus 🌸
  • --print-supported-extensions — prints every extension supported for every CPU target of an architecture (specified through --target=<architecture> or -arch <architecture>). no target? system default target, as always. also only supported on AArch64 and RISC-V currently, so don't come for it on other arches 🙈

🔥 Code Generation Options 🔥

  • -O0, -O1, -O2, -O3, -Ofast, -Os, -Oz, -Og, -O, -O4 — pick your optimization level, bestie. here's the whole menu:
    • -O0 — means "no optimization." compiles the fastest and generates the most debuggable code. raw, unfiltered, iconic.
    • -O1 — somewhere between -O0 and -O2. the middle child.
    • -O2 — moderate level of optimization that enables most optimizations. the reliable one.
    • -O3 — like -O2, except it also turns on optimizations that take longer to perform or that may generate larger code (all in an attempt to make the program run faster). highkey ambitious.
    • -Ofast — enables all the optimizations from -O3 plus other aggressive optimizations that may violate strict compliance with language standards. this is deprecated in Clang 19 and a warning gets emitted telling you to use -O3 in combination with -ffast-math instead if the non-standard math behavior is what you were actually after. there's no removal timeline yet — the whole point is to discourage -Ofast because an optimization flag changing the observable behavior of correct code is genuinely surprising. so like… be careful 💀
    • -Os — like -O2 with extra optimizations to reduce code size. smol but mighty.
    • -Oz — like -Os (and therefore like -O2), but reduces code size even further. extra smol.
    • -Og — similar to -O1, but with slightly reduced optimization and better variable visibility. runs the same optimizations as -O1, but also sets the -fextend-variable-liveness flag, which tries to stop optimizations from reducing the liveness of your variables so they're actually available when you're debugging. debugging bestie rights 🫶
    • -O — equivalent to -O1. that's it, that's the whole sentence.
    • -O4 and higher — currently equivalent to -O3. (yes, really. no secret ultra mode. sorry 😭)
  • -g, -gline-tables-only, -gmodules — controls debug information output. quick note: Clang debug info works best at -O0. and when you pass more than one option starting with -g, the last one wins, so order matters:
    • -g — generate debug information. the classic.
    • -gline-tables-only — generates only line table debug information. this lets you get symbolicated backtraces with inlining information, but it does not include any info about variables, their locations, or their types. so backtraces: slay. variable inspection: nope.
    • -gmodules — generates debug info that contains external references to types defined in Clang modules or precompiled headers, instead of emitting redundant debug type information into every single object file. this transparently switches the Clang module format to object file containers that hold the Clang module together with the debug information. when you're compiling a program that uses Clang modules or precompiled headers, this gives you complete debug info with faster compile times and much smaller object files. the glow-up is real ✨
    • > ⚠️ do not use -gmodules when building static libraries for distribution to other machines, because the debug info will contain references to the module cache on the machine where the object files in the library were built. that path won't exist over there, and it will be a whole mess 💀
  • -fstandalone-debug, -fno-standalone-debug — okay so Clang does a bunch of optimizations to shrink debug info in the binary, and they all rely on the assumption that debug type information can be spread across multiple compilation units. for example, Clang won't emit type definitions for types that a module doesn't need and that could be replaced with a forward declaration. further, Clang only emits type info for a dynamic C++ class in the module that contains the vtable for that class. -fstandalone-debug turns all those optimizations off. super useful when you're working with 3rd-party libraries that don't ship debug information. and fun fact: this is the default on Darwin. also note that Clang will never emit type information for types that aren't referenced by the program at all — that part is non-negotiable 👑
  • -feliminate-unused-debug-types — by default, Clang doesn't emit type information for types that are defined but not used in a program. if you want to keep the debug info for those unused types, use the negation -fno-eliminate-unused-debug-types. keeping the strays, love that for them 🎀
  • -fexceptions — allows exceptions to be thrown through Clang-compiled stack frames (on many targets this enables unwind information for functions that might have an exception thrown through them). for most targets this is enabled by default for C++. so, y'know, C++ girlies are already covered 💅
  • -ftrapv — generates code to catch integer overflow errors. signed integer overflow is undefined in C, so with this flag, extra code gets generated to detect it and abort when it happens. no silent chaos allowed 🚨
  • -fvisibility — this flag sets the default visibility level. short and sweet.
  • -fcommon, -fno-common — this flag specifies that variables without initializers get common linkage. you can turn it off with -fno-common. pick a lane bestie.
  • -ftls-model=<model> — sets the default thread-local storage (TLS) model used for thread-local variables. valid values are: "global-dynamic", "local-dynamic", "initial-exec" and "local-exec". the default is "global-dynamic". the default model can be overridden with the tls_model attribute, and the compiler will try to choose a more efficient model when it can. it's giving optimizer with initiative 🌈
  • -flto, -flto=full, -flto=thin, -emit-llvm — generates output files in LLVM formats, suitable for link time optimization. when used with -S this generates LLVM intermediate language assembly files; otherwise it generates LLVM bitcode format object files (which may be passed to the linker depending on the stage selection options). the default for -flto is "full", where the LLVM bitcode is suitable for monolithic Link Time Optimization (LTO) — the linker merges all such modules into a single combined module for optimization. with "thin", ThinLTO compilation is invoked instead. two paths, both valid ✨
note: on Darwin, when you use -flto together with -g and you're compiling and linking in separate steps, you also need to pass -Wl,-object_path_lto,<lto-filename>.o at the linking step to tell the ld64 linker not to delete the temporary object file generated during Link Time Optimization. (Clang passes this flag to the linker automatically if compilation and linking happen in a single step.) doing this lets you debug the executable and generate the .dSYM bundle using dsymutil(1). iykyk 🦋

🚗 Driver Options 🚗

  • -### — print (but do not run) the commands that would run for this compilation. all the tea, none of the consequences 👀
  • --help — display available options. the classic cry for guidance.
  • -Qunused-arguments — do not emit any warnings for unused driver arguments. quiet quitting the nagging 🙈
  • -Wa,<args> — pass the comma separated arguments in args to the assembler.
  • -Wl,<args> — pass the comma separated arguments in args to the linker.
  • -Wp,<args> — pass the comma separated arguments in args to the preprocessor.
  • -Xanalyzer <arg> — pass arg to the static analyzer.
  • -Xassembler <arg> — pass arg to the assembler.
  • -Xlinker <arg> — pass arg to the linker.
  • -Xpreprocessor <arg> — pass arg to the preprocessor.
  • -o <file> — write output to file. a true essential 💖
  • -print-file-name=<file> — print the full library path of file.
  • -print-libgcc-file-name — print the library path for the compiler runtime library currently in use ("libgcc.a" or "libclang_rt.builtins.*.a"). useful when you need to know exactly which one is getting linked 🎀
  • -print-prog-name=<name> — print the full program path of name.
  • -print-search-dirs — print the paths used for finding libraries and programs. a little map of where Clang goes looking 🗺️
  • -save-temps — save intermediate compilation results. future you says thank you ✨
  • -save-stats, -save-stats=cwd, -save-stats=obj — save internal code generation (LLVM) statistics to a file, either in the current directory (-save-stats / -save-stats=cwd) or in the directory of the output file (-save-state=obj). you can also control statistics reporting with environment variables: setting CC_PRINT_INTERNAL_STAT to 1 enables the feature and the report goes to stdout in JSON format. setting CC_PRINT_INTERNAL_STAT_FILE to a file path makes it report statistics to that given file, also in JSON format.
psst — -save-stats takes precedence over CC_PRINT_INTERNAL_STAT and CC_PRINT_INTERNAL_STAT_FILE. the flag wins, always 💅
  • -integrated-as, -no-integrated-as — used to enable and disable, respectively, the integrated assembler. whether the integrated assembler is on by default is target dependent. so like… check your target, bestie 🔍
  • -time — time individual commands. ⏱️
  • -ftime-report — print a timing summary of each stage of compilation. where did the time go? now you know 🕰️
  • -v — show the commands to run and use verbose output. the talkative mode 🌸

🩺 Diagnostics Options (yes bestie, how clang talks to you)

  • -fshow-column, -fshow-source-location, -fcaret-diagnostics, -fdiagnostics-fixit-info, -fdiagnostics-parseable-fixits, -fdiagnostics-print-source-range-info, -fprint-source-range-info, -fdiagnostics-show-option, -fmessage-length — okay so this whole little squad is about how Clang prints out info about diagnostics, aka your errors and warnings 💖. That's the entire vibe of the group. For the actual tea, go read the Clang User's Manual — it's all there, iykyk.

🧪 Preprocessor Options (the before-times, literally)

  • -D<macroname>=<value> — sneaks an implicit #define into the predefines buffer, and that buffer gets read before your source file is preprocessed. Pre-loading the lore, basically ✨
  • -U<macroname> — same deal but the opposite energy: an implicit #undef into the predefines buffer, read before the source file is preprocessed.
  • -include <filename> — drops an implicit #include into the predefines buffer, read before the source file is preprocessed. Surprise header, but make it intentional 🎀
  • -I<directory> — adds the directory you name to the search path for include files.
  • -F<directory> — adds the directory you name to the search path for framework include files.
  • -nostdinc — nope, not searching the standard system directories or the compiler builtin directories for include files. None of them. Bye 👋
  • -nostdlibinc — skips the standard system directories for include files, but does still search the compiler builtin include directories. Half a ghosting, not a full one 💀
  • -nobuiltininc — doesn't search clang's builtin directory for include files.
  • -nostdinc++ — doesn't search the system C++ standard library directory for include files. C++ girlies, this one's for you 🦋
  • -fkeep-system-includes — the main character of this list ngl. Usable only with -E. It does not copy the preprocessed content of "system" headers into the output — instead it preserves the #include directive. The way this can greatly reduce the volume of text produced by -E?? So helpful when you're trying to produce a "small" reproduceable test case 🙌
⚠️ But bestie, listen: this option does not guarantee reproduceability. If the including source defines preprocessor symbols that influence the behavior of system headers (for example, _XOPEN_SOURCE), the operation of -E will remove that definition and thus can change the semantics of the included header. Also, using a different version of the system headers (especially a different version of the STL) may result in different behavior. Always verify the preprocessed file by compiling it separately. Fr fr, don't skip the vibe check on this one 😭

🌍 ENVIRONMENT (the invisible hands, lowkey)

  • TMPDIR, TEMP, TMP — these get checked in order for the location to write temporary files used during the compilation process. First one standing wins 💅
  • CPATH — specifies additional (non-system) header search paths used to find included header files. These paths are searched after paths specified with the -I<directory> option, but before any system header search paths. Paths are delimited by the platform dependent delimiter as used in the PATH environment variable. And here's the spicy bit: empty entries in the delimited path list — including those at the beginning or end of the list — are treated as specifying the compiler's current working directory 🌀
  • C_INCLUDE_PATH, OBJC_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJCPLUS_INCLUDE_PATH — these specify additional system header file search paths, used when processing the corresponding language. Search paths are delimited exactly as for the CPATH environment variable. Language-specific glow-up 🌈
  • MACOSX_DEPLOYMENT_TARGET — if -mmacos-version-min is unspecified, the default deployment target is read from this environment variable. This option only affects Darwin targets. Apple-only behavior, no cap 🍎

🐛 BUGS (snitch era)

Found a bug? To report bugs, please visit <https://github.com/llvm/llvm-project/issues/>. Most bug reports should include preprocessed source files (use the -E option) and the full output of the compiler, along with information to reproduce. Give them the whole story, receipts and all 🫶

👀 SEE ALSO

as(1), ld(1)

👑 Author

Maintained by the Clang / LLVM Team (<http://clang.llvm.org>)

2007-2026, The Clang Team

And that's a wrap on the whole page, bestie!! 🎀 This icon was brought to you by CLANG(1) — clang, section 21, dated May 15, 2026, in all its glory. Go forth and compile, you absolute legend 💜✨

📦 where this page comes from