GCC(1)

💖 gcc(1) 💖

Manual page for gcc, section 1, from the GNU project ✨

🎀 NAME 🎀

gcc - the GNU project C and C++ compiler 💅

✨ SYNOPSIS ✨

gcc [-c|-S|-E] [-std=standard]
    [-g] [-pg] [-Olevel]
    [-Wwarn...] [-Wpedantic]
    [-Idir...] [-Ldir...]
    [-Dmacro[=defn]...] [-Umacro]
    [-foption...] [-mmachine-option...]
    [-o outfile] [@file] infile...

okay so the synopsis only shows the highlights 🙈 for everything else, scroll on down. and g++ takes pretty much the same options as gcc, so you're not learning two whole languages here, bestie 🫶

📜 DESCRIPTION 📜

okay so when you invoke GCC, it normally does preprocessing, compilation, assembly and linking, all in one go 🔥 the "overall options" let you stop the process at an intermediate stage. for example, -c says not to run the linker, so the output is just the object files that the assembler spat out 🧚

other options get passed along to one or more of those stages. some control the preprocessor, some control the compiler itself, and yet other options control the assembler and linker. most of those aren't documented here because you rarely need them, and honestly that's a mercy 😭

most of the command-line options you can use with GCC are for C programs. when an option is only useful with another language (usually C++), the explanation will say so explicitly. if the description doesn't mention a source language, you can use that option with all supported languages ✨

the usual way to run GCC is to run the executable called gcc, or machine-gcc when you're cross-compiling, or machine-gcc-version if you want one specific version of GCC 💜 and when you compile C++ programs, you should invoke GCC as g++ instead, no cap.

the gcc program takes options and file names as operands. a lot of options have multi-letter names, so multiple single-letter options can't be grouped together. -dv is very different from -d -v, so don't try to be clever 🙈

you can mix options and other arguments. for the most part, the order doesn't matter. order does matter when you use several options of the same kind: for example, if you specify -L more than once, the directories get searched in the order you gave them. also, where you put the -l option is significant 👑

a bunch of options have long names starting with -f or with -W---for example, -fmove-loop-invariants, -Wformat and so on 🦋 most of these have both positive and negative forms, and the negative form of -ffoo is -fno-foo. this manual only documents one of those two forms, whichever one is not the default. main character energy for the default 💅

some options take one or more arguments, usually separated from the option name by either a space or an equals sign (=). unless it's documented otherwise, an argument can be either numeric or a string. numeric arguments should typically be small unsigned decimal or hexadecimal integers, and hexadecimal arguments must begin with the 0x prefix 🌸

arguments to options that set a size threshold of some sort can be arbitrarily large decimal or hexadecimal integers followed by a byte size suffix. that suffix designates a multiple of bytes, like kB and KiB for kilobyte and kibibyte, MB and MiB for megabyte and mebibyte, GB and GiB for gigabyte and gigibyte, and so on. these arguments get called byte-size in the rest of the text. if you want the full listing and explanation of the binary and decimal byte size prefixes, check the NIST, IEC, and other relevant national and international standards 🤓

🌈 OPTIONS 🌈

✨ Option Summary ✨

okay here's the big list of every option, grouped by type 🫶 the explanations live in the following sections, so this is just your cheat sheet to vibe-check first.

🔥 Overall Options 🔥

-c  -S  -E  -o file -dumpbase dumpbase  -dumpbase-ext auxdropsuf
-dumpdir dumppfx  -x language -v  -###  --help[=class[,...]]
--target-help  --version -pass-exit-codes  -pipe  -specs=file
-wrapper @file  -ffile-prefix-map=old=new  -fcanon-prefix-map
-fplugin=file  -fplugin-arg-name=arg -fdump-ada-spec[-slim]
-fada-spec-parent=unit  -fdump-go-spec=file

🎀 C Language Options 🎀

-ansi  -std=standard  -aux-info filename -fno-asm -fno-builtin
-fno-builtin-function  -fcond-mismatch -ffreestanding  -fgimple
-fgnu-tm  -fgnu89-inline  -fhosted -flax-vector-conversions
-fms-extensions -fpermitted-flt-eval-methods=standard
-fplan9-extensions  -fsigned-bitfields  -funsigned-bitfields
-fsigned-char  -funsigned-char  -fstrict-flex-arrays[=n]
-fsso-struct=endianness

🧚 C++ Language Options 🧚

-fabi-version=n  -fno-access-control -faligned-new=n
-fno-assume-sane-operators-new-delete -fchar8_t  -fcheck-new
-fconcepts  -fconstexpr-depth=n  -fconstexpr-cache-depth=n
-fconstexpr-loop-limit=n  -fconstexpr-ops-limit=n
-fno-elide-constructors -fno-enforce-eh-specs -fno-gnu-keywords
-fno-immediate-escalation -fno-implicit-templates
-fno-implicit-inline-templates -fno-implement-inlines
-fmodule-header[=kind] -fmodule-only -fmodules
-fmodule-implicit-inline -fno-module-lazy
-fmodule-mapper=specification -fmodule-version-ignore
-fms-extensions -fnew-inheriting-ctors -fnew-ttp-matching
-fno-nonansi-builtins  -fnothrow-opt  -fno-operator-names
-fno-optional-diags -fno-pretty-templates  -frange-for-ext-temps
-fno-rtti  -fsized-deallocation -fstrong-eval-order[=kind]
-ftemplate-backtrace-limit=n -ftemplate-depth=n
-fno-threadsafe-statics  -fuse-cxa-atexit -fno-weak  -nostdinc++
-fvisibility-inlines-hidden -fvisibility-ms-compat
-fext-numeric-literals -flang-info-include-translate[=header]
-flang-info-include-translate-not -flang-info-module-cmi[=module]
-stdlib=libstdc++,libc++ -Wabi-tag  -Wcatch-value  -Wcatch-value=n
-Wno-class-conversion  -Wclass-memaccess -Wcomma-subscript
-Wconditionally-supported -Wno-conversion-null
-Wctad-maybe-unsupported -Wctor-dtor-privacy  -Wdangling-reference
-Wno-defaulted-function-deleted -Wno-delete-incomplete
-Wdelete-non-virtual-dtor  -Wno-deprecated-array-compare
-Wdeprecated-copy -Wdeprecated-copy-dtor
-Wno-deprecated-enum-enum-conversion
-Wno-deprecated-enum-float-conversion -Weffc++
-Wno-elaborated-enum-base -Wno-exceptions -Wextra-semi
-Wno-global-module -Wno-inaccessible-base
-Wno-inherited-variadic-ctor  -Wno-init-list-lifetime
-Winvalid-constexpr -Winvalid-imported-macros -Wno-invalid-offsetof
-Wno-literal-suffix -Wmismatched-new-delete -Wmismatched-tags
-Wmultiple-inheritance  -Wnamespaces  -Wnarrowing -Wnoexcept
-Wnoexcept-type  -Wnon-virtual-dtor -Wpessimizing-move
-Wno-placement-new  -Wplacement-new=n -Wrange-loop-construct
-Wredundant-move -Wredundant-tags -Wreorder  -Wregister
-Wstrict-null-sentinel  -Wno-subobject-linkage  -Wtemplates
-Wno-non-template-friend  -Wold-style-cast -Woverloaded-virtual
-Wno-pmf-conversions -Wself-move -Wsign-promo -Wsized-deallocation
-Wsuggest-final-methods -Wsuggest-final-types  -Wsuggest-override
-Wno-template-body -Wno-template-id-cdtor  -Wtemplate-names-tu-local
-Wno-terminate  -Wno-vexing-parse  -Wvirtual-inheritance
-Wno-virtual-move-assign  -Wvolatile

💜 Objective-C and Objective-C++ Language Options 💜

-fconstant-string-class=class-name -fgnu-runtime  -fnext-runtime
-fno-nil-receivers -fobjc-abi-version=n -fobjc-call-cxx-cdtors
-fobjc-direct-dispatch -fobjc-exceptions -fobjc-gc -fobjc-nilcheck
-fobjc-std=objc1 -fno-local-ivars
-fivar-visibility=[public|protected|private|package]
-freplace-objc-classes -fzero-link -gen-decls -Wassign-intercept
-Wno-property-assign-default -Wno-protocol -Wobjc-root-class
-Wselector -Wstrict-selector-match -Wundeclared-selector

🌸 OpenMP and OpenACC Options 🌸

-foffload=arg  -foffload-options=arg -fopenacc  -fopenacc-dim=geom
-fopenmp  -fopenmp-simd  -fopenmp-target-simd-clone[=device-type]

🍓 Diagnostic Message Formatting Options 🍓

-fmessage-length=n -fdiagnostics-plain-output
-fdiagnostics-show-location=[once|every-line]
-fdiagnostics-color=[auto|never|always]
-fdiagnostics-urls=[auto|never|always]
-fdiagnostics-format=[text|sarif-stderr|sarif-file|json|json-
stderr|json-file] -fdiagnostics-add-output=DIAGNOSTICS-OUTPUT-SPEC
-fdiagnostics-set-output=DIAGNOSTICS-OUTPUT-SPEC
-fno-diagnostics-json-formatting -fno-diagnostics-show-option
-fno-diagnostics-show-caret -fno-diagnostics-show-event-links
-fno-diagnostics-show-labels  -fno-diagnostics-show-line-numbers
-fno-diagnostics-show-cwe -fno-diagnostics-show-rules
-fno-diagnostics-show-highlight-colors
-fdiagnostics-minimum-margin-width=width
-fdiagnostics-parseable-fixits  -fdiagnostics-generate-patch
-fdiagnostics-show-template-tree  -fno-elide-type
-fdiagnostics-path-format=[none|separate-events|inline-events]
-fdiagnostics-show-path-depths -fno-show-column
-fdiagnostics-column-unit=[display|byte]
-fdiagnostics-column-origin=origin
-fdiagnostics-escape-format=[unicode|bytes]
-fdiagnostics-text-art-charset=[none|ascii|unicode|emoji]

🌸 Warning Options 🌸

okay so this is the big warnings lineup bestie 😭🫶 every single one of these is a flag you can toss at GCC to make it speak up about sketchy code. slay.

-fsyntax-only  -fmax-errors=n  -Wpedantic -pedantic-errors
-fpermissive -w  -Wextra  -Wall  -Wabi=n -Waddress
-Wno-address-of-packed-member  -Waggregate-return -Walloc-size
-Walloc-size-larger-than=byte-size  -Walloc-zero -Walloca
-Walloca-larger-than=byte-size -Wno-aggressive-loop-optimizations
-Warith-conversion -Warray-bounds  -Warray-bounds=n  -Warray-compare
-Warray-parameter  -Warray-parameter=n -Wno-attributes
-Wattribute-alias=n -Wno-attribute-alias -Wno-attribute-warning
-Wbidi-chars=[none|unpaired|any|ucn] -Wbool-compare
-Wbool-operation -Wno-builtin-declaration-mismatch
-Wno-builtin-macro-redefined  -Wc90-c99-compat  -Wc99-c11-compat
-Wc11-c23-compat  -Wc23-c2y-compat -Wc++-compat  -Wc++11-compat
-Wc++14-compat  -Wc++17-compat -Wc++20-compat -Wno-c++11-extensions
-Wno-c++14-extensions -Wno-c++17-extensions -Wno-c++20-extensions
-Wno-c++23-extensions -Wcalloc-transposed-args -Wcast-align
-Wcast-align=strict  -Wcast-function-type  -Wcast-qual
-Wchar-subscripts -Wclobbered  -Wcomment
-Wcompare-distinct-pointer-types -Wno-complain-wrong-lang
-Wconversion  -Wno-coverage-mismatch  -Wno-cpp -Wdangling-else
-Wdangling-pointer  -Wdangling-pointer=n -Wdate-time -Wno-deprecated
-Wno-deprecated-declarations  -Wno-designated-init
-Wdisabled-optimization -Wno-discarded-array-qualifiers
-Wno-discarded-qualifiers -Wno-div-by-zero  -Wdouble-promotion
-Wduplicated-branches  -Wduplicated-cond -Wempty-body
-Wno-endif-labels  -Wenum-compare  -Wenum-conversion
-Wenum-int-mismatch -Werror  -Werror=*  -Wexpansion-to-defined
-Wfatal-errors -Wflex-array-member-not-at-end -Wfloat-conversion
-Wfloat-equal  -Wformat  -Wformat=2 -Wno-format-contains-nul
-Wno-format-extra-args -Wformat-nonliteral  -Wformat-overflow=n
-Wformat-security  -Wformat-signedness  -Wformat-truncation=n
-Wformat-y2k  -Wframe-address -Wframe-larger-than=byte-size
-Wno-free-nonheap-object -Wheader-guard  -Wno-if-not-aligned
-Wno-ignored-attributes -Wignored-qualifiers
-Wno-incompatible-pointer-types  -Whardened -Wimplicit
-Wimplicit-fallthrough  -Wimplicit-fallthrough=n
-Wno-implicit-function-declaration  -Wno-implicit-int
-Winfinite-recursion -Winit-self  -Winline  -Wno-int-conversion
-Wint-in-bool-context -Wno-int-to-pointer-cast
-Wno-invalid-memory-model -Winvalid-pch  -Winvalid-utf8
-Wno-unicode  -Wjump-misses-init -Wlarger-than=byte-size
-Wleading-whitespace=kind -Wlogical-not-parentheses  -Wlogical-op
-Wlong-long  -Wno-lto-type-mismatch -Wmain  -Wmaybe-uninitialized
-Wmemset-elt-size  -Wmemset-transposed-args -Wmisleading-indentation
-Wmissing-attributes  -Wmissing-braces -Wmissing-field-initializers
-Wmissing-format-attribute -Wmissing-include-dirs
-Wmissing-noreturn  -Wmusttail-local-addr
-Wmaybe-musttail-local-addr  -Wno-missing-profile -Wno-multichar
-Wmultistatement-macros  -Wnonnull  -Wnonnull-compare
-Wnormalized=[none|id|nfc|nfkc] -Wnull-dereference  -Wno-odr
-Wopenacc-parallelism -Wopenmp -Wopenmp-simd -Wno-overflow
-Woverlength-strings  -Wno-override-init-side-effects -Wpacked
-Wno-packed-bitfield-compat  -Wpacked-not-aligned  -Wpadded
-Wparentheses  -Wno-pedantic-ms-format -Wpointer-arith
-Wno-pointer-compare  -Wno-pointer-to-int-cast -Wno-pragmas
-Wno-pragma-once-outside-header  -Wno-prio-ctor-dtor -Wno-psabi
-Wredundant-decls  -Wrestrict -Wno-return-local-addr  -Wreturn-type
-Wno-scalar-storage-order  -Wsequence-point -Wshadow
-Wshadow=global  -Wshadow=local  -Wshadow=compatible-local
-Wno-shadow-ivar -Wno-shift-count-negative
-Wno-shift-count-overflow  -Wshift-negative-value
-Wno-shift-overflow  -Wshift-overflow=n -Wsign-compare
-Wsign-conversion -Wno-sizeof-array-argument -Wsizeof-array-div
-Wsizeof-pointer-div  -Wsizeof-pointer-memaccess -Wstack-protector
-Wstack-usage=byte-size  -Wstrict-aliasing -Wstrict-aliasing=n
-Wstrict-overflow  -Wstrict-overflow=n -Wstring-compare
-Wno-stringop-overflow -Wno-stringop-overread
-Wno-stringop-truncation  -Wstrict-flex-arrays
-Wsuggest-attribute=attribute-name -Wswitch  -Wno-switch-bool
-Wswitch-default  -Wswitch-enum -Wno-switch-outside-range
-Wno-switch-unreachable  -Wsync-nand -Wsystem-headers
-Wtautological-compare  -Wtrailing-whitespace
-Wtrailing-whitespace=kind  -Wtrampolines  -Wtrigraphs
-Wtrivial-auto-var-init  -Wno-tsan  -Wtype-limits  -Wundef
-Wuninitialized  -Wunknown-pragmas -Wunsuffixed-float-constants
-Wunterminated-string-initialization -Wunused
-Wunused-but-set-parameter  -Wunused-but-set-variable
-Wunused-const-variable  -Wunused-const-variable=n -Wunused-function
-Wunused-label  -Wunused-local-typedefs -Wunused-macros
-Wunused-parameter  -Wno-unused-result -Wunused-value
-Wunused-variable -Wuse-after-free  -Wuse-after-free=n
-Wuseless-cast -Wno-varargs  -Wvariadic-macros
-Wvector-operation-performance -Wvla  -Wvla-larger-than=byte-size
-Wno-vla-larger-than -Wvolatile-register-var  -Wwrite-strings
-Wno-xor-used-as-pow -Wzero-as-null-pointer-constant
-Wzero-length-bounds

---

🦋 Static Analyzer Options 🦋

the analyzer crew, bestie 🔍✨ these are the flags for the static analyzer. it's giving detective energy, and every checker has its own little -Wno-analyzer-... switch if you wanna mute one. no cap, it's a lot 💀

-fanalyzer -fanalyzer-call-summaries -fanalyzer-checker=name
-fno-analyzer-feasibility -fanalyzer-fine-grained
-fanalyzer-show-events-in-system-headers -fno-analyzer-state-merge
-fno-analyzer-state-purge -fno-analyzer-suppress-followups
-fanalyzer-transitivity -fno-analyzer-undo-inlining
-fanalyzer-verbose-edges -fanalyzer-verbose-state-changes
-fanalyzer-verbosity=level -fdump-analyzer -fdump-analyzer-callgraph
-fdump-analyzer-exploded-graph -fdump-analyzer-exploded-nodes
-fdump-analyzer-exploded-nodes-2 -fdump-analyzer-exploded-nodes-3
-fdump-analyzer-exploded-paths -fdump-analyzer-feasibility
-fdump-analyzer-infinite-loop -fdump-analyzer-json
-fdump-analyzer-state-purge -fdump-analyzer-stderr
-fdump-analyzer-supergraph -fdump-analyzer-untracked
-Wno-analyzer-double-fclose -Wno-analyzer-double-free
-Wno-analyzer-exposure-through-output-file
-Wno-analyzer-exposure-through-uninit-copy
-Wno-analyzer-fd-access-mode-mismatch -Wno-analyzer-fd-double-close
-Wno-analyzer-fd-leak -Wno-analyzer-fd-phase-mismatch
-Wno-analyzer-fd-type-mismatch -Wno-analyzer-fd-use-after-close
-Wno-analyzer-fd-use-without-check -Wno-analyzer-file-leak
-Wno-analyzer-free-of-non-heap -Wno-analyzer-imprecise-fp-arithmetic
-Wno-analyzer-infinite-loop -Wno-analyzer-infinite-recursion
-Wno-analyzer-jump-through-null -Wno-analyzer-malloc-leak
-Wno-analyzer-mismatching-deallocation -Wno-analyzer-null-argument
-Wno-analyzer-null-dereference -Wno-analyzer-out-of-bounds
-Wno-analyzer-overlapping-buffers
-Wno-analyzer-possible-null-argument
-Wno-analyzer-possible-null-dereference
-Wno-analyzer-putenv-of-auto-var -Wno-analyzer-shift-count-negative
-Wno-analyzer-shift-count-overflow -Wno-analyzer-stale-setjmp-buffer
-Wno-analyzer-tainted-allocation-size
-Wno-analyzer-tainted-assertion -Wno-analyzer-tainted-array-index
-Wno-analyzer-tainted-divisor -Wno-analyzer-tainted-offset
-Wno-analyzer-tainted-size -Wanalyzer-symbol-too-complex
-Wanalyzer-too-complex -Wno-analyzer-undefined-behavior-ptrdiff
-Wno-analyzer-undefined-behavior-strtok
-Wno-analyzer-unsafe-call-within-signal-handler
-Wno-analyzer-use-after-free
-Wno-analyzer-use-of-pointer-in-stale-stack-frame
-Wno-analyzer-use-of-uninitialized-value
-Wno-analyzer-va-arg-type-mismatch -Wno-analyzer-va-list-exhausted
-Wno-analyzer-va-list-leak -Wno-analyzer-va-list-use-after-va-end
-Wno-analyzer-write-to-const -Wno-analyzer-write-to-string-literal

---

💜 C and Objective-C-only Warning Options 💜

these ones are only for C and Objective-C, so if you're in C++ land they just aren't it 🙈 lowkey a super specific crew, but iconic for the people who need them 👑

-Wbad-function-cast -Wdeprecated-non-prototype -Wfree-labels
-Wmissing-declarations -Wmissing-parameter-name
-Wmissing-parameter-type -Wdeclaration-missing-parameter-type
-Wmissing-prototypes -Wmissing-variable-declarations
-Wnested-externs -Wold-style-declaration -Wold-style-definition
-Wstrict-prototypes -Wtraditional -Wtraditional-conversion
-Wdeclaration-after-statement -Wpointer-sign

---

🔍 Debugging Options 🔍

okay debugging era, bestie 🪲💖 these flags are all about getting GCC to tuck extra debug info into your build so your debugger can actually help you. the -g family is the main squad, and there are a ton of little knobs for DWARF, CodeView, BTF, CTF and friends. let's gooo ✨

-g  -glevel  -gdwarf  -gdwarf-version -gbtf -gctf  -gctflevel
-gprune-btf -gno-prune-btf -ggdb  -grecord-gcc-switches
-gno-record-gcc-switches -gstrict-dwarf  -gno-strict-dwarf
-gas-loc-support  -gno-as-loc-support -gas-locview-support
-gno-as-locview-support -gcodeview -gcolumn-info  -gno-column-info
-gdwarf32  -gdwarf64 -gstatement-frontiers  -gno-statement-frontiers
-gvariable-location-views  -gno-variable-location-views
-ginternal-reset-location-views  -gno-internal-reset-location-views
-ginline-points  -gno-inline-points -gvms -gz[=type] -gsplit-dwarf
-gdescribe-dies  -gno-describe-dies -fdebug-prefix-map=old=new
-fdebug-types-section -fno-eliminate-unused-debug-types
-femit-struct-debug-baseonly  -femit-struct-debug-reduced
-femit-struct-debug-detailed[=spec-list]
-fno-eliminate-unused-debug-symbols  -femit-class-debug-always
-fno-merge-debug-strings  -fno-dwarf2-cfi-asm -fvar-tracking
-fvar-tracking-assignments

✨ Optimization Options ✨

okay bestie, this is the big one 💅 so many flags that make your code go zoom 🔥 here's the whole lineup, no cap:

• -faggressive-loop-optimizations
• -falign-functions[=n[:m:[n2[:m2]]]]
• -falign-jumps[=n[:m:[n2[:m2]]]]
• -falign-labels[=n[:m:[n2[:m2]]]]
• -falign-loops[=n[:m:[n2[:m2]]]]
• -fmin-function-alignment=[n]
• -fno-allocation-dce
• -fallow-store-data-races
• -fassociative-math
• -fauto-profile
• -fauto-profile[=path]
• -fauto-inc-dec
• -fbranch-probabilities
• -fcaller-saves
• -fcombine-stack-adjustments
• -fconserve-stack
• -ffold-mem-offsets
• -fcompare-elim
• -fcprop-registers
• -fcrossjumping
• -fcse-follow-jumps
• -fcse-skip-blocks
• -fcx-fortran-rules
• -fcx-limited-range
• -fdata-sections
• -fdce
• -fdelayed-branch
• -fdelete-null-pointer-checks
• -fdevirtualize
• -fdevirtualize-speculatively
• -fdevirtualize-at-ltrans
• -fdse
• -fearly-inlining
• -fipa-sra
• -fexpensive-optimizations
• -ffat-lto-objects
• -ffast-math
• -ffinite-math-only
• -ffloat-store
• -fexcess-precision=style
• -ffinite-loops
• -fforward-propagate
• -ffp-contract=style
• -ffunction-sections
• -fgcse
• -fgcse-after-reload
• -fgcse-las
• -fgcse-lm
• -fgraphite-identity
• -fgcse-sm
• -fhoist-adjacent-loads
• -fif-conversion
• -fif-conversion2
• -findirect-inlining
• -finline-stringops[=fn]
• -finline-functions
• -finline-functions-called-once
• -finline-limit=n
• -finline-small-functions
• -fipa-modref
• -fipa-cp
• -fipa-cp-clone
• -fipa-bit-cp
• -fipa-vrp
• -fipa-pta
• -fipa-profile
• -fipa-pure-const
• -fipa-reference
• -fipa-reference-addressable
• -fipa-reorder-for-locality
• -fipa-stack-alignment
• -fipa-icf
• -fira-algorithm=algorithm
• -flate-combine-instructions
• -flifetime-dse
• -flive-patching=level
• -fira-region=region
• -fira-hoist-pressure
• -fira-loop-pressure
• -fno-ira-share-save-slots
• -fno-ira-share-spill-slots
• -fisolate-erroneous-paths-dereference
• -fisolate-erroneous-paths-attribute
• -fivopts
• -fkeep-inline-functions
• -fkeep-static-functions
• -fkeep-static-consts
• -flimit-function-alignment
• -flive-range-shrinkage
• -floop-block
• -floop-interchange
• -floop-strip-mine
• -floop-unroll-and-jam
• -floop-nest-optimize
• -floop-parallelize-all
• -flra-remat
• -flto
• -flto-compression-level
• -flto-partition=alg
• -flto-incremental=path
• -flto-incremental-cache-size=n
• -fmalloc-dce
• -fmerge-all-constants
• -fmerge-constants
• -fmodulo-sched
• -fmodulo-sched-allow-regmoves
• -fmove-loop-invariants
• -fmove-loop-stores
• -fno-branch-count-reg
• -fno-defer-pop
• -fno-fp-int-builtin-inexact
• -fno-function-cse
• -fno-guess-branch-probability
• -fno-inline
• -fno-math-errno
• -fno-peephole
• -fno-peephole2
• -fno-printf-return-value
• -fno-sched-interblock
• -fno-sched-spec
• -fno-signed-zeros
• -fno-toplevel-reorder
• -fno-trapping-math
• -fno-zero-initialized-in-bss
• -fomit-frame-pointer
• -foptimize-crc
• -foptimize-sibling-calls
• -fpartial-inlining
• -fpeel-loops
• -fpredictive-commoning
• -fprefetch-loop-arrays
• -fprofile-correction
• -fprofile-use
• -fprofile-use=path
• -fprofile-partial-training
• -fprofile-values
• -fprofile-reorder-functions
• -freciprocal-math
• -free
• -frename-registers
• -freorder-blocks
• -freorder-blocks-algorithm=algorithm
• -freorder-blocks-and-partition
• -freorder-functions
• -frerun-cse-after-loop
• -freschedule-modulo-scheduled-loops
• -frounding-math
• -fsave-optimization-record
• -fsched2-use-superblocks
• -fsched-pressure
• -fsched-spec-load
• -fsched-spec-load-dangerous
• -fsched-stalled-insns-dep[=n]
• -fsched-stalled-insns[=n]
• -fsched-group-heuristic
• -fsched-critical-path-heuristic
• -fsched-spec-insn-heuristic
• -fsched-rank-heuristic
• -fsched-last-insn-heuristic
• -fsched-dep-count-heuristic
• -fschedule-fusion
• -fschedule-insns
• -fschedule-insns2
• -fsection-anchors
• -fselective-scheduling
• -fselective-scheduling2
• -fsel-sched-pipelining
• -fsel-sched-pipelining-outer-loops
• -fsemantic-interposition
• -fshrink-wrap
• -fshrink-wrap-separate
• -fsignaling-nans
• -fsingle-precision-constant
• -fsplit-ivs-in-unroller
• -fsplit-loops
• -fsplit-paths
• -fsplit-wide-types
• -fsplit-wide-types-early
• -fssa-backprop
• -fssa-phiopt
• -fstdarg-opt
• -fstore-merging
• -fstrict-aliasing
• -fipa-strict-aliasing
• -fthread-jumps
• -ftracer
• -ftree-bit-ccp
• -ftree-builtin-call-dce
• -ftree-ccp
• -ftree-ch
• -ftree-coalesce-vars
• -ftree-copy-prop
• -ftree-cselim
• -ftree-dce
• -ftree-dominator-opts
• -ftree-dse
• -ftree-forwprop
• -ftree-fre
• -fcode-hoisting
• -ftree-loop-if-convert
• -ftree-loop-im
• -ftree-phiprop
• -ftree-loop-distribution
• -ftree-loop-distribute-patterns
• -ftree-loop-ivcanon
• -ftree-loop-linear
• -ftree-loop-optimize
• -ftree-loop-vectorize
• -ftree-parallelize-loops=n
• -ftree-pre
• -ftree-partial-pre
• -ftree-pta
• -ftree-reassoc
• -ftree-scev-cprop
• -ftree-sink
• -ftree-slsr
• -ftree-sra
• -ftree-switch-conversion
• -ftree-tail-merge
• -ftree-ter
• -ftree-vectorize
• -ftree-vrp
• -ftrivial-auto-var-init
• -funconstrained-commons
• -funit-at-a-time
• -funroll-all-loops
• -funroll-loops
• -funsafe-math-optimizations
• -funswitch-loops
• -fipa-ra
• -fvariable-expansion-in-unroller
• -fvect-cost-model
• -fvpt
• -fweb
• -fwhole-program
• -fwpa
• -fuse-linker-plugin
• -fzero-call-used-regs
• --param name=value
• -O
• -O0
• -O1
• -O2
• -O3
• -Os
• -Ofast
• -Og
• -Oz

---

✨ Program Instrumentation Options ✨

ooh, this bundle is all about watching your program's every move 👀🎀

• -p
• -pg
• -fprofile-arcs
• --coverage
• -ftest-coverage
• -fcondition-coverage
• -fpath-coverage
• -fprofile-abs-path
• -fprofile-dir=path
• -fprofile-generate
• -fprofile-generate=path
• -fprofile-info-section
• -fprofile-info-section=name
• -fprofile-note=path
• -fprofile-prefix-path=path
• -fprofile-update=method
• -fprofile-filter-files=regex
• -fprofile-exclude-files=regex
• -fprofile-reproducible=[multithreaded|parallel-runs|serial]
• -fsanitize=style
• -fsanitize-recover
• -fsanitize-recover=style
• -fsanitize-trap
• -fsanitize-trap=style
• -fasan-shadow-offset=number
• -fsanitize-sections=s1,s2,...
• -fsanitize-undefined-trap-on-error
• -fbounds-check
• -fcf-protection
• -fcf-protection=[full|branch|return|none|check]
• -fharden-compares
• -fharden-conditional-branches
• -fhardened
• -fharden-control-flow-redundancy
• -fhardcfr-skip-leaf
• -fhardcfr-check-exceptions
• -fhardcfr-check-returning-calls
• -fhardcfr-check-noreturn-calls=[always|no-xthrow|nothrow|never]
• -fstack-protector
• -fstack-protector-all
• -fstack-protector-strong
• -fstack-protector-explicit
• -fstack-check
• -fstack-limit-register=reg
• -fstack-limit-symbol=sym
• -fno-stack-limit
• -fsplit-stack
• -fstrub=disable
• -fstrub=strict
• -fstrub=relaxed
• -fstrub=all
• -fstrub=at-calls
• -fstrub=internal
• -fvtable-verify=[std|preinit|none]
• -fvtv-counts
• -fvtv-debug
• -finstrument-functions
• -finstrument-functions-once
• -finstrument-functions-exclude-function-list=sym,sym,...
• -finstrument-functions-exclude-file-list=file,file,...
• -fprofile-prefix-map=old=new
• -fpatchable-function-entry=N[,M]

---

✨ Preprocessor Options ✨

the preprocessor is basically the prep team before the main event 🧚

• -Aquestion=answer
• -A-question[=answer]
• -C
• -CC
• -Dmacro[=defn]
• -dD
• -dI
• -dM
• -dN
• -dU
• -fdebug-cpp
• -fdirectives-only
• -fdollars-in-identifiers
• -fexec-charset=charset
• -fextended-identifiers
• -finput-charset=charset
• -fmacro-prefix-map=old=new
• -fmax-include-depth=depth
• -fno-canonical-system-headers
• -fpch-deps
• -fpch-preprocess
• -fpreprocessed
• -ftabstop=width
• -ftrack-macro-expansion
• -fwide-exec-charset=charset
• -fworking-directory
• -H
• -imacros file
• -include file
• -M
• -MD
• -MF
• -MG
• -MM
• -MMD
• -MP
• -MQ
• -MT
• -Mno-modules
• -no-integrated-cpp
• -P
• -pthread
• -remap
• -traditional
• -traditional-cpp
• -trigraphs
• -Umacro
• -undef
• -Wp,option
• -Xpreprocessor option

---

✨ Assembler Options ✨

just two, but they slay 🫶

• -Wa,option
• -Xassembler option

---

✨ Linker Options ✨

the linker is where everything comes together, bestie 🔗👑

• object-file-name
• -fuse-ld=linker
• -llibrary
• -nostartfiles
• -nodefaultlibs
• -nolibc
• -nostdlib
• -nostdlib++
• -e entry
• --entry=entry
• -pie
• -pthread
• -r
• -rdynamic
• -s
• -static
• -static-pie
• -static-libgcc
• -static-libstdc++
• -static-libasan
• -static-libtsan
• -static-liblsan
• -static-libubsan
• -shared
• -shared-libgcc
• -symbolic
• -T script
• -Wl,option
• -Xlinker option
• -u symbol
• -z keyword

---

✨ Directory Options ✨

where the compiler goes looking for stuff 🗺️🦋

• -Bprefix
• -Idir
• -I-
• -idirafter dir
• -imacros file
• -imultilib dir
• -iplugindir=dir
• -iprefix file
• -iquote dir
• -isysroot dir
• -isystem dir
• -iwithprefix dir
• -iwithprefixbefore dir
• --embed-dir=dir
• -Ldir
• -no-canonical-prefixes
• --no-sysroot-suffix
• -nostdinc
• -nostdinc++
• --sysroot=dir

---

✨ Code Generation Options ✨

this is where the actual machine code gets shaped 🔥💖

• -fcall-saved-reg
• -fcall-used-reg
• -ffixed-reg
• -fexceptions
• -fnon-call-exceptions
• -fdelete-dead-exceptions
• -funwind-tables
• -fasynchronous-unwind-tables
• -fno-gnu-unique
• -finhibit-size-directive
• -fcommon
• -fno-ident
• -fpcc-struct-return
• -fpic
• -fPIC
• -fpie
• -fPIE
• -fno-plt
• -fno-jump-tables
• -fno-bit-tests
• -frecord-gcc-switches
• -freg-struct-return
• -fshort-enums
• -fshort-wchar
• -fverbose-asm
• -fpack-struct[=n]
• -fleading-underscore
• -ftls-model=model
• -fstack-reuse=reuse_level
• -ftrampolines
• -ftrampoline-impl=[stack|heap]
• -ftrapv
• -fwrapv
• -fvisibility=[default|internal|hidden|protected]
• -fstrict-volatile-bitfields
• -fsync-libcalls
• -fzero-init-padding-bits=value

---

✨ Developer Options ✨

for the power users 🤓💅 these are the debugging and dumping flags, so handle with care (and snacks) 🍓

• -dletters
• -dumpspecs
• -dumpmachine
• -dumpversion
• -dumpfullversion
• -fcallgraph-info[=su,da]
• -fchecking
• -fchecking=n
• -fdbg-cnt-list
• -fdbg-cnt=counter-value-list
• -fdisable-ipa-pass_name
• -fdisable-rtl-pass_name
• -fdisable-rtl-pass-name=range-list
• -fdisable-tree-pass_name
• -fdisable-tree-pass-name=range-list
• -fdump-debug
• -fdump-earlydebug
• -fdump-noaddr
• -fdump-unnumbered
• -fdump-unnumbered-links
• -fdump-final-insns[=file]
• -fdump-ipa-all
• -fdump-ipa-cgraph
• -fdump-ipa-inline
• -fdump-lang-all
• -fdump-lang-switch
• -fdump-lang-switch-options
• -fdump-lang-switch-options=filename
• -fdump-passes
• -fdump-rtl-pass
• -fdump-rtl-pass=filename
• -fdump-statistics
• -fdump-tree-all
• -fdump-tree-switch
• -fdump-tree-switch-options
• -fdump-tree-switch-options=filename
• -fcompare-debug[=opts]
• -fcompare-debug-second
• -fenable-kind-pass
• -fenable-kind-pass=range-list
• -fira-verbose=n
• -flto-report
• -flto-report-wpa
• -fmem-report-wpa
• -fmem-report
• -fpre-ipa-mem-report
• -fpost-ipa-mem-report
• -fopt-info
• -fopt-info-options[=file]
• -fmultiflags
• -fprofile-report
• -frandom-seed=string
• -fsched-verbose=n
• -fsel-sched-verbose
• -fsel-sched-dump-cfg
• -fsel-sched-pipelining-verbose
• -fstats
• -fstack-usage
• -ftime-report
• -ftime-report-details
• -fvar-tracking-assignments-toggle
• -gtoggle
• -print-file-name=library
• -print-libgcc-file-name
• -print-multi-directory
• -print-multi-lib
• -print-multi-os-directory
• -print-prog-name=program
• -print-search-dirs
• -Q
• -print-sysroot
• -print-sysroot-headers-suffix
• -save-temps
• -save-temps=cwd
• -save-temps=obj
• -time[=file]

🦋 Machine-Dependent Options 🦋

okay so this part is the machine-specific squad 💅 every architecture gets its own little group of flags, and they only matter for their own chip family 🧚 let's go bestie 💖

✨ AArch64 Options (AArch64 Options) ✨

• -mabi=name — slay flag 💅
• -mbig-endian — big-endian drip 🌸
• -mlittle-endian — little-endian drip 🌸
• -mgeneral-regs-only — general registers only 🎀
• -mcmodel=tiny — tiny code model 🧚
• -mcmodel=small — small code model 🧚
• -mcmodel=large — large code model 🧚
• -mstrict-align — strict alignment 📏
• -mno-strict-align — strict alignment, turned off 🙈
• -momit-leaf-frame-pointer — leaf frame pointer goes bye 👋
• -mtls-dialect=desc — desc TLS dialect 🦋
• -mtls-dialect=traditional — traditional TLS dialect 🦋
• -mtls-size=size — TLS size 📐
• -mfix-cortex-a53-835769 — Cortex-A53 erratum fix 🔧
• -mfix-cortex-a53-843419 — another Cortex-A53 fix 🔧
• -mlow-precision-recip-sqrt — low-precision reciprocal sqrt 🧮
• -mlow-precision-sqrt — low-precision sqrt 🧮
• -mlow-precision-div — low-precision division 🧮
• -mpc-relative-literal-loads — PC-relative literal loads 🌈
• -msign-return-address=scope — return address signing ✍️
• -mbranch-protection=none|standard|pac-ret[+leaf +b-key]|bti|gcs — branch protection, pick your vibe 🛡️
• -mharden-sls=opts — straight-line speculation hardening 🛡️
• -march=name — architecture of choice 🏛️
• -mcpu=name — CPU of choice 🧠
• -mtune=name — tuning target 🎚️
• -moverride=string — override string 📝
• -mverbose-cost-dump — verbose cost dump 📜
• -mstack-protector-guard=guard — stack protector guard 🛡️
• -mstack-protector-guard-reg=sysreg — guard system register 🛡️
• -mstack-protector-guard-offset=offset — guard offset 🛡️
• -mtrack-speculation — speculation tracking 👀
• -moutline-atomics — outline atomics 🔥
• -mearly-ldp-fusion — early LDP fusion 🔗
• -mlate-ldp-fusion — late LDP fusion 🔗
• -Wexperimental-fmv-target — experimental FMV target warning ⚠️

🐝 Adapteva Epiphany Options (Adapteva Epiphany Options) 🐝

• -mhalf-reg-file — half register file 🌙
• -mprefer-short-insn-regs — prefer short instruction registers 🌙
• -mbranch-cost=num — branch cost 💸
• -mcmove — conditional move 🎀
• -mnops=num — number of nops 🫧
• -msoft-cmpsf — soft compare for floats 🧃
• -msplit-lohi — split low and high 🍓
• -mpost-inc — post-increment 📈
• -mpost-modify — post-modify 📈
• -mstack-offset=num — stack offset 📚
• -mround-nearest — round to nearest 🎯
• -mlong-calls — long calls 📞
• -mshort-calls — short calls 📱
• -msmall16 — small16 🧸
• -mfp-mode=mode — FP mode 🌊
• -mvect-double — vector double 👯
• -max-vect-align=num — max vector alignment 📐
• -msplit-vecmove-early — split vector moves early ⏩
• -m1reg-reg — one reg-reg 🫶

🌀 AMD GCN Options (AMD GCN Options) 🌀

• -march=gpu — GPU architecture 🎮
• -mtune=gpu — GPU tuning 🎮
• -mstack-size=bytes — stack size in bytes 📏

🌺 ARC Options (ARC Options) 🌺

• -mbarrel-shifter — barrel shifter 🌀
• -mjli-always — JLI always 🌀
• -mcpu=cpu — CPU pick 🧠
• -mA6 — A6 🧩
• -mARC600 — ARC600 🧩
• -mA7 — A7 🧩
• -mARC700 — ARC700 🧩
• -mdpfp — double-precision FP 🔢
• -mdpfp-compact — compact double-precision FP 🔢
• -mdpfp-fast — fast double-precision FP 🔢
• -mno-dpfp-lrsr — no DPFP LR/SR ❌
• -mea — extension access 🔓
• -mno-mpy — no multiply ❌
• -mmul32x16 — 32x16 multiply ✖️
• -mmul64 — 64-bit multiply ✖️
• -matomic — atomics ⚛️
• -mnorm — norm instruction 🧭
• -mspfp — single-precision FP 🔢
• -mspfp-compact — compact single-precision FP 🔢
• -mspfp-fast — fast single-precision FP 🔢
• -msimd — SIMD 🎶
• -msoft-float — soft float 🧈
• -mswap — swap 🔄
• -mcrc — CRC 🧮
• -mdsp-packa — DSP pack-A 📦
• -mdvbf — DVBF 🧩
• -mlock — lock 🔒
• -mmac-d16 — MAC D16 🧮
• -mmac-24 — MAC 24 🧮
• -mrtsc — RTSC ⏱️
• -mswape — swape 🔄
• -mtelephony — telephony 📞
• -mxy — XY memory 🧠
• -misize — instruction size 📏
• -mannotate-align — annotate alignment 📝
• -marclinux — ARC Linux 🐧
• -marclinux_prof — ARC Linux with profiling 🐧
• -mlong-calls — long calls 📞
• -mmedium-calls — medium calls 📞
• -msdata — small data 📦
• -mirq-ctrl-saved — IRQ control saved 🛑
• -mrgf-banked-regs — banked register file 🏦
• -mlpc-width=width — LPC width 📏
• -G num — small-data threshold 📦
• -mvolatile-cache — volatile cache 🗄️
• -mtp-regno=regno — TP register number 🔢
• -malign-call — align calls 📐
• -mauto-modify-reg — auto-modify register 🔧
• -mbbit-peephole — BBIT peephole 🔍
• -mno-brcc — no BRcc ❌
• -mcase-vector-pcrel — PC-relative case vectors 🧭
• -mcompact-casesi — compact casesi 📦
• -mno-cond-exec — no conditional execution ❌
• -mearly-cbranchsi — early cbranchsi ⏩
• -mexpand-adddi — expand adddi ➕
• -mindexed-loads — indexed loads 📚
• -mlra — LRA 🧠
• -mlra-priority-none — LRA priority none 🧠
• -mlra-priority-compact — LRA priority compact 🧠
• -mlra-priority-noncompact — LRA priority noncompact 🧠
• -mmillicode — millicode 🧞
• -mmixed-code — mixed code 🎨
• -mq-class — Q class 🏷️
• -mRcq — Rcq 🏷️
• -mRcw — Rcw 🏷️
• -msize-level=level — size level 📏
• -mtune=cpu — tuning CPU 🎚️
• -mmultcost=num — multiply cost 💸
• -mcode-density-frame — code density frame 🧱
• -munalign-prob-threshold=probability — unaligned probability threshold 🎲
• -mmpy-option=multo — multiply option 🧮
• -mdiv-rem — divide and remainder ➗
• -mcode-density — code density 🧱
• -mll64 — LL64 🧩
• -mfpu=fpu — FPU pick 🔢
• -mrf16 — RF16 🧩
• -mbranch-index — branch index 🧭

🎨 ARM Options (ARM Options) 🎨

• -mapcs-frame — APCS frame 🖼️
• -mno-apcs-frame — no APCS frame ❌
• -mabi=name — ABI pick 🧾
• -mapcs-stack-check — APCS stack check 🔍
• -mno-apcs-stack-check — no APCS stack check ❌
• -mapcs-reentrant — APCS reentrant 🔁
• -mno-apcs-reentrant — no APCS reentrant ❌
• -mgeneral-regs-only — general registers only 🎀
• -msched-prolog — scheduled prologue 🗓️
• -mno-sched-prolog — no scheduled prologue ❌
• -mlittle-endian — little-endian 🌸
• -mbig-endian — big-endian 🌸
• -mbe8 — BE-8 🌸
• -mbe32 — BE-32 🌸
• -mfloat-abi=name — float ABI 🧈
• -mfp16-format=name — FP16 format 🔢
• -mthumb-interwork — Thumb interworking 🔀
• -mno-thumb-interwork — no Thumb interworking ❌
• -mcpu=name — CPU pick 🧠
• -march=name — architecture pick 🏛️
• -mfpu=name — FPU pick 🔢
• -mtune=name — tuning pick 🎚️
• -mprint-tune-info — print tuning info 🖨️
• -mstructure-size-boundary=n — structure size boundary 📏
• -mabort-on-noreturn — abort on noreturn 🛑
• -mlong-calls — long calls 📞
• -mno-long-calls — no long calls ❌
• -msingle-pic-base — single PIC base 🧭
• -mno-single-pic-base — no single PIC base ❌
• -mpic-register=reg — PIC register 🧭
• -mnop-fun-dllimport — nop for dllimport 🫧
• -mpoke-function-name — poke function name 📝
• -mthumb — Thumb 🧵
• -marm — ARM mode 🎨
• -mflip-thumb — flip Thumb 🔁
• -mtpcs-frame — TPCS frame 🖼️
• -mtpcs-leaf-frame — TPCS leaf frame 🖼️
• -mcaller-super-interworking — caller super interworking 🔀
• -mcallee-super-interworking — callee super interworking 🔀
• -mtp=name — TP pick 🧵
• -mtls-dialect=dialect — TLS dialect 🦋
• -mword-relocations — word relocations 🧩
• -mfix-cortex-m3-ldrd — Cortex-M3 LDRD fix 🔧
• -mfix-cortex-a57-aes-1742098 — Cortex-A57 AES fix 🔧
• -mfix-cortex-a72-aes-1655431 — Cortex-A72 AES fix 🔧
• -munaligned-access — unaligned access 🫸
• -mneon-for-64bits — NEON for 64-bit 🎶
• -mslow-flash-data — slow flash data 🐢
• -masm-syntax-unified — unified assembler syntax 📝
• -mrestrict-it — restrict IT 🔒
• -mverbose-cost-dump — verbose cost dump 📜
• -mpure-code — pure code 🧼
• -mcmse — CMSE 🛡️
• -mfix-cmse-cve-2021-35465 — CMSE CVE fix 🛡️
• -mstack-protector-guard=guard — stack protector guard 🛡️
• -mstack-protector-guard-offset=offset — guard offset 🛡️
• -mfdpic — FDPIC 🧭
• -mbranch-protection=none|standard|pac-ret[+leaf] — branch protection, pick your vibe 🛡️
• [+bti]|bti[+pac-ret[+leaf]] — the rest of the branch protection combos 🛡️

⚡ AVR Options (AVR Options) ⚡

• -mmcu=mcu — MCU pick 🧠
• -mabsdata — absolute data 📦
• -maccumulate-args — accumulate args 📚
• -mcvt — CVT 🔁
• -mbranch-cost=cost — branch cost 💸
• -mfuse-add=level — fuse add level ➕
• -mfuse-move=level — fuse move level ➡️
• -mfuse-move2 — fuse move 2 ➡️
• -mcall-prologues — call prologues 🗓️
• -mgas-isr-prologues — GAS ISR prologues 🗓️
• -mint8 — int8 🔢
• -mflmap — flmap 🗺️
• -mdouble=bits — double width 🔢
• -mlong-double=bits — long double width 🔢
• -mno-call-main — no call to main ❌
• -mn_flash=size — flash size 🗄️
• -mfract-convert-truncate — fract convert truncate ✂️
• -mno-interrupts — no interrupts ❌
• -mmain-is-OS_task — main is an OS task 🧵
• -mrelax — relax 🧘
• -mrmw — read-modify-write ✏️
• -mstrict-X — strict X 🧭
• -mtiny-stack — tiny stack 🧸
• -mrodata-in-ram — rodata in RAM 🧠
• -msplit-bit-shift — split bit shift ↔️
• -msplit-ldst — split load/store 📦
• -mshort-calls — short calls 📱
• -mskip-bug — skip bug 🐛
• -muse-nonzero-bits — use nonzero bits 🎯
• -nodevicelib — no device library 🚫
• -nodevicespecs — no device specs 🚫
• -Waddr-space-convert — address space convert warning ⚠️
• -Wmisspelled-isr — misspelled ISR warning ⚠️

🎵 Blackfin Options (Blackfin Options) 🎵

• -mcpu=cpu[-sirevision] — CPU and silicon revision 🧠
• -msim — simulator 🎮
• -momit-leaf-frame-pointer — leaf frame pointer goes bye 👋
• -mno-omit-leaf-frame-pointer — leaf frame pointer stays 🫶
• -mspecld-anomaly — speculative load anomaly 🐛
• -mno-specld-anomaly — no speculative load anomaly ❌
• -mcsync-anomaly — CSYNC anomaly 🐛
• -mno-csync-anomaly — no CSYNC anomaly ❌
• -mlow-64k — low 64k 🧠
• -mno-low64k — no low 64k ❌
• -mstack-check-l1 — stack check L1 🔍
• -mid-shared-library — ID shared library 📚
• -mno-id-shared-library — no ID shared library ❌
• -mshared-library-id=n — shared library ID 🔢
• -mleaf-id-shared-library — leaf ID shared library 📚
• -mno-leaf-id-shared-library — no leaf ID shared library ❌
• -msep-data — separate data 🧩
• -mno-sep-data — no separate data ❌
• -mlong-calls — long calls 📞
• -mno-long-calls — no long calls ❌
• -mfast-fp — fast FP 🚀
• -minline-plt — inline PLT 🧵
• -mmulticore — multicore 🧠
• -mcorea — core A 🅰️
• -mcoreb — core B 🅱️
• -msdram — SDRAM 🗄️
• -micplb — ICPLB 🧱

🧩 C6X Options (C6X Options) 🧩

• -mbig-endian — big-endian 🌸
• -mlittle-endian — little-endian 🌸
• -march=cpu — architecture pick 🏛️
• -msim — simulator 🎮
• -msdata=sdata-type — small data type 📦

🦎 CRIS Options (CRIS Options) 🦎

• -mcpu=cpu — CPU pick 🧠
• -march=cpu — architecture pick 🏛️
• -mtune=cpu — tuning pick 🎚️
• -mmax-stack-frame=n — max stack frame size 📏
• -metrax4 — ETRAX 4 🧩
• -metrax100 — ETRAX 100 🧩
• -mpdebug — P-debug 🔍
• -mcc-init — CC init 🧭
• -mno-side-effects — no side effects ❌
• -mstack-align — stack alignment 📐
• -mdata-align — data alignment 📐
• -mconst-align — constant alignment 📐
• -m32-bit — 32-bit 🔢
• -m16-bit — 16-bit 🔢
• -m8-bit — 8-bit 🔢
• -mno-prologue-epilogue — no prologue or epilogue ❌
• -melf — ELF 🧾
• -maout — a.out 🧾
• -sim — simulator 🎮
• -sim2 — simulator 2 🎮
• -mmul-bug-workaround — multiply bug workaround 🐛
• -mno-mul-bug-workaround — no multiply bug workaround ❌

🌙 C-SKY Options (C-SKY Options) 🌙

• -march=arch — architecture pick 🏛️
• -mcpu=cpu — CPU pick 🧠
• -mbig-endian — big-endian 🌸
• -EB — big-endian, the short way 🌸
• -mlittle-endian — little-endian 🌸
• -EL — little-endian, the short way 🌸
• -mhard-float — hard float 🧈
• -msoft-float — soft float 🧈
• -mfpu=fpu — FPU pick 🔢
• -mdouble-float — double float 🔢
• -mfdivdu — FDIVDU ➗
• -mfloat-abi=name — float ABI 🧈
• -melrw — ELRW 🧩
• -mistack — interrupt stack 🛑
• -mmp — MP 🧵
• -mcp — CP 🧩
• -mcache — cache 🗄️
• -msecurity — security 🛡️
• -mtrust — trust 🛡️
• -mdsp — DSP 🎶
• -medsp — enhanced DSP 🎶
• -mvdsp — vector DSP 🎶
• -mdiv — divide ➗
• -msmart — smart mode 🧠
• -mhigh-registers — high registers 🏔️
• -manchor — anchor 🧭
• -mpushpop — push and pop 📚
• -mmultiple-stld — multiple load/store 📦
• -mconstpool — constant pool 🧺
• -mstack-size — stack size 📏
• -mccrt — CCRT 🧩
• -mbranch-cost=n — branch cost 💸
• -mcse-cc — CSE CC 🔁
• -msched-prolog — scheduled prologue 🗓️
• -msim — simulator 🎮

🪟 Cygwin and MinGW Options (Cygwin and MinGW Options) 🪟

• -mconsole — console 🖥️
• -mcrtdll=library — CRT DLL library 📚
• -mdll — DLL 🧩
• -mnop-fun-dllimport — nop for dllimport 🫧
• -mthread — thread 🧵
• -municode — Unicode 🔤
• -mwin32 — Win32 🪟
• -mwindows — Windows 🪟
• -fno-set-stack-executable — no executable stack setting 🚫

🍎 Darwin Options (Darwin Options) 🍎

• -all_load — all load 📥
• -allowable_client — allowable client 🧑‍🤝‍🧑
• -arch — arch 🏛️
• -arch_errors_fatal — arch errors fatal 🛑
• -arch_only — arch only 🏛️
• -bind_at_load — bind at load 🔗
• -bundle — bundle 📦
• -bundle_loader — bundle loader 📦
• -client_name — client name 🏷️
• -compatibility_version — compatibility version 🔢
• -current_version — current version 🔢
• -dead_strip — dead strip ✂️
• -dependency-file — dependency file 📄
• -dylib_file — dylib file 📄
• -dylinker_install_name — dylinker install name 🏷️
• -dynamic — dynamic 🌀
• -dynamiclib — dynamic library 📚
• -exported_symbols_list — exported symbols list 📜
• -filelist — file list 📜
• -flat_namespace — flat namespace 🗂️
• -force_cpusubtype_ALL — force CPU subtype ALL 🧠
• -force_flat_namespace — force flat namespace 🗂️
• -headerpad_max_install_names — header pad for install names 📏
• -iframework — include framework 📚
• -image_base — image base 🖼️
• -init — init 🌱
• -install_name — install name 🏷️
• -keep_private_externs — keep private externs 🔒
• -multi_module — multi-module 🧩
• -multiply_defined — multiply defined 🔁
• -multiply_defined_unused — multiply defined unused 🔁
• -noall_load — no all load ❌
• -no_dead_strip_inits_and_terms — no dead stripping of inits and terms 🚫
• -nodefaultrpaths — no default rpaths 🚫
• -nofixprebinding — no fix prebinding 🚫
• -nomultidefs — no multidefs 🚫
• -noprebind — no prebind 🚫
• -noseglinkedit — no segment link edit 🚫
• -pagezero_size — page zero size 📏
• -prebind — prebind 🔗
• -prebind_all_twolevel_modules — prebind all two-level modules 🔗
• -private_bundle — private bundle 🔒
• -read_only_relocs — read-only relocs 📖
• -sectalign — section align 📐
• -sectobjectsymbols — section object symbols 🧾
• -whyload — why load ❓
• -seg1addr — segment 1 address 📍
• -sectcreate — section create 🧱
• -sectobjectsymbols — section object symbols 🧾
• -sectorder — section order 📚
• -segaddr — segment address 📍
• -segs_read_only_addr — segments read-only address 📍
• -segs_read_write_addr — segments read-write address 📍
• -seg_addr_table — segment address table 🗂️
• -seg_addr_table_filename — segment address table filename 📄
• -seglinkedit — segment link edit 🔗
• -segprot — segment protection 🛡️
• -segs_read_only_addr — segments read-only address 📍
• -segs_read_write_addr — segments read-write address 📍
• -single_module — single module 🧩
• -static — static 🧱
• -sub_library — sub library 📚
• -sub_umbrella — sub umbrella ☂️
• -twolevel_namespace — two-level namespace 🗂️
• -umbrella — umbrella ☂️
• -undefined — undefined ❓
• -unexported_symbols_list — unexported symbols list 📜
• -weak_reference_mismatches — weak reference mismatches ⚠️
• -whatsloaded — what's loaded 📋
• -F — framework path 📁
• -gused — gused 🧾
• -gfull — gfull 🧾
• -mmacosx-version-min=version — minimum macOS version 🍏
• -mkernel — kernel 🧠
• -mone-byte-bool — one-byte bool 🔢

🧭 DEC Alpha Options (DEC Alpha Options) 🧭

• -mno-fp-regs — no FP registers ❌
• -msoft-float — soft float 🧈
• -mieee — IEEE 🔢
• -mieee-with-inexact — IEEE with inexact 🔢
• -mieee-conformant — IEEE conformant 🔢
• -mfp-trap-mode=mode — FP trap mode 🪤
• -mfp-rounding-mode=mode — FP rounding mode 🎯
• -mtrap-precision=mode — trap precision 🎯
• -mbuild-constants — build constants 🧱
• -mcpu=cpu-type — CPU type pick 🧠
• -mtune=cpu-type — tuning CPU type 🎚️
• -mbwx — BWX 🧩
• -mmax — MAX 🧩
• -mfix — FIX 🧩
• -mcix — CIX 🧩
• -msafe-bwa — safe BWA 🛡️
• -msafe-partial — safe partial 🛡️
• -mfloat-vax — VAX float 🧈
• -mfloat-ieee — IEEE float 🧈
• -mexplicit-relocs — explicit relocs 🧩
• -msmall-data — small data 📦
• -mlarge-data — large data 📦
• -msmall-text — small text 📦
• -mlarge-text — large text 📦
• -mmemory-latency=time — memory latency 🕰️

🐝 eBPF Options (eBPF Options) 🐝

• -mbig-endian — big-endian 🌸
• -mlittle-endian — little-endian 🌸
• -mframe-limit=bytes — frame limit in bytes 📏
• -mxbpf — XBPF 🧩
• -mco-re — CO-RE 🧩
• -mno-co-re — no CO-RE ❌
• -mjmpext — jump extension ⏩
• -mjmp32 — 32-bit jumps ⏩
• -malu32 — ALU32 ➕
• -mv3-atomics — v3 atomics ⚛️
• -mbswap — byte swap 🔄
• -msdiv — signed divide ➗
• -msmov — signed move ➡️
• -mcpu=version — CPU version 🧠
• -masm=dialect — assembler dialect 📝
• -minline-memops-threshold=bytes — inline memops threshold 📏

🦋 FR30 Options (FR30 Options) 🦋

• -msmall-model — small model 🧸
• -mno-lsim — no LSIM ❌

🌷 FT32 Options (FT32 Options) 🌷

• -msim — simulator 🎮
• -mlra — LRA 🧠
• -mnodiv — no divide ❌
• -mft32b — FT32B 🧩
• -mcompress — compress 🗜️
• -mnopm — no PM ❌

🌈 FRV Options (FRV Options) 🌈

• -mgpr-32 — 32 GPRs 🔢
• -mgpr-64 — 64 GPRs 🔢
• -mfpr-32 — 32 FPRs 🔢
• -mfpr-64 — 64 FPRs 🔢
• -mhard-float — hard float 🧈
• -msoft-float — soft float 🧈
• -malloc-cc — alloc CC 🧭
• -mfixed-cc — fixed CC 🧭
• -mdword — doubleword 🔢
• -mno-dword — no doubleword ❌
• -mdouble — double 🔢
• -mno-double — no double ❌
• -mmedia — media 🎶
• -mno-media — no media ❌
• -mmuladd — multiply-add ✖️
• -mno-muladd — no multiply-add ❌
• -mfdpic — FDPIC 🧭
• -minline-plt — inline PLT 🧵
• -mgprel-ro — GP-relative read-only 📖
• -multilib-library-pic — multilib library PIC 📚
• -mlinked-fp — linked frame pointer 🔗
• -mlong-calls — long calls 📞
• -malign-labels — align labels 📐
• -mlibrary-pic — library PIC 📚
• -macc-4 — ACC 4 🧩
• -macc-8 — ACC 8 🧩
• -mpack — pack 📦
• -mno-pack — no pack ❌
• -mno-eflags — no eflags ❌
• -mcond-move — conditional move 🎀
• -mno-cond-move — no conditional move ❌
• -moptimize-membar — optimize membar 🧹
• -mno-optimize-membar — no membar optimization ❌
• -mscc — SCC 🧩
• -mno-scc — no SCC ❌
• -mcond-exec — conditional execution 🎛️
• -mno-cond-exec — no conditional execution ❌
• -mvliw-branch — VLIW branch 🧠
• -mno-vliw-branch — no VLIW branch ❌
• -mmulti-cond-exec — multi conditional execution 🎛️
• -mno-multi-cond-exec — no multi conditional execution ❌
• -mnested-cond-exec — nested conditional execution 🪆
• -mno-nested-cond-exec — no nested conditional execution ❌
• -mtomcat-stats — Tomcat stats 📊
• -mTLS — TLS 🦋
• -mtls — TLS 🦋
• -mcpu=cpu — CPU pick 🧠

🐧 GNU/Linux Options (GNU/Linux Options) 🐧

• -mglibc — glibc 🐧
• -muclibc — uClibc 🐧
• -mmusl — musl 🐧
• -mbionic — Bionic 🤖
• -mandroid — Android 🤖
• -tno-android-cc — no Android CC ❌
• -tno-android-ld — no Android LD ❌

🕹️ H8/300 Options (H8/300 Options) 🕹️

• -mrelax — relax 🧘
• -mh — H 🔤
• -ms — S 🔤
• -mn — N 🔤
• -mexr — EXR 🧩
• -mno-exr — no EXR ❌
• -mint32 — int32 🔢
• -malign-300 — align 300 📐

🧱 HPPA Options (HPPA Options) 🧱

• -march=architecture-type — architecture type 🏛️
• -matomic-libcalls — atomic libcalls ⚛️
• -mbig-switch — big switch 🔀
• -mcaller-copies — caller copies 📋
• -mdisable-fpregs — disable FP registers 🚫
• -mdisable-indexing — disable indexing 🚫
• -mordered — ordered 📚
• -mfast-indirect-calls — fast indirect calls 🚀
• -mgas — GAS 🧩
• -mgnu-ld — GNU ld 🧩
• -mhp-ld — HP ld 🧩
• -mfixed-range=register-range — fixed register range 📏
• -mcoherent-ldcw — coherent LDCW 🧲
• -mjump-in-delay — jump in delay slot ⏩
• -mlinker-opt — linker optimization 🧹
• -mlong-calls — long calls 📞
• -mlong-load-store — long load/store 📦
• -mno-atomic-libcalls — no atomic libcalls ❌
• -mno-disable-fpregs — no disabling FP registers ✅
• -mno-disable-indexing — no disabling indexing ✅
• -mno-fast-indirect-calls — no fast indirect calls ❌
• -mno-gas — no GAS ❌
• -mno-jump-in-delay — no jump in delay slot ❌
• -mno-long-load-store — no long load/store ❌
• -mno-portable-runtime — no portable runtime ❌
• -mno-soft-float — no soft float ❌
• -mno-space-regs — no space registers ❌
• -msoft-float — soft float 🧈
• -mpa-risc-1-0 — PA-RISC 1.0 🧱
• -mpa-risc-1-1 — PA-RISC 1.1 🧱
• -mpa-risc-2-0 — PA-RISC 2.0 🧱
• -mportable-runtime — portable runtime 📱
• -mschedule=cpu-type — schedule CPU type 🗓️
• -mspace-regs — space registers 🌌
• -msoft-mult — soft multiply ✖️
• -msio — SIO 🧩
• -mwsio — WSIO 🧩
• -munix=unix-std — UNIX standard 🧾
• -nolibdld — no libdld 🚫
• -static — static 🧱
• -threads — threads 🧵

🏔️ IA-64 Options (IA-64 Options) 🏔️

• -mbig-endian — big-endian 🌸
• -mlittle-endian — little-endian 🌸
• -mgnu-as — GNU as 🧩
• -mgnu-ld — GNU ld 🧩
• -mno-pic — no PIC ❌
• -mvolatile-asm-stop — volatile asm stop 🛑
• -mregister-names — register names 🏷️
• -msdata — small data 📦
• -mno-sdata — no small data ❌
• -mconstant-gp — constant GP 🧭
• -mauto-pic — auto PIC 🧭
• -mfused-madd — fused multiply-add ✖️
• -minline-float-divide-min-latency — inline float divide, min latency ➗
• -minline-float-divide-max-throughput — inline float divide, max throughput ➗
• -mno-inline-float-divide — no inline float divide ❌
• -minline-int-divide-min-latency — inline int divide, min latency ➗
• -minline-int-divide-max-throughput — inline int divide, max throughput ➗
• -mno-inline-int-divide — no inline int divide ❌
• -minline-sqrt-min-latency — inline sqrt, min latency 🧮
• -minline-sqrt-max-throughput — inline sqrt, max throughput 🧮
• -mno-inline-sqrt — no inline sqrt ❌
• -mdwarf2-asm — DWARF2 asm 🧾
• -mearly-stop-bits — early stop bits 🛑
• -mfixed-range=register-range — fixed register range 📏
• -mtls-size=tls-size — TLS size 📐
• -mtune=cpu-type — tuning CPU type 🎚️
• -milp32 — ILP32 🔢
• -mlp64 — LP64 🔢
• -msched-br-data-spec — branch data speculation 🔮
• -msched-ar-data-spec — AR data speculation 🔮
• -msched-control-spec — control speculation 🔮
• -msched-br-in-data-spec — branch in data speculation 🔮
• -msched-ar-in-data-spec — AR in data speculation 🔮
• -msched-in-control-spec — in-control speculation 🔮
• -msched-spec-ldc — speculative LDC 🔮
• -msched-spec-control-ldc — speculative control LDC 🔮
• -msched-prefer-non-data-spec-insns — prefer non-data-speculative insns 🎯
• -msched-prefer-non-control-spec-insns — prefer non-control-speculative insns 🎯
• -msched-stop-bits-after-every-cycle — stop bits after every cycle 🛑
• -msched-count-spec-in-critical-path — count speculation in critical path 🧮
• -msel-sched-dont-check-control-spec — selective scheduler, skip control spec check 🙈
• -msched-fp-mem-deps-zero-cost — FP memory deps at zero cost 💸
• -msched-max-memory-insns-hard-limit — max memory insns hard limit 🛑
• -msched-max-memory-insns=max-insns — max memory insns 🔢

🧠 LM32 Options (LM32 Options) 🧠

• -mbarrel-shift-enabled — barrel shift enabled 🌀
• -mdivide-enabled — divide enabled ➗
• -mmultiply-enabled — multiply enabled ✖️
• -msign-extend-enabled — sign extend enabled ➕
• -muser-enabled — user enabled 🫶

Okay bestie, this is the machine-specific flag pile, so grab a snack 🍓 Each target gets its own little drawer, and the page just lists the flags with no fine print, so I'm keeping it exactly as-is 💅

🦋 LoongArch Options 🦋

-march=arch-type -mtune=tune-type -mabi=base-abi-type -mfpu=fpu-type
-msimd=simd-type -msoft-float -msingle-float -mdouble-float -mlsx -mno-lsx
-mlasx -mno-lasx -mbranch-cost=n -maddr-reg-reg-cost=n
-mcheck-zero-division -mno-check-zero-division -mcond-move-int
-mno-cond-move-int -mcond-move-float -mno-cond-move-float -memcpy
-mno-memcpy -mstrict-align -mno-strict-align -G num
-mmax-inline-memcpy-size=n -mexplicit-relocs=style -mexplicit-relocs
-mno-explicit-relocs -mdirect-extern-access -mno-direct-extern-access
-mcmodel=code-model -mrelax -mpass-mrelax-to-as -mrecip -mrecip=opt
-mfrecipe -mno-frecipe -mdiv32 -mno-div32 -mlam-bh -mno-lam-bh -mlamcas
-mno-lamcas -mld-seq-sa -mno-ld-seq-sa -mtls-dialect=opt
-mannotate-tablejump -mno-annotate-tablejump

🌸 M32C Options 🌸

-mcpu=cpu -msim -memregs=number

🧚 M32R/D Options 🧚

-m32r2 -m32rx -m32r -mdebug -malign-loops -mno-align-loops
-missue-rate=number -mbranch-cost=number -mmodel=code-size-model-type
-msdata=sdata-type -mno-flush-func -mflush-func=name -mno-flush-trap
-mflush-trap=number -G num

💜 M680x0 Options 💜

-march=arch -mcpu=cpu -mtune=tune -m68000 -m68020 -m68020-40 -m68020-60
-m68030 -m68040 -m68060 -mcpu32 -m5200 -m5206e -m528x -m5307 -m5407
-mcfv4e -mbitfield -mno-bitfield -mc68000 -mc68020 -mnobitfield -mrtd
-mno-rtd -mdiv -mno-div -mshort -mno-short -mhard-float -m68881
-msoft-float -mpcrel -malign-int -mstrict-align -msep-data -mno-sep-data
-mshared-library-id=n -mid-shared-library -mno-id-shared-library -mxgot
-mno-xgot -mlong-jump-table-offsets

🎀 MCore Options 🎀

-mhardlit -mno-hardlit -mdiv -mno-div -mrelax-immediates
-mno-relax-immediates -mwide-bitfields -mno-wide-bitfields
-m4byte-functions -mno-4byte-functions -mcallgraph-data
-mno-callgraph-data -mslow-bytes -mno-slow-bytes -mno-lsim -mlittle-endian
-mbig-endian -m210 -m340 -mstack-increment

🔥 MicroBlaze Options 🔥

-msoft-float -mhard-float -msmall-divides -mcpu=cpu -mmemcpy
-mxl-soft-mul -mxl-soft-div -mxl-barrel-shift -mxl-pattern-compare
-mxl-stack-check -mxl-gp-opt -mno-clearbss -mxl-multiply-high
-mxl-float-convert -mxl-float-sqrt -mbig-endian -mlittle-endian
-mxl-reorder -mxl-mode-app-model -mpic-data-is-text-relative

👑 MIPS Options 👑

Lowkey the biggest drawer in the whole closet, so let's gooo ✨

-EL -EB -march=arch -mtune=arch -mips1 -mips2 -mips3 -mips4 -mips32
-mips32r2 -mips32r3 -mips32r5 -mips32r6 -mips64 -mips64r2 -mips64r3
-mips64r5 -mips64r6 -mips16 -mno-mips16 -mflip-mips16
-minterlink-compressed -mno-interlink-compressed -minterlink-mips16
-mno-interlink-mips16 -mabi=abi -mabicalls -mno-abicalls -mshared
-mno-shared -mplt -mno-plt -mxgot -mno-xgot -mgp32 -mgp64 -mfp32 -mfpxx
-mfp64 -mhard-float -msoft-float -mno-float -msingle-float
-mdouble-float -modd-spreg -mno-odd-spreg -mabs=mode -mnan=encoding -mdsp
-mno-dsp -mdspr2 -mno-dspr2 -mmcu -mmno-mcu -meva -mno-eva -mvirt
-mno-virt -mxpa -mno-xpa -mcrc -mno-crc -mginv -mno-ginv -mmicromips
-mno-micromips -mmsa -mno-msa -mloongson-mmi -mno-loongson-mmi
-mloongson-ext -mno-loongson-ext -mloongson-ext2 -mno-loongson-ext2
-mfpu=fpu-type -msmartmips -mno-smartmips -mpaired-single
-mno-paired-single -mdmx -mno-mdmx -mips3d -mno-mips3d -mmt -mno-mt
-mllsc -mno-llsc -mlong64 -mlong32 -msym32 -mno-sym32 -Gnum -mlocal-sdata
-mno-local-sdata -mextern-sdata -mno-extern-sdata -mgpopt -mno-gopt
-membedded-data -mno-embedded-data -muninit-const-in-rodata
-mno-uninit-const-in-rodata -mcode-readable=setting -msplit-addresses
-mno-split-addresses -mexplicit-relocs -mno-explicit-relocs
-mexplicit-relocs=release -mcheck-zero-division -mno-check-zero-division
-mdivide-traps -mdivide-breaks -mload-store-pairs -mno-load-store-pairs
-mstrict-align -mno-strict-align -mno-unaligned-access -munaligned-access
-mmemcpy -mno-memcpy -mlong-calls -mno-long-calls -mmad -mno-mad -mimadd
-mno-imadd -mfused-madd -mno-fused-madd -nocpp -mfix-24k -mno-fix-24k
-mfix-r4000 -mno-fix-r4000 -mfix-r4400 -mno-fix-r4400 -mfix-r5900
-mno-fix-r5900 -mfix-r10000 -mno-fix-r10000 -mfix-rm7000 -mno-fix-rm7000
-mfix-vr4120 -mno-fix-vr4120 -mfix-vr4130 -mno-fix-vr4130 -mfix-sb1
-mno-fix-sb1 -mflush-func=func -mno-flush-func -mbranch-cost=num
-mbranch-likely -mno-branch-likely -mcompact-branches=policy
-mfp-exceptions -mno-fp-exceptions -mvr4130-align -mno-vr4130-align
-msynci -mno-synci -mlxc1-sxc1 -mno-lxc1-sxc1 -mmadd4 -mno-madd4
-mrelax-pic-calls -mno-relax-pic-calls -mmcount-ra-address
-mframe-header-opt -mno-frame-header-opt

🌈 MMIX Options 🌈

-mlibfuncs -mno-libfuncs -mepsilon -mno-epsilon -mabi=gnu -mabi=mmixware
-mzero-extend -mknuthdiv -mtoplevel-symbols -melf -mbranch-predict
-mno-branch-predict -mbase-addresses -mno-base-addresses -msingle-exit
-mno-single-exit

🫶 MN10300 Options 🫶

-mmult-bug -mno-mult-bug -mno-am33 -mam33 -mam33-2 -mam34 -mtune=cpu-type
-mreturn-pointer-on-d0 -mno-crt0 -mrelax -mliw -msetlb

🍓 Moxie Options 🍓

-meb -mel -mmul.x -mno-crt0

⭐ MSP430 Options ⭐

-msim -masm-hex -mmcu= -mcpu= -mlarge -msmall -mrelax -mwarn-mcu
-mcode-region= -mdata-region= -msilicon-errata= -msilicon-errata-warn=
-mhwmult= -minrt -mtiny-printf -mmax-inline-shift=

🦋 NDS32 Options 🦋

-mbig-endian -mlittle-endian -mreduced-regs -mfull-regs -mcmov -mno-cmov
-mext-perf -mno-ext-perf -mext-perf2 -mno-ext-perf2 -mext-string
-mno-ext-string -mv3push -mno-v3push -m16bit -mno-16bit
-misr-vector-size=num -mcache-block-size=num -march=arch
-mcmodel=code-model -mctor-dtor -mrelax

💅 Nvidia PTX Options 💅

-m64 -mmainkernel -moptimize

🌸 OpenRISC Options 🌸

-mboard=name -mnewlib -mhard-mul -mhard-div -msoft-mul -msoft-div
-msoft-float -mhard-float -mdouble-float -munordered-float -mcmov -mror
-mrori -msext -msfimm -mshftimm -mcmodel=code-model

🧚 PDP-11 Options 🧚

-mfpu -msoft-float -mac0 -mno-ac0 -m40 -m45 -m10 -mint32 -mno-int16
-mint16 -mno-int32 -msplit -munix-asm -mdec-asm -mgnu-asm -mlra

💜 PowerPC Options 💜

See RS/6000 and PowerPC Options.

🎀 PRU Options 🎀

-mmcu=mcu -minrt -mno-relax -mloop -mabi=variant

🔥 RISC-V Options 🔥

-mbranch-cost=N-instruction -mplt -mno-plt -mabi=ABI-string -mfdiv
-mno-fdiv -mfence-tso -mno-fence-tso -mdiv -mno-div -misa-spec=ISA-spec-string
-march=ISA-string -mtune=processor-string -mpreferred-stack-boundary=num
-msmall-data-limit=N-bytes -msave-restore -mno-save-restore
-mshorten-memrefs -mno-shorten-memrefs -mstrict-align -mno-strict-align
-mcmodel=medlow -mcmodel=medany -mcmodel=large -mexplicit-relocs
-mno-explicit-relocs -mrelax -mno-relax -mriscv-attribute
-mno-riscv-attribute -malign-data=type -mbig-endian -mlittle-endian
-mstack-protector-guard=guard -mstack-protector-guard-reg=reg
-mstack-protector-guard-offset=offset -mcsr-check -mno-csr-check
-mmovcc -mno-movcc -minline-atomics -mno-inline-atomics -minline-strlen
-mno-inline-strlen -minline-strcmp -mno-inline-strcmp -minline-strncmp
-mno-inline-strncmp -mtls-dialect=desc -mtls-dialect=trad

👑 RL78 Options 👑

-msim -mmul=none -mmul=g13 -mmul=g14 -mallregs -mcpu=g10 -mcpu=g13
-mcpu=g14 -mg10 -mg13 -mg14 -m64bit-doubles -m32bit-doubles
-msave-mduc-in-interrupts

✨ RS/6000 and PowerPC Options ✨

Last drawer in this part, and it's a whole vibe 🌈

-mcpu=cpu-type -mtune=cpu-type -mcmodel=code-model -mpowerpc64 -maltivec
-mno-altivec -mpowerpc-gpopt -mno-powerpc-gpopt -mpowerpc-gfxopt
-mno-powerpc-gfxopt -mmfcrf -mno-mfcrf -mpopcntb -mno-popcntb -mpopcntd
-mno-popcntd -mfprnd -mno-fprnd -mcmpb -mno-cmpb -mhard-dfp -mno-hard-dfp
-mfull-toc -mminimal-toc -mno-fp-in-toc -mno-sum-in-toc -m64 -m32
-mxl-compat -mno-xl-compat -mpe -malign-power -malign-natural
-msoft-float -mhard-float -mmultiple -mno-multiple -mupdate -mno-update
-mavoid-indexed-addresses -mno-avoid-indexed-addresses -mfused-madd
-mno-fused-madd -mbit-align -mno-bit-align -mstrict-align -mno-strict-align
-mrelocatable -mno-relocatable -mrelocatable-lib -mno-relocatable-lib
-mtoc -mno-toc -mlittle -mlittle-endian -mbig -mbig-endian
-mdynamic-no-pic -mswdiv -msingle-pic-base
-mprioritize-restricted-insns=priority
-msched-costly-dep=dependence_type -minsert-sched-nops=scheme
-mcall-aixdesc -mcall-eabi -mcall-freebsd -mcall-linux -mcall-netbsd
-mcall-openbsd -mcall-sysv -mcall-sysv-eabi -mcall-sysv-noeabi
-mtraceback=traceback_type -maix-struct-return -msvr4-struct-return
-mabi=abi-type -msecure-plt -mbss-plt -msplit-patch-nops -mlongcall
-mno-longcall -mpltseq -mno-pltseq -mblock-move-inline-limit=num
-mblock-compare-inline-limit=num -mblock-compare-inline-loop-limit=num
-mno-block-ops-unaligned-vsx -mstring-compare-inline-limit=num -misel
-mno-isel -mvrsave -mno-vrsave -mmulhw -mno-mulhw -mdlmzb -mno-dlmzb
-mprototype -mno-prototype -msim -mmvme -mads -myellowknife -memb -msdata
-msdata=opt -mreadonly-in-sdata -mvxworks -G num -mrecip -mrecip=opt
-mno-recip -mrecip-precision -mno-recip-precision -mveclibabi=type -mfriz
-mno-friz -mpointers-to-nested-functions -mno-pointers-to-nested-functions
-msave-toc-indirect -mno-save-toc-indirect -mpower8-fusion
-mno-mpower8-fusion -mcrypto -mno-crypto -mhtm -mno-htm -mquad-memory
-mno-quad-memory -mquad-memory-atomic -mno-quad-memory-atomic
-mcompat-align-parm -mno-compat-align-parm -mfloat128 -mno-float128
-mfloat128-hardware -mno-float128-hardware -mgnu-attribute
-mno-gnu-attribute -mstack-protector-guard=guard
-mstack-protector-guard-reg=reg -mstack-protector-guard-offset=offset
-mprefixed -mno-prefixed -mpcrel -mno-pcrel -mmma -mno-mmma -mrop-protect
-mno-rop-protect -mprivileged -mno-privileged

🎀 RX Options 🎀

okay so RX has its own little squad of options, bestie 💖 -m64bit-doubles -m32bit-doubles -fpu -nofpu -mcpu= -mbig-endian-data -mlittle-endian-data -msmall-data -msim -mno-sim -mas100-syntax -mno-as100-syntax -mrelax -mmax-constant-size= -mint-register= -mpid -mallow-string-insns -mno-allow-string-insns -mjsr -mno-warn-multiple-fast-interrupts -msave-acc-in-interrupts 🧚

✨ S/390 and zSeries Options ✨

this one is giving big mainframe energy 💅 -mtune=cpu-type -march=cpu-type -mhard-float -msoft-float -mhard-dfp -mno-hard-dfp -mlong-double-64 -mlong-double-128 -mbackchain -mno-backchain -mpacked-stack -mno-packed-stack -msmall-exec -mno-small-exec -mmvcle -mno-mvcle -m64 -m31 -mdebug -mno-debug -mesa -mzarch -mhtm -mvx -mzvector -mtpf-trace -mno-tpf-trace -mtpf-trace-skip -mno-tpf-trace-skip -mfused-madd -mno-fused-madd -mwarn-framesize -mwarn-dynamicstack -mstack-size -mstack-guard -mhotpatch=halfwords,halfwords 🔥

🦋 SH Options 🦋

SH has a whole lineup, no cap 😭 -m1 -m2 -m2e -m2a-nofpu -m2a-single-only -m2a-single -m2a -m3 -m3e -m4-nofpu -m4-single-only -m4-single -m4 -m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al -mb -ml -mdalign -mrelax -mbigtable -mfmovd -mrenesas -mno-renesas -mnomacsave -mieee -mno-ieee -mbitops -misize -minline-ic_invalidate -mpadstruct -mprefergot -musermode -multcost=number -mdiv=strategy -mdivsi3_libfunc=name -mfixed-range=register-range -maccumulate-outgoing-args -matomic-model=atomic-model -mbranch-cost=num -mzdcbranch -mno-zdcbranch -mcbranch-force-delay-slot -mfused-madd -mno-fused-madd -mfsca -mno-fsca -mfsrra -mno-fsrra -mpretend-cmove -mtas 🌸

🫶 Solaris 2 Options 🫶

the Solaris crew is small but mighty ✨ -mclear-hwcap -mno-clear-hwcap -mimpure-text -mno-impure-text -pthreads 💜

💅 SPARC Options 💅

SPARC has so many toggles it's unreal 😭 -mcpu=cpu-type -mtune=cpu-type -mcmodel=code-model -mmemory-model=mem-model -m32 -m64 -mapp-regs -mno-app-regs -mfaster-structs -mno-faster-structs -mflat -mno-flat -mfpu -mno-fpu -mhard-float -msoft-float -mhard-quad-float -msoft-quad-float -mstack-bias -mno-stack-bias -mstd-struct-return -mno-std-struct-return -munaligned-doubles -mno-unaligned-doubles -muser-mode -mno-user-mode -mv8plus -mno-v8plus -mvis -mno-vis -mvis2 -mno-vis2 -mvis3 -mno-vis3 -mvis3b -mno-vis3b -mvis4 -mno-vis4 -mvis4b -mno-vis4b -mcbcond -mno-cbcond -mfmaf -mno-fmaf -mfsmuld -mno-fsmuld -mpopc -mno-popc -msubxc -mno-subxc -mfix-at697f -mfix-ut699 -mfix-ut700 -mfix-gr712rc 🍓

🎀 System V Options 🎀

only a few here, but they're iconic 👑 -Qy -Qn -YP,paths -Ym,dir 💖

🌈 V850 Options 🌈

the V850 lineup is serving so many variants 😭 -mlong-calls -mno-long-calls -mep -mno-ep -mprolog-function -mno-prolog-function -mspace -mtda=n -msda=n -mzda=n -mapp-regs -mno-app-regs -mdisable-callt -mno-disable-callt -mv850e2v3 -mv850e2 -mv850e1 -mv850es -mv850e -mv850 -mv850e3v5 -mloop -mrelax -mlong-jumps -msoft-float -mhard-float -mgcc-abi -mrh850-abi -mbig-switch ⭐

🧚 VAX Options 🧚

VAX keeps it classic 🙈 -munix -mgnu -md -md-float -mg -mg-float -mlra 🦋

🌸 Visium Options 🌸

Visium is lowkey underrated 💜 -mdebug -msim -mfpu -mno-fpu -mhard-float -msoft-float -mcpu=cpu-type -mtune=cpu-type -msv-mode -muser-mode ✨

🔥 VMS Options 🔥

VMS has its own vibe, okay 💀 -mvms-return-codes -mdebug-main=prefix -mmalloc64 -mpointer-size=size 🫶

🌊 VxWorks Options 🌊

the VxWorks options are a whole mood 🌸 -mrtp -msmp -non-static -Bstatic -Bdynamic -Xbind-lazy -Xbind-now 💖

👑 x86 Options 👑

okay x86 is the main character of this whole page, bestie 😭✨ it has so many options it's actually unhinged in the best way. here they all are: -mtune=cpu-type -march=cpu-type -mtune-ctrl=feature-list -mdump-tune-features -mno-default -mfpmath=unit -masm=dialect -mno-fancy-math-387 -mno-fp-ret-in-387 -m80387 -mhard-float -msoft-float -mno-wide-multiply -mrtd -malign-double -mpreferred-stack-boundary=num -mincoming-stack-boundary=num -mcld -mcx16 -msahf -mmovbe -mcrc32 -mmwait -mrecip -mrecip=opt -mvzeroupper -mprefer-avx128 -mprefer-vector-width=opt -mpartial-vector-fp-math -mmove-max=bits -mstore-max=bits -mnoreturn-no-callee-saved-registers -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx -mavx2 -mavx512f -mavx512cd -mavx512vl -mavx512bw -mavx512dq -mavx512ifma -mavx512vbmi -msha -maes -mpclmul -mfsgsbase -mrdrnd -mf16c -mfma -mpconfig -mwbnoinvd -mptwrite -mclflushopt -mclwb -mxsavec -mxsaves -msse4a -m3dnow -m3dnowa -mpopcnt -mabm -mbmi -mtbm -mfma4 -mxop -madx -mlzcnt -mbmi2 -mfxsr -mxsave -mxsaveopt -mrtm -mhle -mlwp -mmwaitx -mclzero -mpku -mthreads -mgfni -mvaes -mwaitpkg -mshstk -mmanual-endbr -mcet-switch -mforce-indirect-call -mavx512vbmi2 -mavx512bf16 -menqcmd -mvpclmulqdq -mavx512bitalg -mmovdiri -mmovdir64b -mavx512vpopcntdq -mavx512vnni -mprfchw -mrdpid -mrdseed -msgx -mavx512vp2intersect -mserialize -mtsxldtrk -mamx-tile -mamx-int8 -mamx-bf16 -muintr -mhreset -mavxvnni -mamx-fp8 -mavx512fp16 -mavxifma -mavxvnniint8 -mavxneconvert -mcmpccxadd -mamx-fp16 -mprefetchi -mraoint -mamx-complex -mavxvnniint16 -msm3 -msha512 -msm4 -mapxf -musermsr -mavx10.1 -mavx10.1-256 -mavx10.1-512 -mevex512 -mavx10.2 -mamx-avx512 -mamx-tf32 -mamx-transpose -mmovrs -mamx-movrs -mcldemote -mms-bitfields -mno-align-stringops -minline-all-stringops -minline-stringops-dynamically -mstringop-strategy=alg -mkl -mwidekl -mmemcpy-strategy=strategy -mmemset-strategy=strategy -mpush-args -maccumulate-outgoing-args -m128bit-long-double -m96bit-long-double -mlong-double-64 -mlong-double-80 -mlong-double-128 -mregparm=num -msseregparm -mveclibabi=type -mvect8-ret-in-mem -mpc32 -mpc64 -mpc80 -mdaz-ftz -mstackrealign -momit-leaf-frame-pointer -mno-red-zone -mno-tls-direct-seg-refs -mcmodel=code-model -mabi=name -maddress-mode=mode -m32 -m64 -mx32 -m16 -miamcu -mlarge-data-threshold=num -msse2avx -mfentry -mrecord-mcount -mnop-mcount -m8bit-idiv -minstrument-return=type -mfentry-name=name -mfentry-section=name -mavx256-split-unaligned-load -mavx256-split-unaligned-store -malign-data=type -mstack-protector-guard=guard -mstack-protector-guard-reg=reg -mstack-protector-guard-offset=offset -mstack-protector-guard-symbol=symbol -mgeneral-regs-only -mcall-ms2sysv-xlogues -mrelax-cmpxchg-loop -mindirect-branch=choice -mfunction-return=choice -mindirect-branch-register -mharden-sls=choice -mindirect-branch-cs-prefix -mneeded -mno-direct-extern-access -munroll-only-small-loops -mlam=choice 🎀

🍓 x86 Windows Options 🍓

for the x86 Windows stuff, just peek at Cygwin and MinGW Options, it's got you 💖

⭐ Xstormy16 Options ⭐

just -msim for this one, short and sweet 🧚

🦋 Xtensa Options 🦋

Xtensa has a glow-up list too ✨ -mconst16 -mno-const16 -mfused-madd -mno-fused-madd -mforce-no-pic -mserialize-volatile -mno-serialize-volatile -mtext-section-literals -mno-text-section-literals -mauto-litpools -mno-auto-litpools -mtarget-align -mno-target-align -mlongcalls -mno-longcalls -mabi=abi-type -mextra-l32r-costs=cycles -mstrict-align -mno-strict-align 💜

🌷 zSeries Options 🌷

zSeries is the same as S/390 and zSeries Options, so check that one out 💅

---

🌈 Options Controlling the Kind of Output 🌈

okay so compiling is basically a four-step glow-up: preprocessing, compilation proper, assembly, and linking, always in that order 💖 GCC can preprocess and compile several files into several assembler input files, or squish them into one assembler input file. then each assembler input file makes an object file, and linking combines all the object files (the ones freshly compiled plus any you handed it) into an executable file ✨

for any given input file, the file name suffix decides what kind of compilation happens, so the ending really matters bestie 🫶

• file.c — C source code that must be preprocessed.
• file.i — C source code that should not be preprocessed.
• file.ii — C++ source code that should not be preprocessed.
• file.m — Objective-C source code. heads up, you must link with the libobjc library to make an Objective-C program work 🔥
• file.mi — Objective-C source code that should not be preprocessed.
• file.mm, file.M — Objective-C++ source code. again, you must link with the libobjc library to make an Objective-C++ program work. and .M refers to a literal capital M 💀
• file.mii — Objective-C++ source code that should not be preprocessed.
• file.h — C, C++, Objective-C or Objective-C++ header file to be turned into a precompiled header (default), or C, C++ header file to be turned into an Ada spec (via the -fdump-ada-spec switch) 🎀
• file.cc, file.cp, file.cxx, file.cpp, file.CPP, file.c++, file.C — C++ source code that must be preprocessed. quick note: in .cxx, the last two letters must both be literally x, and .C refers to a literal capital C 🧚
• file.mm, file.M — Objective-C++ source code that must be preprocessed.
• file.mii — Objective-C++ source code that should not be preprocessed.
• file.hh, file.H, file.hp, file.hxx, file.hpp, file.HPP, file.h++, file.tcc — C++ header file to be turned into a precompiled header or Ada spec. 🦋
• file.f, file.for, file.ftn, file.fi — Fixed form Fortran source code that should not be preprocessed.
• file.F, file.FOR, file.fpp, file.FPP, file.FTN — Fixed form Fortran source code that must be preprocessed (with the traditional preprocessor). 🌸
• file.f90, file.f95, file.f03, file.f08, file.fii — Free form Fortran source code that should not be preprocessed.
• file.F90, file.F95, file.F03, file.F08 — Free form Fortran source code that must be preprocessed (with the traditional preprocessor). 💜
• file.cob, file.COB, file.cbl, file.CBL — COBOL source code. ✨
• file.go — Go source code. 🫶
• file.d — D source code.
• file.di — D interface file.
• file.dd — D documentation code (Ddoc). 💖
• file.ads — Ada source code file that contains a library unit declaration (a declaration of a package, subprogram, or generic, or a generic instantiation), or a library unit renaming declaration (a package, generic, or subprogram renaming declaration). these are also called specs 👑
• file.adb — Ada source code file containing a library unit body (a subprogram or package body). these are also called bodies. 🌊
• file.s — Assembler code. 🧚
• file.S, file.sx — Assembler code that must be preprocessed. 💅
• other — an object file to be fed straight into linking. any file name with no recognized suffix gets treated this way, so it's giving "skip the line" energy 🙈

You can pick the input language yourself with the -x option, bestie 💅

• -x language — okay so this one lets you declare the language for the input files that come after it, instead of letting the compiler guess from the file name suffix 🔮 It stays active for every following input file until the next -x shows up. The valid values are:

c  c-header  cpp-output
c++  c++-header  c++-system-header c++-user-header c++-cpp-output
objective-c  objective-c-header  objective-c-cpp-output
objective-c++ objective-c++-header objective-c++-cpp-output
assembler  assembler-with-cpp
ada
cobol
d
f77  f77-cpp-input f95  f95-cpp-input
go

Note that -x does not imply a particular language standard, bestie 🙈 For example, -x f77 may also need -std=legacy for some older source codes. Don't skip it!

• -x none — the main character reset 🧹 This turns off any language specification, so the files after it get handled by their file name suffixes again, as if -x had never been used at all ✨

If you only want some stages of compilation, you can use -x (or filename suffixes) to tell gcc where to start, and one of the options -c, -S, or -E to say where gcc should stop 🦋 Heads up: some combinations, like -x cpp-output -E, instruct gcc to do absolutely nothing at all 💀

• -c — compile or assemble the source files, but do NOT link 🌸 The linking stage simply doesn't happen. The final output is an object file for each source file.

By default, the object file name for a source file is made by swapping the suffix .c, .i, .s, etc. for .o.

Unrecognized input files that don't need compiling or assembling are ignored, so they just get left alone 🫶

• -S — stop right after the compilation proper and skip assembling 💜 The output is an assembler code file for each non-assembler input file you gave it.

By default, the assembler file name for a source file is made by swapping the suffix .c, .i, etc. for .s.

Input files that don't need compilation are ignored.

• -E — stop after the preprocessing stage and don't run the compiler proper 🧚 The output is preprocessed source code, which gets sent to the standard output.

Input files that don't need preprocessing are ignored.

• -o file — place the primary output in file 🎀 This applies to whatever kind of output you're making, whether that's an executable, an object file, an assembler file, or preprocessed C code.

If you don't use -o, the default is to put an executable file in a.out, the object file for source.suffix in source.o, its assembler file in source.s, a precompiled header file in source.suffix.gch, and all preprocessed C source on standard output 🍓

Okay, so -o only names the primary output, but it also affects how the auxiliary and dump outputs get named 👑 Unless overridden, both auxiliary outputs and dump outputs get placed in the same directory as the primary output. For auxiliary outputs, the input file's suffix gets replaced with the suffix of the auxiliary output file type. For dump outputs, the dump file's suffix gets appended to the input file's suffix. In compilation commands, the base name of both auxiliary and dump outputs is the base name of the primary output. In compile and link commands, the primary output name, minus the executable suffix, gets combined with the input file name. If both share the same base name (ignoring the suffix), the result of the combination is that base name. Otherwise they get concatenated, separated by a dash 🌈

Here's the vibe with -c:

gcc -c foo.c ...

This will use foo.o as the primary output, and place aux outputs and dumps next to it, e.g., aux file foo.dwo for -gsplit-dwarf, and dump file foo.c.???r.final for -fdump-rtl-final.

If a non-linker output file is explicitly specified, aux and dump files take the same base name by default:

gcc -c foo.c -o dir/foobar.o ...

This will name aux outputs dir/foobar.* and dump outputs dir/foobar.c.*.

A linker output will prefix aux and dump outputs instead 😭

gcc foo.c bar.c -o dir/foobar ...

This will generally name aux outputs dir/foobar-foo.* and dir/foobar-bar.*, and dump outputs dir/foobar-foo.c.* and dir/foobar-bar.c.*.

The one exception is when the executable shares the base name with the single input:

gcc foo.c -o dir/foo ...

In that case, aux outputs are named dir/foo.* and dump outputs are named dir/foo.c.* ✨

The location and names of auxiliary and dump outputs can be adjusted with the options -dumpbase, -dumpbase-ext, -dumpdir, -save-temps=cwd, and -save-temps=obj 🦋

• -dumpbase dumpbase — this sets the base name for auxiliary and dump output files 🫶 It does NOT affect the name of the primary output file. Intermediate outputs, when preserved, aren't treated as primary outputs. They're treated as auxiliary outputs instead.

Like, this one:

gcc -save-temps -S foo.c

saves the (no longer) temporary preprocessed file in foo.i, and then compiles to the (implied) output file foo.s. Whereas this one:

gcc -save-temps -dumpbase save-foo -c foo.c

preprocesses to save-foo.i, compiles to save-foo.s (now an intermediate, and therefore an auxiliary output), and then assembles to the (implied) output file foo.o 💅

Without this option, dump and aux files take their names from the input file, or from the (non-linker) output file if one is explicitly specified. Dump output files (for example, those requested by -fdump-* options) keep the input name suffix. Aux output files (those requested by other non-dump options, e.g. -save-temps, -gsplit-dwarf, -fcallgraph-info) drop it.

Similar suffix differentiation of dump and aux outputs can be achieved for an explicitly given -dumpbase basename.suf by also specifying -dumpbase-ext .suf.

If dumpbase is explicitly specified with any directory component, any dumppfx specification (e.g. -dumpdir or -save-temps=*) is ignored. Instead of appending to it, dumpbase fully overrides it:

gcc foo.c -c -o dir/foo.o -dumpbase alt/foo \
  -dumpdir pfx- -save-temps=cwd ...

This creates auxiliary and dump outputs named alt/foo.*, disregarding dir/ in -o, the ./ prefix implied by -save-temps=cwd, and pfx- in -dumpdir 🌸

When -dumpbase is specified in a command that compiles multiple inputs, or that compiles and then links, it may be combined with dumppfx, as described under -dumpdir. Then each input file is compiled using the combined dumppfx, and default values for dumpbase and auxdropsuf are computed for each input file:

gcc foo.c bar.c -c -dumpbase main ...

This creates foo.o and bar.o as primary outputs. It avoids overwriting the auxiliary and dump outputs by using the dumpbase as a prefix, creating auxiliary and dump outputs named main-foo.* and main-bar.* 🧚

An empty string given as dumpbase avoids the influence of the output basename on the naming of auxiliary and dump outputs during compilation, and computes default values instead:

gcc -c foo.c -o dir/foobar.o -dumpbase " ...

This will name aux outputs dir/foo.* and dump outputs dir/foo.c.*. Notice how their basenames come from the input name, but the directory still defaults to that of the output 💖

The empty-string dumpbase does not stop the output basename from being used for outputs during linking:

gcc foo.c bar.c -o dir/foobar -dumpbase " -flto ...

The compilation of the source files will name auxiliary outputs dir/foo.* and dir/bar.*, and dump outputs dir/foo.c.* and dir/bar.c.*. LTO recompilation during linking will use dir/foobar. as the prefix for dumps and auxiliary files ✨

• -dumpbase-ext auxdropsuf — when forming the name of an auxiliary (but NOT a dump) output file, this drops the trailing auxdropsuf from dumpbase before any suffixes get appended 🎀 If you don't specify it, this option defaults to the suffix of a default dumpbase. That's the suffix of the input file when -dumpbase isn't on the command line, or when dumpbase is combined with dumppfx.

gcc foo.c -c -o dir/foo.o -dumpbase x-foo.c -dumpbase-ext .c ...

This creates dir/foo.o as the main output, and generates auxiliary outputs in dir/x-foo.*. It takes the location of the primary output and drops the .c suffix from the dumpbase. Dump outputs keep the suffix: dir/x-foo.c.* 🦋

This option is disregarded if it doesn't match the suffix of a specified dumpbase, except as an alternative to the executable suffix when appending the linker output base name to dumppfx, as described below:

gcc foo.c bar.c -o main.out -dumpbase-ext .out ...

This creates main.out as the primary output, and avoids overwriting the auxiliary and dump outputs by using the executable name minus auxdropsuf as a prefix. It creates auxiliary outputs named main-foo.* and main-bar.*, and dump outputs named main-foo.c.* and main-bar.c.* 💜

• -dumpdir dumppfx — when forming the name of an auxiliary or dump output file, use dumppfx as a prefix 🌈

gcc -dumpdir pfx- -c foo.c ...

This creates foo.o as the primary output, and auxiliary outputs named pfx-foo.*. It combines the given dumppfx with the default dumpbase, which is derived from the default primary output, which is in turn derived from the input name. Dump outputs also take the input name suffix: pfx-foo.c.* 🍓

If dumppfx is going to be used as a directory name, it must end with a directory separator:

gcc -dumpdir dir/ -c foo.c -o obj/bar.o ...

This creates obj/bar.o as the primary output, and auxiliary outputs named dir/bar.*, combining the given dumppfx with the default dumpbase derived from the primary output name. Dump outputs also take the input name suffix: dir/bar.c.* 🔥

It defaults to the location of the output file, unless the output file is a special file like "/dev/null". The options -save-temps=cwd and -save-temps=obj override this default, just like an explicit -dumpdir option does. If multiple such options are given, the last one prevails:

gcc -dumpdir pfx- -c foo.c -save-temps=obj ...

So it still spits out foo.o, but the auxiliary outputs get named foo.* 🙈 because -save-temps=* overrides the dumppfx you gave with the earlier -dumpdir option. 💅 It's not a big deal that =obj is the default for -save-temps, or that the output directory is implicitly the current directory. Dump outputs are named foo.c.*.

When you compile from multiple input files and pass -dumpbase, the dumpbase minus an auxdropsuf suffix, plus a dash, gets tacked onto (or overrides, if it has any directory components) an explicit or defaulted dumppfx. That way each of the compilations gets its own differently-named aux and dump outputs ✨

gcc foo.c bar.c -c -dumpdir dir/pfx- -dumpbase main ...

This outputs auxiliary dumps to dir/pfx-main-foo.* and dir/pfx-main-bar.*, appending dumpbase- to dumppfx. Dump outputs keep the input file suffix: dir/pfx-main-foo.c.* and dir/pfx-main-bar.c.*, respectively. Now compare that with the single-input version:

gcc foo.c -c -dumpdir dir/pfx- -dumpbase main ...

Applying -dumpbase to a single source does not compute and append a separate dumpbase per input file, so its auxiliary and dump outputs just go in dir/pfx-main.* 🎀

When you compile and then link from multiple input files, a defaulted or explicitly specified dumppfx also gets the dumpbase- treatment from above (think the foo.c and bar.c compilation, but without -c). If neither -dumpdir nor -dumpbase is given, the linker output base name, minus auxdropsuf if specified (or the executable suffix otherwise), plus a dash gets appended to the default dumppfx instead. 🦋 Heads up though, this is different from the earlier cases of linking:

gcc foo.c bar.c -dumpdir dir/pfx- -o main ...

This does not append the output name main to dumppfx, because -dumpdir was explicitly specified. The vibe here is that an explicitly-specified dumppfx can include the output name as part of the prefix, if you want that. Only an explicitly-specified -dumpbase gets combined with it, so a meaningful option never just gets thrown away 🫶

When you compile and then link from a single input file, the linker output base name only gets appended to the default dumppfx (like above) if it doesn't share the base name with the single input file name. This was covered in the single-input linking cases above, but not with an explicit -dumpdir that stops the combination, even if -save-temps=* overrides it:

gcc foo.c -dumpdir alt/pfx- -o dir/main.exe -save-temps=cwd ...

Auxiliary outputs are named foo.*, and dump outputs foo.c.*, in the current working directory, as ultimately requested by -save-temps=cwd 🌸

Okay, so here's the big-picture data flow. It's a little imprecise, but it's intuitive 🧚 The primary output name gets split into a directory part and a basename part. dumppfx is set to the directory part, unless -dumpdir or -save-temps=* overrides it, and dumpbase is set to the basename part, unless -dumpbase overrides it. With multiple inputs or linking, this dumpbase may get combined with dumppfx and taken from each input file. Auxiliary output names for each input are formed by combining dumppfx, dumpbase minus its suffix, and the auxiliary output suffix. Dump output names only differ in that the suffix from dumpbase is kept 💜

When it comes to auxiliary and dump outputs created during LTO recompilation 🌈, a combination of dumppfx and dumpbase gets passed down to lto-wrapper as a -dumpdir option. This happens whether it's given explicitly or derived from the linker output name (but not from inputs), and even in cases where this combination wouldn't otherwise get used as such. The trailing period replaces the compiler-added dash, if there is one. Since linking is involved, this program doesn't normally get any -dumpbase and -dumpbase-ext, and it ignores them 🙈

When lto-wrapper runs sub-compilers, it appends the LTO stage names to the dumppfx it received, makes sure it contains a directory component so it overrides any -dumpdir, and passes that along as -dumpbase to the sub-compilers ✨

---

✨ OPTIONS ✨

• -v — Prints the commands the compiler runs for each stage of compilation (on standard error output). It also prints the version number of the compiler driver program, plus the preprocessor and the compiler proper 📣
• -### — Basically -v, except the commands are not actually executed. Arguments get quoted unless they only contain alphanumeric characters or "./-_". This is super handy for shell scripts that want to capture the driver-generated command lines 🤓
• --help — Prints (on the standard output) a description of the command-line options gcc understands. If -v is also specified, then --help gets passed on to the various processes gcc invokes, so they can show the command-line options they accept. If -Wextra has also been specified (before the --help option), then command-line options with no documentation attached are displayed too 📚
• --target-help — Prints (on the standard output) a description of the target-specific command-line options for each tool. For some targets, extra target-specific info may also get printed 🎯
• --help={class|[^]qualifier}[,...] — Prints (on the standard output) a description of the command-line options the compiler understands that fit into all of the specified classes and qualifiers. Here are the supported classes:
  • optimizers — Displays all of the optimization options the compiler supports.
  • warnings — Displays all of the options that control warning messages the compiler produces.
  • target — Displays target-specific options. Unlike --target-help, target-specific options of the linker and assembler are not displayed, because those tools don't currently support the extended --help= syntax 🙃
  • params — Displays the values recognized by the --param option.
  • language — Displays the options supported for language, where language is the name of one of the languages supported in this version of GCC. If an option is supported by all languages, you need to select the common class.
  • common — Displays the options that are common to all languages.

And here are the supported qualifiers:

• undocumented — Displays only the options that are undocumented.
• joined — Displays options that take an argument appearing after an equal sign in the same continuous piece of text, such as: --help=target.
• separate — Displays options that take an argument appearing as a separate word following the original option, such as: -o output-file.

Want all the undocumented target-specific switches the compiler supports? Use:

--help=target,undocumented

You can invert a qualifier by putting the ^ character in front of it. So if you want every binary warning option (the ones that are either on or off and don't take an argument) that has a description, use:

--help=warnings,^joined,^undocumented

The argument to --help= should not consist solely of inverted qualifiers.

Combining several classes is possible, but it usually narrows the output so much that there's nothing to show. One case where it does work is when one of the classes is target. For example, to display all the target-specific optimization options, use:

--help=target,optimizers

The --help= option can be repeated on the command line. Each use displays its requested class of options, skipping any that were already displayed. If --help is also specified anywhere on the command line, it takes precedence over any --help= option 👑

If the -Q option appears on the command line before --help=, the descriptive text that --help= shows changes. Instead of describing the options, it indicates whether each option is enabled, disabled, or set to a specific value (assuming the compiler knows this at the point where --help= is used) 💅

Here's a truncated example from the ARM port of GCC:

% gcc -Q -mabi=2 --help=target -c
The following options are target specific:
-mabi=                                2
-mabort-on-noreturn                   [disabled]
-mapcs                                [disabled]

The output is sensitive to the effects of previous command-line options, so for example you can find out which optimizations are enabled at -O2 by using:

-Q -O2 --help=optimizers

Or, if you want to see which binary optimizations are enabled by -O3, do this:

gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled

• --version — Displays the version number and copyrights of the invoked GCC 🎀
• -pass-exit-codes — Normally, the gcc program exits with the code of 1 if any phase of the compiler returns a non-success return code. If you specify -pass-exit-codes, then gcc instead returns with the numerically highest error produced by any phase that returned an error indication. The C, C++, and Fortran front ends return 4 if they hit an internal compiler error 😭
• -pipe — Uses pipes rather than temporary files for communication between the various stages of compilation. This fails to work on some systems where the assembler can't read from a pipe, but the GNU assembler has no trouble with it 🦋
• -specs=file — Processes file after the compiler reads in the standard specs file, in order to override the defaults that the gcc driver program uses when deciding which switches to pass to cc1, cc1plus, as, ld, etc. You can specify more than one -specs=file on the command line, and they're processed in order, from left to right 🧁
• -wrapper — Invokes all subcommands under a wrapper program. The name of the wrapper program and its parameters are passed as a comma-separated list:

gcc -c t.c -wrapper gdb,--args

This invokes all subprograms of gcc under gdb --args, so the invocation of cc1 becomes gdb --args cc1 .... 🌈

✨ -ffile-prefix-map=old=new 🗺️💖

When you're compiling files that live in the directory old, GCC will record any references to them in the compilation result as if those files lived in new instead. Writing this option is the same as writing out every individual -f*-prefix-map option, so it's basically the one-stop shop 🛍️. It's a lowkey perfect tool for reproducible builds that don't care where they're built 🌸. Directories referenced by directives are not affected by these options. See also -fmacro-prefix-map, -fdebug-prefix-map, -fprofile-prefix-map and -fcanon-prefix-map 🦋.

• -fcanon-prefix-map — okay so, when you use the -f*-prefix-map options, GCC normally compares the old prefix against the filename it would reference by doing a plain textual comparison of the prefixes. On case-insensitive filesystems it ignores character case, and on DOS-based filesystems it treats slashes and backslashes as the same thing 💅. -fcanon-prefix-map switches this so the comparisons happen on canonicalized paths for both old and the referenced filename. Main character energy 👑.
• -fplugin=name.so — loads the plugin code from the file name.so, which is assumed to be a shared object that the compiler will dlopen. The base name of the shared object file is what identifies the plugin when parsing arguments (see -fplugin-arg-name-key=value below) 🧚. Each plugin should define the callback functions specified in the Plugins API ✨.
• -fplugin-arg-name-key=value — defines an argument called key with a value of value for the plugin called name 🎀.
• -fdump-ada-spec[-slim] — for C and C++ source and include files, this generates the matching Ada specs 💜.
• -fada-spec-parent=unit — used together with -fdump-ada-spec[-slim] above, this makes the generated Ada specs child units of the parent unit 🌈.
• -fdump-go-spec=file — for input files in any language, this generates matching Go declarations in file. You get Go const, type, var, and func declarations, which is a really useful way to start writing a Go interface to code written in some other language 🐹🫶.
• @file — reads command-line options from file. The options it reads get slotted in right where the original @file option was 🍓. If file doesn't exist or can't be read, then the option gets treated literally and isn't removed 💀.

Options inside file are separated by whitespace. If you need a whitespace character inside an option, wrap the entire option in single or double quotes. Any character (including a backslash) can be included by putting a backslash in front of it 🙈. The file can also contain more @file options of its own, and those get processed recursively, so yes, it can go deep 🌀.

---

✨ Compiling C++ Programs ✨

C++ source files conventionally use one of the suffixes .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx 💖. C++ header files often use .hh, .hpp, .H, or (for shared template code) .tcc 🦋. Preprocessed C++ files use the suffix .ii ✨, and C++20 module interface units sometimes use .ixx, .cppm, .cxxm, .c++m, or .ccm 🫶.

GCC recognizes files with these names and compiles them as C++ programs, even if you call the compiler the same way you do for C programs (usually with the name gcc) 💅.

Heads up though: using gcc does not add the C++ library 😭. g++ is a program that calls GCC and automatically specifies linking against the C++ library, so it's the one you want for C++ vibes 👑. It treats .c, .h and .i files as C++ source files instead of C source files, unless you use -x 🙈. This program is also useful when precompiling a C header file with a .h extension for use in C++ compilations 🧚. On many systems, g++ is also installed with the name c++ 🌸.

When you compile C++ programs, you can use many of the same command-line options you'd use for programs in any language 🍓. You can also use command-line options meaningful for C and related languages, or options that only mean something for C++ programs 💜.

---

✨ Options Controlling C Dialect ✨

The following options control the dialect of C (or languages derived from C, like C++, Objective-C and Objective-C++) that the compiler accepts 🌈.

• -ansi — in C mode, this is equivalent to -std=c90. In C++ mode, it's equivalent to -std=c++98 🎀.
• -std= — determines the language standard 🔥. This option is currently only supported when compiling C or C++ 🙈.

The compiler can accept several base standards, like c90 or c++98, and GNU dialects of those standards, like gnu90 or gnu++98 💖. When you specify a base standard, the compiler accepts all programs following that standard, plus those using GNU extensions that don't contradict it. For example, -std=c90 turns off certain GCC features that are incompatible with ISO C90, like the "asm" and "typeof" keywords 🙃. It doesn't turn off other GNU extensions that have no meaning in ISO C90, like omitting the middle term of a "?:" expression 🦋.

On the flip side, when you specify a GNU dialect of a standard, every feature the compiler supports gets enabled, even when those features change the meaning of the base standard 😭. Because of that, some strictly conforming programs may get rejected 💀. The particular standard is also what -Wpedantic uses to figure out which features are GNU extensions for that version of the standard. For example, -std=gnu90 -Wpedantic warns about C++ style // comments, while -std=gnu99 -Wpedantic does not 🧐.

You must provide a value for this option. The possible values are:

• c90, c89, iso9899:1990 — supports all ISO C90 programs (certain GNU extensions that conflict with ISO C90 are disabled). Same as -ansi for C code 🌸.
• iso9899:199409 — ISO C90 as modified in amendment 1 📜.
• c99, c9x, iso9899:1999, iso9899:199x — ISO C99 🌟. This standard is substantially completely supported, modulo bugs and floating-point issues (mainly, but not entirely, relating to optional C99 features from Annexes F and G). Check out <https://gcc.gnu.org/c99status.html> for more info 👀. The names c9x and iso9899:199x are deprecated 🚫.
• c11, c1x, iso9899:2011 — ISO C11, the 2011 revision of the ISO C standard ✨. This one is substantially completely supported, modulo bugs, floating-point issues (mainly, but not entirely, relating to optional C11 features from Annexes F and G), and the optional Annexes K (Bounds-checking interfaces) and L (Analyzability) 🎀. The name c1x is deprecated 🚫.
• c17, c18, iso9899:2017, iso9899:2018 — ISO C17, the 2017 revision of the ISO C standard (published in 2018) 🌈. This is the same as C11 except for corrections of defects (all of which are also applied with -std=c11) and a new value of "__STDC_VERSION__", so it's supported to the same extent as C11 💅.
• c23, c2x, iso9899:2024 — ISO C23, the 2023 revision of the ISO C standard (published in 2024) 🔥. The name c2x is deprecated 🚫.
• c2y — the next version of the ISO C standard, still under development 🧪. Support for this version is experimental and incomplete 🙈.
• gnu90, gnu89 — GNU dialect of ISO C90 (including some C99 features) 🦋.
• gnu99, gnu9x — GNU dialect of ISO C99 💜. The name gnu9x is deprecated 🚫.
• gnu11, gnu1x — GNU dialect of ISO C11 🌸. The name gnu1x is deprecated 🚫.
• gnu17, gnu18 — GNU dialect of ISO C17 🎀.
• gnu23, gnu2x — GNU dialect of ISO C23. This is the default for C code 👑. The name gnu2x is deprecated 🚫.
• gnu2y — the next version of the ISO C standard, still under development, plus GNU extensions 🧪. Support for this version is experimental and incomplete. The name gnu2x is deprecated 🚫.
• c++98, c++03 — the 1998 ISO C++ standard plus the 2003 technical corrigendum and some additional defect reports 📜. Same as -ansi for C++ code 🍓.
• gnu++98, gnu++03 — GNU dialect of -std=c++98 ✨.
• c++11, c++0x — the 2011 ISO C++ standard plus amendments 🌈. The name c++0x is deprecated 🚫.
• gnu++11, gnu++0x — GNU dialect of -std=c++11 💖. The name gnu++0x is deprecated 🚫.
• c++14, c++1y — the 2014 ISO C++ standard plus amendments 🦋. The name c++1y is deprecated 🚫.
• gnu++14, gnu++1y — GNU dialect of -std=c++14 🫶. The name gnu++1y is deprecated 🚫.
• c++17, c++1z — the 2017 ISO C++ standard plus amendments 🎀. The name c++1z is deprecated 🚫.
• gnu++17, gnu++1z — GNU dialect of -std=c++17. This is the default for C++ code 👑. The name gnu++1z is deprecated 🚫.
• c++20, c++2a — the 2020 ISO C++ standard plus amendments 🧪. Support is experimental and could change in incompatible ways in future releases 😬. The name c++2a is deprecated 🚫.
• gnu++20, gnu++2a — GNU dialect of -std=c++20 🧪. Support is experimental and could change in incompatible ways in future releases 😬. The name gnu++2a is deprecated 🚫.
• c++23, c++2b — the 2023 ISO C++ standard plus amendments (published in 2024) 🌟. Support is experimental and could change in incompatible ways in future releases 😬. The name c++2b is deprecated 🚫.
• gnu++23, gnu++2b — GNU dialect of -std=c++23 🧪. Support is experimental and could change in incompatible ways in future releases 😬. The name gnu++2b is deprecated 🚫.
• c++2c, c++26 — the next revision of the ISO C++ standard, planned for 2026 🔮. Support is highly experimental, and will almost certainly change in incompatible ways in future releases 💀.
• gnu++2c, gnu++26 — GNU dialect of -std=c++2c 🔮. Support is highly experimental, and will almost certainly change in incompatible ways in future releases 💀.

• -aux-info filename — outputs prototyped declarations to the given filename for all functions declared and/or defined in a translation unit, including the ones in header files 📝. This option is silently ignored in any language other than C 🤫.

Okay so bestie, the aux-info file is lowkey iconic 💅 Besides the declarations, it leaves little comments showing where each one came from (source file and line) 📍. It also tags each declaration as I (implicit), N (new, prototyped) or O (old, unprototyped), right after the line number and colon ✨. The next character says whether it came from a declaration (C) or a definition (F) 🎀. And for function definitions, it also drops a K&R-style list of arguments and their declarations in comments right after the declaration 🦋

---

• -fno-asm — Stops asm, inline and typeof from being treated as keywords, so you can use them as regular identifiers 🙈

Your code can use __asm__, __inline__ and __typeof__ instead, which is giving full keyword energy ✨ In C, -ansi already implies -fno-asm, so no need to add it twice 💅

In C++, inline is a standard keyword, so this switch doesn't touch it at all 🙅‍♀️ If you only want typeof gone and want to keep asm and inline, use -fno-gnu-keywords instead 🎀 In C99 mode (-std=c99 or -std=gnu99), this switch only affects asm and typeof, because inline is already a standard keyword in ISO C99 🌸 In C23 mode (-std=c23 or -std=gnu23), it only affects asm, since typeof is standard in ISO C23 🧚

• -fno-builtin, -fno-builtin-function — Don't recognize built-in functions whose names don't start with __builtin_ 🙅‍♀️

GCC usually generates special code for certain built-in functions so they run faster 🏎️ For example, calls to alloca might turn into a single instruction that adjusts the stack directly, and calls to memcpy might become inline copy loops 🔁 The result is often smaller and faster, but the calls don't show up as calls anymore. That means you can't set a breakpoint on them, and you can't change what they do by linking against a different library 😭 Also, once GCC recognizes a built-in function, it can use what it knows about that function to warn you about bad calls, or to generate more efficient code, even when the code still contains calls to it 👀 For example, warnings are given with -Wformat for bad calls to printf when printf is built in and strlen is known not to modify global memory 💅

With the -fno-builtin-function option, only that one built-in function gets disabled 🎯 function must not begin with __builtin_. If you name a function that isn't built-in in this version of GCC, the option is simply ignored 🤷‍♀️ There's no matching -fbuiltin-function option. If you want to turn built-in functions back on selectively while using -fno-builtin or -ffreestanding, you can define macros like these 🦋

        #define abs(n)          __builtin_abs ((n))
        #define strcpy(d, s)    __builtin_strcpy ((d), (s))

• -fcond-mismatch — Lets conditional expressions have mismatched types in their second and third arguments 🌈 The value of that kind of expression is void. This option is not supported for C++ 🙅‍♀️
• -ffreestanding — Tells GCC that compilation targets a freestanding environment ✨ This implies -fno-builtin. A freestanding environment is one where the standard library might not exist, and program startup might not necessarily start at main 🧚 The most obvious example is an OS kernel 👑 This is equivalent to -fno-hosted.
• -fgimple — Turns on parsing of function definitions marked with __GIMPLE. It's an experimental feature that lets you unit test GIMPLE passes 🧪
• -fgnu-tm — When you specify -fgnu-tm, the compiler generates code for the Linux variant of Intel's current Transactional Memory ABI specification document (Revision 1.1, May 6 2009) 💜 This is experimental, and its interface may change in future versions of GCC as the official specification changes 😬 Not every architecture supports this feature, so heads up 🫶

For more information on GCC's support for transactional memory,

Transactional memory is not supported together with non-call exceptions (-fnon-call-exceptions). Don't mix them, bestie 💀

• -fgnu89-inline — Tells GCC to use the traditional GNU semantics for inline functions when in C99 mode 🌸

Using this option is roughly the same as adding the gnu_inline function attribute to every inline function 🎀

The option -fno-gnu89-inline explicitly tells GCC to use the C99 semantics for inline when in C99 or gnu99 mode. In other words, it sets the default behavior 💅 This option is not supported in -std=c90 or -std=gnu90 mode 🙈

The preprocessor macros __GNUC_GNU_INLINE__ and __GNUC_STDC_INLINE__ can be used to check which semantics are in effect for inline functions 🔍

• -fhosted — Tells GCC that compilation targets a hosted environment ✨ This implies -fbuiltin. A hosted environment is one where the entire standard library is available and main has a return type of int 👑 Basically everything except a kernel fits this description 🧚 This is equivalent to -fno-freestanding.
• -flax-vector-conversions — Allows implicit conversions between vectors with different numbers of elements and/or incompatible element types 😬 Please don't use this in new code, it's giving "old and messy" 💀
• -fms-extensions — Accepts some non-standard constructs found in Microsoft header files 🪟

In C++ code, this lets member names in structures match earlier type declarations, which is so chaotic but also kind of fun 🙈

        typedef int UOW;
        struct ABC {
          UOW UOW;
        };

Some cases of unnamed fields in structures and unions are only accepted with this option 🫣

This option is off for all targets except x86 targets using ms-abi, so don't expect it to just work everywhere 🙅‍♀️

• -fpermitted-flt-eval-methods=style — Controls which values of FLT_EVAL_METHOD the compiler is allowed to use 🦋

ISO/IEC TS 18661-3 defines new permissible values for FLT_EVAL_METHOD. These say that operations and constants whose semantic type is an interchange or extended format should be evaluated to the precision and range of that type 🤓 The new values are a superset of what C99/C11 allows, and C99/C11 doesn't specify what other positive values of FLT_EVAL_METHOD mean. So code that's C11-conformant might never have expected these new values to show up 😭

-fpermitted-flt-eval-methods decides whether the compiler only allows the FLT_EVAL_METHOD values from C99/C11, or the extended set from ISO/IEC TS 18661-3 ✨

style is either c11 or ts-18661-3, depending on what you need 💖

In a standards-compliant mode (-std=c11 or similar), the default is -fpermitted-flt-eval-methods=c11. In a GNU dialect (-std=gnu11 or similar), the default is -fpermitted-flt-eval-methods=ts-18661-3 🌈

The -fdeps-* options extract structured dependency information for a source file 🧠 This means figuring out which resources from other source files the source needs in order to compile, and which resources the source itself provides. That info can add required dependencies between compilation rules of dependent sources based on their actual contents, so the build tools don't have to reflect that information themselves 🫶

• -fdeps-file=file — Where to write the structured dependency information 📝
• -fdeps-format=format — The format to use for structured dependency information. p1689r5 is the only supported format right now 💅 When this argument is specified, the output of -MF gets stripped of some information (namely C++ modules), so it doesn't use extended makefile syntax that most tools won't understand 🙈
• -fdeps-target=file — This is the -MT equivalent for structured dependency information 🎯 It names the target that will ultimately need any required resources, and that will provide any resources extracted from the source that other sources might need 🧚
• -fplan9-extensions — Accepts some non-standard constructs used in Plan 9 code 🐹

This turns on -fms-extensions, lets you pass pointers to structures with anonymous fields to functions that expect pointers to elements of the field's type, and lets you refer to anonymous fields declared using a typedef 🌸 This is only supported for C, not C++ 🙅‍♀️

• -fsigned-bitfields, -funsigned-bitfields, -fno-signed-bitfields, -fno-unsigned-bitfields — Control whether a bit-field is signed or unsigned when the declaration doesn't use either signed or unsigned 🔢 By default, such a bit-field is signed, which is consistent, since basic integer types like int are signed too 💖
• -fsigned-char — Makes the type char signed, just like signed char ✨

This is equivalent to -fno-unsigned-char, which is the negative form of -funsigned-char. Likewise, -fno-signed-char is equivalent to -funsigned-char 🙃

• -funsigned-char — Makes the type char unsigned, just like unsigned char 🌈

Every kind of machine has a default for what char should be. It's either like unsigned char by default, or like signed char by default 🖥️

Ideally, a portable program always uses signed char or unsigned char when it depends on the signedness of an object 🧼 But lots of programs were written to use plain char and expect it to be signed, or expect it to be unsigned, depending on the machines they were written for 😩 This option, and its inverse, let you make those programs work with the opposite default 🫶

The type char is always a distinct type from both signed char and unsigned char, even though it behaves exactly like one of those two 🤓

• -fstrict-flex-arrays (C and C++ only), -fstrict-flex-arrays=level (C and C++ only) — Controls when the trailing array of a structure gets treated as a flexible array member when you're accessing its elements 🦋 The value of level sets how strict that is 💅

-fstrict-flex-arrays is equivalent to -fstrict-flex-arrays=3, which is the strictest option. A trailing array only counts as a flexible array member when it's declared as one, per the C99 standard onwards 📏

The negative form, -fno-strict-flex-arrays, is equivalent to -fstrict-flex-arrays=0, which is the least strict. In that case, every trailing array of a structure is treated as a flexible array member 🌷

okay so there are two more levels hiding between 0 and 3 ✨ they exist for older code that uses the GCC zero-length array extension ([0]) or one-element arrays as flexible array members ([1]) 🧚 when level is 1, the trailing array gets treated as a flexible array member when it's declared as [], [0], or [1]. when level is 2, it only counts when it's declared as [] or [0] 💅

you can control this for one specific trailing array field in a struct by using the variable attribute "strict_flex_array" attribute 🎀

and yes, the -fstrict_flex_arrays option interacts with the -Wstrict-flex-arrays option 🫶

• -fsso-struct=endianness — okay this one sets the default scalar storage order of structures and unions to whatever endianness you pick 🌈 the accepted values are big-endian, little-endian, and native (the native endianness of the target, which is the default). this option is not supported for C++ 🙈

⚠️ warning, bestie: -fsso-struct makes GCC generate code that is not binary compatible with code generated without it if the endianness you specify isn't the native endianness of the target 😭 handle with care

---

✨ Options Controlling C++ Dialect ✨

this section is all about the command-line options that only mean something for C++ programs 💜 you can still use most of the GNU compiler options no matter what language your program is in, though. for example, you might compile a file firstClass.C like this:

g++ -g -fstrict-enums -O -c firstClass.C

in this example, only -fstrict-enums is meant only for C++ programs 🍓 you can use the other options with any language GCC supports.

some options for compiling C programs, like -std, are also relevant for C++ programs too 🦋

here's the list of options that are only for compiling C++ programs 👑

• -fabi-version=n — use version n of the C++ ABI 💖 the default is version 0.
  • version 0 refers to the version that conforms most closely to the C++ ABI specification. so the ABI you get with version 0 will change between versions of G++ as ABI bugs get fixed 🙈
  • version 1 is the version of the C++ ABI that first showed up in G++ 3.2.
  • version 2 is the version that first showed up in G++ 3.4, and it was the default through G++ 4.9.
  • version 3 fixes an error in mangling a constant address as a template argument.
  • version 4, which first showed up in G++ 4.5, implements a standard mangling for vector types.
  • version 5, which first showed up in G++ 4.6, fixes the mangling of attribute const/volatile on function pointer types, decltype of a plain decl, and use of a function parameter in the declaration of another parameter.
  • version 6, which first showed up in G++ 4.7, fixes the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and --, and a class scope function used as a template argument.
  • version 7, which first showed up in G++ 4.8, treats nullptr_t as a builtin type and fixes the mangling of lambdas in default argument scope.
  • version 8, which first showed up in G++ 4.9, fixes the substitution behavior of function types with function-cv-qualifiers.
  • version 9, which first showed up in G++ 5.2, fixes the alignment of "nullptr_t".
  • version 10, which first showed up in G++ 6.1, adds mangling of attributes that affect type identity, such as ia32 calling convention attributes (e.g. stdcall).
  • version 11, which first showed up in G++ 7, fixes the mangling of sizeof... expressions and operator names. for multiple entities with the same name within a function, declared in different scopes, the mangling now changes starting with the twelfth occurrence. it also implies -fnew-inheriting-ctors.
  • version 12, which first showed up in G++ 8, fixes the calling conventions for empty classes on the x86_64 target and for classes with only deleted copy/move constructors. it accidentally changes the calling convention for classes with a deleted copy constructor and a trivial move constructor.
  • version 13, which first showed up in G++ 8.2, fixes the accidental change in version 12 🫶
  • version 14, which first showed up in G++ 10, fixes the mangling of the nullptr expression.
  • version 15, which first showed up in G++ 10.3, fixes the G++ 10 ABI tag regression.
  • version 16, which first showed up in G++ 11, changes the mangling of "__alignof__" so it's distinct from that of "alignof", plus dependent operator names.
  • version 17, which first showed up in G++ 12, fixes the layout of classes that inherit from aggregate classes with default member initializers in C++14 and up.
  • version 18, which first showed up in G++ 13, fixes manglings of lambdas that have additional context.
  • version 19, which first showed up in G++ 14, fixes manglings of structured bindings to include ABI tags.
  • version 20, which first showed up in G++ 15, fixes manglings of lambdas in static data member initializers.
  • see also -Wabi.
• -fabi-compat-version=n — on targets that support strong aliases, G++ works around mangling changes by creating an alias with the correct mangled name whenever it defines a symbol with an incorrect mangled name 🌸 this switch picks which ABI version to use for that alias.
  • with -fabi-version=0 (the default), this defaults to 13 (GCC 8.2 compatibility). if another ABI version is explicitly selected, it defaults to 0. for compatibility with GCC versions 3.2 through 4.9, use -fabi-compat-version=2.
  • if this option isn't provided but -Wabi=n is, that version is used for compatibility aliases. if this option is provided along with -Wabi (without the version), the version from this option gets used for the warning ✨
• -fno-access-control — turns off all access checking 🔓 this switch is mainly useful for working around bugs in the access control code.
• -faligned-new — enables support for C++17 "new" of types that need more alignment than "void* ::operator new(std::size_t)" provides 🎀 a numeric argument like "-faligned-new=32" can say how much alignment (in bytes) that function provides, but few users will need to override the default of alignof(std::max_align_t).
  • this flag is enabled by default for -std=c++17.
• -fno-assume-sane-operators-new — the C++ standard lets you replace the global "new", "new[]", "delete" and "delete[]" operators, though a lot of C++ programs don't replace them and just use the implementation-provided version 🧁 the standard also lets you omit those calls when they're made from new or delete expressions (and by extension the same is assumed if "__builtin_operator_new" or "__builtin_operator_delete" functions are used). this option controls some optimizations around calls to those operators.
  • with "-fassume-sane-operators-new-delete", GCC may assume that calls to the replaceable global operators from new or delete expressions, or from "__builtin_operator_new" or "__builtin_operator_delete" calls, don't read or modify any global variables, or variables whose address could escape to the operators (global state; except for "errno" for the "new" and "new[]" operators). this allows most optimizations across those calls. the implementation-provided operators satisfy this unless "malloc" implementation details are observable in the code or "malloc" hooks are used, but it might not hold if a program replaces those operators.
  • this behavior is enabled by default.
  • with "-fno-assume-sane-operators-new-delete", GCC must assume all these calls (whether from new or delete expressions or called directly) may read and write global state unless proven otherwise (e.g. when GCC compiles their implementation). use this option if those operators are or may be replaced and your code needs to expect that behavior 😤
• -fchar8_t, -fno-char8_t — enables support for "char8_t" as adopted for C++20 💅 that includes a new "char8_t" fundamental type, changes to the types of UTF-8 string and character literals, new signatures for user-defined literals, associated standard library updates, and new "__cpp_char8_t" and "__cpp_lib_char8_t" feature test macros.

this option lets functions be overloaded for ordinary and UTF-8 strings:

        int f(const char *);    // #1
        int f(const char8_t *); // #2
        int v1 = f("text");     // Calls #1
        int v2 = f(u8"text");   // Calls #2

and it introduces new signatures for user-defined literals:

        int operator""_udl1(char8_t);
        int v3 = u8'x'_udl1;
        int operator""_udl2(const char8_t*, std::size_t);
        int v4 = u8"text"_udl2;
        template<typename T, T...> int operator""_udl3();
        int v5 = u8"text"_udl3;

🚨 heads up: the change to the types of UTF-8 string and character literals introduces incompatibilities with ISO C++11 and later standards. for example, the following code is well-formed under ISO C++11, but it's ill-formed when -fchar8_t is specified 💀

        const char *cp = u8"xx";// error: invalid conversion from
                                //        `const char8_t*' to `const char*'
        int f(const char*);
        auto v = f(u8"xx");     // error: invalid conversion from
                                //        `const char8_t*' to `const char*'
        std::string s{u8"xx"};  // error: no matching function for call to
                                //        `std::basic_string<char>::basic_string()'
        using namespace std::literals;
        s = u8"xx"s;            // error: conversion from
                                //        `basic_string<char8_t>' to non-scalar
                                //        type `basic_string<char>' requested

• -fcheck-new — okay so this one makes G++ check that the pointer operator new hands back isn't null before it starts messing with the memory 🎀. Honestly it's usually unnecessary, because the C++ standard says operator new only returns 0 if it's declared throw(), and in that case the compiler checks the return value anyway, even without this flag. In every other case, where operator new has a non-empty exception specification, running out of memory gets signalled by throwing std::bad_alloc 💀. See also new (nothrow).
• -fconcepts — the bestie of template arguments 🦋. This turns on support for the C++ Concepts feature, which lets you constrain template arguments. With -std=c++20 and above, Concepts are part of the language standard, so -fconcepts is on by default ✨.

Some constructs from the earlier C++ Extensions for Concepts Technical Specification, ISO 19217 (2015), didn't make it into the standard, but they can still be enabled with -fconcepts-ts 🌸. Real talk though, -fconcepts-ts was deprecated in GCC 14 and removed in GCC 15, so users are expected to convert their code to C++20 concepts 😭.

• -fconstexpr-depth=n — sets the maximum nested evaluation depth for C++11 constexpr functions to n 🧚. You need a limit like this so endless recursion gets caught during constant expression evaluation. The standard's minimum is 512.
• -fconstexpr-cache-depth=n — sets the maximum level of nested evaluation depth for C++11 constexpr functions that gets cached, to n 💜. This is a heuristic, so it's a trade-off: caching can speed up compilation when it avoids repeated calculations, but it eats memory when highly recursive evaluations make the cache grow huge. The default is 8. Very few people need to touch it, but if your code does heavy constexpr maths, feel free to experiment and find what works best for you ✨.
• -fconstexpr-fp-except — okay this one is spicy 🔥. Annex F of the C standard says IEC559 floating point exceptions hit at compile time shouldn't stop compilation. C++ compilers have historically ignored that and treated floating point division by zero as non-constant, even though it has a well defined value. This flag tells the compiler to give Annex F priority over other rules that say an operation is undefined:

        constexpr float inf = 1./0.; // OK with -fconstexpr-fp-except

• -fconstexpr-loop-limit=n — sets the maximum number of iterations for a loop in C++14 constexpr functions to n 🔁. Endless loops need a cap so they get caught during constant expression evaluation. The default is 262144 (1<<18).
• -fconstexpr-ops-limit=n — sets the maximum number of operations during a single constexpr evaluation 🙈. Even if each loop is under the iteration limit above, several nested loops with lots of iterations, or a ton of expressions inside a loop or outside of one, can make the evaluation take forever. The default is 33554432 (1<<25).
• -fcontracts — enables experimental support for the C++ Contracts feature 🧪. It was briefly added to and then removed from the C++20 working paper (N4820), and the implementation also includes proposed enhancements from papers P1290, P1332, and P1429. This is mostly for people who want to experiment and help shape the feature for a future C++ standard 🫶.

When a checked contract is violated, the violation handler gets called. You can swap in your own handler by defining:

        void
        handle_contract_violation (const std::experimental::contract_violation&);

There are different sets of extra flags for N4820, P1332, or P1429 contracts, and you can't mix these sets together 🌈. Here they are:

• -fcontract-mode=[on|off] — controls whether contracts have any semantics at all. Defaults to on.
• -fcontract-assumption-mode=[on|off] — [N4820] controls whether contracts with level axiom should have the assume semantic. Defaults to on.
• -fcontract-build-level=[off|default|audit] — [N4820] picks which level of contracts gets checks generated for it. Defaults to default.
• -fcontract-continuation-mode=[on|off] — [N4820] controls whether the program is allowed to keep running after a contract violation. In other words, do checked contracts get the maybe semantic instead of the never semantic. Defaults to off.
• -fcontract-role=<name>:<default>,<audit>,<axiom> — [P1332] sets the concrete semantics for each contract level of a particular contract role 💖.
• -fcontract-semantic=[default|audit|axiom]:<semantic> — [P1429] sets the concrete semantic for a particular contract level ✨.
• -fcontract-strict-declarations=[on|off] — controls whether adding contracts to a function after its first declaration gets rejected. Defaults to off.

The concrete semantics you can pick with -fcontract-role or -fcontract-semantic are:

• ignore — this contract has no effect 🙈.
• assume — this contract is treated like C++23 [[assume]].
• check_never_continue, never, abort — this contract is checked. If it fails, the violation handler gets called. If the handler returns, std::terminate is called 💀.
• check_maybe_continue, maybe — this contract is checked. If it fails, the violation handler gets called. If the handler returns, execution keeps going normally 🦋.

• -fcoroutines — enables support for the C++ coroutines extension. It's experimental, so handle with a little care 🧚.
• -fdiagnostics-all-candidates — lets the C++ front end note all the candidates during an overload resolution failure 🔍. That includes the case where a deleted function gets selected.
• -fno-elide-constructors — the C++ standard lets an implementation skip creating a temporary that's only used to initialize another object of the same type 🎀. This flag turns that optimization off and forces G++ to call the copy constructor in all cases. It also makes G++ call trivial member functions that would otherwise be expanded inline.

In C++17, the compiler is required to omit these temporaries, but this option still affects trivial member functions 🫠.

• -fno-enforce-eh-specs — don't generate code that checks for violations of exception specifications at run time 🧃. This breaks the C++ standard, but it can be handy for shrinking code size in production builds, kind of like defining NDEBUG. It does not give your code permission to throw exceptions that break the exception specifications. The compiler still optimizes based on those specs, so throwing an unexpected exception gives you undefined behavior at run time 😬.
• -fextern-tls-init, -fno-extern-tls-init — the C++11 and OpenMP standards let thread_local and threadprivate variables have dynamic (runtime) initialization 🧵. To make that work, any use of such a variable goes through a wrapper function that does the necessary initialization. When the use and the definition are in the same translation unit, the compiler can optimize that overhead away. But when the use is in a different translation unit, there's a big overhead even if the variable doesn't actually need dynamic initialization. If you can be sure that no use in a non-defining TU needs to trigger dynamic initialization, either because the variable is statically initialized or because a use in the defining TU runs before any use in another TU, you can skip that overhead with -fno-extern-tls-init 💅.

On targets that support symbol aliases, the default is -fextern-tls-init. On targets that don't support symbol aliases, the default is -fno-extern-tls-init.

• -ffold-simple-inlines, -fno-fold-simple-inlines — lets the C++ frontend fold calls to std::move, std::forward, std::addressof, and std::as_const 🌷. Unlike inlining, this means no debug information gets generated for those calls. Since these functions are rarely interesting to debug, this flag is enabled by default unless -fno-inline is active.
• -fno-gnu-keywords — typeof stops being a keyword, so your code can use that word as an identifier 🙈. You can use the keyword __typeof__ instead. This option is implied by the strict ISO C++ dialects: -ansi, -std=c++98, -std=c++11, etc.
• -fno-immediate-escalation — stops immediate function escalation, where certain functions can get promoted to consteval, as specified in P2564R3 👑. Here's an example:

        consteval int id(int i) { return i; }

        constexpr int f(auto t)
        {
          return t + id(t); // id causes f<int> to be promoted to consteval
        }

        void g(int i)
        {
          f (3);
        }

That compiles in C++20: f is an immediate-escalating function (because of the auto it's a function template and it's declared constexpr), and id(t) is an immediate-escalating expression, so f gets promoted to consteval. As a result, the call to id(t) sits in an immediate context, so it doesn't have to produce a constant. That's the mechanism that allows consteval function composition 🧚. However, with -fno-immediate-escalation, f doesn't get promoted to consteval, and since the call to the consteval function id(t) isn't a constant expression, the compiler rejects the code ❌.

This option is turned on by default, and it only does anything in C++20 mode or later.

• -fimplicit-constexpr — makes inline functions implicitly constexpr if they meet the requirements for a constexpr function ✨. This option can be used in C++14 mode or later. It can change initialization from dynamic to static, plus some other optimizations come along for the ride 🌈.

✨ OPTIONS (continued) ✨

• -fno-implicit-templates — okay so this one is a lot. The compiler will never emit code for non-inline templates that get instantiated implicitly (aka just by using them) 🙈. It only emits code for explicit instantiations. If you turn this on, you have to structure your code so you include every explicit instantiation you need, or you'll get undefined symbols at link time 💀.

⚠️ bestie, if you skip the explicit instantiations with this flag on, the linker will throw undefined symbol errors at you. Plan ahead!

• -fno-implicit-inline-templates — don't emit code for implicit instantiations of inline templates either 💅. By default the compiler handles inlines differently, so that compiles with and without optimization need the same set of explicit instantiations. Iconic consistency 🫶.
• -fno-implement-inlines — to save space, don't emit out-of-line copies of inline functions controlled by #pragma implementation ✨. Heads up: this causes linker errors if those functions aren't inlined everywhere they're called 😭.
• -fmodules, -fno-modules — enable support for C++20 modules 🧚. The -fno-modules flag is usually not needed, since that's already the default. Even though modules are a C++20 feature, selecting that standard version does not currently turn them on implicitly, so you have to ask for -fmodules yourself 🎀.
• -fmodule-header, -fmodule-header=user, -fmodule-header=system — compile a header file so it becomes an importable header unit 🦋.
• -fmodule-implicit-inline — okay so in modular code, member functions defined inside their class definition are not implicitly inline. That's different from traditional C++ behavior, and it's for good reasons 🤓. It can cause a bit of a headache when porting code though. This option makes those function definitions implicitly inline. Be warned: it creates an ABI incompatibility, so you must use it everywhere or nowhere 🚫. (Definitions outside of a named module stay implicitly inline no matter what 🌸.)
• -fno-module-lazy — disable lazy module importing and module mapper creation 💤.
• -fmodule-mapper=[hostname]:port[?ident], -fmodule-mapper=|program[?ident] args..., -fmodule-mapper==socket[?ident], -fmodule-mapper=<>[inout][?ident], -fmodule-mapper=<in>out[?ident], -fmodule-mapper=file[?ident] — this is the oracle that answers "which filename belongs to this module name?" 🔮. If you don't specify one, the CXX_MODULE_MAPPER environment variable gets used, and if that's unset too, an in-process default is provided ✨.
• -fmodule-only — only emit the Compiled Module Interface, and skip the object file entirely 📦.
• -fms-extensions — disable -Wpedantic warnings about constructs used in MFC 🪟. Examples are implicit int, and getting a pointer to a member function using non-standard syntax 🙈.
• -fnew-inheriting-ctors — enable the P0136 adjustment to the semantics of C++11 constructor inheritance 👑. It's part of C++17, but it's also considered a Defect Report against C++11 and C++14. This flag is enabled by default unless -fabi-version=10 or lower is specified 💖.
• -fnew-ttp-matching — enable the P0522 resolution to Core issue 150, which covers template template parameters and default arguments 🌈. It allows a template with default template arguments to be passed as an argument for a template template parameter that has fewer template parameters. This flag is enabled by default for -std=c++17 ⭐.
• -fno-nonansi-builtins — disable built-in declarations of functions that aren't mandated by ANSI/ISO C 🧹. That includes "ffs", "alloca", "_exit", "index", "bzero", "conjf", and other related functions 🍓.
• -fnothrow-opt — treat a throw() exception specification as if it were a "noexcept" specification 🌸. This reduces or eliminates the text size overhead compared to a function with no exception specification. If the function has local variables with non-trivial destructors, the exception specification actually makes the function smaller, because the EH cleanups for those variables can be optimized away 🤯. The semantic effect is that an exception thrown out of a function with this exception specification results in a call to "terminate" instead of "unexpected" 💀.
• -fno-operator-names — do not treat the operator name keywords "and", "bitand", "bitor", "compl", "not", "or", and "xor" as synonyms for the operators 🙅.
• -fno-optional-diags — disable diagnostics that the standard says a compiler doesn't need to issue 🫠. Right now, the only one G++ issues like that is the one for a name having multiple meanings within a class 🎭.
• -fno-pretty-templates — okay so when an error message refers to a specialization of a function template, the compiler normally prints the template's signature, followed by the template arguments and any typedefs or typenames in that signature. So you get something like "void f(T) [with T = int]" instead of "void f(int)", so you can tell which template is involved 🔍. When an error refers to a specialization of a class template, it leaves out any template arguments that match the default template arguments for that template ✂️. If either of those behaviors makes errors harder to read instead of easier, use -fno-pretty-templates to turn them off 💅.
• -frange-for-ext-temps — enable lifetime extension of C++ range-based for temporaries 🎀. With -std=c++23 and above this is part of the language standard, so the temporaries get extended until the end of the loop by default. This option lets you turn that behavior on in earlier versions of the standard too ⏳.
• -fno-rtti — disable generation of run-time type information for every class with virtual functions 🧬. That info is what the "dynamic_cast" and "typeid" features use. If you don't use those parts of the language, you can save some space with this flag 💜. Exception handling uses the same information, but G++ generates it only when needed 🌷. The "dynamic_cast" operator can still be used for casts that don't need run-time type information, like casts to "void *" or to unambiguous base classes ✨.

⚠️ Mixing code compiled with -frtti and code compiled with -fno-rtti may not work 😬. For example, programs may fail to link if a class compiled with -fno-rtti is used as a base for a class compiled with -frtti.

• -fsized-deallocation — enable the built-in global declarations below, which were introduced in C++14 🗑️:

void operator delete (void *, std::size_t) noexcept;
void operator delete[] (void *, std::size_t) noexcept;

This is useful for user-defined replacement deallocation functions that, for example, use the size of the object to make deallocation faster 🚀. It's enabled by default under -std=c++14 and above. The flag -Wsized-deallocation warns about places that might want to add a definition 👀.

• -fstrict-enums — lets the compiler optimize using the assumption that a value of an enumerated type can only be one of the values of the enumeration 🔢. (As defined in the C++ standard: basically, a value that can be represented in the minimum number of bits needed to represent all the enumerators.) This assumption may not hold if the program uses a cast to convert an arbitrary integer value to the enumerated type 🙃. This option has no effect for an enumeration type with a fixed underlying type 🫥.
• -fstrong-eval-order, -fstrong-eval-order=kind — evaluate member access, array subscripting, and shift expressions in left-to-right order, and evaluate assignment in right-to-left order, as adopted for C++17 🏹. -fstrong-eval-order is equivalent to -fstrong-eval-order=all, and it's enabled by default with -std=c++17 or later 👑.
  • -fstrong-eval-order=some enables just the ordering of member access and shift expressions, and it's the default for C++ dialects prior to C++17 🌙.
  • -fstrong-eval-order=none is equivalent to -fno-strong-eval-order 🫧.
• -ftemplate-backtrace-limit=n — set the maximum number of template instantiation notes for a single warning or error to n 📜. The default value is 10 🔟.
• -ftemplate-depth=n — set the maximum instantiation depth for template classes to n 🌀. A limit on template instantiation depth is needed to detect endless recursions during template class instantiation 🔁. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17 (changed to 1024 in C++11) 📏. The default value is 900, since the compiler can run out of stack space before hitting 1024 in some situations 😵.
• -fno-threadsafe-statics — don't emit the extra code that uses the routines from the C++ ABI for thread-safe initialization of local statics 🧵. You can use this to shave a bit off code size in code that doesn't need to be thread-safe 🍃.
• -fuse-cxa-atexit — register destructors for objects with static storage duration with the "__cxa_atexit" function, instead of the "atexit" function 🚪. This option is required for fully standards-compliant handling of static destructors, but it only works if your C library supports "__cxa_atexit" 📚.
• -fno-use-cxa-get-exception-ptr — don't use the "__cxa_get_exception_ptr" runtime routine 🙅‍♀️. This causes "std::uncaught_exception" to be incorrect, but it's necessary if the runtime routine isn't available 🛠️.
• -fvisibility-inlines-hidden — this switch declares that the user doesn't try to compare pointers to inline functions or methods where the addresses of the two functions are taken in different shared objects 🫣.

The effect is that GCC may, effectively, mark inline methods with __attribute__ ((visibility ("hidden"))), so they don't show up in the export table of a DSO and don't need a PLT indirection when used inside the DSO 🦋. Turning this on can have a dramatic effect on the load and link times of a DSO, because it massively shrinks the dynamic export table when the library makes heavy use of templates 🚀.

The behavior isn't quite the same as marking the methods as hidden directly, because it doesn't affect static variables local to the function, and it doesn't make the compiler deduce that the function is defined in only one shared object 🧐.

You can give a method an explicit visibility to cancel out the effect of the switch for that method 💫. For example, if you do want to compare pointers to a particular inline method, you might mark it as having default visibility 👀. Marking the enclosing class with explicit visibility has no effect 🙃.

Explicitly instantiated inline methods are unaffected by this option, since their linkage might otherwise cross a shared library boundary 🌉.

• -fvisibility-ms-compat — okay so this one is a whole mood 🎀 It tries to use visibility settings to make GCC's C++ linkage model act like Microsoft Visual Studio's, bestie 💅

It makes these changes to GCC's linkage model:

1. It sets the default visibility to "hidden", same as -fvisibility=hidden 🙈
2. Types are not hidden by default, but their members are 👀
3. The One Definition Rule gets relaxed for types with no explicit visibility specification that are defined in more than one shared object. Those declarations are allowed if they'd be allowed without this option ✨

Honestly, in new code you should use -fvisibility=hidden and export only the classes you actually want visible outside. Unfortunately, code might be relying on the Visual Studio behavior, perhaps by accident 😭

Some of the fallout: static data members of the same type, with the same name, defined in different shared objects are different, so changing one won't change the other 💀 Also, pointers to function members defined in different shared objects may not compare equal. And when this flag is given, defining types with the same name in different ways is a violation of the ODR 🚨

• -fno-weak — no weak symbol support, even if your linker provides it 🙅‍♀️ By default, G++ uses weak symbols when they're available. This one only exists for testing and should not be used by end-users. It gives you inferior code and has no benefits, so don't. It may be removed in a future release of G++ 🥀
• -fext-numeric-literals (C++ and Objective-C++ only) — accepts imaginary, fixed-point, or machine-defined literal number suffixes as GNU extensions ✨ When this option is turned off, those suffixes are treated as C++11 user-defined literal numeric suffixes instead. It's on by default for all pre-C++11 dialects and all GNU dialects: -std=c++98, -std=gnu++98, -std=gnu++11, -std=gnu++14. It's off by default for ISO C++11 onwards (-std=c++11, ...) 🌸
• -nostdinc++ — skips the standard directories that are specific to C++ when searching for header files, but still searches the other standard directories 🧚 (This one is used when building the C++ library, so it's giving behind-the-scenes energy 💜)
• -flang-info-include-translate, -flang-info-include-translate-not, -flang-info-include-translate=header — these tell you about include translation events 👀 The first notes accepted include translations, the second notes declined ones. The header form informs you about include translations for that specific header. If header is of the form "user" or "<system>", it gets resolved to a specific user or system header using the include path 🫶
• -flang-info-module-cmi, -flang-info-module-cmi=module — informs you about Compiled Module Interface pathnames 🦋 The first one notes all read CMI pathnames. The module form does not read a specific module's CMI, which is the vibe to remember here 😅 module may be a named module or a header-unit. A header-unit is indicated by either a pathname containing directory separators, or by being enclosed in "<>" or "".
• -stdlib=libstdc++,libc++ — when G++ is configured to support this option, you can pick an alternate C++ runtime library 🌈 There are two options: libstdc++ (the default, native C++ runtime for G++) and libc++, which is the C++ runtime installed on some operating systems (for example, Darwin versions from Darwin11 onwards). This switches G++ to use the headers from the library you pick, and emits "-lstdc++" or "-lc++" respectively when a C++ runtime is needed for linking 🔥

In addition, these warning options only have meanings for C++ programs, so here's the C++-only tea ☕

• -Wabi-tag (C++ and Objective-C++ only) — warns when a type with an ABI tag is used in a context that doesn't have that ABI tag 🏷️ Check out C++ Attributes for more info on ABI tags ✨
• -Wcomma-subscript (C++ and Objective-C++ only) — warns about uses of a comma expression inside a subscripting expression 🙈 This was deprecated in C++20 and is going to be removed in C++23. A comma expression wrapped in "( )" is not deprecated, though, so you're safe there 💖 Example:

void f(int *a, int b, int c) {
    a[b,c];     // deprecated in C++20, invalid in C++23
    a[(b,c)];   // OK
}

In C++23 it's valid to have comma separated expressions in a subscript when an overloaded subscript operator is found and supports the right number and types of arguments 🦄 G++ will accept the formerly valid syntax for code that's not valid in C++23, but used to be valid (though deprecated) in C++20, with a pedantic warning. You can disable that with -Wno-comma-subscript 💅

It's enabled by default with -std=c++20 unless you use -Wno-deprecated, and after -std=c++23 regardless of -Wno-deprecated. Before -std=c++20, it's enabled with an explicit -Wdeprecated 🌸

This warning gets upgraded to an error by -pedantic-errors in C++23 mode or later 😭

• -Wctad-maybe-unsupported (C++ and Objective-C++ only) — warns when you do class template argument deduction (CTAD) on a type with no explicitly written deduction guides 👀 This points out cases where CTAD only succeeded because the compiler synthesized the implicit deduction guides, which might not be what the programmer meant. Some style guides only allow CTAD on types that specifically "opt-in", meaning types designed to support CTAD 🧁 You can suppress this warning with the following pattern:

struct allow_ctad_t; // any name works
template <typename T> struct S {
  S(T) { }
};
// Guide with incomplete parameter type will never be considered.
S(allow_ctad_t) -> S<void>;

• -Wctor-dtor-privacy (C++ and Objective-C++ only) — warns when a class seems unusable because all its constructors or destructors are private, and it has neither friends nor public static member functions 🔒 It also warns if there are no non-private methods, and there's at least one private member function that isn't a constructor or destructor.
• -Wdangling-reference (C++ and Objective-C++ only) — warns when a reference is bound to a temporary whose lifetime has already ended 💀 For example:

int n = 1;
const int& r = std::max(n - 1, n + 1); // r is dangling

In that example, two temporaries are created, one for each argument, and a reference to one of them is returned. Both temporaries are destroyed at the end of the full expression, so the reference "r" is dangling 😱 This warning also catches dangling references in member initializer lists:

const int& f(const int& i) { return i; }
struct S {
  const int &r; // r is dangling
  S() : r(f(10)) { }
};

Member functions get checked too, but only their object argument:

struct S {
   const S& self () { return *this; }
};
const S& s = S().self(); // s is dangling

Some functions are safe in this respect. For example, "std::use_facet" takes and returns a reference, but it doesn't return one of its arguments, which can fool the warning 🫠 You can exclude functions like that by wrapping them in a "#pragma":

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
const T& foo (const T&) { ... }
#pragma GCC diagnostic pop

The "#pragma" can also surround the class. In that case, the warning is disabled for all the member functions ✨

-Wdangling-reference also warns about code like this:

auto p = std::minmax(1, 2);

where "std::minmax" returns "std::pair<const int&, const int&>", and both references dangle after the end of the full expression that contains the call to "std::minmax" 🥀

The warning doesn't fire for "std::span"-like classes 🧚 We consider classes of this form:

template<typename T>
struct Span {
  T* data_;
  std::size len_;
};

as "std::span"-like. That means the class is a non-union class that has a pointer data member and a trivial destructor.

You can disable the warning by using the "gnu::no_dangling" attribute 🙅‍♀️

This warning is enabled by -Wextra 🔥

• -Wdelete-non-virtual-dtor (C++ and Objective-C++ only) — warns when "delete" is used to destroy an instance of a class that has virtual functions and a non-virtual destructor 🚨 It's unsafe to delete an instance of a derived class through a pointer to a base class if the base class doesn't have a virtual destructor. This warning is enabled by -Wall 💖
• -Wdeprecated-copy (C++ and Objective-C++ only) — warns that the implicit declaration of a copy constructor or copy assignment operator is deprecated if the class has a user-provided copy constructor or copy assignment operator, in C++11 and up 🌷 This warning is enabled by -Wextra. With -Wdeprecated-copy-dtor, it also deprecates the implicit declaration if the class has a user-provided destructor 🫶
• -Wno-deprecated-enum-enum-conversion (C++ and Objective-C++ only) — disables the warning about when the usual arithmetic conversions are applied to operands where one is an enumeration type and the other is a different enumeration type 🙃 This conversion was deprecated in C++20. For example:

enum E1 { e };
enum E2 { f };
int k = f - e;

-Wdeprecated-enum-enum-conversion is enabled by default with -std=c++20. In pre-C++20 dialects, you can enable this warning with -Wenum-conversion or -Wdeprecated 🌈

• -Wno-deprecated-enum-float-conversion (C++ and Objective-C++ only) — disables the warning about when the usual arithmetic conversions are applied to operands where one is an enumeration type and the other is a floating-point type 🫧 This conversion was deprecated in C++20. For example:

enum E1 { e };
enum E2 { f };
bool b = e <= 3.7;

-Wdeprecated-enum-float-conversion is enabled by default with -std=c++20. In pre-C++20 dialects, you can enable this warning with -Wenum-conversion or -Wdeprecated ✨

• -Wdeprecated-literal-operator (C++ and Objective-C++ only) — okay so this one warns you that declaring a user-defined literal operator with a space before the suffix is deprecated 🙅‍♀️. It's on by default in C++23, or whenever you explicitly turn on -Wdeprecated. 💅

string operator "" _i18n(const char*, std::size_t); // deprecated
string operator ""_i18n(const char*, std::size_t); // preferred

• -Wdeprecated-variadic-comma-omission (C++ and Objective-C++ only) — leaving out the comma before the varargs ... at the end of a parameter list is deprecated, and this warning tells you so 🎀. It's enabled by default in C++26, or with an explicit -Wdeprecated. ✨

void f1(int...); // deprecated
void f1(int, ...); // preferred
template <typename ...T>
void f2(T...); // ok
template <typename ...T>
void f3(T......); // deprecated

• -Wno-elaborated-enum-base — for C++11 and up, this warns if an (invalid) extra enum-base shows up in an elaborated-type-specifier 🙈. Basically that's an enum with a given underlying type and no enumerator list, used somewhere other than a standalone declaration of the enum. It's enabled by default, and -pedantic-errors upgrades it into a full error. 😭
• -Wno-init-list-lifetime (C++ and Objective-C++ only) — this turns off warnings for std::initializer_list uses that are likely to leave you with dangling pointers 💀. The underlying array of an initializer_list gets treated like a normal C++ temporary, so it's super easy to accidentally keep a pointer to that array after its lifetime is over. Some classic ways that happens:
  • If a function returns a temporary initializer_list, or a local initializer_list variable, the array's lifetime ends at the end of the return statement, so the returned value has a dangling pointer.
  • If a new-expression creates an initializer_list, the array only lives until the end of the enclosing full-expression, so the initializer_list on the heap has a dangling pointer.
  • When an initializer_list variable is assigned from a brace-enclosed initializer list, the temporary array made for the right side of the assignment only lives until the end of the full-expression. So by the next statement, that variable has a dangling pointer.
  • When a list constructor stores the begin pointer from the initializer_list argument, that doesn't extend the array's lifetime. So if a class variable is constructed from a temporary initializer_list, the pointer is left dangling by the end of the variable declaration statement.

// li's initial underlying array lives as long as li
std::initializer_list<int> li = { 1,2,3 };
// assignment changes li to point to a temporary array
li = { 4, 5 };
// now the temporary is gone and li has a dangling pointer
int i = li.begin()[0] // undefined behavior

• -Winvalid-constexpr — this warns when a function never produces a constant expression 🧐. In C++20 and earlier, every constexpr function and function template needs at least one set of arguments in at least one instantiation where calling it could be an evaluated subexpression of a core constant expression. C++23 dropped that rule, so you can now have a constexpr function or function template where no call ever meets the requirements of a core constant expression.

This warning is enabled as a pedantic warning by default in C++20 and earlier. In C++23, you can turn -Winvalid-constexpr on, and then it becomes an ordinary warning. For example:

void f (int& i);
constexpr void
g (int& i)
{
  // Warns by default in C++20, in C++23 only with -Winvalid-constexpr.
  f(i);
}

• -Winvalid-imported-macros — this checks that all imported macro definitions are valid at the end of compilation 🦋. It's not on by default, because it needs extra processing to figure out. It can be really handy when you're preparing sets of header-units and want your macros to stay consistent. 🫶
• -Wno-literal-suffix (C++ and Objective-C++ only) — this stops the warning when a string or character literal is followed by a ud-suffix that doesn't start with an underscore 🌸. GCC treats those suffixes as separate preprocessing tokens, which is a conforming extension that keeps old code using formatting macros from <inttypes.h> working. For example:

#define __STDC_FORMAT_MACROS
#include <inttypes.h>
#include <stdio.h>

int main() {
  int64_t i64 = 123;
  printf("My int64: %" PRId64"\n", i64);
}

In this case, PRId64 is treated as a separate preprocessing token.

This option also controls the warnings you get when a user-defined literal operator is declared with a literal suffix identifier that doesn't start with an underscore. Those suffixes are reserved for future standardization, so GCC warns you about them 👀. These warnings are enabled by default.

• -Wno-narrowing (C++ and Objective-C++ only) — for C++11 and later, narrowing conversions get diagnosed by default, just like the standard requires 🚫. A narrowing conversion from a constant is an error, and a narrowing conversion from a non-constant is a warning. -Wno-narrowing silences that diagnostic. Heads up: this doesn't change what well-formed code means, since narrowing conversions are still ill-formed in SFINAE contexts. 🙅‍♀️

With -Wnarrowing in C++98, you get a warning when a narrowing conversion that C++11 prohibits happens inside { }, like this:

int i = { 2.2 }; // error: narrowing from double to int

This flag is included in -Wall and -Wc++11-compat. 💖

• -Wnoexcept (C++ and Objective-C++ only) — warns when a noexcept-expression evaluates to false because of a call to a function that doesn't have a non-throwing exception specification (so no throw() or noexcept), even though the compiler knows it never actually throws an exception 🤔.
• -Wnoexcept-type (C++ and Objective-C++ only) — this warns if the C++17 feature that makes noexcept part of a function type changes the mangled name of a symbol compared to C++14 🌈. It's enabled by -Wabi and -Wc++17-compat. Here's the example:

template <class T> void f(T t) { t(); };
void g() noexcept;
void h() { f(g); }

In C++14, f calls f<void(*)()>, but in C++17 it calls f<void(*)()noexcept>. 🧚

• -Wclass-memaccess (C++ and Objective-C++ only) — this warns when the destination of a call to a raw memory function, like memset or memcpy, is an object of class type 🙈. It also warns when writing into that object might sidestep a non-trivial or deleted constructor or copy assignment, break const-correctness or encapsulation, or corrupt virtual table pointers. Messing with the representation of those objects can break invariants that the class's member functions rely on. For example, the memset call below is undefined because it modifies a non-trivial class object, so it gets flagged:

std::string str = "abc";
memset (&str, 0, sizeof str);

The safe move is to initialize or clear those objects with the appropriate constructor or assignment operator, if one exists ✨. -Wclass-memaccess is enabled by -Wall. Explicitly casting the pointer to the class object to void *, or to a type that the raw memory function can safely access, suppresses the warning.

• -Wnon-virtual-dtor (C++ and Objective-C++ only) — this warns when a class has virtual functions and an accessible non-virtual destructor, either on itself or on an accessible polymorphic base class 😬. That combo makes it possible (but unsafe) to delete a derived-class instance through a pointer to the class or base class. This warning gets turned on automatically when you specify -Weffc++. Honestly, -Wdelete-non-virtual-dtor (enabled by -Wall) is the better pick, because it warns about the unsafe cases without false positives. 👑
• -Wregister (C++ and Objective-C++ only) — warns on uses of the register storage class specifier, unless it's part of the GNU Explicit Register Variables extension 🗑️. register was deprecated in C++11 and removed in C++17. It's enabled by default with -std=c++17.
• -Wreorder (C++ and Objective-C++ only) — warns when the order of member initializers in your code doesn't match the order they actually have to run in 🔁. For instance:

struct A {
  int i;
  int j;
  A(): j (0), i (1) { }
};

The compiler rearranges the member initializers for i and j to match the declaration order of the members, and it emits a warning about that. -Wreorder is enabled by -Wall.

• -Wno-pessimizing-move (C++ and Objective-C++ only) — this warns when a call to std::move stops copy elision from happening 🙅‍♀️. A typical case where copy elision can kick in is when you return from a function with a class return type, the expression being returned is the name of a non-volatile automatic object (and not a function parameter), and it has the same type as the function's return type. Check this one out:

struct T {
...
};
T fn()
{
  T t;
  ...
  return std::move (t);
}

In this example, the std::move call prevents copy elision, so you get the warning. This warning is enabled by -Wall. 💅

• -Wno-redundant-move (C++ and Objective-C++ only) — this warns about redundant calls to std::move, meaning a move operation would have happened even without the std::move call 🫠. That happens because the compiler is forced to treat the object as an rvalue in certain situations, like returning a local variable where copy elision doesn't apply. Consider:

                   struct T {
                   ...
                   };
                   T fn(T t)
                   {
                     ...
                     return std::move (t);
                   }

okay so here the std::move call is redundant 🙄 and bestie, G++ implements Core Issue 1579, so there's another example that's lowkey sneaky:

                   struct T { // convertible to U
                   ...
                   };
                   struct U {
                   ...
                   };
                   U fn()
                   {
                     T t;
                     ...
                     return std::move (t);
                   }

in this one, copy elision isn't applicable because the type of the expression being returned and the function return type differ 💀 but G++ still treats the return value as if it were designated by an rvalue. it's giving confusing, fr fr 🌸

This warning is enabled by -Wextra ✨

---

• -Wrange-loop-construct (C++ and Objective-C++ only) — the main character of this warning is an unnecessary copy inside a C++ range-based for-loop 🦋 it happens when the range declaration isn't a reference, but it probably should be. for example:

                   struct S { char arr[128]; };
                   void fn () {
                     S arr[5];
                     for (const auto x : arr) { ... }
                   }

it does not warn when the type being copied is a trivially-copyable type whose size is less than 64 bytes, so no need to panic over tiny stuff 🫶

this warning also catches a loop variable in a range-based for-loop that gets initialized with a value of a different type, which results in a copy. like:

                   void fn() {
                     int arr[10];
                     for (const double &x : arr) { ... }
                   }

in the example above, every single iteration makes a temporary value of type double that gets created and destroyed, and the reference const double & is bound to it. not it 😭

This warning is enabled by -Wall 💜

• -Wredundant-tags (C++ and Objective-C++ only) — warns about redundant class-key and enum-key in references to class types and enumerated types, in contexts where the key can be dropped without causing an ambiguity ✨ for example:

                   struct foo;
                   struct foo *p;   // warn that keyword struct can be eliminated

but on the other hand, in this example there is no warning, because the keyword is actually necessary:

                   struct foo;
                   void foo ();   // "hides" struct foo
                   void bar (struct foo&);  // no warning, keyword struct is necessary

• -Wno-subobject-linkage (C++ and Objective-C++ only) — turns off the warning for when a class type has a base or a field whose type uses the anonymous namespace or depends on a type with no linkage 🎀 if a type A depends on a type B with no or internal linkage, defining it in multiple translation units would be an ODR violation, because the meaning of B is different in each translation unit. if A only shows up in a single translation unit, the best way to silence the warning is to give it internal linkage by putting it in an anonymous namespace as well. the compiler doesn't give this warning for types defined in the main .C file, since those are unlikely to have multiple definitions. -Wsubobject-linkage is enabled by default 🧚
• -Weffc++ (C++ and Objective-C++ only) — warns about violations of the following style guidelines from Scott Meyers' Effective C++ series of books 📚
  • Define a copy constructor and an assignment operator for classes with dynamically-allocated memory.
  • Prefer initialization to assignment in constructors.
  • Have "operator=" return a reference to *this.
  • Don't try to return a reference when you must return an object.
  • Distinguish between prefix and postfix forms of increment and decrement operators.
  • Never overload "&&", "||", or ",".

this option also enables -Wnon-virtual-dtor, which is also one of the effective C++ recommendations. however, the check is extended to warn about the lack of virtual destructor in accessible non-polymorphic bases classes too 💅

heads up: when you pick this option, the standard library headers don't obey all of these guidelines, so use grep -v to filter out those warnings 🙈

• -Wno-exceptions (C++ and Objective-C++ only) — disables the warning for when an exception handler is shadowed by another handler, which can point out a wrong ordering of exception handlers 🌈
• -Wstrict-null-sentinel (C++ and Objective-C++ only) — warns about the use of an uncasted "NULL" as sentinel. when compiling only with GCC this is a valid sentinel, since "NULL" is defined to "__null". it's a null pointer constant rather than a null pointer, but it's guaranteed to be the same size as a pointer. BUT this use is not portable across different compilers, so be careful bestie ⭐
• -Wno-non-template-friend (C++ and Objective-C++ only) — disables warnings when non-template friend functions are declared within a template. in very old versions of GCC that predate the implementation of the ISO standard, declarations such as friend int foo(int), where the name of the friend is an unqualified-id, could be interpreted as a particular specialization of a template function. the warning exists to diagnose compatibility problems, and it's enabled by default 🍓
• -Wold-style-cast (C++ and Objective-C++ only) — warns if an old-style (C-style) cast to a non-void type is used within a C++ program 👑 the new-style casts ("dynamic_cast", "static_cast", "reinterpret_cast", and "const_cast") are less vulnerable to unintended effects and way easier to search for, so ngl, use those instead 💖
• -Woverloaded-virtual (C++ and Objective-C++ only)
• -Woverloaded-virtual=n — warns when a function declaration hides virtual functions from a base class 🦋 for example, in:

                   struct A {
                     virtual void f();
                   };

                   struct B: public A {
                     void f(int); // does not override
                   };

the "A" class version of "f" is hidden in "B", and code like this:

                   B* b;
                   b->f();

fails to compile 💀

in cases where the different signatures are not an accident, the simplest solution is to add a using-declaration to the derived class to un-hide the base function, e.g. add "using A::f;" to "B" 🫶

the optional level suffix controls the behavior when all the declarations in the derived class override virtual functions in the base class, even if not all of the base functions are overridden. for example:

                   struct C {
                     virtual void f();
                     virtual void f(int);
                   };

                   struct D: public C {
                     void f(int); // does override
                   }

this pattern is less likely to be a mistake. if D is only used virtually, the user might have decided that the base class semantics for some of the overloads are fine.

at level 1, this case does not warn; at level 2, it does. -Woverloaded-virtual by itself selects level 2. Level 1 is included in -Wall ✨

• -Wno-pmf-conversions (C++ and Objective-C++ only) — disables the diagnostic for converting a bound pointer to member function to a plain pointer 🌸
• -Wsign-promo (C++ and Objective-C++ only) — warns when overload resolution chooses a promotion from an unsigned or enumerated type to a signed type, over a conversion to an unsigned type of the same size. previous versions of G++ tried to preserve unsignedness, but the standard mandates the current behavior 📜
• -Wtemplates (C++ and Objective-C++ only) — warns when a primary template declaration is encountered. some coding rules disallow templates, and this can be used to enforce that rule. the warning is inactive inside a system header file, such as the STL, so you can still use the STL 🧚 one may also instantiate or specialize templates, no warning there 💜
• -Wmismatched-new-delete (C++ and Objective-C++ only) — warns for mismatches between calls to "operator new" or "operator delete" and the corresponding call to the allocation or deallocation function 😭 this includes invocations of C++ "operator delete" with pointers returned from either mismatched forms of "operator new", or from other functions that allocate objects for which the "operator delete" isn't a suitable deallocator, as well as calls to other deallocation functions with pointers returned from "operator new" for which the deallocation function isn't suitable.

for example, the "delete" expression in the function below gets diagnosed, because it doesn't match the array form of the "new" expression the pointer argument was returned from. similarly, the call to "free" is also diagnosed:

                   void f ()
                   {
                     int *a = new int[n];
                     delete a;   // warning: mismatch in array forms of expressions

                     char *p = new char[n];
                     free (p);   // warning: mismatch between new and free
                   }

the related option -Wmismatched-dealloc diagnoses mismatches involving allocation and deallocation functions other than "operator new" and "operator delete" 🎀

-Wmismatched-new-delete is included in -Wall 🔥

• -Wmismatched-tags (C++ and Objective-C++ only) — warns for declarations of structs, classes, and class templates and their specializations with a class-key that doesn't match either the definition or the first declaration if no definition is provided 💅

for example, the declaration of "struct Object" in the argument list of "draw" triggers the warning. to avoid it, either remove the redundant class-key "struct" or replace it with "class" to match its definition:

                   class Object {
                   public:
                     virtual ~Object () = 0;
                   };
                   void draw (struct Object*);

it's not wrong to declare a class with the class-key "struct" as the example above shows 🙈 the -Wmismatched-tags option is intended to help achieve a consistent style of class declarations. in code that's meant to be portable to Windows-based compilers, the warning helps prevent unresolved references due to the difference in the mangling of symbols declared with different class-keys 🌈 the option can be used either on its own or in conjunction with -Wredundant-tags 🫶

• -Wmultiple-inheritance (C++ and Objective-C++ only) — okay so this one warns you when a class is defined with multiple direct base classes 👀 Some coding rules ban multiple inheritance, so this is how you enforce that rule 📏 It goes quiet inside system header files like the STL, so you can still use the STL freely 💖 You're also still allowed to define classes that indirectly use multiple inheritance ✨
• -Wvirtual-inheritance — this warns when a class is defined with a virtual direct base class 🦋 Same deal as above: some coding rules disallow multiple inheritance, and this helps enforce that 💅 It's also silent inside system headers like the STL, and you can still define classes that indirectly use virtual inheritance 🌸
• -Wno-virtual-move-assign — this one suppresses warnings about inheriting from a virtual base that has a non-trivial C++11 move assignment operator 🙈 Heads up, this is a bit of a danger zone 💀 If the virtual base is reachable along more than one path, it gets moved multiple times, which can leave both objects in the moved-from state 😭 If your move assignment operator is written so it never moves from a moved-from object, you're safe to turn this warning off 🫶
• -Wnamespaces — warns when a namespace definition is opened 🧚 Some coding rules say no namespaces, and this is the enforcer 👑 Like the others, it's inactive inside system header files such as the STL, so the STL is still yours 💜 You can also still use using directives and qualified names 🎀
• -Wno-template-body (C++ and Objective-C++ only) — this disables diagnosing errors while parsing a template, and instead hits you with an error only when the template actually gets instantiated 🫠 It can also downgrade those errors into warnings with Wno-error= or -fpermissive ✨
• -Wno-template-id-cdtor (C++ and Objective-C++ only) — this turns off the warning about using a simple-template-id as the declarator-id of a constructor or destructor 💅 That stopped being valid in C++20 thanks to DR 2237, so here's what that looks like:

        template<typename T> struct S {
          S<T>(); // should be S();
          ~S<T>();  // should be ~S();
        };

-Wtemplate-id-cdtor is enabled by default with -std=c++20, and it's also turned on by -Wc++20-compat 🌈

• -Wtemplate-names-tu-local — this warns when a template body hides an exposure of a translation-unit-local entity 🔍 Usually, referring to a translation-unit-local entity (like an internal linkage declaration) inside something emitted into a module's CMI is an error 🚨 BUT inside a variable's initializer, or in the body of a non-inline function, it isn't an exposure, so no error gets emitted 🙃

The tricky part: variable or function templates can accidentally become unusable if they reference one of these entities, because other translation units that import the template will never be able to instantiate it 😭 This warning tries to catch cases where that might happen 🕵️‍♀️ An explicit instantiation silences the warning 🤫

This flag is enabled by -Wextra 💖

• -Wno-terminate (C++ and Objective-C++ only) — disables the warning about a throw-expression that will immediately result in a call to "terminate" 💥
• -Wno-vexing-parse (C++ and Objective-C++ only) — this warns about the most vexing parse syntactic ambiguity 🤯 It flags declarations that look like variable definitions, but C++ says they have to be read as function declarations 🙈 For instance:

        void f(double a) {
          int i();        // extern int i (void);
          int n(int(a));  // extern int n (int);
        }

Another example:

        struct S { S(int); };
        void f(double a) {
          S x(int(a));   // extern struct S x (int);
          S y(int());    // extern struct S y (int (*) (void));
          S z();         // extern struct S z (void);
        }

The warning will suggest ways to deal with the ambiguity, e.g. removing the parentheses or using braces instead ✨

This warning is enabled by default 🌸

• -Wno-class-conversion (C++ and Objective-C++ only) — don't warn when a conversion function converts an object to the same type, to a base class of that type, or to void 🫧 Such a conversion function will never be called, so the warning is kind of pointless 🙄
• -Wvolatile (C++ and Objective-C++ only) — warns about deprecated uses of the "volatile" qualifier 📛 That includes:
  • postfix and prefix "++" and "--" expressions of "volatile"-qualified types
  • simple assignments where the left operand is a "volatile"-qualified non-class type, using its value
  • compound assignments where the left operand is a "volatile"-qualified non-class type
  • "volatile"-qualified function return types
  • "volatile"-qualified parameter types
  • structured bindings of a "volatile"-qualified type

This usage was deprecated in C++20 🥲

It's enabled by default with -std=c++20. Before -std=c++20, it's enabled with an explicit -Wdeprecated 💜

• -Waligned-new — warns about a new-expression of a type that needs greater alignment than alignof(std::max_align_t) but uses an allocation function without an explicit alignment parameter 📐 This option is enabled by -Wall 🎀

Normally this only warns about global allocation functions, but -Waligned-new=all also warns about class member allocation functions 👀

• -Wno-placement-new and -Wplacement-new=n — warns about placement new expressions with undefined behavior, like constructing an object in a buffer that's smaller than the object's type 😱 For example, this placement new gets diagnosed because it tries to construct an array of 64 integers in a buffer that's only 64 bytes:

        char buf [64];
        new (buf) int[64];

This warning is enabled by default 🫶

• -Wplacement-new=1 — this is the default warning level for -Wplacement-new 💅 At this level, the warning isn't issued for some strictly undefined constructs that GCC allows as extensions for compatibility with legacy code 🫠 For example, the following "new" expression isn't diagnosed at this level, even though the C++ standard says it's undefined behavior, because it writes past the end of the one-element array:

            struct S { int n, a[1]; };
            S *s = (S *)malloc (sizeof *s + 31 * sizeof s->a[0]);
            new (s->a)int [32]();

• -Wplacement-new=2 — at this level, GCC diagnoses everything level 1 does, plus placement new expressions that construct an object in the last member of a structure, where that member is an array of a single element and the size is less than the size of the object being constructed 🔥 The previous example would be diagnosed here, but the following construct uses the flexible member array extension to dodge the warning at level 2 🦋

            struct S { int n, a[]; };
            S *s = (S *)malloc (sizeof *s + 32 * sizeof s->a[0]);
            new (s->a)int [32]();

• -Wcatch-value and -Wcatch-value=n (C++ and Objective-C++ only) — warns about catch handlers that don't catch via reference 🙅‍♀️
  • -Wcatch-value=1 (or just -Wcatch-value for short) warns about polymorphic class types that are caught by value 🧁
  • -Wcatch-value=2 warns about all class types that are caught by value 💫
  • -Wcatch-value=3 warns about all types that are not caught by reference 🌈

-Wcatch-value is enabled by -Wall ✨

• -Wconditionally-supported (C++ and Objective-C++ only) — warns for conditionally-supported constructs (C++11 [intro.defs]) 🧩
• -Wno-defaulted-function-deleted (C++ and Objective-C++ only) — warns when an explicitly defaulted function gets deleted by the compiler 🗑️ That can happen when the function's declared type doesn't match the type of the function that would have been implicitly declared 🙈 This warning is enabled by default 🌸
• -Wno-delete-incomplete (C++ and Objective-C++ only) — don't warn when deleting a pointer to an incomplete type, which may cause undefined behavior at runtime 😬 This warning is enabled by default 💜
• -Wextra-semi (C++, Objective-C++ only) — warns about redundant semicolons 🙄 Extra semicolons can pop up in a few different places:
  • a semicolon after in-class function definitions, which is valid in all C++ dialects and is never a pedwarn:

        struct S {
          void foo () {};
        };

• an extra semicolon at namespace scope, which has been allowed since C++11 (so it's a pedwarn in C++98):

        struct S {
        };
        ;

• an extra semicolon in class definitions, which has also been allowed since C++11 (so it's a pedwarn in C++98):

        struct S {
          int a;
          ;
        };

• -Wno-global-module (C++ and Objective-C++ only) — disables the diagnostic for when the global module fragment of a module unit doesn't consist only of preprocessor directives 🧚
• -Wno-inaccessible-base (C++, Objective-C++ only) — this controls warnings when a base class is inaccessible in a class derived from it because of ambiguity 🔎 The warning is enabled by default ✨ Note that the warning for ambiguous virtual bases is enabled by the -Wextra option 💅

        struct A { int a; };

        struct B : A { };

        struct C : B, A { };

• -Wno-inherited-variadic-ctor — suppresses warnings about using C++11 inheriting constructors when the base class being inherited from has a C variadic constructor 🙃 The warning is on by default, because the ellipsis is not inherited 🫠
• -Wno-invalid-offsetof (C++ and Objective-C++ only) — suppresses warnings from applying the "offsetof" macro to a non-POD type 🙈 According to the 2014 ISO C++ standard, applying "offsetof" to a non-standard-layout type is undefined 😳 In existing C++ implementations, though, "offsetof" typically gives meaningful results 🤷‍♀️ This flag is for users who know they're writing nonportable code and have deliberately chosen to ignore the warning 💖

The restrictions on "offsetof" may be relaxed in a future version of the C++ standard 🌸

• -Wsized-deallocation (C++ and Objective-C++ only) — bestie, this one warns when you define an unsized deallocation function but there's no matching sized one (or the other way around) 🧹✨ The unsized version looks like this:

void operator delete (void *) noexcept;
void operator delete[] (void *) noexcept;

and the sized version looks like this:

void operator delete (void *, std::size_t) noexcept;
void operator delete[] (void *, std::size_t) noexcept;

It's enabled by -Wextra along with -fsized-deallocation 🎀

• -Wsuggest-final-types — this one is giving code-review energy 🧐 It warns about types with virtual methods where your code would be cleaner if the type were declared with the C++11 final specifier or, if possible, declared in an anonymous namespace. That lets GCC devirtualize the polymorphic calls more aggressively, which is lowkey iconic 💅 This warning hits harder with link-time optimization, because the class hierarchy graph is more complete then 🌸
• -Wsuggest-final-methods — same vibe, but at the method level 🦋 It warns about virtual methods that would be better off declared with the C++11 final specifier or, if possible, with their type declared in an anonymous namespace or with the final specifier. Again, this is more effective with link-time optimization, when the class hierarchy graph is more complete 👑 Pro tip from the manual (not me, the manual 🙈): look at the -Wsuggest-final-types suggestions first, then rebuild with the new annotations ✨
• -Wsuggest-override — warns about overriding virtual functions that aren't marked with the override keyword. No sneaky overrides allowed, periodt 💜
• -Wno-conversion-null (C++ and Objective-C++ only) — this one turns off warnings for conversions between NULL and non-pointer types 🙅‍♀️ Heads up, -Wconversion-null is enabled by default, so you'd have to ask for this one specifically 🥺

---

✨ Options Controlling Objective-C and Objective-C++ Dialects ✨

(Quick note first, okay? 📝 This manual does not describe the Objective-C and Objective-C++ languages themselves. This section is only about the command-line options that are meaningful for Objective-C and Objective-C++ programs. You can also use most of the language-independent GNU compiler options. For example, you might compile a file some_class.m like this:)

gcc -g -fgnu-runtime -O -c some_class.m

In this example, -fgnu-runtime is an option meant only for Objective-C and Objective-C++ programs. You can use the other options with any language GCC supports 🌈

Since Objective-C is an extension of the C language, Objective-C compilations may also use options specific to the C front-end (e.g., -Wtraditional). Similarly, Objective-C++ compilations may use C++-specific options (e.g., -Wabi) 🫶

Here's the list of options that are only for compiling Objective-C and Objective-C++ programs 💖

• -fconstant-string-class=class-name — tells GCC which class to instantiate for each literal string written with the @"..." syntax 🧁 Use class-name as that class. The default is NXConstantString if the GNU runtime is being used, and NSConstantString if the NeXT runtime is being used (see below). On Darwin / macOS platforms, the -fconstant-cfstrings option, if it's also present, overrides the -fconstant-string-class setting and causes @"..." literals to be laid out as constant CoreFoundation strings. Also, -fconstant-cfstrings is an alias for the target-specific -mconstant-cfstrings equivalent 💅
• -fgnu-runtime — generates object code compatible with the standard GNU Objective-C runtime. This is the default on most types of systems 🐣
• -fnext-runtime — generates output compatible with the NeXT runtime. This is the default on NeXT-based systems, including Darwin / macOS 🍎 The macro __NEXT_RUNTIME__ is predefined if, and only if, this option is used ✨
• -fno-nil-receivers — assumes that all Objective-C message dispatches ([receiver message:arg]) in this translation unit make sure the receiver is not nil. That lets the runtime use more efficient entry points 🏃‍♀️ This option is only available together with the NeXT runtime and ABI version 0 or 1.
• -fobjc-abi-version=n — uses version n of the Objective-C ABI for the selected runtime 🎀 Right now this is only supported for the NeXT runtime. In that case, version 0 is the traditional (32-bit) ABI without support for properties and other Objective-C 2.0 additions. Version 1 is the traditional (32-bit) ABI with support for properties and other Objective-C 2.0 additions. Version 2 is the modern (64-bit) ABI. If you don't specify anything, the default is version 0 on 32-bit target machines, and version 2 on 64-bit target machines 💜
• -fobjc-call-cxx-cdtors — for each Objective-C class, GCC checks whether any of its instance variables is a C++ object with a non-trivial default constructor. If so, it synthesizes a special - (id) .cxx_construct instance method, which runs those non-trivial default constructors on the instance variables, in order, and then returns self. It also checks whether any instance variable is a C++ object with a non-trivial destructor, and if so, synthesizes a special - (void) .cxx_destruct method, which runs all those default destructors in reverse order 🧨

The - (id) .cxx_construct and - (void) .cxx_destruct methods generated this way only operate on instance variables declared in the current Objective-C class, not the ones inherited from superclasses. It's the Objective-C runtime's responsibility to invoke all of these methods across an object's inheritance hierarchy. The - (id) .cxx_construct methods get invoked by the runtime right after a new object instance is allocated, and the - (void) .cxx_destruct methods get invoked right before the runtime deallocates an object instance 🫧

As of this writing, only the NeXT runtime on Mac OS X 10.4 and later can invoke the - (id) .cxx_construct and - (void) .cxx_destruct methods 🍏

• -fobjc-direct-dispatch — allows fast jumps to the message dispatcher. On Darwin, this is done via the comm page 🚀
• -fobjc-exceptions — enables syntactic support for structured exception handling in Objective-C, similar to what C++ offers 🙌 This option is required to use the Objective-C keywords @try, @throw, @catch, @finally and @synchronized. It's available with both the GNU runtime and the NeXT runtime, but it's not available together with the NeXT runtime on Mac OS X 10.2 and earlier 💀
• -fobjc-gc — enables garbage collection (GC) in Objective-C and Objective-C++ programs 🗑️ This is only available with the NeXT runtime. The GNU runtime has a different garbage collection implementation that doesn't need any special compiler flags 🧹
• -fobjc-nilcheck — for the NeXT runtime with version 2 of the ABI, checks for a nil receiver in method invocations before doing the actual method call 🔍 This is the default, and you can turn it off with -fno-objc-nilcheck. Class methods and super calls are never checked for nil this way, no matter what this flag is set to. Right now this flag does nothing when the GNU runtime, or an older version of the NeXT runtime ABI, is used 🙃
• -fobjc-std=objc1 — conforms to the language syntax of Objective-C 1.0, the language recognized by GCC 4.0 📜 This only affects the Objective-C additions to the C/C++ language. It doesn't change conformance to C/C++ standards, which is controlled by the separate C/C++ dialect option flags. When you use this option with the Objective-C or Objective-C++ compiler, any Objective-C syntax that GCC 4.0 doesn't recognize gets rejected. It's useful if you need to make sure your Objective-C code can be compiled with older versions of GCC 🕰️
• -freplace-objc-classes — emits a special marker that tells ld(1) not to statically link the resulting object file, and lets dyld(1) load it at run time instead 🔁 This is used with the Fix-and-Continue debugging mode, where the object file may be recompiled and dynamically reloaded during program execution, without restarting the program itself. Right now, Fix-and-Continue is only available together with the NeXT runtime on Mac OS X 10.3 and later ✨
• -fzero-link — when compiling for the NeXT runtime, the compiler normally replaces calls to objc_getClass("...") (when the class name is known at compile time) with static class references that get initialized at load time, which is better for run-time performance 🏎️ Specifying -fzero-link suppresses that behavior and keeps the calls to objc_getClass("..."). This is useful in Zero-Link debugging mode, since it lets you modify individual class implementations during program execution. The GNU runtime currently always keeps calls to objc_get_class("...") regardless of command-line options 🫠
• -fno-local-ivars — by default, instance variables in Objective-C can be accessed as if they were local variables from within the methods of the class they're declared in. That can cause shadowing between instance variables and other variables declared locally inside a class method, or globally, with the same name 👀 Specifying -fno-local-ivars disables this behavior, which avoids those variable shadowing issues 🌷
• -fivar-visibility=[public|protected|private|package] — sets the default instance variable visibility to the option you choose, so that instance variables declared outside the scope of any access modifier directive default to that visibility 🔒
• -gen-decls — dumps interface declarations for all classes seen in the source file to a file named sourcename.decl 📂
• -Wassign-intercept (Objective-C and Objective-C++ only) — warns whenever an Objective-C assignment is being intercepted by the garbage collector 🚨
• -Wno-property-assign-default (Objective-C and Objective-C++ only) — doesn't warn if a property for an Objective-C object has no assign semantics specified 🤫

Okay so bestie, we're picking up right where the Objective-C warnings get spicy 🙈

• -Wno-protocol (Objective-C and Objective-C++ only) — okay so if a class says it implements a protocol, GCC yells at you for every protocol method the class doesn't implement 😤 By default it even yells about methods the class inherits from its superclass without explicitly implementing them. But if you use -Wno-protocol, inherited methods count as implemented and GCC stays quiet about them 🫶
• -Wobjc-root-class (Objective-C and Objective-C++ only) — warns if a class interface has no superclass. Most classes inherit from "NSObject" (or "Object"), for example 💅 If you're making a root class on purpose, you can shut the warning up by marking its interface with "__attribute__((objc_root_class))" ✨
• -Wselector (Objective-C and Objective-C++ only) — warns if you end up with multiple methods of different types for the same selector during compilation 👀 It checks the method list at the very final stage of compilation, and it also checks each selector used in a @selector(...) expression that has a matching method somewhere in the compilation. Because all of this happens only at the end, these warnings won't show up if the final stage never gets reached, like when there's an error earlier on or when you're using -fsyntax-only 💀
• -Wstrict-selector-match (Objective-C and Objective-C++ only) — warns if a selector has multiple methods with different argument and/or return types when you're sending a message to a receiver of type "id" or "Class" 🔥 This is off by default, and when it's off GCC skips the warning if the differences are only between types that share the same size and alignment.
• -Wundeclared-selector (Objective-C and Objective-C++ only) — warns if you use a @selector(...) expression for a selector that hasn't been declared yet 🙅‍♀️ A selector counts as undeclared if no method with that name was declared before the @selector(...) expression, either explicitly in an @interface or @protocol declaration, or implicitly in an @implementation section. This one checks the moment it spots a @selector(...) expression, while -Wselector waits for the final stage. It also enforces the coding style rule that methods and selectors must be declared before you use them 🧚
• -print-objc-runtime-info — generates a C header describing the largest structure that gets passed by value, if there is one 🌸

🌈 Options Controlling OpenMP and OpenACC 🌈

okay so GCC supports OpenMP extensions for C, C++, and Fortran with -fopenmp ✨ And OpenACC extensions work in all three languages with -fopenacc 💖

• -foffload=disable, -foffload=default, -foffload=target-list — this is where you pick which OpenMP and OpenACC offload targets get code generated for them 🎯 The default, which is the same as -foffload=default, generates code for all supported offload targets. -foffload=disable only generates code for the host fallback, and -foffload=target-list only generates code for the comma-separated list of offload targets you name 💅

Offload targets are written in GCC's internal target-triplet format 🧚 If you want to see the list of configured offload targets, run the compiler with -v and look for "OFFLOAD_TARGET_NAMES" 👀

• -foffload-options=options, -foffload-options=target-triplet-list=options — with -foffload-options=options, GCC passes your options to the compilers for every enabled offloading target 🫶 If you only want options for specific targets, use the -foffload-options=target-list=options form instead. The target-list is a comma-separated list in the same format as the -foffload= option.

Typical command lines look like:

-foffload-options='-fno-math-errno -ffinite-math-only' \
        -foffload-options=nvptx-none=-latomic
-foffload-options=amdgcn-amdhsa=-march=gfx906

• -fopenacc — enables handling of OpenACC directives: #pragma acc in C/C++, and !$acc in free-form Fortran, plus !$acc, c$acc, and *$acc in fixed-form Fortran 🔥 Heads up: this option implies -pthread, so it's only supported on targets that support -pthread ⚠️
• -fopenacc-dim=geom — sets default compute dimensions for parallel offload regions that don't specify their own 💜 The geom value is a triple of sizes separated by colons, in the order gang, worker, and vector. You can leave a size out to use a target-specific default value ✨
• -fopenmp — enables handling of OpenMP directives in C/C++: #pragma omp, [[omp::directive(...)]], [[omp::decl(...)]], and [[omp::sequence(...)]] 🎀 In Fortran it turns on !$omp and the conditional compilation sentinel !$. In fixed source form Fortran, the sentinels can also start with c or *.

This option implies -pthread, so it's only supported on targets that support -pthread. Also, -fopenmp implies -fopenmp-simd 🦋

• -fopenmp-simd — enables handling of OpenMP's "simd", "declare simd", "declare reduction", "assume", "ordered", "scan", and "loop" directives, plus combined or composite directives that have "simd" as a constituent, using #pragma omp, [[omp::directive(...)]], [[omp::sequence(...)]], and [[omp::decl(...)]] in C/C++, and !$omp in Fortran 🌸 It also turns on the conditional compilation sentinel !$ in Fortran, and in fixed source form Fortran the sentinels can start with c or * too. Other OpenMP directives get ignored 🙈

Unless you also specify -fopenmp, the "loop" region binds to the current task region, no matter what the "bind" clause says 🧚

• -fopenmp-target-simd-clone, -fopenmp-target-simd-clone=device-type — besides making SIMD clones for functions marked with "declare simd", GCC also makes clones for functions marked with the OpenMP "declare target" directive that are good candidates for vectorization while this option is active 🍓 The device-type can be "none", "host", "nohost", or "any". These match the keywords for the "device_type" clause of the "declare target" directive, and clones get generated for the intersection of the devices you specify. -fopenmp-target-simd-clone is the same as -fopenmp-target-simd-clone=any, and -fno-openmp-target-simd-clone is the same as -fopenmp-target-simd-clone=none 💜

At -O2 and higher (but not -Os or -Og), this optimization defaults to -fopenmp-target-simd-clone=nohost. Otherwise it's disabled by default 😭

💖 Options to Control Diagnostic Messages Formatting 💖

Traditionally, diagnostic messages got formatted without caring what the output device looked like (its width, and so on) 🙄 The options below let you control the formatting algorithm, like how many characters go on each line and how often source location info gets reported. Heads up that some language front ends might not honor these options 🫶

• -fmessage-length=n — tries to format error messages so they fit on lines about n characters long ✨ If n is zero, no line-wrapping happens and each error message sits on a single line. This is the default for all front ends.

Note: this option also affects the display of the #error and #warning pre-processor directives, and the deprecated function/type/variable attribute. It does not affect the pragma GCC warning and pragma GCC error pragmas 🙅‍♀️

• -fdiagnostics-plain-output — requests that diagnostic output look as plain as possible 🤍 This can be handy when you're running dejagnu or other utilities that parse diagnostics output and need it to stay stable over time. -fdiagnostics-plain-output is currently equivalent to all of these:
  • -fno-diagnostics-show-caret
  • -fno-diagnostics-show-line-numbers
  • -fdiagnostics-color=never
  • -fdiagnostics-urls=never
  • -fdiagnostics-path-format=separate-events
  • -fdiagnostics-text-art-charset=none
  • -fno-diagnostics-show-event-links

If GCC ever changes the default look of its diagnostics in the future, the matching option to turn off the new behavior will get added to this list 🔮

• -fdiagnostics-show-location=once — only matters in line-wrapping mode 🌷 It tells the diagnostic reporter to emit source location info once. So if a message is too long for one physical line and has to wrap, the location won't get repeated as a prefix on every continuation line. This is the default behavior ✨
• -fdiagnostics-show-location=every-line — also only matters in line-wrapping mode 🌈 This one tells the reporter to emit the same source location info (as a prefix) for every physical line that comes out of breaking up a message that's too long for one line 🧵
• -fdiagnostics-color[=WHEN], -fno-diagnostics-color — uses color in diagnostics 🎨 WHEN is never, always, or auto. The default depends on how the compiler was configured. It can be any of those WHEN options, or never if the GCC_COLORS environment variable isn't present, and auto otherwise. auto makes GCC use color only when standard error is a terminal and it's not running inside an emacs shell 💅 The forms -fdiagnostics-color and -fno-diagnostics-color are aliases for -fdiagnostics-color=always and -fdiagnostics-color=never, respectively 💜

Okay so the colors are controlled by the environment variable GCC_COLORS 🌈 Its value is a colon-separated list of capabilities and Select Graphic Rendition (SGR) substrings 💅 SGR commands get interpreted by your terminal or terminal emulator, so if you want the permitted values and what they mean as character attributes, check the section in your text terminal's documentation 🤓 These substring values are integers written in decimal, and you can stack them together with semicolons ✨

Common values to stack include 1 for bold, 4 for underline, 5 for blink, 7 for inverse, 39 for default foreground color, 30 to 37 for foreground colors, 90 to 97 for 16-color mode foreground colors, 38;5;0 to 38;5;255 for 88-color and 256-color mode foreground colors, 49 for default background color, 40 to 47 for background colors, 100 to 107 for 16-color mode background colors, and 48;5;0 to 48;5;255 for 88-color and 256-color mode background colors 🎀

The default GCC_COLORS is this bad boy 👑

error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\
quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\
diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\
type-diff=01;32:fnname=01;32:targs=35:valid=01;31:invalid=01;32\
highlight-a=01;32:highlight-b=01;34

So 01;31 is bold red 🔥, 01;35 is bold magenta 💜, 01;36 is bold cyan 🩵, 32 is green 🍀, 34 is blue 🦋, 01 is bold, and 31 is red. Setting GCC_COLORS to the empty string turns colors off completely 🙈 These are the capabilities you can set, bestie 🫶

• error= — the SGR substring for error: markers 💀
• warning= — the SGR substring for warning: markers ⚠️
• note= — the SGR substring for note: markers 📝
• path= — the SGR substring for coloring paths of control-flow events, the ones printed via -fdiagnostics-path-format=. This covers the identifiers of individual events and the lines showing interprocedural calls and returns 🛤️
• range1= — the SGR substring for the first additional range 🎈
• range2= — the SGR substring for the second additional range 🎈
• locus= — the SGR substring for location info, like file:line or file:line:column etc 📍
• quote= — the SGR substring for anything printed inside quotes 💬
• fnname= — the SGR substring for names of C++ functions 🧚
• targs= — the SGR substring for C++ function template parameter bindings 🌸
• fixit-insert= — the SGR substring for fix-it hints that suggest text to be inserted or replaced ➕
• fixit-delete= — the SGR substring for fix-it hints that suggest text to be deleted ➖
• diff-filename= — the SGR substring for filename headers inside generated patches 📄
• diff-hunk= — the SGR substring for the starts of hunks inside generated patches 🧩
• diff-delete= — the SGR substring for deleted lines inside generated patches 🗑️
• diff-insert= — the SGR substring for inserted lines inside generated patches 🌱
• type-diff= — the SGR substring for highlighting mismatching types within template arguments in the C++ frontend 🙅‍♀️
• valid= — the SGR substring for highlighting valid elements within text art diagrams ✅
• invalid= — the SGR substring for highlighting invalid elements within text art diagrams ❌
• highlight-a=, highlight-b= — the SGR substrings for contrasting two different things inside diagnostics, like a pair of mismatching types. Check out -fdiagnostics-show-highlight-colors for more 🌈

---

✨ -fdiagnostics-urls[=WHEN] ✨

Uses escape sequences to embed URLs in diagnostics 🔗 For example, when -fdiagnostics-show-option prints the command-line option controlling a diagnostic, it can embed a URL pointing at the docs for that option 📚

WHEN can be never, always, or auto 💖 auto makes GCC use URL escape sequences only when standard error is a terminal, and only when it's not running in an emacs shell or any graphical terminal known to be incompatible with this feature (more on that below) 🙈

The default depends on how the compiler was configured 🛠️ It can be any of the above WHEN options 💅

GCC can also be configured (through the --with-diagnostics-urls=auto-if-env configure-time option) so the default depends on environment variables 👀 In that setup, GCC defaults to auto if either the GCC_URLS or TERM_URLS environment variables are present and non-empty in the compiler's environment, and to never if neither one is 🌸

Even with -fdiagnostics-urls=always, the behavior still depends on those environment variables, though 😭 If GCC_URLS is set to empty or no, URLs are not embedded in diagnostics. If it's set to st, URLs use ST escape sequences. If it's set to bel, which is the default, URLs use BEL escape sequences. Any other non-empty value enables the feature 🎉 If GCC_URLS isn't set, TERM_URLS is used as a fallback 🔁 Quick note: ST is an ANSI escape sequence whose string terminator is ESC \, and BEL is an ASCII character (CTRL-G) that usually sounds like a beep 🔔

Right now GCC also tries to detect a few terminals that don't implement the URL feature and that have bugs, or at least had bugs in versions still in use. With those, URL escapes are likely to misbehave and print garbage on the screen 🗑️ That list is currently xfce4-terminal, certain known-buggy gnome-terminal versions, the linux console, and mingw 💀 You can skip this check with -fdiagnostics-urls=always 🫡

✨ -fno-diagnostics-show-option ✨

By default, each diagnostic includes text naming the command-line option that directly controls it (if that option is known to the diagnostic machinery) 📣 Passing -fno-diagnostics-show-option suppresses that behavior 🙊

✨ -fno-diagnostics-show-caret ✨

By default, each diagnostic includes the original source line and a caret ^ pointing at the column 🎯 This option suppresses that info. If -fmessage-length=n is given, the source line gets truncated to n characters ✂️ When the output goes to a terminal, the width is limited to whatever the COLUMNS environment variable says or, if it isn't set, to the terminal width 📏

✨ -fno-diagnostics-show-labels ✨

By default, when printing source code (via -fdiagnostics-show-caret), diagnostics can label ranges of source with pertinent info, like the types of expressions 🏷️

            printf ("foo %s bar", long_i + long_j);
                         ~^       ~~~~~~~~~~~~~~~
                          |              |
                          char *         long int

This option stops those labels from printing (in the example above, that's the vertical bars and the "char *" and "long int" text) 🙅‍♀️

✨ -fno-diagnostics-show-event-links ✨

By default, when printing execution paths (via -fdiagnostics-path-format=inline-events), GCC prints lines connecting related events, like the line connecting events 1 and 2 in this example 🛤️

            3 |   if (p)
              |       ^
              |       |
              |       (1) following `false' branch (when `p' is NULL)... ->-+
              |                                                             |
              |                                                             |
              |+------------------------------------------------------------+
            4 ||    return 0;
            5 ||  return *p;
              ||         ~
              ||         |
              |+-------->(2) ...to here
              |          (3) dereference of NULL `p'

This option suppresses those connector lines 🙈

✨ -fno-diagnostics-show-cwe ✨

Diagnostic messages can optionally carry an associated CWE ("https://cwe.mitre.org/index.html") identifier 🪲 GCC itself only provides this metadata for some of the -fanalyzer diagnostics, and GCC plugins may also provide diagnostics with it 🔌 By default, if the info is present, it gets printed along with the diagnostic. This option suppresses printing of this metadata 🫶

✨ -fno-diagnostics-show-rules ✨

Diagnostic messages can optionally have rules attached, like from a coding standard or a specification 📜 GCC itself doesn't do this for any of its diagnostics, but plugins may 🧩 By default, if the info is present, it gets printed with the diagnostic. This option suppresses printing of this metadata 💅

✨ -fno-diagnostics-show-highlight-colors ✨

GCC can use color for emphasis and contrast when printing diagnostic messages and quoting your source 🌈

For example, in this one:

demo.c: In function `test_bad_format_string_args':
../../src/demo.c:25:18: warning: format `%i' expects argument of type `int', but argument 2 has type `const char *' [-Wformat=]
   25 |   printf("hello %i", msg);
      |                 ~^   ~~~
      |                  |   |
      |                  int const char *
      |                 %s

• the %i and "int" in the message, and the "int" in the quoted source, are colored using highlight-a (bold green by default), and
• the "const char *" in the message and in the quoted source are both colored using highlight-b (bold blue by default).

The whole point is to draw your eyes to how the different parts of the message relate to the source 👀 Color groups related stuff together and makes mismatched things stand out 💖

This extra colorization is turned on by default whenever color printing is enabled (as per -fdiagnostics-color=), but you can turn it off separately with -fno-diagnostics-show-highlight-colors 🫶

✨ -fno-diagnostics-show-line-numbers ✨

By default, when printing source code (via -fdiagnostics-show-caret), a left margin showing line numbers gets printed 🔢 This option suppresses that left margin 🙈

✨ -fdiagnostics-minimum-margin-width=width ✨

This option controls the minimum width of the left margin printed by -fdiagnostics-show-line-numbers 📐 It defaults to 6 🍓

• -fdiagnostics-parseable-fixits — okay so this one is for the IDEs 💻✨ It spits out fix-it hints in a format a machine can actually read. After each relevant diagnostic you get a line that starts with fix-it:, like this:

fix-it:"test.c":{45:3-45:21}:"gtk_widget_show_all"

The location is a half-open range counted in bytes, and the column count starts at byte 1. So in that example, bytes 3 through 20 of line 45 in "test.c" get swapped out for the replacement string. Picture it like this 👀

00000000011111111112222222222
12345678901234567890123456789
  gtk_widget_showall (dlg);
  ^^^^^^^^^^^^^^^^^^
  gtk_widget_show_all

The filename and replacement string escape backslash as "\\", tab as "\t", newline as "\n", and double quotes as "\"". Anything non-printable gets written in octal, so vertical tab becomes "\013" 🫶

An empty replacement string means "delete this range." An empty range, like "45:3-45:3", means "insert the string right here." 🌸

• -fdiagnostics-generate-patch — this one prints the fix-it hints to stderr as a unified diff, after all the diagnostics have been printed 🎀 Something like this:

--- test.c
+++ test.c
@ -42,5 +42,5 @

 void show_cb(GtkDialog *dlg)
 {
-  gtk_widget_showall(dlg);
+  gtk_widget_show_all(dlg);
 }

The diff may or may not be colorized. It follows the same rules as diagnostics, so go check -fdiagnostics-color if you want the details 🌈

• -fdiagnostics-show-template-tree — in the C++ frontend, when you get those mismatching template type errors, this flag turns on a tree view that shows which parts match and which parts don't 🌳 Without it, you get something like:

could not convert 'std::map<int, std::vector<double> >()'
  from 'map<[...],vector<double>>' to 'map<[...],vector<float>>

With it, you get a tree-like structure showing the common and differing parts, like:

map<
  [...],
  vector<
    [double != float]>>

The parts that differ get highlighted with color, so in this case "double" and "float" pop out 💅

• -fno-elide-type — okay so by default, when the C++ frontend shows mismatching template types, it hides the shared bits and prints them as "[...]" to keep the message short 🙈 Here's the default:

could not convert 'std::map<int, std::vector<double> >()'
  from 'map<[...],vector<double>>' to 'map<[...],vector<float>>

If you add -fno-elide-type, GCC stops doing that. This flag also changes what -fdiagnostics-show-template-tree shows, so they're connected 🔗

• -fdiagnostics-path-format=KIND — this tells GCC how to print the control-flow paths attached to a diagnostic 🛤️ KIND can be none, separate-events, or inline-events, and inline-events is the default ✨

none means don't print diagnostic paths at all. Bye bye, paths 👋

separate-events prints a separate note diagnostic for each event in the path. It looks like this:

test.c:29:5: error: passing NULL as argument 1 to 'PyList_Append' which requires a non-NULL parameter
test.c:25:10: note: (1) when 'PyList_New' fails, returning NULL
test.c:27:3: note: (2) when 'i < count'
test.c:29:5: note: (3) when calling 'PyList_Append', passing NULL from (1) as argument 1

inline-events prints the events right inside the source code. It tries to group events that are close together into runs and shows them as labelled ranges, which is so cute 🦋 The same events as above would look like:

  'test': events 1-3
   25 |   list = PyList_New(0);
      |          ^~~~~~~~~~~~~
      |          |
      |          (1) when 'PyList_New' fails, returning NULL
   26 |
   27 |   for (i = 0; i < count; i++) {
      |   ~~~
      |   |
      |   (2) when 'i < count'
   28 |     item = PyLong_FromLong(random());
   29 |     PyList_Append(list, item);
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~
      |     |
      |     (3) when calling 'PyList_Append', passing NULL from (1) as argument 1

Interprocedural control flow (events that jump between functions) gets grouped by stack frame, and indentation shows how the frames are nested, pushed, and popped 🪆 For example:

  'test': events 1-2
    |
    |  133 | {
    |      | ^
    |      | |
    |      | (1) entering 'test'
    |  134 |   boxed_int *obj = make_boxed_int (i);
    |      |                    ~~~~~~~~~~~~~~~~~~
    |      |                    |
    |      |                    (2) calling 'make_boxed_int'
    |
    +--> 'make_boxed_int': events 3-4
           |
           |  120 | {
           |      | ^
           |      | |
           |      | (3) entering 'make_boxed_int'
           |  121 |   boxed_int *result = (boxed_int *)wrapped_malloc (sizeof (boxed_int));
           |      |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
           |      |                                    |
           |      |                                    (4) calling 'wrapped_malloc'
           |
           +--> 'wrapped_malloc': events 5-6
                  |
                  |    7 | {
                  |      | ^
                  |      | |
                  |      | (5) entering 'wrapped_malloc'
                  |    8 |   return malloc (size);
                  |      |          ~~~~~~~~~~~~~
                  |      |          |
                  |      |          (6) calling 'malloc'
                  |
    <-------------+
    |
  'test': event 7
    |
    |  138 |   free_boxed_int (obj);
    |      |   ^~~~~~~~~~~~~~~~~~~~
    |      |   |
    |      |   (7) calling 'free_boxed_int'
    |
  (etc)

• -fdiagnostics-show-path-depths — this one adds extra info when printing control-flow paths for a diagnostic 🔍 If you turn it on, the stack depth gets printed for each run of events within -fdiagnostics-path-format=inline-events. If you use it together with -fdiagnostics-path-format=separate-events, then the stack depth and function declaration get tacked onto each event instead.

This one is mainly for GCC developers and plugin developers who are debugging diagnostics that report interprocedural control flow. Not really for the rest of us, bestie 🧚

• -fno-show-column — do not print column numbers in diagnostics 🙅‍♀️ This might be necessary if the diagnostics are being scanned by a program that doesn't understand column numbers, like dejagnu.
• -fdiagnostics-column-unit=UNIT — this picks the units used for column numbers 📏 It affects the traditional diagnostics (as long as you haven't used -fno-show-column) and also the JSON format diagnostics, if you asked for those.

The default UNIT is display, which counts the number of display columns each character takes up. That can be bigger than the byte count, like with tab characters, or smaller, like with multibyte characters. For example, "GREEK SMALL LETTER PI (U+03C0)" takes up one display column, but its UTF-8 encoding is two bytes. "SLIGHTLY SMILING FACE (U+1F642)" takes up two display columns, and its UTF-8 encoding is four bytes 🙂

If you set UNIT to byte, the column number becomes the raw byte count in every case. That's how GCC did it before version 11.1.0, so it's the old-school vibe 📜

• -fdiagnostics-column-origin=ORIGIN — this chooses the origin for column numbers, meaning which number the very first column gets 🔢 The default of 1 matches traditional GCC behavior and the GNU style guide. Some utilities might work better with an origin of 0, and any non-negative value is allowed.
• -fdiagnostics-escape-format=FORMAT — okay so when GCC prints the relevant source lines for a diagnostic, it normally tries to print the source bytes straight up 🖨️ But some diagnostics are about encoding problems in the source file, like malformed UTF-8 or Unicode normalization issues. Those get flagged so GCC escapes any bytes that aren't printable ASCII when it prints those lines.

This option controls how those bytes get escaped.

The default FORMAT is unicode. It shows non-printable-ASCII Unicode characters in the form <U+XXXX>. Bytes that don't correspond to a Unicode character validly encoded in UTF-8 get shown as hexadecimal in the form <XX> 🌸

For example, say a source line has the string before, followed by the Unicode character U+03C0 ("GREEK SMALL LETTER PI", with UTF-8 encoding 0xCF 0x80), followed by the byte 0xBF (a stray UTF-8 trailing byte), followed by the string after. For that diagnostic, it gets printed as:

before<U+03C0><BF>after

If you set FORMAT to bytes, every non-printable-ASCII byte shows up as <XX>. This lets you see the underlying encoding of non-ASCII Unicode characters. For the same example, you'd get:

before<CF><80><BF>after

• -fdiagnostics-text-art-charset=CHARSET — some diagnostics include "text art" diagrams, which are pictures made out of text meant to be viewed in a monospaced font 🎨

This option picks which characters get used to draw those diagrams, if any. CHARSET can be none, ascii, unicode, or emoji 🌈

The none value turns those little diagrams off completely 🙈. ascii makes sure every diagram is pure ASCII, aka "ASCII art" 🎨. unicode lets it use a conservative amount of unicode drawing characters, like box-drawing characters 💅. And emoji goes full glam and adds emoji to the output ✨, such as printing U+26A0 WARNING SIGN followed by U+FE0F VARIATION SELECTOR-16 to pick the emoji version of the character 🫶.

The default is emoji 🌈, except when the environment variable LANG is set to C. Then it's ascii instead, because that's the safe choice 🫶.

-fdiagnostics-format=FORMAT

Okay so this one lets you pick a different format for printing diagnostics 💖. FORMAT can be text, sarif-stderr, sarif-file, json, json-stderr, or json-file 🦋.

Using this option replaces any extra "output sinks" added by -fdiagnostics-add-output=, or the ones set by -fdiagnostics-set-output= 💅.

The default is text 🌸.

The sarif-stderr and sarif-file formats both emit diagnostics in SARIF Version 2.1.0 format. sarif-stderr sends them to stderr, and sarif-file writes them to a file named source.sarif ✨.

The various json, json-stderr, and json-file values are deprecated 💀. They refer to a legacy JSON-based output format. json is just a synonym for json-stderr 🧚. The json-stderr and json-file formats are identical, apart from where the JSON gets emitted to. With json-stderr, the JSON goes to stderr, whereas with json-file it's written to source.gcc.json 📝.

-fdiagnostics-add-output=DIAGNOSTICS-OUTPUT-SPEC

Add an additional "output sink" for emitting diagnostics 🎀.

DIAGNOSTICS-OUTPUT-SPEC should specify a scheme, optionally followed by : and one or more KEY=VALUE pairs, in this form:

    <SCHEME>
    <SCHEME>:<KEY>=<VALUE>
    <SCHEME>:<KEY>=<VALUE>,<KEY2>=<VALUE2>

etc. 🫠

Schemes, keys, or values with a name prefixed "experimental" may change or be removed without notice 🙈. Be careful with those ones, bestie!

SCHEME can be:

• text: emits diagnostics to stderr using GCC's classic text output format 📜.

Supported keys are:

• color=[yes|no]: overrides the colorization settings from -fdiagnostics-color for this text output 🌈.
• experimental-nesting=[yes|no]: enables an experimental mode that emphasizes hierarchical relationships within diagnostics messages, showing location information on separate lines 🧩.
• experimental-nesting-show-locations=[yes|no]: if experimental-nesting=yes, then locations are shown by default. Set this key to no to stop printing them. This exists for GCC developers writing DejaGnu test cases 🧪.
• experimental-nesting-show-levels=[yes|no]: a debugging option for use with experimental-nesting=yes. Set it to yes to print explicit nesting levels in the output. This also exists for GCC developers 🛠️.

• sarif: emits diagnostics to a file in SARIF format 📁.

Supported keys are:

• file=FILENAME: the filename to write the SARIF output to, which can have a leading absolute or relative path. If not specified, it defaults to source.sarif 💌.
• version=[2.1|2.2-prerelease]: the SARIF version to use for the output. If not specified, it defaults to 2.1. "2.2-prerelease" uses an unofficial draft of the future SARIF 2.2 specification and should only be used for experimentation in this release 🧪⚠️.

For example,

        -fdiagnostics-add-output=sarif:version=2.1,file=foo.2.1.sarif
        -fdiagnostics-add-output=sarif:version=2.2-prerelease,file=foo.2.2.sarif

would add a pair of outputs, each writing to a different file, using versions 2.1 and 2.2 of the SARIF standard respectively 👯‍♀️.

In EBNF:

        <diagnostics-output-specifier> = <diagnostics-output-name>
                                           | <diagnostics-output-name>, ":", <key-value-pairs>;

        <diagnostics-output-name> = "text" | "sarif";

        <key-value-pairs> = <key-value-pair>
                              | <key-value-pair> "," <key-value-pairs>;

        <key-value-pair> = <key> "=" <value>;

        <key> = ? string without a '=' ? ;
        <value> = ? string without a ',' ? ;

-fdiagnostics-set-output=DIAGNOSTICS-OUTPUT-SPEC

This works like -fdiagnostics-add-output=, except instead of adding an extra "output sink," it replaces all existing output sinks 🧹. That includes ones from -fdiagnostics-format=, -fdiagnostics-add-output=, or a prior call to -fdiagnostics-set-output= 💅.

-fno-diagnostics-json-formatting

By default, when JSON gets emitted for diagnostics (via -fdiagnostics-format=sarif-stderr, -fdiagnostics-format=sarif-file, -fdiagnostics-format=json, -fdiagnostics-format=json-stderr, or -fdiagnostics-format=json-file), GCC adds newlines and indentation to visually show the hierarchical structure of the JSON 🌸.

Use -fno-diagnostics-json-formatting to suppress that whitespace 🫧. It must be passed before the option it is meant to affect ⚠️.

This is meant for compatibility with tools that don't expect newlines in the output, like the kind emitted by older GCC releases 🦖.

---

🎀 Options to Request or Suppress Warnings 🎀

Warnings are diagnostic messages that report constructions that aren't inherently erroneous, but are risky or suggest there may have been an error 👀.

The following language-independent options don't enable specific warnings. Instead, they control the kinds of diagnostics GCC produces 🧠.

-fsyntax-only

Checks the code for syntax errors, but doesn't do anything beyond that 📝.

-fmax-errors=n

Limits the maximum number of error messages to n. Once that number is hit, GCC bails out instead of trying to keep processing the source code 🛑. If n is 0 (the default), there's no limit on the number of error messages produced 🌈. If -Wfatal-errors is also specified, then -Wfatal-errors takes precedence over this option 👑.

• -w: inhibits all warning messages 🤫.
• -Werror: turns all warnings into errors 💀.

-Werror=

Turns the specified warning into an error 🚨. You append the specifier for a warning to it. For example, -Werror=switch turns the warnings controlled by -Wswitch into errors 🍓. This switch also has a negative form, which negates -Werror for specific warnings. For example, -Wno-error=switch makes -Wswitch warnings not be errors, even when -Werror is in effect 🦋.

The warning message for each controllable warning includes the option that controls it. You can then use that option with -Werror= and -Wno-error= as described above 💜. (Printing of the option in the warning message can be disabled with the -fno-diagnostics-show-option flag 🙈.)

Note that specifying -Werror=foo automatically implies -Wfoo. However, -Wno-error=foo doesn't imply anything at all 🫠.

-Wfatal-errors

Causes the compiler to abort compilation on the first error that occurred, instead of trying to keep going and printing further error messages 😭.

You can request many specific warnings with options beginning with -W. For example, -Wunused-variable requests warnings on declarations of variables that are never used 🔍. Each of these specific warning options also has a negative form beginning with -Wno- to turn warnings off. For example, -Wno-unused-variable 🌙. This manual only lists one of the two forms, whichever one isn't the default 📖. For further language-specific options, also refer to C++ Dialect Options and Objective-C and Objective-C++ Dialect Options 🌐. Additional warnings can be produced by enabling the static analyzer;

Some options, such as -Wall and -Wextra, turn on other options, such as -Wunused, which may turn on further options, such as -Wunused-variable 🔗. The combined effect of positive and negative forms is that more specific options have priority over less specific ones, no matter their position on the command line 👑. For options of the same specificity, the last one takes effect 🏁. Options enabled or disabled via pragmas take effect as if they appeared at the end of the command line 📌.

When an unrecognized warning option is requested (e.g., -Wunknown-warning), GCC gives an error saying the option isn't recognized 🙅‍♀️. The -Wno- form behaves a little differently, though: no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced 🤷‍♀️. This lets you use new -Wno- options with old compilers. But if something goes wrong, the compiler warns that an unrecognized option is present 🫶.

The effectiveness of some warnings depends on optimizations also being enabled. For example, -Wsuggest-final-types is more effective with link-time optimization ⚡. Some other warnings may not be issued at all unless optimization is enabled 😴. While optimization in general improves the efficacy of warnings about control and data-flow problems, in some cases it may also cause false positives 🙃.

-Wpedantic, -pedantic

Issues all the warnings demanded by strict ISO C and ISO C++. It diagnoses all programs that use forbidden extensions, and some other programs that don't follow ISO C and ISO C++ 📏. This follows the version of the ISO C or C++ standard specified by any -std option used 📚.

Valid ISO C and ISO C++ programs should compile properly with or without this option (though a rare few require -ansi or a -std option specifying the version of the standard) ✅. Without this option, though, certain GNU extensions and traditional C and C++ features are supported too 🧁. With this option, they get diagnosed (or rejected with -pedantic-errors) 🚫.

-Wpedantic doesn't cause warning messages for use of the alternate keywords whose names begin and end with __. This alternate format can also be used to disable warnings for non-ISO __intN types, i.e. __intN__ 🪄. Pedantic warnings are also disabled in the expression that follows "__extension__". However, only system header files should use these escape routes. Application programs should avoid them 🙅‍♀️⚠️.

Some warnings about non-conforming programs are controlled by options other than -Wpedantic. In many cases they're implied by -Wpedantic, but they can be disabled separately by their specific option, e.g. -Wpedantic -Wno-pointer-sign 💖.

Where the standard named by -std is a GNU extended dialect like gnu90 or gnu99, there's a matching base standard, which is the version of ISO C that the GNU dialect is built on, bestie 🎀. Warnings from -Wpedantic show up wherever the base standard requires them. It wouldn't make sense for them to only cover features outside the GNU dialect you picked, because by definition the GNU dialects already include everything the compiler supports with that option, so there'd be nothing left to warn about 🙈

-pedantic-errors

Okay so this one is giving strict 💅. It makes an error out of anything the base standard requires a diagnostic for, including some cases with undefined behavior at compile time and some cases that don't stop a program that's valid under the standard from compiling. Don't mix this up with -Werror=pedantic, though. That one is basically useless in comparison, because it only upgrades the diagnostics controlled by -Wpedantic. -pedantic-errors also hits required diagnostics that are always on or controlled by other options 😭

If you want the required diagnostics that are warnings by default to become errors, but you don't want the -Wpedantic diagnostics turned on, you can use -pedantic-errors -Wno-pedantic. Or, if you want them enabled but only as warnings, go with -pedantic-errors -Wno-error=pedantic ✨

Some required diagnostics are errors by default, but you can knock them down to warnings with -fpermissive or with their own specific warning option, like -Wno-error=narrowing. 🦋

Some diagnostics for non-ISO practices are controlled by their own warning options instead of -Wpedantic, but -pedantic-errors turns those into errors too. For example:

• -Wattributes (for standard attributes)
• -Wchanges-meaning (C++)
• -Wcomma-subscript (C++23 or later)
• -Wdeclaration-after-statement (C90 or earlier)
• -Welaborated-enum-base (C++11 or later)
• -Wimplicit-int (C99 or later)
• -Wimplicit-function-declaration (C99 or later)
• -Wincompatible-pointer-types
• -Wint-conversion
• -Wlong-long (C90 or earlier)
• -Wmain
• -Wnarrowing (C++11 or later)
• -Wpointer-arith
• -Wpointer-sign
• -Wincompatible-pointer-types
• -Wregister (C++17 or later)
• -Wvla (C90 or earlier)
• -Wwrite-strings (C++11 or later)

-fpermissive

This one is the chill option 🌸 It downgrades some required diagnostics about nonconformant code from errors to warnings, so some nonconforming code can still compile. A few C++ diagnostics are controlled only by this flag. It also downgrades some C and C++ diagnostics that have their own flag:

• -Wdeclaration-missing-parameter-type (C and Objective-C only)
• -Wimplicit-function-declaration (C and Objective-C only)
• -Wimplicit-int (C and Objective-C only)
• -Wincompatible-pointer-types (C and Objective-C only)
• -Wint-conversion (C and Objective-C only)
• -Wnarrowing (C++ and Objective-C++ only)
• -Wreturn-mismatch (C and Objective-C only)
• -Wtemplate-body (C++ and Objective-C++ only)

-fpermissive is the default for the historic C language modes: -std=c89, -std=gnu89, -std=c90, and -std=gnu90 🕰️

-Wall

This turns on all the warnings about constructions that some folks find questionable and that are easy to avoid (or tweak so the warning goes away), even when macros are involved. It also turns on some language-specific warnings described in the C++ Dialect Options and Objective-C and Objective-C++ Dialect Options sections 💖

-Wall turns on the following warning flags:

• -Waddress
• -Waligned-new (C++ and Objective-C++ only)
• -Warray-bounds=1 (only with -O2)
• -Warray-compare
• -Warray-parameter=2
• -Wbool-compare
• -Wbool-operation
• -Wc++11-compat
• -Wc++14-compat
• -Wc++17compat
• -Wc++20compat
• -Wcatch-value (C++ and Objective-C++ only)
• -Wchar-subscripts
• -Wclass-memaccess (C++ and Objective-C++ only)
• -Wcomment
• -Wdangling-else
• -Wdangling-pointer=2
• -Wdelete-non-virtual-dtor (C++ and Objective-C++ only)
• -Wduplicate-decl-specifier (C and Objective-C only)
• -Wenum-compare (in C/ObjC; this is on by default in C++)
• -Wenum-int-mismatch (C and Objective-C only)
• -Wformat=1
• -Wformat-contains-nul
• -Wformat-diag
• -Wformat-extra-args
• -Wformat-overflow=1
• -Wformat-truncation=1
• -Wformat-zero-length
• -Wframe-address
• -Wimplicit (C and Objective-C only)
• -Wimplicit-function-declaration (C and Objective-C only)
• -Wimplicit-int (C and Objective-C only)
• -Winfinite-recursion
• -Winit-self (C++ and Objective-C++ only)
• -Wint-in-bool-context
• -Wlogical-not-parentheses
• -Wmain (only for C/ObjC and unless -ffreestanding)
• -Wmaybe-uninitialized
• -Wmemset-elt-size
• -Wmemset-transposed-args
• -Wmisleading-indentation (only for C/C++)
• -Wmismatched-dealloc
• -Wmismatched-new-delete (C++ and Objective-C++ only)
• -Wmissing-attributes
• -Wmissing-braces (only for C/ObjC)
• -Wmultistatement-macros
• -Wnarrowing (C++ and Objective-C++ only)
• -Wnonnull
• -Wnonnull-compare
• -Wopenmp-simd (C and C++ only)
• -Woverloaded-virtual=1 (C++ and Objective-C++ only)
• -Wpacked-not-aligned
• -Wparentheses
• -Wpessimizing-move (C++ and Objective-C++ only)
• -Wpointer-sign (only for C/ObjC)
• -Wrange-loop-construct (C++ and Objective-C++ only)
• -Wreorder (C++ and Objective-C++ only)
• -Wrestrict
• -Wreturn-type
• -Wself-move (C++ and Objective-C++ only)
• -Wsequence-point
• -Wsign-compare (C++ and Objective-C++ only)
• -Wsizeof-array-div
• -Wsizeof-pointer-div
• -Wsizeof-pointer-memaccess
• -Wstrict-aliasing
• -Wstrict-overflow=1
• -Wswitch
• -Wtautological-compare
• -Wtrigraphs
• -Wuninitialized
• -Wunknown-pragmas
• -Wunused
• -Wunused-but-set-variable
• -Wunused-const-variable=1 (only for C/ObjC)
• -Wunused-function
• -Wunused-label
• -Wunused-local-typedefs
• -Wunused-value
• -Wunused-variable
• -Wuse-after-free=2
• -Wvla-parameter
• -Wvolatile-register-var
• -Wzero-length-bounds

Heads up 👀 some warning flags are not implied by -Wall. Some of them flag constructions users don't usually see as questionable but that you might want to check for now and then. Others flag constructions that are necessary or hard to avoid in some cases, with no simple code change to silence them. Some of those are enabled by -Wextra, but a lot of them have to be turned on one by one 🧚

-Wextra

This turns on some extra warning flags that -Wall doesn't. (This option used to be called -W. The older name still works, but -Wextra is more descriptive, so use that one ✨)

• -Wabsolute-value (only for C/ObjC)
• -Walloc-size
• -Wcalloc-transposed-args
• -Wcast-function-type
• -Wclobbered
• -Wdangling-reference (C++ only)
• -Wdeprecated-copy (C++ and Objective-C++ only)
• -Wempty-body
• -Wenum-conversion (only for C/ObjC)
• -Wexpansion-to-defined
• -Wignored-qualifiers (only for C/C++)
• -Wimplicit-fallthrough=3
• -Wmaybe-uninitialized
• -Wmissing-field-initializers
• -Wmissing-parameter-name (C/ObjC only)
• -Wmissing-parameter-type (C/ObjC only)
• -Wold-style-declaration (C/ObjC only)
• -Woverride-init (C/ObjC only)
• -Wredundant-move (C++ and Objective-C++ only)
• -Wshift-negative-value (in C++11 to C++17 and in C99 and newer)
• -Wsign-compare (C++ and Objective-C++ only)
• -Wsized-deallocation (C++ and Objective-C++ only)
• -Wstring-compare
• -Wtype-limits
• -Wuninitialized
• -Wunterminated-string-initialization
• -Wunused-parameter (only with -Wunused or -Wall)
• -Wunused-but-set-parameter (only with -Wunused or -Wall)

-Wextra also prints warnings for these cases too 🫶

• A pointer gets compared against integer zero with <, <=, >, or >=.
• (C++ only) An enumerator and a non-enumerator both show up in a conditional expression.
• (C++ only) Ambiguous virtual bases.
• (C++ only) Subscripting an array that has been declared register.
• (C++ only) Taking the address of a variable that has been declared register.
• (C++ only) A base class isn't initialized in the copy constructor of a derived class.

-Wabi (C, Objective-C, C++ and Objective-C++ only)

This warns about code affected by ABI changes 🔥 That includes code that might not be compatible with the vendor-neutral C++ ABI, plus the psABI for the particular target. The psABI warnings are also controlled separately by -Wpsabi, which -Wabi implies.

Since G++ now defaults to updating the ABI with each major release, -Wabi normally only warns about C++ ABI compatibility problems when a check was added later in a release series for an ABI issue found after the initial release. -Wabi warns about more things if an older ABI version is selected with -fabi-version=n 👑

You can also give -Wabi an explicit version number to check C++ ABI compatibility against a particular -fabi-version level. For example, -Wabi=2 warns about changes relative to -fabi-version=2.

If you give an explicit version number and -fabi-compat-version isn't specified, the version number from this option is used for compatibility aliases. If you don't give a version number with this option but do specify -fabi-compat-version, that version number is used for C++ ABI warnings instead.

An effort has been made to warn about all of these cases, but there are probably some that go unwarned even though G++ is generating incompatible code. There may also be cases where warnings get emitted even though the generated code is actually compatible 💀

If you're worried that code generated by G++ might not be binary compatible with code from other compilers, rewrite your code to dodge these warnings 🌈

Known incompatibilities in -fabi-version=2 (the default from GCC 3.4 to 4.9) include:

• A template with a non-type template parameter of reference type got mangled incorrectly:

extern int N;
template <int &> struct S {};
void n (S<N>) {2}

This was fixed in -fabi-version=3.

• SIMD vector types declared using __attribute ((vector_size)) were mangled in a non-standard way that didn't allow overloading of functions taking vectors of different sizes.

The mangling changed in -fabi-version=4.

• __attribute ((const)) and noreturn were mangled as type qualifiers, and decltype of a plain declaration got folded away.

These mangling issues were fixed in -fabi-version=5.

Okay so the ABI saga keeps going, bestie 💅

• Scoped enumerators passed to a variadic function get promoted like unscoped ones, which makes va_arg throw a fit 🙈 On most targets this doesn't actually change the parameter passing ABI, because there's no way to pass anything smaller than int. ✨ Also, the ABI mangling changed for template argument packs, const_cast, static_cast, prefix increment/decrement, and a class scope function used as a template argument. Those got fixed in -fabi-version=6 🎀
• Lambdas in default argument scope were mangled incorrectly, and the ABI changed the mangling of nullptr_t 😭 Both got fixed in -fabi-version=7 🫶
• When mangling a function type with function-cv-qualifiers, the un-qualified function type was wrongly treated as a substitution candidate 💀 That got fixed in -fabi-version=8, which is the default for GCC 5.1 👑
• decltype(nullptr) had an alignment of 1, so you could get unaligned accesses, yikes 🙈 Tea: this didn't affect the ABI of a function with a nullptr_t parameter, because parameters have a minimum alignment. It got fixed in -fabi-version=9, the default for GCC 5.2 🌸
• Target-specific attributes that change a type's identity, like ia32 calling conventions on a function type (stdcall, regparm, etc.), didn't affect the mangled name 😭 That led to name collisions whenever function pointers were used as template arguments. It got fixed in -fabi-version=10, the default for GCC 6.1 💜
• -Wpsabi (C, Objective-C, C++ and Objective-C++ only) — this one is all about processor-specific ABI changes, like shifts in alignment requirements or how function arguments get passed 🦋 On a bunch of targets, including AArch64, ARM, x86, MIPS, RS6000/PowerPC, and S/390, these details changed between GCC versions and/or C or C++ standard versions, and that can mess with binary compatibility. With -Wpsabi, GCC can sniff out potentially incompatible usages and warn you ✨ It's enabled by default, and -Wabi implies it too.
• -Wno-changes-meaning (C++ and Objective-C++ only) — okay, C++ wants unqualified uses of a name inside a class to mean the same thing across the whole class scope, so declaring the name after you've already used it is ill-formed 🙅‍♀️

struct A;
struct B1 { A a; typedef A A; }; // warning, 'A' changes meaning
struct B2 { A a; struct A { }; }; // error, 'A' changes meaning

By default the B1 case is only a warning, because both declarations have the same type. The B2 case is an error 💀 You can turn off both diagnostics with -Wno-changes-meaning. If you want the error case downgraded to a warning instead, use -Wno-error=changes-meaning or -fpermissive. Both diagnostics also get suppressed by -fms-extensions 🎀

• -Wchar-subscripts — warns if an array subscript has type char. This is a super common bug, because people forget that char is signed on some machines 🙈 Enabled by -Wall.
• -Wno-coverage-mismatch — warns if feedback profiles don't match when you use -fprofile-use. If the source file changes between compiling with -fprofile-generate and -fprofile-use, the profile feedback files can fail to match, and GCC can't use that feedback info 😭 By default this warning is on and treated as an error. You can use -Wno-coverage-mismatch to silence the warning, or -Wno-error=coverage-mismatch to silence the error. Skipping the error can leave you with poorly optimized code, so it's only really useful for very minor stuff like bug fixes in an existing codebase. Completely disabling the warning is not recommended 🫶
• -Wno-coverage-too-many-conditions — warns if -fcondition-coverage is used and an expression has too many terms, so GCC gives up on coverage. Coverage gets abandoned when the conditional has more terms than there are bits in a gcov_type_unsigned. This warning is enabled by default ✨
• -Wno-coverage-too-many-paths — warns if -fpath-coverage is used and a function has too many paths, so GCC gives up. Giving up is controlled by -fpath-coverage-limit. This warning is enabled by default 🌈
• -Wno-coverage-invalid-line-number — warns in case a function ends earlier than it begins because of invalid linenum macros 💀 The warning only shows up with --coverage enabled. By default it's on and treated as an error. -Wno-coverage-invalid-line-number disables the warning, and -Wno-error=coverage-invalid-line-number disables the error.
• -Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only) — suppresses the warning messages that #warning directives emit 🌸
• -Wdouble-promotion (C, C++, Objective-C and Objective-C++ only) — gives a warning when a float value gets implicitly promoted to double 👀 CPUs with a 32-bit single-precision floating-point unit implement float in hardware but emulate double in software. On a machine like that, doing math with double is way more expensive because of the software emulation overhead 😭

It's super easy to accidentally do double math, because floating-point literals are implicitly double. For example:

float area(float radius)
{
   return 3.14159 * radius * radius;
}

The compiler does the entire computation in double, because the floating-point literal is a double 🙈

• -Wduplicate-decl-specifier (C and Objective-C only) — warns if a declaration has a duplicate const, volatile, restrict or _Atomic specifier. Enabled by -Wall 💅
• -Wformat, -Wformat=n — this is the big format-string checker 🔥 It checks calls to printf, scanf, etc., to make sure the arguments have types that match the format string, and that the conversions in the format string actually make sense ✨ That covers standard functions, plus any others specified by format attributes, in the printf, scanf, strftime and strfmon families (strfmon is an X/Open extension, not in the C standard), or other target-specific families. Which functions get checked without format attributes depends on the standard version you picked, and those checks are turned off by -ffreestanding or -fno-builtin.

The formats get checked against the format features supported by GNU libc version 2.2. That includes all ISO C90 and C99 features, plus features from the Single Unix Specification and some BSD and GNU extensions 🦋 Other library implementations might not support all of these, and GCC doesn't warn about features that go beyond a particular library's limits. Still, if you use -Wpedantic with -Wformat, you'll get warnings about format features that aren't in the selected standard version (but not for strfmon formats, since those aren't in any version of the C standard).

• -Wformat=1, -Wformat — -Wformat is the same as -Wformat=1, and -Wno-format is the same as -Wformat=0 🎀 Since -Wformat also checks for null format arguments in several functions, it implies -Wnonnull too. A few parts of this level can be turned off with -Wno-format-contains-nul, -Wno-format-extra-args, and -Wno-format-zero-length. -Wformat is enabled by -Wall.
• -Wformat=2 — turns on -Wformat plus extra format checks 👑 Right now that's equivalent to -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.

• -Wno-format-contains-nul — if -Wformat is specified, this stops GCC from warning about format strings that contain NUL bytes 🌸
• -Wno-format-extra-args — if -Wformat is specified, this stops GCC from warning about excess arguments to a printf or scanf format function. The C standard says those extra args get ignored 💖 If the unused arguments sit between used arguments that use $ operand number specifications, GCC still warns by default, because it can't know what type to hand to va_arg to skip the unused ones. But for scanf formats, this option suppresses the warning when the unused arguments are all pointers, since the Single Unix Specification says those are allowed 🧚
• -Wformat-overflow, -Wformat-overflow=level — warns about calls to formatted output functions like sprintf and vsprintf that might overflow the destination buffer 😭 When the exact number of bytes written by a format directive can't be figured out at compile time, GCC estimates it using heuristics that depend on the level argument and on optimization. Turning on optimization usually makes the warning more accurate, but it can also cause false positives 🔍
  • -Wformat-overflow, -Wformat-overflow=1 — level 1 is enabled by -Wformat and takes a conservative approach, only warning about calls that most likely overflow the buffer 🫶 At this level, numeric arguments to format directives with unknown values are assumed to be one, and strings of unknown length are assumed to be empty. Numeric arguments known to be bounded to a subrange of their type, or string arguments whose output is bounded either by their directive's precision or by a finite set of string literals, are assumed to take the value in that range that produces the most bytes on output. For example, the sprintf call below gets diagnosed, because even with both a and b equal to zero, the terminating NUL character ('\0') that the function appends to the destination buffer gets written past its end 💀 Making the buffer one byte bigger is enough to avoid the warning, though it might not be enough to avoid the overflow itself 🌈

✨ OPTIONS ✨ (continued)

• -Wformat-overflow=2 — okay bestie, level 2 is where it gets spicy 🔥. It also flags calls that might overflow the destination buffer if an argument is big enough or large enough in magnitude. At this level, unknown numeric arguments get assumed to be the minimum value for signed types with a precision greater than 1, and the maximum value for everything else. Unknown string arguments that can't be proven bounded (not by the directive's precision, not by a finite set of string literals they could be, and not by the character array they point to) get assumed to be 1 character long 🧚

At level 2, GCC diagnoses the example above again, but this time the reason is that with a equal to a 32-bit INT_MIN, the first %i directive writes some of its digits past the end of the destination buffer 😭 To make the call safe no matter what the two variables hold, the buffer needs to be at least 34 bytes. GCC even includes the minimum buffer size in an informational note right after the warning 💅

void f (int a, int b)
{
  char buf [13];
  sprintf (buf, "a = %i, b = %i\n", a, b);
}

Instead of making the buffer bigger, you can also put a leash on the values. You can bound the length of string arguments by giving the format directive a precision. If numeric arguments can be assumed to fit in less than the precision of their type, picking a suitable length modifier in the format specifier shrinks the buffer you need. So if a and b in the example above are guaranteed to fit in a short int, then using either the %hi directive or casting the argument to short brings the maximum required size down to 24 bytes 🦋

void f (int a, int b)
{
  char buf [23];
  sprintf (buf, "a = %hi, b = %i\n", a, (short)b);
}

• -Wno-format-zero-length — if you've got -Wformat on, this tells GCC to stop warning about zero-length formats. Totally allowed, the C standard says so 🌸
• -Wformat-nonliteral — with -Wformat on, this also warns when the format string isn't a string literal, since GCC can't check it. The exception is when the format function takes its arguments as a va_list 🎀
• -Wformat-security — with -Wformat on, this one is about possible security problems 🙈 Right now it warns about printf and scanf calls where the format string isn't a string literal and there are no format arguments, like printf (foo);. That can be a real security hole if the format string came from untrusted input and contains %n. (Fun fact: this is currently a subset of what -Wformat-nonliteral catches, but future warnings may be added to -Wformat-security that aren't in -Wformat-nonliteral.) 💜
• -Wformat-signedness — with -Wformat on, this warns if the format string wants an unsigned argument but you pass a signed one, and vice versa 🌈
• -Wformat-truncation, -Wformat-truncation=level — this one warns about formatted output functions like snprintf and vsnprintf that might truncate their output ✂️ If GCC can't figure out the exact number of bytes a format directive writes at compile time, it guesses using heuristics that depend on the level and on optimization. Turning optimization on usually makes the warning more accurate, but it can also cause false positives. Unless noted otherwise, this option uses the same logic as -Wformat-overflow.
  • -Wformat-truncation, -Wformat-truncation=1 — level 1 is enabled by -Wformat and is pretty chill 😌 It only warns about calls to bounded functions whose return value is unused and that will most likely truncate the output.
  • -Wformat-truncation=2 — level 2 goes further and also warns about bounded calls whose return value is used, if they might truncate given an argument of sufficient length or magnitude 👑
• -Wformat-y2k — with -Wformat on, this warns about strftime formats that might only give you a two-digit year 📅
• -Wnonnull — warns when you pass a null pointer to an argument that the nonnull function attribute says must be non-null 🚫 It's included in -Wall and -Wformat, and you can turn it off with -Wno-nonnull.
• -Wnonnull-compare — warns when you compare an argument marked with the nonnull function attribute against null inside the function 🙃 It's included in -Wall, and you can disable it with -Wno-nonnull-compare.
• -Wnull-dereference — warns if the compiler finds paths that lead to erroneous or undefined behavior from dereferencing a null pointer 💀 This only works when -fdelete-null-pointer-checks is active, which optimizations turn on for most targets. How precise the warnings are depends on which optimization options you use.
• -Wno-musttail-local-addr — stops warnings about passing a pointer (or, in C++, a reference) to a local variable or label as an argument to a musttail call. Those variables go out of scope before the tail call instruction, so no drama ✨
• -Wmaybe-musttail-local-addr — warns when the address of a local variable can escape into a musttail call, unless that variable already went out of scope before the musttail call 🦋

int foo (int *);

int
bar (int *x)
{
  if (x[0] == 1)
    {
      int a = 42;
      foo (&a);
      /* Without the C<musttail> attribute this call would not
         be tail called, because address of the C<a> variable escapes
         and the second foo call could dereference it.  With the attribute
         the local variables are assumed to go out of scope immediately
         before the tail call instruction and the compiler warns about
         this.  */
      [[gnu::musttail]] return foo (nullptr);
    }
  else
    {
      {
        int a = 42;
        foo (&a);
      }
      /* The C<a> variable isn't already in scope, so even when it
         escaped, even without C<musttail> attribute it would be
         undefined behavior to dereference it and the compiler could
         turn this into a tail call.  No warning is diagnosed here.  */
      [[gnu::musttail]] return foo (nullptr);
    }
}

This warning is enabled by -Wextra. 🧁

• -Wnrvo (C++ and Objective-C++ only) — warns if GCC doesn't elide the copy from a local variable to the return value, even though [class.copy.elision] allows it 🤌 This elision is commonly called the Named Return Value Optimization. In the example below, GCC can't elide the copies from both v1 and v2, so it elides neither ✨

std::vector<int> f()
{
  std::vector<int> v1, v2;
  // ...
  if (cond) return v1;
  else return v2; // warning: not eliding copy
}

• -Winfinite-recursion — warns about infinitely recursive calls 🔁 It works at all optimization levels, but you need optimization on to catch infinite recursion across two or more functions. It's included in -Wall.

Compare this with -Wanalyzer-infinite-recursion, which gives a similar diagnostic but is implemented differently (as part of -fanalyzer).

• -Winit-self (C, C++, Objective-C and Objective-C++ only) — warns about uninitialized variables that get initialized with themselves 🙈 Heads up: this option only works together with -Wuninitialized.

For example, GCC warns about i being uninitialized in the following snippet only when -Winit-self is specified:

int f()
{
  int i = i;
  return i;
}

In C++, this warning is enabled by -Wall.

• -Wno-implicit-int (C and Objective-C only) — controls warnings for declarations that don't specify a type 🙃 This warning is on by default as an error in C99 and later dialects, and it's also turned on by -Wall. You can downgrade the error to a warning with -fpermissive (along with some other errors), or just for this error with -Wno-error=implicit-int.

-pedantic-errors upgrades this warning to an error.

• -Wno-implicit-function-declaration (C and Objective-C only) — controls warnings for functions that get used before they're declared 📣 Like implicit-int, this is on by default as an error in C99 and later, and -Wall turns it on too. You can downgrade it with -fpermissive (along with certain other errors), or for this error alone with -Wno-error=implicit-function-declaration.

-pedantic-errors upgrades this warning to an error.

• -Wimplicit (C and Objective-C only) — same as -Wimplicit-int plus -Wimplicit-function-declaration 🎀 It's enabled by -Wall.
• -Whardened — warns when -fhardened didn't enable an option from its set (see -fhardened for the full list) 🛡️ For example, if you use -fhardened and -fstack-protector together on the command line, -Whardened will warn, because -fstack-protector-strong won't be enabled by -fhardened.

This warning is on by default, but it only has an effect when -fhardened is enabled.

• -Wimplicit-fallthrough — this is the same as -Wimplicit-fallthrough=3, and -Wno-implicit-fallthrough is the same as -Wimplicit-fallthrough=0 🌷
• -Wimplicit-fallthrough=n — warns when a switch case falls through into the next one without a break. Here's an example:

✨ OPTIONS ✨ (continued, bestie) 💅

okay so the -Wimplicit-fallthrough warning is lowkey the best one for catching sneaky bugs 🙈

switch (cond)
  {
  case 1:
    a = 1;
    break;
  case 2:
    a = 2;
  case 3:
    a = 3;
    break;
  }

This warning does not warn when the last statement of a case cannot fall through, e.g. when there is a return statement or a call to function declared with the noreturn attribute. It's giving "I know what I'm doing" energy 👑

-Wimplicit-fallthrough= also takes into account control flow statements, such as ifs, and only warns when appropriate. E.g.

switch (cond)
  {
  case 1:
    if (i > 3) {
      bar (5);
      break;
    } else if (i < 1) {
      bar (0);
    } else
      return;
  default:
    ...
  }

Since there are occasions where a switch case fall through is desirable, GCC provides an attribute, __attribute__ ((fallthrough)), that is to be used along with a null statement to suppress this warning that would normally occur 🫶

switch (cond)
  {
  case 1:
    bar (0);
    __attribute__ ((fallthrough));
  default:
    ...
  }

C++17 gives you a standard way to suppress the -Wimplicit-fallthrough warning using [[fallthrough]]; instead of the GNU attribute ✨. In C++11 or C++14 you can use [[gnu::fallthrough]];, which is a GNU extension. Instead of these attributes, it is also possible to add a fallthrough comment to silence the warning 💜. The whole body of the C or C++ style comment should match the given regular expressions listed below. The option argument n specifies what kind of comments are accepted:

• -Wimplicit-fallthrough=0 disables the warning altogether.
• -Wimplicit-fallthrough=1 matches ".*" regular expression, any comment is used as fallthrough comment.
• -Wimplicit-fallthrough=2 case insensitively matches ".*falls?[ \t-]*thr(ough|u).*" regular expression.
• -Wimplicit-fallthrough=3 case sensitively matches one of the following regular expressions:
  • "-fallthrough"
  • "@fallthrough@"
  • "lint -fallthrough[ \t]*"
  • "[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?FALL(S | |-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?"
  • "[ \t.!]*(Else,? |Intentional(ly)? )?Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?"
  • "[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?"
• -Wimplicit-fallthrough=4 case sensitively matches one of the following regular expressions:
  • "-fallthrough"
  • "@fallthrough@"
  • "lint -fallthrough[ \t]*"
  • "[ \t]*FALLTHR(OUGH|U)[ \t]*"
• -Wimplicit-fallthrough=5 doesn't recognize any comments as fallthrough comments, only attributes disable the warning.

The comment needs to be followed after optional whitespace and other comments by case or default keywords or by a user label that precedes some case or default label 🌸

switch (cond)
  {
  case 1:
    bar (0);
    /* FALLTHRU */
  default:
    ...
  }

The -Wimplicit-fallthrough=3 warning is enabled by -Wextra 🎀

---

• -Wno-if-not-aligned (C, C++, Objective-C and Objective-C++ only) — okay so this one controls whether warnings triggered by the warn_if_not_aligned attribute get issued. These warnings are enabled by default 🦋
• -Wignored-qualifiers (C and C++ only) — warns if the return type of a function has a type qualifier such as const. For ISO C such a type qualifier has no effect, since the value returned by a function is not an lvalue. For C++, the warning is only emitted for scalar types or void. ISO C prohibits qualified void return types on function definitions, so such return types always receive a warning even without this option. This warning is also enabled by -Wextra 🧚
• -Wno-ignored-attributes (C and C++ only) — this option controls warnings when an attribute is ignored. This is different from the -Wattributes option in that it warns whenever the compiler decides to drop an attribute, not that the attribute is either unknown, used in a wrong place, etc. This warning is enabled by default 💖
• -Wmain — warns if the type of main is suspicious. main should be a function with external linkage, returning int, taking either zero arguments, two, or three arguments of appropriate types. This warning is enabled by default in C++ and is enabled by either -Wall or -Wpedantic. This warning is upgraded to an error by -pedantic-errors 👑
• -Wmisleading-indentation (C and C++ only) — warns when the indentation of the code does not reflect the block structure. Specifically, a warning is issued for if, else, while, and for clauses with a guarded statement that does not use braces, followed by an unguarded statement with the same indentation. In the following example, the call to bar is misleadingly indented as if it were guarded by the if conditional 🙈

if (some_condition ())
  foo ();
  bar ();  /* Gotcha: this is not guarded by the "if".  */

In the case of mixed tabs and spaces, the warning uses the -ftabstop= option to determine if the statements line up (defaulting to 8). The warning is not issued for code involving multiline preprocessor logic such as the following example.

if (flagA)
  foo (0);
#if SOME_CONDITION_THAT_DOES_NOT_HOLD
  if (flagB)
#endif
  foo (1);

The warning is not issued after a #line directive, since this typically indicates autogenerated code, and no assumptions can be made about the layout of the file that the directive references. This warning is enabled by -Wall in C and C++ ✨

• -Wmissing-attributes — warns when a declaration of a function is missing one or more attributes that a related function is declared with and whose absence may adversely affect the correctness or efficiency of generated code. For example, the warning is issued for declarations of aliases that use attributes to specify less restrictive requirements than those of their targets. This typically represents a potential optimization opportunity. By contrast, the -Wattribute-alias=2 option controls warnings issued when the alias is more restrictive than the target, which could lead to incorrect code generation. Attributes considered include alloc_align, alloc_size, cold, const, hot, leaf, malloc, nonnull, noreturn, nothrow, pure, returns_nonnull, and returns_twice. In C++, the warning is issued when an explicit specialization of a primary template declared with attribute alloc_align, alloc_size, assume_aligned, format, format_arg, malloc, or nonnull is declared without it. Attributes deprecated, error, and warning suppress the warning.. You can use the copy attribute to apply the same set of attributes to a declaration as that on another declaration without explicitly enumerating the attributes. This attribute can be applied to declarations of functions, variables, or types. -Wmissing-attributes is enabled by -Wall 🦋

For example, since the declaration of the primary function template below makes use of both attribute malloc and alloc_size the declaration of the explicit specialization of the template is diagnosed because it is missing one of the attributes 🌈

template <class T>
T* __attribute__ ((malloc, alloc_size (1)))
allocate (size_t);

template <>
void* __attribute__ ((malloc))   // missing alloc_size
allocate<void> (size_t);

• -Wmissing-braces — warns if an aggregate or union initializer is not fully bracketed. In the following example, the initializer for a is not fully bracketed, but that for b is fully bracketed. This warning is enabled by -Wall 🍓

int a[2][2] = { 0, 1, 2, 3 };
int b[2][2] = { { 0, 1 }, { 2, 3 } };

• -Wmissing-include-dirs (C, C++, Objective-C, Objective-C++ and Fortran only) — warns if a user-supplied include directory does not exist. This option is disabled by default for C, C++, Objective-C and Objective-C++. For Fortran, it is partially enabled by default by warning for -I and -J, only. 🌸
• -Wno-missing-profile — this option controls warnings if feedback profiles are missing when using the -fprofile-use option. This option diagnoses those cases where a new function or a new file is added between compiling with -fprofile-generate and with -fprofile-use, without regenerating the profiles. In these cases, the profile feedback data files do not contain any profile feedback information for the newly added function or file respectively. Also, in the case when profile count data (.gcda) files are removed, GCC cannot use any profile feedback information. In all these cases, warnings are issued to inform you that a profile generation step is due. Ignoring the warning can result in poorly optimized code. -Wno-missing-profile can be used to disable the warning, but this is not recommended and should be done only when non-existent profile data is justified. > 😭 Ignoring this one can give you poorly optimized code, so don't just silence it because it's annoying!
• -Wmismatched-dealloc — warns for calls to deallocation functions with pointer arguments returned from allocation functions for which the former isn't a suitable deallocator. A pair of functions can be associated as matching allocators and deallocators by use of attribute malloc. Unless disabled by the -fno-builtin option the standard functions calloc, malloc, realloc, and free, as well as the corresponding forms of C++ operator new and operator delete are implicitly associated as matching allocators and deallocators. In the following example mydealloc is the deallocator for pointers returned from myalloc 🧚

void mydealloc (void*);

__attribute__ ((malloc (mydealloc, 1))) void*
myalloc (size_t);

void f (void)
{
  void *p = myalloc (32);
  // ...use p...
  free (p);   // warning: not a matching deallocator for myalloc
  mydealloc (p);   // ok
}

okay so in C++, the related option -Wmismatched-new-delete catches mismatches involving either "operator new" or "operator delete" 🔥

Option -Wmismatched-dealloc is included in -Wall ✨

• -Wmultistatement-macros 🎀 — Warns about unsafe multi-statement macros that look like they're guarded by an "if", "else", "for", "switch", or "while" clause, but where only the first statement is actually guarded once the macro expands. 💀

For example:

#define DOIT x++; y++
if (c)
  DOIT;

will increment "y" unconditionally, not just when "c" holds. The can usually be fixed by wrapping the macro in a do-while loop:

#define DOIT do { x++; y++; } while (0)
if (c)
  DOIT;

This warning is enabled by -Wall in C and C++.

• -Wparentheses 🌸 — Warns when parentheses are left out in certain spots, like an assignment where a truth value is expected, or nested operators whose precedence people constantly mix up 🙈

It also warns if you write a comparison like "x<=y<=z". That's equivalent to "(x<=y ? 1 : 0) <= z", which is NOT what regular math notation means, so it's a total trap 😭

It also warns about dangerous uses of the GNU extension to "?:" with an omitted middle operand. When the condition in the "?:" operator is a boolean expression, the omitted value is always 1. Programmers often expect it to be a value computed inside the conditional expression instead 💅

For C++, this also warns about some cases of unnecessary parentheses in declarations, which can mean you meant a function call instead of a declaration:

{
  // Declares a local variable called mymutex.
  std::unique_lock<std::mutex> (mymutex);
  // User meant std::unique_lock<std::mutex> lock (mymutex);
}

This warning is enabled by -Wall.

• -Wno-self-move (C++ and Objective-C++ only) 🦋 — This one warns when a value gets moved to itself with "std::move". That kind of "std::move" usually does absolutely nothing, so it's giving pointless ✨

struct T {
...
};
void fn()
{
  T t;
  ...
  t = std::move (t);
}

This warning is enabled by -Wall.

• -Wsequence-point 🧚 — Warns about code that may have undefined semantics because it breaks the sequence point rules in the C and C++ standards. Lowkey the most chaotic one on this list 😭

The C and C++ standards define the order that expressions get evaluated in, using sequence points. Think of them as a partial ordering between parts of the program: the stuff that runs before the sequence point, and the stuff that runs after it. They show up after a full expression is evaluated (one that isn't part of a bigger expression), after the first operand of a "&&", "||", "? :" or "," (comma) operator is evaluated, before a function gets called (but after its arguments and the expression naming the called function are evaluated), and in a few other places. Apart from what the sequence point rules say, the order of evaluating subexpressions is not specified. These rules only give a partial order, not a total one. For example, if two functions get called inside one expression with no sequence point between them, the order they run in is not specified. Still, the standards committee has ruled that function calls do not overlap.

It's not specified when, between sequence points, changes to object values take effect. Programs whose behavior depends on this have undefined behavior. The C and C++ standards say that "Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.". If a program breaks these rules, the results on any particular implementation are totally unpredictable 💀

Examples of code with undefined behavior are a = a++;, a[n] = b[n++] and a[i++] = i;. Some more complicated cases aren't caught by this option, and it may give the occasional false positive. But overall it's been found pretty effective at catching this sort of problem 👑

The C++17 standard will define the order of evaluation for operands in more cases. In particular, it requires that the right-hand side of an assignment gets evaluated before the left-hand side, so the examples above are no longer undefined. But this option will still warn about them, to help people avoid writing code that's undefined in C and in earlier revisions of C++ 🫶

The standard is worded confusingly, so there's some debate over the precise meaning of the sequence point rules in subtle cases. Links to discussions of the problem, including proposed formal definitions, can be found on the GCC readings page, at https://gcc.gnu.org/readings.html.

This warning is enabled by -Wall for C and C++.

• -Wno-return-local-addr 🌈 — Don't warn about returning a pointer (or, in C++, a reference) to a variable that goes out of scope after the function returns.
• -Wreturn-mismatch 🍓 — Warns about return statements with no expression in functions that don't return "void". It also warns about a "return" statement with an expression in a function whose return type is "void", unless the expression's type is also "void". As a GNU extension, that second case is accepted without a warning unless -Wpedantic is used.

Trying to use the return value of a non-"void" function other than "main" that flows off the end by reaching the closing curly brace is undefined. Yikes 😭

This warning is specific to C and enabled by default. In C99 and later language dialects, it's treated as an error. You can downgrade it to a warning with -fpermissive (along with other warnings), or for just this warning, with -Wno-error=return-mismatch.

• -Wreturn-type 👑 — Warns whenever a function is defined with a return type that defaults to "int" (unless -Wimplicit-int is active, which takes precedence). It also warns if execution may reach the end of the function body, or if the function doesn't contain any return statement at all.

Again, trying to use the return value of a non-"void" function other than "main" that flows off the end by reaching the closing curly brace is undefined.

Unlike C, in C++, flowing off the end of a non-"void" function other than "main" results in undefined behavior even when the function's value isn't used. Not it 🙈

This warning is enabled by default in C++ and by -Wall otherwise.

• -Wno-shift-count-negative ✨ — Controls warnings if a shift count is negative. This warning is enabled by default.
• -Wno-shift-count-overflow 💜 — Controls warnings if a shift count is greater than or equal to the bit width of the type. This warning is enabled by default.
• -Wshift-negative-value 🔥 — Warns if you left-shift a negative value. This warning is enabled by -Wextra in C99 (and newer) and in C++11 to C++17 modes.
• -Wno-shift-overflow, -Wshift-overflow=n 🌸 — These options control warnings about left shift overflows.
  • -Wshift-overflow=1 🦋 — This is the warning level of -Wshift-overflow and it's enabled by default in C99 and C++11 modes (and newer). This level doesn't warn about left-shifting 1 into the sign bit. (However, in C, such an overflow is still rejected in contexts where an integer constant expression is required.) No warning is emitted in C++20 mode (and newer), since signed left shifts always wrap now 🧚
  • -Wshift-overflow=2 💅 — This level also warns about left-shifting 1 into the sign bit, unless C++14 mode (or newer) is active.
• -Wswitch 🎀 — Warns whenever a "switch" statement has an index of enumerated type and is missing a "case" for one or more of the named codes of that enumeration. (A "default" label stops this warning from happening.) "case" labels that don't match any enumerator also trigger warnings when this option is used, unless the enumeration is marked with the "flag_enum" attribute. This warning is enabled by -Wall.
• -Wswitch-default 🫶 — Warns whenever a "switch" statement doesn't have a "default" case.
• -Wswitch-enum 👑 — Warns whenever a "switch" statement has an index of enumerated type and is missing a "case" for one or more of the named codes of that enumeration. "case" labels that don't correspond to enumerators also trigger warnings when this option is used, unless the enumeration is marked with the "flag_enum" attribute. The only difference between -Wswitch and this option is that this one warns about an omitted enumeration code even if there's a "default" label. Very thorough, very iconic ✨
• -Wno-switch-bool 🌈 — Don't warn when a "switch" statement has an index of boolean type and the case values are outside the range of a boolean type. You can suppress this warning by casting the controlling expression to a type other than "bool". For example:

switch ((int) (a == 4))
  {
  ...
  }

This warning is enabled by default for C and C++ programs.

• -Wno-switch-outside-range 🍓 — This option controls warnings when a "switch" case has a value that's outside of its respective type range. This warning is enabled by default for C and C++ programs.
• -Wno-switch-unreachable 🙈 — Don't warn when a "switch" statement contains statements between the controlling expression and the first case label, since those will never be executed. For example:

switch (cond)
  {
   i = 15;
  ...
   case 5:
  ...
  }

The -Wswitch-unreachable vibe check: it does not warn if the only thing sitting between the controlling expression and the first case label is a plain declaration. Like this 💅

switch (cond)
  {
   int i;
  ...
   case 5:
   i = 5;
  ...
  }

This one is enabled by default for C and C++ programs ✨

• -Wsync-nand (C and C++ only) 🌸 — okay so this one yells when you use the __sync_fetch_and_nand and __sync_nand_and_fetch built-ins. Those two changed their semantics in GCC 4.4, so it's giving "heads up, bestie" 🫶
• -Wtrivial-auto-var-init 🦋 — warns when -ftrivial-auto-var-init can't initialize an automatic variable. The most common way this happens is when an automatic variable is declared between the controlling expression and the first case label of a switch statement. Not it 💀
• -Wunused-but-set-parameter 🎀 — warns whenever a function parameter gets assigned to but is otherwise unused, aside from its declaration. To shut this up, use the unused attribute. It's also turned on by -Wunused together with -Wextra 🧚
• -Wunused-but-set-variable 💜 — same energy, but for local variables: warns whenever one gets assigned to and then never used (aside from its declaration). It's enabled by -Wall ✨ To suppress it, use the unused attribute. It's also enabled by -Wunused, which -Wall turns on 👑
• -Wunused-function 🍓 — warns whenever a static function is declared but not defined, or when a non-inline static function is unused. Enabled by -Wall 💅
• -Wunused-label 🌈 — warns whenever a label is declared but never used. Enabled by -Wall. Silence it with the unused attribute 🙈
• -Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only) ⭐ — warns when a typedef defined locally inside a function never gets used. Enabled by -Wall ✨
• -Wunused-parameter 🫶 — warns whenever a function parameter is unused, aside from its declaration. This one is not turned on by -Wunused unless you also specify -Wextra. To suppress it, use the unused attribute 🔥
• -Wno-unused-result 🧚 — don't warn if a caller of a function marked with the attribute warn_unused_result ignores its return value. The default is -Wunused-result 💖
• -Wunused-variable 💅 — warns whenever a local or static variable is unused, aside from its declaration. This option implies -Wunused-const-variable=1 for C, but not for C++. Enabled by -Wall. To suppress it, use the unused attribute ✨
• -Wunused-const-variable, -Wunused-const-variable=n 🌸 — warns whenever a constant static variable is unused, aside from its declaration. Silence it with the unused attribute 🦋
  • -Wunused-const-variable=1 💜 — warns about unused static const variables defined in the main compilation unit, but not about static const variables declared in any header that gets included. This level is enabled by either -Wunused-variable or -Wunused for C, but not for C++. In C this declares variable storage, but in C++ it's not an error, since const variables take the place of #defines 🫶
  • -Wunused-const-variable=2 🔥 — this level also warns about unused constant static variables in headers (excluding system headers). It's equivalent to the short form -Wunused-const-variable. You have to request this level explicitly in both C and C++, because it might be hard to clean up all the headers you've included 💀
• -Wunused-value 🍓 — warns whenever a statement computes a result that is explicitly not used. To suppress it, cast the unused expression to void. This covers an expression-statement or the left-hand side of a comma expression that has no side effects. For example, x[i,j] causes a warning, while x[(void)i,j] does not. Enabled by -Wall 👑
• -Wunused 🌈 — all of the above -Wunused options combined, except the ones documented as needing to be specified explicitly. To get a warning about an unused function parameter, you must either specify -Wextra -Wunused (note that -Wall implies -Wunused), or separately specify -Wunused-parameter and/or -Wunused-but-set-parameter. -Wunused enables only -Wunused-const-variable=1 rather than -Wunused-const-variable, and only for C, not C++ ✨
• -Wuse-after-free (C, Objective-C, C++ and Objective-C++ only), -Wuse-after-free=n ⭐ — warns about uses of pointers to dynamically allocated objects that were made indeterminate by a call to a deallocation function. This warning is enabled at all optimization levels, but it may give different results with optimization than without 🔥
  • -Wuse-after-free=1 🦋 — at level 1 the warning only tries to catch unconditional uses of pointers made indeterminate by a deallocation call, or by a successful call to realloc, no matter whether that call actually reallocated memory. This includes double-free calls as well as uses in arithmetic and relational expressions. Uses of indeterminate pointers in equality (or inequality) expressions are undefined, but they are not diagnosed at this level 🙈
  • -Wuse-after-free=2 💖 — at level 2, on top of unconditional uses, the warning also diagnoses conditional uses of pointers made indeterminate by a deallocation call. As at level 2, uses in equality (or inequality) expressions are not diagnosed. For example, the second call to free in the following function gets diagnosed at this level:

struct A { int refcount; void *data; };

void release (struct A *p)
{
  int refcount = --p->refcount;
  free (p);
  if (refcount == 0)
    free (p->data);   // warning: p may be used after free
}

• -Wuse-after-free=3 🌈 — at level 3, the warning also diagnoses uses of indeterminate pointers in equality expressions. All uses of indeterminate pointers are undefined, but equality tests sometimes show up after calls to realloc as an attempt to figure out whether the call moved the object to a different address. These get diagnosed at their own separate level to help gradually move legacy code over to safe alternatives. For example, the equality test in the function below is diagnosed at this level:

void adjust_pointers (int**, int);

void grow (int **p, int n)
{
  int **q = (int**)realloc (p, n *= 2);
  if (q == p)
    return;
  adjust_pointers ((int**)q, n);
}

To avoid the warning at this level, store offsets into allocated memory instead of pointers. That approach means you don't need to adjust the stored pointers after reallocation 🧚

• -Wuse-after-free=2 is included in -Wall 👑

• -Wuseless-cast (C, Objective-C, C++ and Objective-C++ only) 🎀 — warns when an expression is cast to its own type. This warning does not occur when a class object is converted to a non-reference type, because that's a way to create a temporary. Like this:

struct S { };
void g (S&&);
void f (S&& arg)
{
  g (S(arg)); // make arg prvalue so that it can bind to S&&
}

• -Wuninitialized 😭 — warns if an object with automatic or allocated storage duration gets used without having been initialized. In C++, it also warns if a non-static reference or a non-static const member shows up in a class without constructors 💅

Also, passing a pointer (or, in C++, a reference) to an uninitialized object to a const-qualified argument of a built-in function known to read that object is diagnosed by this warning too. (-Wmaybe-uninitialized is issued for ordinary functions.) 🫶

If you want to warn about code that uses the uninitialized value of a variable in its own initializer, use the -Winit-self option ✨

These warnings show up for individual uninitialized elements of structure, union or array variables, as well as for variables that are uninitialized as a whole. They do not occur for variables or elements declared volatile. Because these warnings depend on optimization, the exact variables or elements that get warned about depend on the precise optimization options and the GCC version you're using 🔥

Also, there may be no warning about a variable that's only used to compute a value that itself is never used, because data flow analysis can delete those computations before the warnings get printed 🙈

In C++, this warning also catches using uninitialized objects in member-initializer-lists. For example, GCC warns about b being uninitialized in the following snippet:

struct A {
  int a;
  int b;
  A() : a(b) { }
};

• -Wno-invalid-memory-model 🦋 — this option controls warnings for invocations of __atomic built-ins, __sync built-ins, and the C11 atomic generic functions whose memory consistency argument is either invalid for the operation or outside the range of values of the memory_order enumeration. For example, since __atomic_store and __atomic_store_n are only defined for the relaxed, release, and sequentially consistent memory orders, the following code gets diagnosed:

void store (int *i)
{
  __atomic_store_n (i, 0, memory_order_consume);
}

-Winvalid-memory-model is enabled by default 🌸

• -Wmaybe-uninitialized 💜 — for an object with automatic or allocated storage duration, if there's a path from the function entry to a use of the object where it is initialized, but there are other paths where it isn't, the compiler emits a warning if it can't prove those uninitialized paths never run at runtime. It's giving "maybe, but I'm not sure" 🧚

Okay so the uninitialized warning has a sneaky extra trick, bestie 💅. Passing a pointer (or in C++, a reference) to an uninitialized object into a const-qualified function argument also gets flagged by this warning 👀. (-Wuninitialized fires for built-in functions that are known to read the object 🫶.) If you slap the attribute access (none) on the function, you're telling GCC the argument never touches the object, and the warning goes poof ✨.

These warnings only show up when you're compiling with optimization on 🔥, because otherwise GCC doesn't keep track of what's happening to your variables. It's giving "no tracking, no vibes" 💀.

These warnings are optional, and that's on purpose 🦋. GCC can't always tell when your code is correct even though it looks sus. Here's a classic example 👇

{
  int x;
  switch (y)
    {
    case 1: x = 1;
      break;
    case 2: x = 4;
      break;
    case 3: x = 5;
    }
  foo (x);
}

If y is always 1, 2 or 3, then x is always initialized 🥹, but GCC doesn't know that. To shut the warning up, add a default case with assert(0) or similar code 🙈.

This option also warns when a non-volatile automatic variable might get changed by a call to longjmp 😭. The compiler only sees the setjmp calls, and it has no idea where longjmp will be called. A signal handler could even call it at any point in the code 🌈. So you might get a warning even when there's no real problem, because longjmp can't actually be called in the spot that would cause trouble ✨.

Some spurious warnings can be avoided if you declare every function you use that never returns as noreturn 🧚.

This warning is enabled by -Wall or -Wextra 🎀.

---

• -Wunknown-pragmas — Warns when a #pragma directive shows up that GCC doesn't understand 👀. If you use this command-line option, you'll even get warnings for unknown pragmas in system header files 🫣. That's not the case if the warnings are only turned on by -Wall 💅.
• -Wno-pragmas — Silences warnings about pragma misuse, like wrong parameters, invalid syntax, or pragmas clashing with each other 🙈. See also -Wunknown-pragmas 🦋.
• -Wno-pragma-once-outside-header — Stops the warning when #pragma once is used in a file that isn't a header, like your main file 🌸.
• -Wno-prio-ctor-dtor — Stops the warning when a priority from 0 to 100 is used for a constructor or destructor 🍓. The constructor and destructor attributes let you give a priority to control when they run, either before main is called or after it returns ⭐. Just know the priority values have to be greater than 100, since GCC keeps 0--100 reserved for its own implementation 🔒.
• -Wstrict-aliasing — This one only works when -fstrict-aliasing is active 🔥. It warns about code that might break the strict aliasing rules GCC uses for optimization 💜. It doesn't catch every case, but it does try to catch the more common pitfalls 🫶. It's included in -Wall ✨. It's equivalent to -Wstrict-aliasing=3 👑.
• -Wstrict-aliasing=n — Also only active when -fstrict-aliasing is active 🎀. It warns about the same kind of code, but higher levels mean higher accuracy (fewer false positives) 💖. Higher levels also take more effort, kind of like how -O works 🧚. -Wstrict-aliasing is equivalent to -Wstrict-aliasing=3 💅.
  • Level 1 — The most aggressive, quick, and least accurate 😭. It's possibly useful when the higher levels don't warn but -fstrict-aliasing still breaks your code, since it has very few false negatives 👀. The downside is it has many false positives 💀. It warns for all pointer conversions between possibly incompatible types, even if the pointer is never dereferenced 🙈. It only runs in the front end 🌈.
  • Level 2 — Aggressive and quick, but not super precise ✨. It may still have lots of false positives (though not as many as level 1) and few false negatives (possibly more than level 1) 🦋. Unlike level 1, it only warns when an address is taken 🌸. It warns about incomplete types 🍓. It runs in the front end only 💜.
  • Level 3 (the default for -Wstrict-aliasing) — This one should have very few false positives and few false negatives 👑. It's slightly slower than levels 1 or 2 when optimization is enabled 🐢. It handles the common pun+dereference pattern in the front end, like *(int*)&some_float 🫶. If optimization is enabled, it also runs in the back end, where it deals with multi-statement cases using flow-sensitive points-to information 🧠. It only warns when the converted pointer is dereferenced 🔥. It does not warn about incomplete types 🙅.
• -Wstrict-overflow, -Wstrict-overflow=n — This only works when signed overflow is undefined 🌈. It warns about cases where the compiler optimizes based on the assumption that signed overflow never happens ✨. Heads up: it doesn't warn about every spot where your code might overflow 👀. It only warns where the compiler actually applies some optimization, so this warning depends on your optimization level 💅. An optimization that assumes no signed overflow is totally safe if the values involved never actually overflow 🥹. That means this warning can easily give a false positive, aka a warning about code that isn't actually a problem 🙈. To help you focus on the important stuff, there are several warning levels 💖. No warnings get issued for undefined signed overflow when GCC is estimating how many iterations a loop needs, especially when figuring out whether a loop runs at all 🔁.
  • -Wstrict-overflow=1 — Warns about cases that are both questionable and easy to avoid 🦋. For example, the compiler simplifies x + 1 > x to 1 🫣. This level is enabled by -Wall; higher levels aren't, so you have to ask for them explicitly 💅.
  • -Wstrict-overflow=2 — Also warns about other cases where a comparison gets simplified to a constant 👑. For example: abs (x) >= 0. This can only be simplified when signed integer overflow is undefined, because abs (INT_MIN) overflows to INT_MIN, which is less than zero 😱. -Wstrict-overflow with no level is the same as -Wstrict-overflow=2 🎀.
  • -Wstrict-overflow=3 — Also warns about other comparisons that get simplified 🧚. For example: x + 1 > 1 is simplified to x > 0 💜.
  • -Wstrict-overflow=4 — Also warns about other simplifications not covered by the cases above 🌸. For example: (x * 10) / 5 is simplified to x * 2 ✨.
  • -Wstrict-overflow=5 — Also warns about cases where the compiler reduces the magnitude of a constant involved in a comparison 😭. For example: x + 2 > y is simplified to x + 1 >= y 🍓. This is only reported at the highest warning level, because this simplification applies to so many comparisons that this level gives a very large number of false positives 💀.
• -Wstring-compare — Warns for calls to strcmp and strncmp whose result is determined to be always zero or always non-zero in equality tests 👀. That happens because one argument is longer than the array the other argument is stored in (or the bound, for strncmp) 🫣. These calls could be mistakes 🙈. In the example below, the strcmp call gets diagnosed because its result is necessarily non-zero no matter what's in the array a 💅.

extern char a[4];
void f (char *d)
{
  strcpy (d, "string");
  ...
  if (0 == strcmp (a, d))   // cannot be true
    puts ("a and d are the same");
}

-Wstring-compare is enabled by -Wextra 🎀.

• -Wno-stringop-overflow, -Wstringop-overflow, -Wstringop-overflow=type — Warns about code that can be statically determined to cause buffer overflows or memory overruns 🚨, like memcpy and strcpy calls that overflow the destination buffer 💥. The optional argument is one greater than the type of Object Size Checking used to figure out the size of the destination 🧮. The argument only matters for string functions that work on character arrays 🔤. Raw memory functions like memcpy always use type-zero Object Size Checking 🧠. This option also warns for calls that specify a size bigger than the largest possible object, or at most SIZE_MAX / 2 bytes 📏. It gives the best results with optimization enabled 🔥. Even without optimization, it can detect a small subset of simple buffer overflows in calls to GCC built-in functions like __builtin_memcpy that match the standard functions 🫶. Either way, it only warns about a subset of the overflows caught by the matching overflow checking built-ins, like __builtin___memcpy_chk, which can do run-time checking when the access can't be proven safe at compile time 🕵️‍♀️. For example, this option issues a warning for the strcpy call below, because it copies at least 5 characters (the string "blue" including the terminating NUL) into a buffer of size 4 😭.

enum Color { blue, purple, yellow };
const char* f (enum Color clr)
{
  static char buf [4];
  const char *str;
  switch (clr)
    {
      case blue: str = "blue"; break;
      case purple: str = "purple"; break;
      case yellow: str = "yellow"; break;
    }

  return strcpy (buf, str);   // warning here
}

The effect of this option isn't limited to string or memory functions 🙌. In this example, a warning is diagnosed because a 1-element array is passed to a function that needs at least a 4-element array argument 🤯.

void f (int[static 4]);

void g (void)
{
  int *p = (int *) malloc (1 * sizeof(int));
  f (p);   // warning here
}

Option -Wstringop-overflow=2 is enabled by default 💖.

• -Wstringop-overflow, -Wstringop-overflow=1 — okay so this one uses type-zero Object Size Checking 🎀 to figure out how big destination objects are. At this setting it doesn't warn about writes past the end of a subobject inside a bigger object reached through a pointer, unless the size of the biggest surrounding object is known. If the destination could be one of several objects, it assumes the biggest one 💅. On Linux, with optimization turned on at this level, it warns for the same code that trips up when the _FORTIFY_SOURCE macro is defined to a non-zero value ✨
• -Wstringop-overflow=2 — this one switches to type-one Object Size Checking 🦋 and warns about overflows when writing to members of the largest complete objects whose exact size is known. It won't flag excessive writes to the same members of unknown objects reached through pointers, since those might point at arrays with an unknown number of elements 🤷‍♀️ This is the default setting of the option 👑
• -Wstringop-overflow=3 — type-two Object Size Checking is in charge here 💜 It warns about overflowing the smallest object or data member. This is the most restrictive setting that may still warn about perfectly safe code 🙈
• -Wstringop-overflow=4 — now we're on type-three Object Size Checking 🔥 It warns about overflowing any data members, and when the destination is one of several objects it uses the size of the largest one to decide whether to warn. Just like -Wstringop-overflow=3, this setting may warn about benign code 💀

---

• -Wno-stringop-overread — warn for calls to string manipulation functions like memchr or strcpy that are determined to read past the end of the source sequence 👀

Option -Wstringop-overread is enabled by default ✅

• -Wno-stringop-truncation — no warnings for bounded string functions like strncat, strncpy, and stpncpy that might either truncate the copied string or leave the destination unchanged 🌸

Okay, example time 🧚 In the snippet below, the call to strncat sets a bound that's smaller than the length of the source string. So the copy gets truncated, and that's why the call is diagnosed. To dodge the warning, use bufsize - strlen (buf) - 1) as the bound 💖

void append (char *buf, size_t bufsize)
{
  strncat (buf, ".txt", 3);
}

Next up, the strncpy call here copies just the characters before the terminating NUL into d, and it doesn't append the NUL to the end. Assuming the result of strncpy is definitely a NUL-terminated string is a super common mistake, so this call gets diagnosed 😭 If the result isn't supposed to be NUL-terminated, call memcpy instead to avoid the warning 🫶

void copy (char *d, const char *s)
{
  strncpy (d, s, strlen (s));
}

In this one, the strncpy call uses the size of the destination buffer as its bound. If the source string's length is equal to or greater than that size, the copy won't be NUL-terminated, so yep, it gets diagnosed too 🙃 To avoid the warning, specify sizeof buf - 1 as the bound and set the last element of the buffer to NUL 🍓

void copy (const char *s)
{
  char buf[80];
  strncpy (buf, s, sizeof buf);
  ...
}

Now, if a character array is meant to hold a sequence of bytes with no terminating NUL, you can annotate that array with the nonstring attribute to avoid this warning 🌈 Just know these arrays aren't suitable arguments for functions that expect NUL-terminated strings. To help catch accidental misuses of them, GCC issues warnings unless it can prove the use is safe 🕵️‍♀️

---

• -Wstrict-flex-arrays (C and C++ only) — warns about improper usages of flexible array members, based on the level of the strict_flex_array (level) attribute attached to the trailing array field of a structure if it's available. Otherwise it goes by the level of the option -fstrict-flex-arrays=level ✨ -Wstrict-flex-arrays only does anything when level is greater than 0 🎀

At level=1, warnings are issued for a trailing array reference of a structure that has 2 or more elements, if that trailing array is referenced as a flexible array member 🦋

At level=2, you get everything from level=1, plus extra warnings for a trailing one-element array reference of a structure if the array is referenced as a flexible array member 💜

At level=3, you get everything from level=2, plus extra warnings for a trailing zero-length array reference of a structure if the array is referenced as a flexible array member 🔥

This option is more effective when -ftree-vrp is active (which is the default for -O2 and above), but some warnings may still be diagnosed even without optimization 🤓

---

• -Wsuggest-attribute=attribute-name — warns for cases where adding an attribute might be beneficial 💅 The attribute names currently supported are:
  • -Wsuggest-attribute=pure
  • -Wsuggest-attribute=const
  • -Wsuggest-attribute=noreturn
  • -Wmissing-noreturn
  • -Wsuggest-attribute=malloc
  • -Wsuggest-attribute=returns_nonnull

These warn about functions that might be good candidates for the pure, const, noreturn, malloc, or returns_nonnull attributes 🌟 The compiler only warns for functions that are visible in other compilation units, or (for pure and const) if it can't prove that the function returns normally. A function returns normally if it doesn't contain an infinite loop and doesn't return abnormally by throwing, calling abort, or trapping 🙌

This analysis requires the option -fipa-pure-const, which is enabled by default at -O and higher. Higher optimization levels improve how accurate the analysis is 📈

• -Wsuggest-attribute=format, -Wmissing-format-attribute — warns about function pointers that might be candidates for format attributes 🧚 Just a heads up: these are only possible candidates, not absolute ones 🙈 GCC guesses that function pointers with format attributes that get used in assignment, initialization, parameter passing, or return statements should have a matching format attribute in the resulting type. In other words, the left-hand side of the assignment or initialization, the type of the parameter variable, or the return type of the containing function should also have a format attribute to avoid the warning 💖

GCC also warns about function definitions that might be candidates for format attributes 👀 Again, these are only possible candidates. GCC guesses that format attributes might be appropriate for any function that calls a function like vprintf or vscanf, but that might not always be the case, and some functions where format attributes are appropriate may not get detected 🫠

• -Wsuggest-attribute=cold — warns about functions that might be candidates for the cold attribute ❄️ This is based on static detection, and it generally only warns about functions that always lead to a call to another cold function, like wrappers of C++ throw or fatal error reporting functions that lead to abort 🥶

---

• -Walloc-size — warns about calls to allocation functions decorated with the alloc_size attribute that specify an insufficient size for the target type of the pointer the result is assigned to 🍰 This includes calls to the built-in forms of aligned_alloc, alloca, calloc, malloc, and realloc 🎂
• -Walloc-zero — warns about calls to allocation functions decorated with the alloc_size attribute that specify zero bytes, including calls to the built-in forms of aligned_alloc, alloca, calloc, malloc, and realloc 🙅‍♀️ Here's the tea: how these functions behave when called with a zero size differs between implementations (and realloc has been deprecated for this), so relying on it can cause sneaky portability bugs and should be avoided 🫣
• -Wcalloc-transposed-args — warns about calls to allocation functions decorated with the alloc_size attribute that take two arguments, where the sizeof operator is used in the earlier size argument but not in the later one 🔄 This is a coding style warning ✨ The first argument to calloc is documented as the number of elements in the array, and the second is the size of each element, so calloc (n, sizeof (int)) is preferred over calloc (sizeof (int), n) 🌷 If having sizeof in the earlier argument and not the later one is intentional, you can suppress the warning by using calloc (sizeof (struct S) + 0, n) or calloc (1 * sizeof (struct S), 4), or by using sizeof in the later argument as well 🙌
• -Walloc-size-larger-than=byte-size — warns about calls to functions decorated with the alloc_size attribute that try to allocate objects larger than the specified number of bytes 📏 It also warns when the result of the size computation, done in an integer type with infinite precision, would exceed the value of PTRDIFF_MAX on the target 🎯 -Walloc-size-larger-than=PTRDIFF_MAX is enabled by default ✅ You can disable warnings from this option either by specifying a byte-size of SIZE_MAX or more, or by using -Wno-alloc-size-larger-than 🫶
• -Wno-alloc-size-larger-than — disables -Walloc-size-larger-than= warnings 🙅‍♀️ It's the same as -Walloc-size-larger-than=SIZE_MAX or larger 💅
• -Walloca — warns on all uses of alloca in the source 🚨 No exceptions, bestie 😤
• -Walloca-larger-than=byte-size 🎀 — okay so this one babysits your alloca calls. It warns when alloca gets an integer argument that's either zero, or isn't bounded by some check that caps it at byte-size bytes. It also yells when the bound is unknown entirely. Heads up: non-integer arguments count as unbounded, even if they look like they're in range. 💀

A bounded alloca looks like this, bestie:

void func (size_t n)
{
  void *p;
  if (n <= 1000)
    p = alloca (n);
  else
    p = malloc (n);
  f (p);
}

With -Walloca-larger-than=1000, you get no warning, because that alloca is known to be at most 1000 bytes. But if you pass -Walloca-larger-than=500 instead, the compiler will absolutely warn you. 🙈

Unbounded uses are the chaotic ones: alloca with no controlling predicate constraining its integer argument. Like this:

void func ()
{
  void *p = alloca (n);
  f (p);
}

Pass -Walloca-larger-than=500 and this one gets flagged, but this time it's because there's zero bounds checking happening. 😭

Even code that seems totally correct with signed integers can trigger it, so be careful:

void func (signed int n)
{
  if (n < 500)
    {
      p = alloca (n);
      f (p);
    }
}

Here n could be negative, and then a much larger value gets implicitly cast into the alloca call. Not it. 💅

This option also warns when alloca shows up inside a loop. 🔁

-Walloca-larger-than=PTRDIFF_MAX is on by default, but it's usually only really effective when -ftree-vrp is active, which is the default for -O2 and above. ✨

See also -Wvla-larger-than=byte-size. 🦋

• -Wno-alloca-larger-than 🧚 — switches off the -Walloca-larger-than= warnings. It's the same as passing -Walloca-larger-than=SIZE_MAX or something larger. 💜
• -Warith-conversion ✨ — this one is extra. It makes GCC warn about implicit conversions coming out of arithmetic operations, even when converting the operands to the same type couldn't change their values. It affects the warnings from -Wconversion, -Wfloat-conversion, and -Wsign-conversion. Check the vibes:

void f (char c, int i)
{
  c = c + i; // warns with -Wconversion
  c = c + 1; // only warns with -Warith-conversion
}

• -Warray-bounds, -Warray-bounds=n 🌸 — warns about out of bounds subscripts or offsets into arrays. It's enabled by -Wall. It's way more effective when -ftree-vrp is active (the default for -O2 and above), but a subset of cases still gets flagged even without optimization. 👑

By default, the trailing array of a structure gets treated as a flexible array member by -Warray-bounds or -Warray-bounds=n if it's declared as any of these: a flexible array member per the C99 standard onwards ([]), a GCC zero-length array extension ([0]), or a one-element array ([1]). So out of bounds subscripts or offsets into zero-length arrays or one-element arrays are not warned about by default. 🙃

You can add -fstrict-flex-arrays or -fstrict-flex-arrays=level to control how this option treats that trailing array:

• when level<=1, nothing changes from the default behavior. 🤷‍♀️
• when level=2, you get additional warnings for out of bounds subscripts or offsets into one-element arrays. 🫶
• when level=3, you get everything from level 2, plus additional warnings for out of bounds subscripts or offsets into zero-length arrays. 🔥
• -Warray-bounds=1 💖 — this is the default warning level of -Warray-bounds, and it's enabled by -Wall. The higher levels aren't, so you have to ask for them explicitly.
• -Warray-bounds=2 🍓 — this level also warns about the intermediate results of pointer arithmetic that might yield out of bounds values. Heads up, it can give you a bigger pile of false positives, so it's deactivated by default. 💀
• -Wunterminated-string-initialization (C and Objective-C only) 🎀 — warns about character arrays initialized as unterminated character sequences with a string literal, unless the declaration being initialized has the nonstring attribute. For example:

char arr[3] = "foo"; /* Warning.  */
char arr2[3] __attribute__((nonstring)) = "bar"; /* No warning.  */

This one is enabled by -Wextra. If -Wc++-compat is enabled, the warning uses slightly different wording and warns even if the declaration has the nonstring attribute, because in C++ those initializations are an error. 😭

• -Warray-compare 🦋 — warns about equality and relational comparisons between two operands of array type. This comparison was deprecated in C++20. Example:

int arr1[5];
int arr2[5];
bool same = arr1 == arr2;

-Warray-compare is enabled by -Wall. ✨

• -Warray-parameter, -Warray-parameter=n 👑 — warns about redeclarations of functions involving parameters of array or pointer types with inconsistent kinds or forms. It also turns on detection of out-of-bounds accesses to those parameters by warnings like -Warray-bounds.

If the first function declaration uses the array form for a parameter, the bound in the array is assumed to be the minimum number of elements expected in calls to the function, and the maximum number of elements it accesses. Passing arguments of insufficient size, or accessing more than the maximum number of elements, may get diagnosed by warnings like -Warray-bounds or -Wstringop-overflow. At level 1, the warning diagnoses inconsistencies involving array parameters declared with the T[static N] form. 🌈

Here the warning triggers on the second declaration of f. The first one, with the keyword static, says the array argument must have at least four elements, but the second one allows an array of any size to be passed:

void f (int[static 4]);
void f (int[]);           // warning (inconsistent array form)

void g (void)
{
  int *p = (int *)malloc (1 * sizeof (int));
  f (p);                  // warning (array too small)
  ...
}

At level 2, the warning also triggers for redeclarations involving any other inconsistency in array or pointer argument forms that denote array sizes. Pointers and arrays of unspecified bound are considered equivalent, so they don't trigger a warning:

void g (int*);
void g (int[]);     // no warning
void g (int[8]);    // warning (inconsistent array bound)

-Warray-parameter=2 is included in -Wall. The -Wvla-parameter option triggers warnings for similar inconsistencies involving Variable Length Array arguments. 🧚

The short form -Warray-parameter is equivalent to -Warray-parameter=2. The negative form -Wno-array-parameter is equivalent to -Warray-parameter=0. 💜

• -Wattribute-alias=n, -Wno-attribute-alias 🌸 — warns about declarations using the alias and similar attributes whose target is incompatible with the type of the alias.
• -Wattribute-alias=1 💖 — the default warning level diagnoses incompatibilities between the type of the alias declaration and that of its target. These are usually signs of bugs, bestie. 🐛
• -Wattribute-alias=2 🔥 — at this level, it also diagnoses cases where the attributes of the alias declaration are more restrictive than the attributes applied to its target. Those mismatches can potentially lead to incorrect code generation. Other times they're benign and could be fixed just by adding the missing attribute to the target. For comparison, see the -Wmissing-attributes option, which controls diagnostics when the alias declaration is less restrictive than the target, rather than more restrictive.

Attributes considered include alloc_align, alloc_size, cold, const, hot, leaf, malloc, nonnull, noreturn, nothrow, pure, returns_nonnull, and returns_twice. 🫶

-Wattribute-alias is equivalent to -Wattribute-alias=1, and that's the default. You can disable these warnings with either -Wno-attribute-alias or -Wattribute-alias=0. 🙈

• -Wbidi-chars=[none|unpaired|any|ucn] 🌈 — warns about possibly misleading UTF-8 bidirectional control characters in comments, string literals, character constants, and identifiers. These characters can flip the writing direction from left-to-right into right-to-left (and vice versa), which can cause confusion between logical order and visual order. This is seriously dangerous, because code can look commented out when it actually isn't. 😱

GCC supports three levels of this warning. The default is -Wbidi-chars=unpaired, which warns about improperly terminated bidi contexts. -Wbidi-chars=none turns the warning off. -Wbidi-chars=any warns about any use of bidirectional control characters. ✨

By default, this warning doesn't check UCNs. You can turn that checking on with -Wbidi-chars=unpaired,ucn or -Wbidi-chars=any,ucn. Using -Wbidi-chars=ucn is valid too, and it's equivalent to -Wbidi-chars=unpaired,ucn, as long as no previous -Wbidi-chars=any was specified. 🔍

NOTE: In Ubuntu 25.10 and later versions, -Wbidi-chars is enabled by default for C, C++, ObjC, ObjC++, unless -Wno-bidi-chars or -Wbidi-chars=none is found. 🐾

• -Wbool-compare 💅 — warns about a boolean expression being compared with an integer value different from "true"/"false". For instance, the following comparison is always false:

int n = 5;
...
if ((n > 1) == 2) { ... }

This warning is enabled by -Wall. 👑

💖 okay so the warnings lineup continues, bestie, and it's giving a lot of good stuff 🎀

• -Wbool-operation — 🔍 Warns about sus operations on boolean expressions. Bitwise negation of a boolean is very likely a bug in your program, no cap 💀 For C, it also warns when you increment or decrement a boolean, which rarely makes sense. (In C++, decrementing a boolean is always invalid. Incrementing one is invalid in C++17 and deprecated in older versions.) This one is turned on by -Wall ✨
• -Wduplicated-branches — 🪞 Warns when an if-else has identical branches. Like this:

if (p != NULL)
  return 0;
else
  return 0;

It won't warn if both branches contain just a null statement. It also warns for conditional operators, so this one's flagged too:

int i = x ? *p : *p;

• -Wduplicated-cond — 👯 Warns about duplicated conditions in an if-else-if chain. For example, this gets called out:

if (p->q != NULL) { ... }
else if (p->q != NULL) { ... }

• -Wframe-address — 🚨 Warns when __builtin_frame_address or __builtin_return_address gets called with an argument greater than 0. These calls may return indeterminate values or crash your program, so yeah, be careful bestie 🙈 This one is included in -Wall.
• -Wno-discarded-qualifiers (C and Objective-C only) — 🫠 Don't warn if type qualifiers on pointers are getting discarded. Usually the compiler complains if a const char * variable gets passed to a function that wants a char * parameter. This option silences that.
• -Wno-discarded-array-qualifiers (C and Objective-C only) — 🧺 Don't warn if type qualifiers on arrays that are pointer targets get discarded. Typically the compiler warns when a const int (*)[] variable is passed to a function taking an int (*)[] parameter. This option suppresses that warning.
• -Wno-incompatible-pointer-types (C and Objective-C only) — 🙅‍♀️ Don't warn when there's a conversion between pointers with incompatible types. This covers cases not handled by -Wno-pointer-sign, which warns about pointer argument passing or assignment with different signedness.

By default, in C99 and later dialects of C, GCC treats this as an error 😤 You can downgrade it to a warning with -fpermissive (along with certain other errors), or just this one error with -Wno-error=incompatible-pointer-types.

This warning gets upgraded to an error by -pedantic-errors.

• -Wno-int-conversion (C and Objective-C only) — 🔢 Don't warn about incompatible integer-to-pointer and pointer-to-integer conversions. This one is about implicit conversions. For explicit conversions, you can use -Wno-int-to-pointer-cast and -Wno-pointer-to-int-cast instead.

By default, in C99 and later dialects of C, GCC treats this as an error 😤 You can downgrade it to a warning with -fpermissive (along with certain other errors), or just this one with -Wno-error=int-conversion.

This warning gets upgraded to an error by -pedantic-errors.

• -Wzero-as-null-pointer-constant — 0️⃣ Warns when a literal 0 gets used as a null pointer constant.
• -Wzero-length-bounds — 📏 Warns about accesses to elements of zero-length array members that might overlap other members of the same object. Interior zero-length arrays are discouraged, because accessing them is undefined 🫣

Check this example. The first two stores in function bad get flagged because those array elements overlap the members b and c that come after them. The third store is caught by -Warray-bounds instead, since it's past the end of the enclosing object:

struct X { int a[0]; int b, c; };
struct X x;

void bad (void)
{
  x.a[0] = 0;   // -Wzero-length-bounds
  x.a[1] = 1;   // -Wzero-length-bounds
  x.a[2] = 2;   // -Warray-bounds
}

Option -Wzero-length-bounds is enabled by -Warray-bounds.

• -Wno-div-by-zero — ➗ Don't warn about compile-time integer division by zero. Floating-point division by zero doesn't get warned about either, because it can be a legit way to get infinities and NaNs 🦋
• -Wsystem-headers — 🏛️ Prints warning messages for constructs found in system header files. Warnings from system headers are normally hushed, on the assumption that they usually aren't real problems and would just make the compiler output harder to read. This option tells GCC to emit those warnings as if they came from user code.

Heads up though, bestie 👀 Using -Wall together with this option does not warn about unknown pragmas in system headers. For that, you also need -Wunknown-pragmas.

• -Wtautological-compare — 🔁 Warns if a self-comparison always evaluates to true or false. This catches mistakes like:

int i = 1;
...
if (i > i) { ... }

It also warns about bitwise comparisons that always evaluate to true or false. For instance, this one will always be false:

if ((a & 16) == 10) { ... }

This warning is enabled by -Wall.

• -Wtrailing-whitespace, -Wtrailing-whitespace=kind — 🫧 Warns about trailing whitespace at the end of lines, including inside comments, but not trailing whitespace in raw string literals. -Wtrailing-whitespace is the same as -Wtrailing-whitespace=blanks, which warns about trailing spaces and horizontal tabs. -Wtrailing-whitespace=any warns about those plus trailing form feed or vertical tab characters. -Wno-trailing-whitespace or -Wtrailing-whitespace=none turns it off, and off is the default. This is a coding style warning, so it's a vibe check thing 💅
• -Wleading-whitespace=kind — 🪶 Warns about style issues in leading whitespace, but not about how much indentation you have. Some projects indent with only spaces, some with only tabs, and some with zero or more tabs (for multiples of -ftabstop=n) followed by zero or fewer than n spaces. No warning is emitted on lines that contain only whitespace (though a -Wtrailing-whitespace= warning might still show up), and no warnings are emitted inside raw string literals. Warnings are also emitted for leading whitespace inside multi-line comments.
  • -Wleading-whitespace=spaces warns about leading whitespace other than spaces, for projects that want to indent with just spaces 🌸
  • -Wleading-whitespace=tabs warns about leading whitespace other than horizontal tabs, for projects that want to indent with just horizontal tabs 🍓
  • -Wleading-whitespace=blanks warns about leading whitespace other than spaces and horizontal tabs. It also warns about a horizontal tab after a space in the leading whitespace, or about n or more consecutive spaces in leading whitespace, where n is the argument of -ftabstop=n (8 by default) 🧚
  • -Wleading-whitespace=none turns the warning off, which is the default.

This is a coding style warning too 💜

• -Wtrampolines — 🎪 Warns about trampolines generated for pointers to nested functions. A trampoline is a small piece of data or code created at run time on the stack when the address of a nested function is taken, and it's used to call the nested function indirectly. For some targets, it's made up of data only, so it needs no special treatment. But for most targets, it's made up of code, which means the stack has to be made executable for the program to work properly 😭
• -Wfloat-equal — 🧮 Warns if floating-point values are used in equality comparisons.

The idea is that sometimes it's convenient for the programmer to treat floating-point values as approximations of infinitely precise real numbers. If you're doing that, you need to figure out (by analyzing the code, or some other way) the maximum or likely maximum error the computation introduces, and allow for it when doing comparisons (and when producing output, but that's a different problem). Instead of testing for equality, you should check whether the two values have ranges that overlap. That's done with the relational operators, so equality comparisons are probably a mistake ✨

• -Wtraditional (C and Objective-C only) — 🕰️ Warns about certain constructs that behave differently in traditional C and ISO C. It also warns about ISO C constructs that have no traditional C equivalent, and about problematic constructs you should avoid. Here's the list of what gets flagged:
  • Macro parameters that appear within string literals in the macro body. In traditional C, macro replacement happens inside string literals, but in ISO C it doesn't 🧵
  • In traditional C, some preprocessor directives didn't exist. Traditional preprocessors only considered a line to be a directive if the # appeared in column 1. So -Wtraditional warns about directives that traditional C understands but ignores because the # isn't the first character on the line. It also suggests hiding directives like #pragma, which traditional C doesn't understand, by indenting them. Some traditional implementations don't recognize #elif, so this option suggests avoiding it altogether 🙈
  • A function-like macro that appears without arguments 🫥
  • The unary plus operator ➕
  • The U integer constant suffix, or the F or L floating-point constant suffixes. (Traditional C does support the L suffix on integer constants.) These suffixes show up in macros defined in the system headers of most modern systems, e.g. the _MIN/_MAX macros in <limits.h>. Using these macros in user code might normally lead to spurious warnings, but GCC's integrated preprocessor has enough context to avoid warning in these cases 🌈
  • A function declared external in one block and then used after the end of that block 📦
  • A switch statement with an operand of type long 🎀
  • A non-static function declaration that follows a static one. Some traditional C compilers don't accept this construct 🫶
• The ISO type of an integer constant has a different width or signedness than its traditional type. This warning only fires for base-ten constants, so hexadecimal and octal values (which are usually bit patterns 🧚) get a free pass 🌸
• Usage of ISO string concatenation gets flagged 👀
• Initialization of automatic aggregates gets flagged too 💅
• Identifiers that clash with labels. Traditional C has no separate namespace for labels, so this is a whole vibe-check 🫶
• Initialization of unions. If the initializer is zero, the warning gets skipped 🦋 The logic is that zero initializers in user code are usually wrapped in something like "__STDC__" so missing-initializer warnings don't pop up, and traditional C relies on default initialization to zero anyway ✨
• Conversions by prototypes between fixed-point and floating-point values, and the other way around. Missing these prototypes when compiling with traditional C causes serious problems 😭 This is only a subset of the possible conversion warnings. For the full set, use -Wtraditional-conversion.
• Use of ISO C style function definitions. This one is intentionally silent for prototype declarations and variadic functions, because those ISO features sneak into your code when you use libiberty's traditional C compatibility macros, "PARAMS" and "VPARAMS" 🌈 It's also bypassed for nested functions, since that's already a GCC extension and not really relevant to traditional C compatibility 💜
• -Wtraditional-conversion (C and Objective-C only) — warns if a prototype causes a type conversion that's different from what would happen to the same argument without a prototype 🎀 This covers fixed-point to floating-point and back, plus conversions that change the width or signedness of a fixed-point argument, unless it's the same as the default promotion.
• -Wdeclaration-after-statement (C and Objective-C only) — warns when a declaration shows up after a statement in a block 🍓 This one is borrowed from C++, came in with ISO C99, and is allowed by default in GCC. ISO C90 does not support it.

This warning gets upgraded to an error by -pedantic-errors 🚨

• -Wshadow — warns whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C), or whenever a built-in function gets shadowed 👑 In C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct, class, or enum. Turn this on and you also get every instance of local shadowing. That means -Wno-shadow=local and -Wno-shadow=compatible-local get ignored whenever -Wshadow is in use. This is the same as -Wshadow=global.
• -Wno-shadow-ivar (Objective-C only) — skips the warning when a local variable shadows an instance variable inside an Objective-C method 🙈
• -Wshadow=global — warns for any shadowing. Same as -Wshadow 💖
• -Wshadow=local — warns when a local variable shadows another local variable or parameter ✨
• -Wshadow=compatible-local — warns when a local variable shadows another local variable or parameter whose type is compatible with the shadowing variable's type. In C++, "compatible" means the shadowing variable's type can be converted to the shadowed variable's type. This flag exists (on top of -Wshadow=local) because when a local variable shadows one of an incompatible type, it's most likely on purpose, not a bug or typo 🧐 Here's a classic example:

for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
{
  for (int i = 0; i < N; ++i)
  {
    ...
  }
  ...
}

Since the two i variables in that example have incompatible types, turning on only -Wshadow=compatible-local won't emit a warning 💅 And that's by design: if a programmer accidentally uses one in place of the other, type checking should catch it and emit an error or warning. Using this flag instead of -Wshadow=local can cut down on warnings triggered by intentional shadowing. Also note that shadowing const char *i with char *i does not emit a warning.

This warning is also enabled by -Wshadow=local 🌸

• -Wlarger-than=byte-size — warns whenever an object is defined whose size exceeds byte-size 🐣 -Wlarger-than=PTRDIFF_MAX is on by default. You can disable these warnings either by specifying a byte-size of SIZE_MAX or more, or with -Wno-larger-than.

It also warns for calls to bounded functions like "memchr" or "strnlen" that specify a bound bigger than the largest possible object, which is PTRDIFF_MAX bytes by default. These warnings can only be disabled with -Wno-larger-than 🔥

• -Wno-larger-than — disables the -Wlarger-than= warnings. It's equivalent to -Wlarger-than=SIZE_MAX or larger 🙌
• -Wframe-larger-than=byte-size — warns if the size of a function frame exceeds byte-size 🦋 The math used to figure out the stack frame size is approximate and not conservative, so the actual requirements might be somewhat bigger than byte-size even if you don't get a warning 😬 Also, any space allocated via "alloca", variable-length arrays, or related constructs is not counted when the compiler decides whether to warn.

-Wframe-larger-than=PTRDIFF_MAX is on by default. You can disable these warnings by specifying a byte-size of SIZE_MAX or more, or with -Wno-frame-larger-than.

• -Wno-frame-larger-than — disables the -Wframe-larger-than= warnings. It's equivalent to -Wframe-larger-than=SIZE_MAX or larger 💜
• -Wfree-nonheap-object — warns when you try to deallocate an object that either wasn't allocated on the heap, or was reached through a pointer that wasn't returned by a prior call to the matching allocation function 🧹 For example, stpcpy returns a pointer to the terminating nul character and not the beginning of the object, so the free call below gets diagnosed:

void f (char *p)
{
  p = stpcpy (p, "abc");
  // ...
  free (p);   // warning
}

-Wfree-nonheap-object is included in -Wall ✨

• -Wstack-usage=byte-size — warns if a function's stack usage might exceed byte-size 📚 This calculation is conservative, and any space allocated via "alloca", variable-length arrays, or related constructs is counted when the compiler decides whether to warn. The message matches the output of -fstack-usage:
  • If the stack usage is fully static but goes over the limit, you'll see: warning: stack usage is 1120 bytes
  • If the stack usage is (partly) dynamic but bounded, you'll see: warning: stack usage might be 1648 bytes
  • If the stack usage is (partly) dynamic and unbounded, you'll see: warning: stack usage might be unbounded

-Wstack-usage=PTRDIFF_MAX is on by default. Disable these warnings by specifying a byte-size of SIZE_MAX or more, or with -Wno-stack-usage 🎀

• -Wno-stack-usage — disables the -Wstack-usage= warnings. It's equivalent to -Wstack-usage=SIZE_MAX or larger 🌈
• -Wunsafe-loop-optimizations — warns if a loop can't be optimized because the compiler can't assume anything about the bounds of the loop indices 🤔 With -funsafe-loop-optimizations, it warns if the compiler does make those assumptions.
• -Wno-pedantic-ms-format (MinGW targets only) — when used with -Wformat and -pedantic without GNU extensions, this turns off the warnings about non-ISO "printf" and "scanf" width specifiers "I32", "I64", and "I" that get used on Windows targets, since those depend on the MS runtime 🪟
• -Wpointer-arith — warns about anything that depends on the "size of" a function type or of "void". GNU C gives these types a size of 1, for convenience when doing math with "void *" pointers and function pointers 🧮 In C++, it also warns when an arithmetic operation involves "NULL". This warning is also enabled by -Wpedantic.

This warning gets upgraded to an error by -pedantic-errors 🚨

• -Wno-pointer-compare — doesn't warn when a pointer gets compared with a zero character constant. That usually means the pointer was meant to be dereferenced 👀 For example:

const char *p = foo ();
if (p == '\0')
  return 42;

The code above is invalid in C++11 ❌

This warning is enabled by default 💖

• -Wno-tsan — disables warnings about unsupported features in ThreadSanitizer 🧵 ThreadSanitizer doesn't support "std::atomic_thread_fence" and can report false positives, so this helps you tune out that noise 🫠
• -Wtype-limits — warns if a comparison is always true or always false because of the limited range of the data type, but doesn't warn for constant expressions 📏 For example, it warns if an unsigned variable is compared against zero with "<" or ">=". This warning is also enabled by -Wextra.
• -Wabsolute-value (C and Objective-C only) — warns about calls to standard functions that compute the absolute value of an argument when a more appropriate standard function exists 🙃 For example, calling abs(3.14) triggers the warning, because the right function for a double is "fabs". It also triggers when the argument in such a call has an unsigned type. You can suppress it with an explicit type cast, and it's also enabled by -Wextra 🍒
• -Wcomment, -Wcomments — warns whenever a comment-start sequence /* shows up inside a /* comment, or whenever a backslash-newline shows up in a // comment 💬 This warning is enabled by -Wall.
• -Wtrigraphs — warns if any trigraphs are encountered that might change the meaning of the program 🧐 Trigraphs inside comments aren't warned about, except for the ones that would form escaped newlines.

This one's implied by -Wall 💅 If -Wall isn't on, it's still enabled unless trigraphs are turned on. Want trigraph conversion without the warnings but still all the other -Wall goodies? Use -trigraphs -Wall -Wno-trigraphs 🫶

• -Wundef — okay so this one warns if an undefined identifier gets evaluated in an #if directive 🙈 Those identifiers get replaced with zero, so you're not getting a surprise error, just a heads-up ✨
• -Wexpansion-to-defined — this warns whenever defined shows up in the expansion of a macro, including when the macro gets expanded by an #if directive 💀 That usage is not portable, so you'll want to know about it. It's also turned on by -Wpedantic and -Wextra 🔥
• -Wunused-macros — this one flags macros defined in the main file that nobody's using 👀 A macro counts as used if it gets expanded or tested for existence at least once. The preprocessor will also side-eye you if the macro hasn't been used by the time it's redefined or undefined 💅

Built-in macros, macros defined on the command line, and macros defined in include files are not warned about, so don't stress those 💖

Heads up: if a macro is used, but only inside skipped conditional blocks, the preprocessor still reports it as unused 😭 To dodge the warning, you could improve the scope of the macro's definition, like moving it into the first skipped block. Or you could give it a dummy use with something like:

#if defined the_macro_causing_the_warning
#endif

• -Wno-endif-labels — this stops the warning when an #else or an #endif has text after it 🎀 That happens sometimes in older programs with code like this:

#if FOO
...
#else FOO
...
#endif FOO

The second and third FOO should really be in comments, bestie. This warning is on by default ✨

• -Wbad-function-cast (C and Objective-C only) — warns when a function call gets cast to a non-matching type 🌸 For example, it'll warn if a call to a function returning an integer type gets cast to a pointer type.
• -Wc90-c99-compat (C and Objective-C only) — this one warns about features that exist in ISO C99 but not in ISO C90 🦋 Think variable length arrays, the long long type, the bool type, compound literals, designated initializers, and so on. It doesn't care about your standards mode, and warnings are disabled in the expression that follows __extension__ 🙈
• -Wc99-c11-compat (C and Objective-C only) — same energy, but for features in ISO C11 that aren't in ISO C99 🧚 Like anonymous structures and unions, the _Atomic type qualifier, the _Thread_local storage-class specifier, the _Alignas specifier, the Alignof operator, the _Generic keyword, and so on. Independent of the standards mode, and warnings are disabled in the expression after __extension__ 💜
• -Wc11-c23-compat, -Wc11-c2x-compat (C and Objective-C only) — warns about features in ISO C23 that aren't in ISO C11 🌈 Think omitting the string in _Static_assert, using [[]] attribute syntax, decimal floating-point types, and so on. It's independent of the standards mode, and warnings are disabled in the expression after __extension__. Also, the name -Wc11-c2x-compat is deprecated, so use the newer one 🫠

When you're not compiling in C23 mode, these warnings get upgraded to errors by -pedantic-errors 😤

• -Wc23-c2y-compat (C and Objective-C only) — warns about features in ISO C2Y that aren't in ISO C23 ✨ For instance, _Generic selecting with a type name instead of an expression. Also independent of the standards mode, with warnings disabled in the expression that follows __extension__.
• -Wc23-c2y-compat (C and Objective-C only) — yep, this one's listed twice in the original page, so here it is again 🙈 Same vibe: features in ISO C2Y, not in ISO C23, with the same __extension__ rule.

When you're not compiling in C2Y mode, these warnings get upgraded to errors by -pedantic-errors 💅

• -Wc++-compat (C and Objective-C only) — warns about ISO C constructs that sit outside the common subset of ISO C and ISO C++ 🍓 Like implicitly converting from void * to a pointer to non-void type.
• -Wc++11-compat (C++ and Objective-C++ only) — warns about C++ constructs whose meaning changes between ISO C++ 1998 and ISO C++ 2011 👑 For example, identifiers in ISO C++ 1998 that are keywords in ISO C++ 2011. This one turns on -Wnarrowing and is enabled by -Wall.
• -Wc++14-compat (C++ and Objective-C++ only) — warns about C++ constructs whose meaning differs between ISO C++ 2011 and ISO C++ 2014 💖 Enabled by -Wall.
• -Wc++17-compat (C++ and Objective-C++ only) — same idea for ISO C++ 2014 vs ISO C++ 2017 ⭐ Enabled by -Wall.
• -Wc++20-compat (C++ and Objective-C++ only) — and this one covers ISO C++ 2017 vs ISO C++ 2020 🦋 Enabled by -Wall.
• -Wno-c++11-extensions (C++ and Objective-C++ only) — don't warn about C++11 constructs when you're compiling with an older C++ standard 🌸 Even without this option, some C++11 constructs only get flagged if -Wpedantic is used.
• -Wno-c++14-extensions (C++ and Objective-C++ only) — same deal, but for C++14 constructs 🧚 Some of them only get diagnosed with -Wpedantic.
• -Wno-c++17-extensions (C++ and Objective-C++ only) — you guessed it, C++17 constructs in code compiled with an older standard 💜 Some still only show up under -Wpedantic.
• -Wno-c++20-extensions (C++ and Objective-C++ only) — C++20 constructs, same rules 🌈 Some only get diagnosed when -Wpedantic is used.
• -Wno-c++23-extensions (C++ and Objective-C++ only) — C++23 constructs in code compiled with an older C++ standard ✨ Some only get flagged under -Wpedantic.
• -Wno-c++26-extensions (C++ and Objective-C++ only) — C++26 constructs, same story 🫶 Some still need -Wpedantic to get diagnosed.
• -Wcast-qual — warns whenever a pointer gets cast in a way that removes a type qualifier from the target type 😭 For example, it'll warn if a const char * is cast to an ordinary char *.

It also warns when you make a cast that adds a type qualifier in an unsafe way 💀 Casting char ** to const char ** is unsafe, as in this example:

/* p is char ** value.  */
const char **q = (const char **) p;
/* Assignment of readonly string to const char * is OK.  */
*q = "string";
/* Now char** pointer points to read-only memory.  */
**p = 'b';

• -Wcast-align — warns whenever a pointer is cast so that the required alignment of the target goes up 🎀 For example, it'll warn if a char * is cast to an int * on machines where integers can only be accessed at two- or four-byte boundaries.
• -Wcast-align=strict — same vibe, but stricter 😤 It warns whenever a pointer is cast so the required alignment of the target increases, and it does this for a char * cast to an int * regardless of the target machine.
• -Wcast-function-type — warns when a function pointer is cast to an incompatible function pointer 🔥 For casts involving function types with a variable argument list, only the types of the initial arguments that are provided get considered. Any parameter of pointer type matches any other pointer type. Benign differences in integral types get ignored, like int vs. long on ILP32 targets, and type qualifiers are ignored too. The function type void (*) (void) is special and matches everything, so it can be used to suppress this warning 🙈 For casts involving pointer to member types, this warning fires whenever the cast changes the pointer to member type. Enabled by -Wextra.
• -Wcast-user-defined — warns when a cast to a reference type doesn't involve a user-defined conversion that the programmer might expect to get called 👑 Here's the example:

struct A { operator const int&(); } a;
auto r = (int&)a; // warning

This warning is enabled by default ✨

• -Wwrite-strings — when compiling C, this gives string constants the type const char[length], so copying the address of one into a non-const char * pointer produces a warning 💖 These warnings help you catch, at compile time, code that might try to write into a string constant, but only if you've been super careful about using const in declarations and prototypes. Otherwise, honestly, it's just a nuisance. That's why -Wall doesn't request these warnings 🙄

When compiling C++, it warns about the deprecated conversion from string literals to char *. This warning is enabled by default for C++ programs 🦋

In C++11 mode or later, this warning is upgraded to an error by -pedantic-errors 😭

• -Wclobbered — warns for variables that might be changed by longjmp or vfork 🌸 This warning is also enabled by -Wextra.
• -Wno-complain-wrong-lang — by default, language front ends complain when a command-line option is valid but not applicable to that front end 🧚 You can turn that off with -Wno-complain-wrong-lang, which is mostly useful when you invoke a single compiler driver for multiple source files written in different languages. For example:

$ g++ -fno-rtti a.cc b.f90

The driver g++ invokes the C++ front end to compile a.cc and the Fortran front end to compile b.f90. The latter front end diagnoses f951: Warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for Fortran, which can be disabled with -Wno-complain-wrong-lang 💜

• -Wcompare-distinct-pointer-types (C and Objective-C only) — warns if pointers of distinct types get compared without a cast 🌈 This warning is enabled by default ✨
• -Wconversion — okay so this one is all about sneaky implicit conversions that might quietly change a value 👀 It catches real-to-integer stuff like abs (x) when x is double, signed-to-unsigned stuff like unsigned ui = -1, and squishing things into smaller types like sqrtf (M_PI). It does not warn for explicit casts like abs ((int) x) and ui = (unsigned) -1, or when the value doesn't actually change, like abs (2.0). If the signed/unsigned warnings are too much, you can mute just those with -Wno-sign-conversion 🫶

For C++, it also flags confusing overload resolution for user-defined conversions, plus conversions that never use a type conversion operator (conversions to void, the same type, a base class, or a reference to them) ✨ Heads up though: the signed/unsigned integer warnings are off by default in C++ unless you explicitly turn on -Wsign-conversion 💅

Warnings about conversion from arithmetic on a small type back to that type only show up with -Warith-conversion 🌸

• -Wdangling-else — this one warns when it's unclear which if an else branch actually belongs to 🙈 Check out this chaos:

{
  if (a)
    if (b)
      foo ();
  else
    bar ();
}

In C/C++, every else belongs to the innermost possible if, which here is if (b). That's usually not what the programmer meant, even though the indentation says otherwise. When that confusion is possible, GCC warns if you use this flag 🚨 To kill the warning, slap explicit braces around the innermost if so the else can't possibly belong to the outer one. It ends up looking like this:

{
  if (a)
    {
      if (b)
        foo ();
      else
        bar ();
    }
}

This warning is enabled by -Wparentheses 💖

• -Wdangling-pointer, -Wdangling-pointer=n — okay this is a big one 🦋 It warns about using pointers (or C++ references) to objects with automatic storage duration after their lifetime has ended. That covers local variables declared in nested blocks, compound literals, and other unnamed temporary objects. It also warns about storing the address of those objects in escaped pointers. It's enabled at every optimization level, but the results can look different with optimization than without, so keep that in mind 👀
  • -Wdangling-pointer=1 — at level 1, it only diagnoses unconditional uses of dangling pointers 🌷
  • -Wdangling-pointer=2 — at level 2, it also diagnoses conditional uses of dangling pointers 🌈

The short form -Wdangling-pointer is the same as -Wdangling-pointer=2. Meanwhile, -Wno-dangling-pointer and -Wdangling-pointer=0 both turn the warnings off 💀 And -Wdangling-pointer=2 is already included in -Wall ✨

Here's a level 1 example. The address of the unnamed temporary gets unconditionally used outside of its scope, so it gets flagged:

char f (char c1, char c2, char c3)
{
  char *p;
  {
    p = (char[]) { c1, c2, c3 };
  }
  // warning: using dangling pointer 'p' to an unnamed temporary
  return *p;
}

In this next one, storing the address of the local variable x into the escaped pointer *p triggers the level 1 warning 🧚

void g (int **p)
{
  int x = 7;
  // warning: storing the address of local variable 'x' in '*p'
  *p = &x;
}

And here the array a is out of scope by the time the pointer s gets used. Since the code that sets s is conditional, this one triggers at level 2 🫠

extern void frob (const char *);
void h (char *s)
{
  if (!s)
    {
      char a[12] = "tmpname";
      s = a;
    }
  // warning: dangling pointer 's' to 'a' may be used
  frob (s);
}

• -Wdate-time — this warns whenever the macros __TIME__, __DATE__ or __TIMESTAMP__ show up 🕰️ The reason? They might stop your compilations from being bit-wise-identical and reproducible, which is a whole vibe-killer for builds 😭
• -Wempty-body — warns if an empty body shows up in an if, else or do while statement 🍓 This one is also enabled by -Wextra 💜
• -Wno-endif-labels — stops GCC from complaining about stray tokens after #else and #endif 🎀
• -Wenum-compare — warns about comparing values of different enumerated types 👑 In C++, enumerated type mismatches in conditional expressions get diagnosed too, and that one is enabled by default. In C, this warning comes along with -Wall ✨
• -Wenum-conversion — warns when a value of one enumerated type gets implicitly converted to a different enumerated type 🔥 In C, it's enabled by -Wextra 💅
• -Wenum-int-mismatch (C and Objective-C only) — this one warns about mismatches between an enumerated type and an integer type in declarations 🧐 For example:

enum E { l = -1, z = 0, g = 1 };
int foo(void);
enum E foo(void);

In C, an enumerated type is compatible with char, a signed integer type, or an unsigned integer type. But since the choice of underlying type for an enumerated type is implementation-defined, these mismatches can cause portability issues 🌍 In C++, mismatches like this are an error. In C, this warning is enabled by -Wall and -Wc++-compat 🦋

• -Wjump-misses-init (C, Objective-C only) — warns if a goto or a switch statement jumps forward across the initialization of a variable, or jumps backward to a label after that variable has already been initialized 🙃 It only cares about variables that are initialized when they're declared. This is only supported for C and Objective-C, because in C++ this sort of branch is an error anyway 🚫

In C++, jumping like this is always an error, so there's no need to worry about this warning there.

-Wjump-misses-init is included in -Wc++-compat, and you can disable it with the -Wno-jump-misses-init option 🫶

• -Wsign-compare — warns when a comparison between signed and unsigned values could give a wrong result because the signed value gets converted to unsigned ⚠️ In C++, this is also enabled by -Wall. In C, it's enabled by -Wextra too 💖
• -Wsign-conversion — warns about implicit conversions that might change the sign of an integer value, like assigning a signed integer expression to an unsigned integer variable 🌸 An explicit cast silences the warning ✨ In C, this option is also enabled by -Wconversion 🎀
• -Wflex-array-member-not-at-end (C and C++ only) — warns when a structure that has a C99 flexible array member as its last field ends up not at the end of another structure 🧩 This warning goes off for code like this:

struct flex  { int length; char data[]; };
struct mid_flex { int m; struct flex flex_data; int n; };

• -Wfloat-conversion — warns about implicit conversions that reduce the precision of a real value 🌊 That includes real-to-integer conversions, and conversions from higher precision real values to lower precision ones. This option is also enabled by -Wconversion 🦄
• -Wno-scalar-storage-order — stops GCC from warning about suspicious constructs involving reverse scalar storage order 🙈
• -Wsizeof-array-div — warns about dividing two sizeof operators when the first one is applied to an array and the divisor doesn't match the size of the array element 🧮 In that case, the math won't give you the number of elements in the array, which is probably not what you wanted. This warning goes off for code like this:

int fn ()
{
  int arr[10];
  return sizeof (arr) / sizeof (short);
}

This warning is enabled by -Wall 💅

• -Wsizeof-pointer-div — warns about suspicious divisions of two sizeof expressions that divide the pointer size by the element size. That's the usual trick for computing an array's size, but it won't work with pointers 💀 The warning goes off for sizeof (ptr) / sizeof (ptr[0]) if ptr is a pointer and not an array. It's enabled by -Wall ✨
• -Wsizeof-pointer-memaccess — warns about suspicious length parameters passed to certain string and memory built-in functions when the argument uses sizeof 🧠 For example, it triggers on memset (ptr, 0, sizeof (ptr)); if ptr is a pointer and not an array, and it suggests a possible fix. It also triggers on things like memcpy (&foo, ptr, sizeof (&foo)); 🎀

This option also warns about calls to bounded string copy functions like strncat or strncpy that use the sizeof of the source array as the bound. In the following function, the strncat call uses the size of the source string as its bound. That's almost certainly a mistake, so the call gets diagnosed 🙅‍♀️

void make_file (const char *name)
{
  char path[PATH_MAX];
  strncpy (path, name, sizeof path - 1);
  strncat (path, ".text", sizeof ".text");
  ...
}

-Wsizeof-pointer-memaccess is enabled by -Wall 👑

• -Wno-sizeof-array-argument — stops GCC from warning when the sizeof operator is applied to a parameter that's declared as an array in a function definition 🌈 This warning is enabled by default for C and C++ programs, so this flag is how you turn it off 🫠
• -Wmemset-elt-size — warns about suspicious calls to the memset built-in function. It triggers when the first argument references an array, and the third argument is a number equal to the number of elements but not equal to the size of the array in memory. That usually means you forgot to multiply by the element size 🍓 This warning is enabled by -Wall 🫶

✨ OPTIONS ✨ (continued)

• -Wmemset-transposed-args — okay so this one yells at you 🙈 when you call the memset built-in with a non-zero second argument and a literal zero as the third. memset (buf, sizeof buf, 0) gets flagged because you probably meant memset (buf, 0, sizeof buf) 💅. It only fires when the third argument is a literal zero. If it's an expression that folds to zero, or a cast of zero to some type, the args are way less likely to be mixed up, so it stays quiet. This one is turned on by -Wall 🫶.
• -Waddress — this is the suspicious-address-expression check and it is giving detective 🕵️‍♀️. It catches comparing the address of a function or declared object against the null pointer constant, like this:

void f (void);
void g (void)
{
  if (!f)   // warning: expression evaluates to false
    abort ();
}

It also side-eyes comparing a pointer to a string literal:

void f (const char *x)
{
  if (x == "abc")   // warning: expression evaluates to false
    puts ("equal");
}

And it flags testing the result of pointer addition or subtraction for equality to null:

void f (const int *p, int i)
{
  return p + i == NULL;
}

Real talk, these usually mean a programmer error 😭. The address of most functions and objects always evaluates to true (the exceptions are weak symbols), so putting them in a conditional might mean you're missing parentheses in a function call or a dereference in an array expression. The object-pointer part of the warning can be shushed by casting the pointer operand to an integer type like intptr_t or uintptr_t. Comparisons against string literals give unspecified behavior and aren't portable, and they hint that you meant to call strcmp 🙄. The warning gets suppressed if the sus expression came out of a macro expansion. The -Waddress warning is enabled by -Wall ✨.

• -Wno-address-of-packed-member — the "don't warn me" option 🦋. Skip the warning when the address of a packed member of a struct or union is taken, which usually ends up as an unaligned pointer value. This is enabled by default 💜.
• -Wlogical-op — warns about sus logical operators in expressions 👀. That includes using a logical operator where a bit-wise operator is probably what you wanted. It also flags when both operands of a logical operator are the same, like this:

extern int a;
if (a < 0 && a < 0) { ... }

• -Wlogical-not-parentheses — this one is looking for a logical not on the left hand side of a comparison 🧐. It doesn't warn if the right operand is considered a boolean expression. The whole point is catching code like this:

int a;
...
if (!a > 1) { ... }

You can shut the warning up by wrapping the LHS in parentheses:

if ((!a) > 1) { ... }

This warning is enabled by -Wall 🌸.

• -Waggregate-return — warns if any function that returns a structure or union gets defined or called 📦. In languages where you can return an array, this also gives you a warning, so keep an eye out.
• -Wno-aggressive-loop-optimizations — the "chill, don't warn me" option 😌. Skip the warning when the compiler detects undefined behavior in a loop with a constant number of iterations. -Waggressive-loop-optimizations is enabled by default 🍓.
• -Wno-attributes — silences warnings when you use an unexpected __attribute__, like unrecognized attributes or function attributes slapped on variables 🎀. It doesn't stop errors for using supported attributes wrong, though, so don't get too comfy.

Heads up: ill-formed uses of standard attributes get upgraded to errors by -pedantic-errors.

Also, with -Wno-attributes=, you can suppress warnings about unknown scoped attributes (in C++11 and C23) 🧚. For example, -Wno-attributes=vendor::attr disables the warning about this declaration:

[[vendor::attr]] void f();

You can also hush warnings about all attributes in a namespace with -Wno-attributes=vendor::, which stops the warning about both of these:

[[vendor::safe]] void f();
[[vendor::unsafe]] void f2();

Note that -Wno-attributes= does not imply -Wno-attributes ⚠️.

• -Wno-builtin-declaration-mismatch — the "I know what I'm doing" option 💅. This warns when a built-in function is declared with an incompatible signature or as a non-function, or when a built-in declared with a type that doesn't include a prototype gets called with args whose promoted types don't match what the function expects. With -Wextra, it also warns when a built-in that takes arguments is declared without a prototype. The -Wbuiltin-declaration-mismatch warning is enabled by default. To avoid it, include the right header so the built-in prototypes are in scope 🫶.

Like here, the call to memset gets diagnosed because the function expects a size_t as its argument but 32 is an int. With -Wextra, the declaration gets called out too 👀:

extern void* memset ();
void f (void *d)
{
  memset (d, '\0', 32);
}

• -Wno-builtin-macro-redefined — no more warnings when certain built-in macros get redefined 🌈. This suppresses warnings for redefining __TIMESTAMP__, __TIME__, __DATE__, __FILE__, and __BASE_FILE__ ⏰.
• -Wfree-labels (C and Objective-C only) — warns if a label is slapped on a non-statement, or shows up at the end of a compound statement 🏷️. C23 and later dialects of C allow these, and they're a GCC extension in all other dialects.

This warning is also turned on by -Wc11-c23-compat. It becomes an error if you're building for a C version before C23 with -pedantic-errors 🚫.

• -Wheader-guard — this one is a total detective for header guards 🔍. It warns when a valid preprocessor header multiple-inclusion guard has a #define right after the #ifndef or #if !defined directive, where that #define defines a different macro from the guard with a similar name. The real guard macro isn't defined at the matching #ifndef at the end of the header, and the #define makes an object-like macro with an empty definition. Usually that means it's just a misspelled guard name, either in the #ifndef or #if !defined directive or in the #define after it 📝. This warning is enabled by -Wall ✨.
• -Wstrict-prototypes (C and Objective-C only) — warns if a function is declared or defined without specifying its argument types 📜. An old-style function definition is allowed without a warning if a declaration that specifies the argument types came before it.
• -Wold-style-declaration (C and Objective-C only) — warns about obsolescent declaration usages, according to the C Standard 🦕. For example, it warns if storage-class specifiers like static aren't the first things in a declaration. This warning is also enabled by -Wextra 💖.
• -Wold-style-definition (C and Objective-C only) — warns if an old-style function definition is used 👵. You get the warning even if there's a previous prototype. In C23 mode, a definition using () is not considered old-style, because it's equivalent to (void) in that case. For older standards, though, it counts as an old-style definition.
• -Wdeprecated-non-prototype (C and Objective-C only) — warns if a function declared with an empty parameter list () gets called with one or more arguments, or if a function definition with one or more parameters shows up after such a declaration 🚨. Both cases are errors in C23 and later dialects of C.

This warning is also turned on by -Wc11-c23-compat 💅.

• -Wmissing-parameter-name (C and Objective-C only) — warns if a function definition leaves out a parameter name and only gives its type 🏷️. This is handy for documenting that a parameter is unused in the definition. It's part of C23 and later dialects of C, and available as a GCC extension in all other dialects.

This warning is also turned on by -Wc11-c23-compat. It becomes an error if you're building for a C version before C23 with -pedantic-errors 🚫.

• -Wmissing-parameter-type (C and Objective-C only) — warns when a function parameter gets declared without a type specifier in K&R-style functions 🕰️:

void foo(bar) { }

This warning is also enabled by -Wextra 🌸.

• -Wno-declaration-missing-parameter-type (C and Objective-C only) — stops the warning when a function declaration has a parameter name with no type 🙅‍♀️. Those declarations don't give you a function prototype, and they block most type checking in function calls.

This warning is enabled by default. In C99 and later dialects of C, it's treated as an error 😱. You can downgrade that error to a warning with -fpermissive (along with certain other errors), or for this error alone, with -Wno-error=declaration-missing-parameter-type.

This warning is upgraded to an error by -pedantic-errors 🚫.

• -Wmissing-prototypes (C and Objective-C only) — warns if a global function gets defined without a previous prototype declaration 🔎. You get the warning even if the definition itself provides a prototype. Use this to catch global functions that don't have a matching prototype declaration in a header file 📂. This option isn't valid for C++, because all function declarations there provide prototypes, and a non-matching declaration declares an overload rather than conflicting with an earlier one. Use -Wmissing-declarations to find missing declarations in C++ 💜.
• -Wmissing-variable-declarations (C and Objective-C only) — warns if a global variable gets defined without a previous declaration 🧾. Use this to catch global variables that don't have a matching extern declaration in a header file ✨.

Okay so we're still deep in the OPTIONS drama 💅 and this batch is packed with warnings, bestie 🫶

• -Wmissing-declarations — okay, this one's a vibe check on global functions 🔍. It warns if a global function gets defined without a previous declaration, even if the definition already comes with a prototype. Use it to catch global functions that never got declared in header files. In C, nothing gets flagged for functions with earlier non-prototype declarations, so reach for -Wmissing-prototypes if you want to catch missing prototypes. In C++, it skips function templates, inline functions, and functions in anonymous namespaces ✨
• -Wmissing-field-initializers — this one is SO relatable 😭. It warns when a struct's initializer leaves some fields out. Like, here x.h just quietly becomes zero:

struct s { int f, g, h; };
struct s x = { 3, 4 };

In C, this option doesn't yell about designated initializers, so this one's totally fine 🦋:

struct s { int f, g, h; };
struct s x = { .f = 3, .g = 4 };

In C it also doesn't warn about the universal zero initializer { 0 } 🌸:

struct s { int f, g, h; };
struct s x = { 0 };

Same deal in C++ with the empty { } initializer, no warning 💖:

struct s { int f, g, h; };
s x = { };

This one is part of -Wextra. If you want the other -Wextra warnings without this one, go with -Wextra -Wno-missing-field-initializers 🎀

• -Wno-missing-requires — the compiler warns about a concept-id showing up as a C++20 simple-requirement by default 🧚. Check this out:

bool satisfied = requires { C<T> };

Here satisfied will be true if C<T> is a valid expression, which it is for all T. The person probably meant this instead:

bool satisfied = requires { requires C<T> };

That way satisfied is only true if concept C is satisfied for type T. You can switch this warning off with -Wno-missing-requires 🙈

• -Wno-missing-template-keyword — the member access tokens ., -> and :: need the "template" keyword 👑 if the parent object is dependent and the member you're naming is a template. Look at the good and the not-so-good:

template <class X>
void DoStuff (X x)
{
  x.template DoSomeOtherStuff<X>(); // Good.
  x.DoMoreStuff<X>(); // Warning, x is dependent.
}

Every once in a while you can get false positives. To silence them, wrap the expression in parentheses. Like, this one gets treated as a template even when m and N are integers 🥴:

void NotATemplate (my_class t)
{
  int N = 5;

  bool test = t.m < N > (0); // Treated as a template.
  test = (t.m < N) > (0); // Same meaning, but not treated as a template.
}

You can disable this warning with -Wno-missing-template-keyword 💜

• -Wno-multichar — don't warn about multicharacter constants like 'FOOF' 🍓. Usually these are a typo in your code, since they have implementation-defined values, so they really shouldn't show up in portable code.
• -Wnormalized=[none|id|nfc|nfkc] — this is the identifier normalization era 🌈. In ISO C and ISO C++, two identifiers are different if they're different character sequences. BUT with characters outside basic ASCII you can get two different sequences that look exactly the same 😵. ISO 10646 has normalization rules that turn lookalikes into one shared sequence, and GCC can warn you when your identifiers haven't been normalized. This option controls that warning.

There are four warning levels. The default is -Wnormalized=nfc, which warns about any identifier that isn't in the ISO 10646 "C" normalized form, NFC. NFC is the one recommended for most uses, and it's the same as -Wnormalized.

Some characters that ISO C and ISO C++ let you use in identifiers can't be used once they're turned into NFC. So there's no way to use those symbols in portable ISO C or C++ and keep all your identifiers in NFC 🫠. -Wnormalized=id suppresses the warning for those characters. The hope is that future versions of the standards fix this, which is why it isn't the default.

You can switch the warning off for every character with -Wnormalized=none or -Wno-normalized. Only do this if you're using some other normalization scheme (like "D"), because otherwise you can easily create bugs that are literally impossible to see 💀

Some ISO 10646 characters have distinct meanings but look identical in some fonts or display methods, especially once formatting is applied. For example, "\u207F", "SUPERSCRIPT LATIN SMALL LETTER N", looks just like a regular "n" that's been placed in a superscript 👀. ISO 10646 also defines the NFKC normalization scheme to turn all of these into a standard form, and GCC warns you if your code isn't NFKC when you use -Wnormalized=nfkc. This is kind of like warning about every identifier with the letter O, since it might get mixed up with the digit 0. That's why it isn't the default, but it can be a handy local coding convention if your environment can't be fixed to display these characters differently ✨

• -Wno-attribute-warning — don't warn about using functions declared with the "warning" attribute 🦋. This warning is on by default. You can turn the warning off with -Wno-attribute-warning, or use -Wno-error=attribute-warning to turn off the error you'd get when compiling with -Werror 🎀
• -Wno-deprecated — don't warn about deprecated features 🌸. Heads up though: in C++, explicitly specifying -Wdeprecated also turns on warnings about features that are deprecated in later language standards. Those are -Wcomma-subscript, -Wvolatile, -Wdeprecated-enum-float-conversion, -Wdeprecated-enum-enum-conversion, -Wdeprecated-literal-operator, and -Wdeprecated-variadic-comma-omission 🥹
• -Wno-deprecated-declarations — don't warn about uses of functions, variables, and types marked as deprecated with the "deprecated" attribute 🙃
• -Wno-overflow — don't warn about compile-time overflow in constant expressions 🔢
• -Wno-odr — warn about One Definition Rule violations during link-time optimization ⚖️. It's enabled by default, so you'd have to actively turn it off to lose it.
• -Wopenacc-parallelism — warn about potentially suboptimal choices related to OpenACC parallelism 🚀
• -Wno-openmp — warn about suspicious OpenMP code 🧐
• -Wopenmp-simd — warn if the vectorizer cost model overrides the OpenMP simd directive that the user set 🫣. If you want to relax the cost model, you can use -fsimd-cost-model=unlimited 💜
• -Woverride-init (C and Objective-C only) — warn if an initialized field without side effects gets overridden when you're using designated initializers 🍑. This one is part of -Wextra. To get the other -Wextra warnings without it, use -Wextra -Wno-override-init 💅
• -Wno-override-init-side-effects (C and Objective-C only) — don't warn if an initialized field with side effects gets overridden when using designated initializers. This is enabled by default 🌈
• -Wpacked — warn if a structure gets the packed attribute but that attribute has no effect on the layout or size of the structure 😤. Structures like that can end up misaligned for basically zero benefit. In this code, the variable f.x inside struct bar is misaligned even though struct bar doesn't have the packed attribute itself 🙈:

struct foo {
  int x;
  char a, b, c, d;
} __attribute__((packed));
struct bar {
  char z;
  struct foo f;
};

• -Wnopacked-bitfield-compat — the 4.1, 4.2 and 4.3 series of GCC ignored the packed attribute on bit-fields of type char 🕰️. That got fixed in GCC 4.4, but the change can cause differences in structure layout. GCC tells you when the offset of such a field has changed in GCC 4.4. For example, there's no longer a 4-bit padding between fields a and b in this structure ✨:

struct foo
{
  char a:4;
  char b:8;
} __attribute__ ((packed));

This warning is enabled by default. To disable it, use -Wno-packed-bitfield-compat 💖

• -Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only) — warn if a structure field with explicitly specified alignment in a packed struct or union is misaligned 🧩. For example, this code gets a warning on struct S, like: "warning: alignment 1 of 'struct S' is less than 8" 😬

struct __attribute__ ((aligned (8))) S8 { char a[8]; };
struct __attribute__ ((packed)) S {
  struct S8 s8;
};

This warning is enabled by -Wall 🎀

• -Wpadded — warn if padding is included in a structure, either to align one of its elements or to align the whole structure 🫧. Sometimes you can rearrange the fields to reduce the padding and make the structure smaller 🍓
• -Wredundant-decls — warn if anything gets declared more than once in the same scope, even when multiple declarations are valid and change nothing 🔁
• -Wrestrict — this one catches sneaky aliasing 🕵️‍♀️. It warns when an object referenced by a "restrict"-qualified parameter (or, in C++, a "__restrict"-qualified parameter) is aliased by another argument, or when copies between those objects overlap. In the strcpy call below, the code tries to truncate the string by overwriting its start with its last four characters. But because the call writes the terminating NUL into a[4], the copies overlap and the call gets diagnosed 😭:

void foo (void)
{
  char a[] = "abcd1234";
  strcpy (a, a + 4);
  ...
}

-Wrestrict catches some instances of simple overlap even without optimization, but it works best at -O2 and above. It's included in -Wall 👑

• -Wnested-externs (C and Objective-C only) — warn if an "extern" declaration shows up inside a function 🙅‍♀️
• -Winline — 🦋 okay so this one yells if a function you marked inline can't actually get inlined 😭 Even with it on, GCC stays quiet about functions living in system headers, so no drama there. The compiler is basically running a vibe check on its own heuristics: the size of the function and how much inlining already happened in the current function both factor in. That means tiny edits to your source can make these warnings pop up or vanish, so don't panic if it changes randomly 🙈
• -Winterference-size — ✨ this one warns about using C++17's std::hardware_destructive_interference_size without setting its value via --param destructive-interference-size. It also side-eyes any questionable values you pass for that option 👀

This variable is built for controlling class layout so concurrent code doesn't suffer from false sharing 🧚 Check out this serve:

struct independent_fields {
  alignas(std::hardware_destructive_interference_size)
    std::atomic<int> one;
  alignas(std::hardware_destructive_interference_size)
    std::atomic<int> two;
};

The whole point is that one and two sit far enough apart that writing to one won't force a reload of the cache line holding two 💅

By default, --param destructive-interference-size and --param constructive-interference-size get set based on the current -mtune option. Usually that lands on the L1 cache line size for the target CPU, though for a generic target it can be a range instead 🌸 So every translation unit that relies on ABI compatibility for these variables needs to be compiled with the same -mtune (or -mcpu), or things get messy fr fr.

If ABI stability matters, like when you're using it in a header for a library, you should probably skip the hardware interference size variables entirely 🫶 Or, if you want, you can force a specific value with --param. And if you're totally sure your use doesn't touch ABI outside one build of your project, you can silence the warning with -Wno-interference-size 🔥

• -Wint-in-bool-context — 🎀 this one flags sus integer values showing up where booleans are expected. Think conditional expressions (?:) using non-boolean integer constants in a boolean context, like if (a <= b ? 2 : 3). It also catches left shifting signed integers in a boolean context, like for (a = 0; 1 << a; a++);. And it's the same deal for all kinds of multiplications, no matter the data type 🙃 This warning is enabled by -Wall, so you're covered if you're already using that 💖
• -Wno-int-to-pointer-cast — 🍓 suppresses warnings about casts to a pointer type from an integer of a different size. Quick heads up though: in C++, casting to a pointer type of smaller size is an error 💀 Wint-to-pointer-cast is turned on by default.
• -Wno-pointer-to-int-cast (C and Objective-C only) — 🌈 same energy but flipped. This one silences warnings about casts from a pointer to an integer type of a different size.
• -Winvalid-pch — 🧚 warns if a precompiled header shows up in the search path but can't actually be used. Rude, but useful 😭
• -Winvalid-utf8 — 💜 warns when an invalid UTF-8 character shows up. It's on by default for C++23 as long as -finput-charset=UTF-8 is in use, and it becomes a full-on error with -pedantic-errors 🚫
• -Wno-unicode — 🌸 stops GCC from diagnosing invalid forms of delimited or named escape sequences that get treated as separate tokens. Wunicode is enabled by default, so this is the opt-out 🙈
• -Wlong-long — ⭐ warns if the long long type gets used. It's enabled by either -Wpedantic or -Wtraditional in ISO C90 and C++98 modes. Want those warnings gone? Use -Wno-long-long 🫶

🚨 This warning gets upgraded to an error by -pedantic-errors, so be careful with that combo!

• -Wvariadic-macros — 🦋 warns if variadic macros are used in ISO C90 mode, or if the GNU alternate syntax is used in ISO C99 mode. It's enabled by either -Wpedantic or -Wtraditional. To shush the messages, use -Wno-variadic-macros ✨
• -Wno-varargs — 💅 tells GCC to chill about questionable usage of the macros that handle variable arguments, like va_start. These warnings are on by default, so this is how you turn them off 🌈
• -Wvector-operation-performance — 🔥 warns if a vector operation isn't implemented using the architecture's SIMD capabilities. It's mainly handy for performance tuning. Here's the lineup: a vector operation can be done "piecewise", meaning the scalar operation runs on every vector element; "in parallel", meaning it's implemented using scalars of a wider type, which is usually more performance efficient; or "as a single scalar", meaning the vector fits into a scalar type 💖
• -Wvla — 🎀 warns if a variable-length array is used anywhere in the code. -Wno-vla stops the -Wpedantic warning about variable-length arrays 🙃

🚨 This warning gets upgraded to an error by -pedantic-errors. Don't say I didn't warn you 💀

• -Wvla-larger-than=byte-size — 👑 when this is used, the compiler warns about declarations of variable-length arrays whose size is either unbounded, or bounded by an argument that lets the array size go past byte-size bytes. It's basically the VLA cousin of how -Walloca-larger-than=byte-size works 🧚

Heads up: GCC might optimize small variable-length arrays with a known value into plain arrays, so this warning might not fire for those 🌸

-Wvla-larger-than=PTRDIFF_MAX is enabled by default, but it's typically only effective when -ftree-vrp is active, which is the default for -O2 and above ✨

See also -Walloca-larger-than=byte-size.

• -Wno-vla-larger-than — 🙈 disables the -Wvla-larger-than= warnings. It's the same as -Wvla-larger-than=SIZE_MAX or larger 🫶
• -Wvla-parameter — 🔮 warns about redeclarations of functions involving arguments of Variable Length Array types with inconsistent kinds or forms. It also enables detecting out-of-bounds accesses to those parameters through warnings like -Warray-bounds 🦋

If the first function declaration uses the VLA form, the bound in the array is assumed to be the minimum number of elements expected in calls to the function, and also the maximum number of elements it accesses. Not passing arguments of sufficient size, or accessing more than that maximum, may get diagnosed 💀

For example, the warning triggers for these redeclarations, because the first one lets an array of any size get passed to f while the second one says the array argument must have at least n elements. Plus, calling f with the associated VLA bound parameter bigger than the actual VLA bound triggers a warning too 😭

void f (int n, int[n]);
// warning: argument 2 previously declared as a VLA
void f (int, int[]);

void g (int n)
{
    if (n > 4)
      return;
    int a[n];
    // warning: access to a by f may be out of bounds
    f (sizeof a, a);
  ...
}

-Wvla-parameter is included in -Wall. The -Warray-parameter option triggers warnings for similar problems involving ordinary array arguments 💜

• -Wvolatile-register-var — 💅 warns if a register variable is declared volatile. Here's the tea: the volatile modifier doesn't stop every optimization that might eliminate reads and/or writes to register variables. This warning is enabled by -Wall 🌈
• -Wno-xor-used-as-pow (C, C++, Objective-C and Objective-C++ only) — ✨ disables warnings about uses of ^, the exclusive or operator, when it looks like the code meant exponentiation. Specifically, the warning pops up when the left-hand side is the decimal constant 2 or 10 and the right-hand side is also a decimal constant 🙃

In C and C++, ^ means exclusive or, but in some other languages (like TeX and some versions of BASIC) it means exponentiation 🧚

This warning can be silenced by converting one of the operands to hexadecimal, and also by compiling with -Wno-xor-used-as-pow 🫶

• -Wdisabled-optimization — 🍓 warns if a requested optimization pass is disabled. Don't panic, though: this doesn't usually mean your code is wrong. It just means GCC's optimizers can't handle the code effectively 🥺 Often the problem is that your code is too big or too complex, and GCC refuses to optimize programs when the optimization itself would likely take an inordinate amount of time 💀
• -Wpointer-sign (C and Objective-C only) — 💖 warns for pointer argument passing or assignment with different signedness. It's only supported for C and Objective-C. It's implied by -Wall and by -Wpedantic, and you can disable it with -Wno-pointer-sign 🌸

This warning gets upgraded to an error by -pedantic-errors 🚫

• -Wstack-protector — 🛡️ this one's only active when -fstack-protector is active. It warns about functions that aren't protected against stack smashing 😭
• -Woverlength-strings — 🎀 warns about string constants longer than the "minimum maximum" length the C standard specifies. Modern compilers are generally fine with string constants way longer than that minimum, but very portable programs should steer clear of longer strings 🌈

The limit applies after string constant concatenation, and it doesn't count the trailing NUL. In C90 the limit was 509 characters, and in C99 it got raised to 4095. C++98 doesn't specify a normative minimum maximum, so GCC doesn't diagnose overlength strings in C++ 🙈

This option is implied by -Wpedantic, and you can disable it with -Wno-overlength-strings ✨

• -Wunsuffixed-float-constants (C and Objective-C only) — 🦋 issues a warning for any floating constant that doesn't have a suffix. When it's used together with -Wsystem-headers, it warns about those constants in system header files too 👀 This can be really handy when you're getting code ready to use with the "FLOAT_CONST_DECIMAL64" pragma from the decimal floating-point extension to C99 💜
• -Wno-lto-type-mismatch — 🔥 during link-time optimization, this stops GCC from warning about type mismatches in global declarations coming from different compilation units. It requires -flto to be enabled, and it's enabled by default 🫶
• -Wno-designated-init (C and Objective-C only) — 👑 suppresses warnings when a positional initializer is used to initialize a structure that's been marked with the "designated_init" attribute 💅

✨ Options That Control Static Analysis ✨

-fanalyzer 🔍

okay so this one turns on a static analysis of program flow that hunts for "interesting" interprocedural paths through your code and yells at you about problems it finds along them 📣 no cap, it's a whole vibe

heads up though, this analysis is way more expensive than your regular GCC warnings 💀

technically speaking, it does coverage-guided symbolic execution of the code being compiled 🧚 it is neither sound nor complete, so it can throw false positives and false negatives 🙈 it's a bug-finding tool, not a tool for proving your program correct, so don't go using it as your proof 🫶

the analyzer is only suitable for C code in this release 💜

enabling this option effectively turns on the following warnings 👑

-Wanalyzer-allocation-size -Wanalyzer-deref-before-check
-Wanalyzer-double-fclose -Wanalyzer-double-free
-Wanalyzer-exposure-through-output-file
-Wanalyzer-exposure-through-uninit-copy
-Wanalyzer-fd-access-mode-mismatch -Wanalyzer-fd-double-close
-Wanalyzer-fd-leak -Wanalyzer-fd-phase-mismatch
-Wanalyzer-fd-type-mismatch -Wanalyzer-fd-use-after-close
-Wanalyzer-fd-use-without-check -Wanalyzer-file-leak
-Wanalyzer-free-of-non-heap -Wanalyzer-imprecise-fp-arithmetic
-Wanalyzer-infinite-loop -Wanalyzer-infinite-recursion
-Wanalyzer-jump-through-null -Wanalyzer-malloc-leak
-Wanalyzer-mismatching-deallocation -Wanalyzer-null-argument
-Wanalyzer-null-dereference -Wanalyzer-out-of-bounds
-Wanalyzer-overlapping-buffers -Wanalyzer-possible-null-argument
-Wanalyzer-possible-null-dereference -Wanalyzer-putenv-of-auto-var
-Wanalyzer-shift-count-negative -Wanalyzer-shift-count-overflow
-Wanalyzer-stale-setjmp-buffer -Wanalyzer-tainted-allocation-size
-Wanalyzer-tainted-array-index -Wanalyzer-tainted-assertion
-Wanalyzer-tainted-divisor -Wanalyzer-tainted-offset
-Wanalyzer-tainted-size -Wanalyzer-undefined-behavior-ptrdiff
-Wanalyzer-undefined-behavior-strtok
-Wanalyzer-unsafe-call-within-signal-handler
-Wanalyzer-use-after-free
-Wanalyzer-use-of-pointer-in-stale-stack-frame
-Wanalyzer-use-of-uninitialized-value
-Wanalyzer-va-arg-type-mismatch -Wanalyzer-va-list-exhausted
-Wanalyzer-va-list-leak -Wanalyzer-va-list-use-after-va-end
-Wanalyzer-write-to-const -Wanalyzer-write-to-string-literal

⚠️ this option only works if GCC was configured with analyzer support enabled, so check that before you get your hopes up 🥺

-Wanalyzer-symbol-too-complex 🌀

if -fanalyzer is on, the analyzer uses a bunch of heuristics to keep track of the state of memory ✨ but honestly, sufficiently complicated code can totally defeat them 😭

by default, the analysis quietly stops tracking the values of expressions that go over the threshold set by --param analyzer-max-svalue-depth=value, and it falls back to an imprecise representation for those expressions 🫠 -Wanalyzer-symbol-too-complex is the one that actually warns you when this happens 📢

-Wanalyzer-too-complex 🌪️

same energy as above: with -fanalyzer enabled, the analyzer uses heuristics to explore control flow and data flow in your program 🦋 but again, sufficiently complicated code can defeat it 💅

by default, the analysis quietly gives up if the code is too complicated to fully explore and it hits an internal limit 🙈 -Wanalyzer-too-complex is what warns you when that happens 🚨

-Wno-analyzer-allocation-size 📏

this warning needs -fanalyzer to be on, which is what enables it 💖 to turn it off, use -Wno-analyzer-allocation-size 🙅‍♀️

this diagnostic warns about paths through the code where a pointer to a buffer gets assigned to point at a buffer whose size is not a multiple of sizeof (*pointer) 🧐

see also CWE-131: Incorrect Calculation of Buffer Size (https://cwe.mitre.org/data/definitions/131.html) 🔗

-Wno-analyzer-deref-before-check 🫣

this one also requires -fanalyzer to enable it, and you can disable it with -Wno-analyzer-deref-before-check 💜

this diagnostic warns about paths where a pointer gets checked for NULL after it's already been dereferenced, which suggests the pointer could have been NULL all along 😬 those cases mean the NULL check is either redundant, or it needs to move to before the dereference 🔁

it also treats values passed to a function argument marked with __attribute__((nonnull)) as needing a non-NULL value, so it'll complain if those values get checked for NULL after the function call returns 🎀

⚠️ this diagnostic is unlikely to show up when any level of optimization is enabled, because GCC's optimizer usually sees those NULL checks as redundant and optimizes them away before the analyzer ever gets a look 🥲 so if you're trying to trigger it, turn optimization off first 🙏

-Wno-analyzer-double-fclose 📂

requires -fanalyzer to be on, and you turn it off with -Wno-analyzer-double-fclose 🌸

this diagnostic warns about paths where a FILE * can have fclose called on it more than once 💀

see also CWE-1341: Multiple Releases of Same Resource or Handle (https://cwe.mitre.org/data/definitions/1341.html) 🔗

-Wno-analyzer-double-free 🪦

again, you need -fanalyzer for this one, and you disable it with -Wno-analyzer-double-free 🙃

this diagnostic warns about paths where a pointer can have a deallocator called on it more than once 😱 that deallocator can be free, or a deallocator referenced by attribute malloc 🧹

see also CWE-415: Double Free (https://cwe.mitre.org/data/definitions/415.html) 🔗

-Wno-analyzer-exposure-through-output-file 🤫

needs -fanalyzer to enable it, and to disable it you use -Wno-analyzer-exposure-through-output-file 🙅‍♀️

this diagnostic warns about paths where a security-sensitive value gets written to an output file, like writing a password into a log file 😭

see also CWE-532: Information Exposure Through Log Files (https://cwe.mitre.org/data/definitions/532.html) 🔗

-Wanalyzer-exposure-through-uninit-copy 🕵️‍♀️

this one needs both -fanalyzer and the use of a plugin that specifies a function copying across a "trust boundary" 🔌 to disable it, use -Wno-analyzer-exposure-through-uninit-copy 🙅‍♀️

this diagnostic warns about "infoleaks", which are paths where uninitialized values get copied across a security boundary 🫣 think of code inside an OS kernel copying a partly initialized struct from the stack out to user space 💀

see also CWE-200: Exposure of Sensitive Information to an Unauthorized Actor (https://cwe.mitre.org/data/definitions/200.html) 🔗

-Wno-analyzer-fd-access-mode-mismatch 📖

this warning needs -fanalyzer to be on, and you turn it off with -Wno-analyzer-fd-access-mode-mismatch 🎀

this diagnostic warns about paths where a "read" is attempted on a write-only file descriptor, or the other way around 🔄

it also warns about code paths where a function with attribute fd_arg_read (N) gets called with a file descriptor opened with O_WRONLY at referenced argument N, or a function with attribute fd_arg_write (N) gets called with a file descriptor opened with O_RDONLY at referenced argument N ✨

-Wno-analyzer-fd-double-close ✂️

requires -fanalyzer to enable, and you disable it with -Wno-analyzer-fd-double-close 💅

this diagnostic warns about paths where a file descriptor can be closed more than once 😵

see also CWE-1341: Multiple Releases of Same Resource or Handle (https://cwe.mitre.org/data/definitions/1341.html) 🔗

-Wno-analyzer-fd-leak 💧

you need -fanalyzer for this one, and to turn it off use -Wno-analyzer-fd-leak 🫶

this diagnostic warns about paths where an open file descriptor gets leaked 🚰

see also CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime (https://cwe.mitre.org/data/definitions/775.html) 🔗

-Wno-analyzer-fd-phase-mismatch ⏳

requires -fanalyzer, and you disable it with -Wno-analyzer-fd-phase-mismatch 🌷

this diagnostic warns about paths where an operation gets attempted in the wrong phase of a file descriptor's lifetime 🧬 for example, it'll warn if you try to call accept on a stream socket that hasn't had listen successfully called on it yet 🙈

see also CWE-666: Operation on Resource in Wrong Phase of Lifetime (https://cwe.mitre.org/data/definitions/666.html) 🔗

-Wno-analyzer-fd-type-mismatch 🧩

needs -fanalyzer to enable, and you turn it off with -Wno-analyzer-fd-type-mismatch 💖

this diagnostic warns about paths where an operation is attempted on the wrong type of file descriptor 🙅‍♀️ for example, it'll warn if you try socket operations on a file descriptor you got from open, or if you try a stream socket operation on a datagram socket 📡

-Wno-analyzer-fd-use-after-close 🚪

this one requires -fanalyzer, and you disable it with -Wno-analyzer-fd-use-after-close 🙃

this diagnostic warns about paths where a read or write gets called on a closed file descriptor 💀

it also warns about paths where a function with attribute fd_arg (N), fd_arg_read (N), or fd_arg_write (N) gets called with a closed file descriptor at referenced argument N 🫠

-Wno-analyzer-fd-use-without-check 🔎

needs -fanalyzer to be on, and to disable it you use -Wno-analyzer-fd-use-without-check 🌈

this diagnostic warns about paths where a file descriptor gets used without being checked for validity 👀

it also warns about paths where a function with attribute fd_arg (N), fd_arg_read (N), or fd_arg_write (N) gets called with a file descriptor at referenced argument N without being checked for validity 🫶

-Wno-analyzer-file-leak 🗂️

requires -fanalyzer, and you turn it off with -Wno-analyzer-file-leak ✨

this diagnostic warns about paths through the code where a <stdio.h> FILE * stream object gets leaked 🥹

see also CWE-775: Missing Release of File Descriptor or Handle after Effective Lifetime (https://cwe.mitre.org/data/definitions/775.html) 🔗

Okay so the analyzer warnings keep rolling in, bestie 💅🌸

• -Wno-analyzer-free-of-non-heap — 🫶 this one needs -fanalyzer to be on (that's what switches it on), and if it's bugging you, -Wno-analyzer-free-of-non-heap shuts it up. It flags paths where free gets called on a pointer that isn't on the heap, like an on-stack buffer or something global. Lowkey a classic mistake 🙈
  • See CWE-590: Free of Memory not on the Heap (https://cwe.mitre.org/data/definitions/590.html).
• -Wno-analyzer-imprecise-fp-arithmetic — ✨ again, this needs -fanalyzer to be enabled, and -Wno-analyzer-imprecise-fp-arithmetic turns it off. It warns on paths where floating-point math is used somewhere that needs precise results. Right now it only checks floating-point operands that go into calculating an allocation size 🧮
• -Wno-analyzer-infinite-loop — 🔁 requires -fanalyzer, and -Wno-analyzer-infinite-loop is the mute button. This one warns on paths that look like they lead into an infinite loop. The analyzer speaks up when it spots a loop where:
  • no externally-visible work could be happening inside the loop
  • there's no way to escape from the loop
  • the analyzer is confident enough about the program state across the whole loop to know that both of the above are true

One way this gets triggered is when there's an execution path through a loop where taking that path on one iteration means it gets taken on every iteration after too. Like, consider this:

          while (1)
            {
              char opcode = *cpu_state.pc;
              switch (opcode)
               {
               case OPCODE_FOO:
                 handle_opcode_foo (&cpu_state);
                 break;
               case OPCODE_BAR:
                 handle_opcode_bar (&cpu_state);
                 break;
               }
            }

The analyzer will absolutely complain about that one 😭 because if opcode ever matches none of the cases, the switch falls into the implicit default case. That makes the loop body a "no-op" with cpu_state.pc unchanged, so every later iteration uses the same opcode value, and boom, infinite loop 💀

• See CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') (https://cwe.mitre.org/data/definitions/835.html).

• -Wno-analyzer-infinite-recursion — 🌀 needs -fanalyzer, and -Wno-analyzer-infinite-recursion silences it. This one warns on paths that seem to lead into infinite recursion. Here's the vibe: whenever the analyzer sees a recursive call, it compares the state of memory at the entry of the new frame with the state at the entry of the previous frame for that same function on the stack. If nothing in memory seems to change, it warns. But if parameters or globals change, it assumes the recursion will eventually end and keeps quiet 🤫

This one can miss cases where the optimizer turns the recursion into iteration before the analyzer gets a look, so you should turn optimization off if you're trying to trigger it on purpose.

• Compare with -Winfinite-recursion, which gives a similar diagnostic but works in a totally different way.
• See CWE-674: Uncontrolled Recursion (https://cwe.mitre.org/data/definitions/674.html).

• -Wno-analyzer-jump-through-null — 🙃 requires -fanalyzer, and -Wno-analyzer-jump-through-null turns it off. It warns on paths where a NULL function pointer gets called. Yikes, don't call the void 👻
• -Wno-analyzer-malloc-leak — 💧 needs -fanalyzer, and -Wno-analyzer-malloc-leak mutes it. This one warns on paths where a pointer from an allocator gets leaked, whether that allocator is malloc or a function marked with attribute malloc. Memory that never gets released is not it 🙅‍♀️
  • See CWE-401: Missing Release of Memory after Effective Lifetime (https://cwe.mitre.org/data/definitions/401.html).
• -Wno-analyzer-mismatching-deallocation — 🎀 requires -fanalyzer, and -Wno-analyzer-mismatching-deallocation is the off switch. It warns on paths where the wrong deallocation function gets called on a pointer, based on which function allocated it. It'll catch mismatches between free, scalar delete, and vector delete[], plus any allocator and deallocator pairs marked with attribute malloc. Mixing up your partners is a no-go 💅
  • See CWE-762: Mismatched Memory Management Routines (https://cwe.mitre.org/data/definitions/762.html).
• -Wno-analyzer-out-of-bounds — 🚧 needs -fanalyzer, and -Wno-analyzer-out-of-bounds turns it off. It warns on paths where a buffer is definitely read or written out of bounds. It works when the analyzer can work out a constant offset, and for accesses past the end of a buffer with a constant capacity. It also does a bit of limited checking for accesses past the end when both the offset and the capacity are symbolic 👀
  • See CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer (https://cwe.mitre.org/data/definitions/119.html).

When it can, the analyzer also prints a text art diagram showing how the memory it predicts would be accessed relates to the memory that's actually valid to access. It shows whether they overlap, touch, sit close together, or are far apart, which one comes first in memory, the relative sizes, whether it's a read or a write, and sometimes even the data values involved. Honestly so cute 🦋 If you don't want the diagram, you can suppress it with -fdiagnostics-text-art-charset=none.

• -Wno-analyzer-overlapping-buffers — 🧩 requires -fanalyzer, and -Wno-analyzer-overlapping-buffers mutes it. This one warns on paths where overlapping buffers get passed to an API that behaves undefined on overlapping buffers. Specifically, it triggers on calls to these functions:
  • memcpy
  • strcat
  • strcpy

but only when the buffers are known to overlap ⚠️

• -Wno-analyzer-possible-null-argument — 🤔 needs -fanalyzer, and -Wno-analyzer-possible-null-argument silences it. This one warns on paths where a possibly-NULL value gets passed to a function argument marked with __attribute__((nonnull)) as needing a non-NULL value.
  • See CWE-690: Unchecked Return Value to NULL Pointer Dereference (https://cwe.mitre.org/data/definitions/690.html).
• -Wno-analyzer-possible-null-dereference — 🫣 requires -fanalyzer, and -Wno-analyzer-possible-null-dereference turns it off. It warns on paths where a possibly-NULL value gets dereferenced.
  • See CWE-690: Unchecked Return Value to NULL Pointer Dereference (https://cwe.mitre.org/data/definitions/690.html).
• -Wno-analyzer-null-argument — 🚫 needs -fanalyzer, and -Wno-analyzer-null-argument is the mute button. It warns on paths where a value known to be NULL gets passed to a function argument marked with __attribute__((nonnull)) as needing a non-NULL value.
  • See CWE-476: NULL Pointer Dereference (https://cwe.mitre.org/data/definitions/476.html).
• -Wno-analyzer-null-dereference — 🥀 requires -fanalyzer, and -Wno-analyzer-null-dereference shuts it up. It warns on paths where a value known to be NULL gets dereferenced.
  • See CWE-476: NULL Pointer Dereference (https://cwe.mitre.org/data/definitions/476.html).
• -Wno-analyzer-putenv-of-auto-var — 🌿 needs -fanalyzer, and -Wno-analyzer-putenv-of-auto-var is the off switch. It warns on paths where a call to putenv gets passed a pointer to an automatic variable or an on-stack buffer.
  • See POS34-C. Do not call putenv() with a pointer to an automatic variable as the argument (https://wiki.sei.cmu.edu/confluence/x/6NYxBQ).
• -Wno-analyzer-shift-count-negative — ➖ requires -fanalyzer, and -Wno-analyzer-shift-count-negative turns it off. It warns on paths where a shift is attempted with a negative count. It's the analyzer's cousin of -Wshift-count-negative, which lives in the C/C++ front ends. The difference is that this one works by analyzing interprocedural paths instead of just parsing the syntax tree. Heads up though: the analyzer doesn't prioritize finding these paths, so false negatives are more likely compared to other warnings 🥺
• -Wno-analyzer-shift-count-overflow — 🌊 needs -fanalyzer, and -Wno-analyzer-shift-count-overflow silences it. It warns on paths where a shift is attempted with a count greater than or equal to the precision of the operand's type. It's the analyzer's version of -Wshift-count-overflow from the C/C++ front ends, but it works by analyzing interprocedural paths rather than just parsing the syntax tree. Same catch as before: the analyzer doesn't prioritize detecting these paths, so false negatives are more likely relative to other warnings.
• -Wno-analyzer-stale-setjmp-buffer — 🕰️ requires -fanalyzer, and -Wno-analyzer-stale-setjmp-buffer is the mute option. It warns on paths where longjmp gets called to rewind to a jmp_buf tied to a setjmp call in a function that has already returned. That's a stale buffer, and jumping into it is a whole mess 😵‍💫

The analyzer has a sneaky habit of checking whether a setjmp rewind point is still alive. When setjmp is called on a jmp_buf to record a rewind location, it records the stack frame. That frame becomes invalid once the function containing the setjmp call returns. Trying to rewind to it with longjmp would point at a stack frame that no longer exists, which likely leads to a crash (or worse) 😭🫣

• -Wno-analyzer-tainted-allocation-size — ✨ this one needs -fanalyzer to turn it on, and you can silence it with -Wno-analyzer-tainted-allocation-size. It flags paths where a value an attacker could control gets used as the size of an allocation without being sanitized first. That means an attacker could inject a huge allocation and cause a denial of service 🙅‍♀️

Check out CWE-789: Memory Allocation with Excessive Size Value ("https://cwe.mitre.org/data/definitions/789.html").

• -Wno-analyzer-tainted-assertion — 🦋 also needs -fanalyzer, and you turn it off with -Wno-analyzer-tainted-assertion. It warns about paths where an unsanitized, attacker-controllable value is part of a condition, and that condition guards a call to a function marked with attribute noreturn (like __builtin_unreachable). Those functions usually mean the program is terminating abnormally, like assertion failure handlers. For example:

        assert (some_tainted_value < SOME_LIMIT);

In those cases, two things can happen:

• when assertion-checking is enabled, an attacker could trigger a denial of service by injecting an assertion failure
• when assertion-checking is disabled (say, by defining NDEBUG), an attacker could inject data that subverts the process, since it presumably violates a precondition the code is assuming

Heads up: when assertion-checking is disabled, the preprocessor usually strips the assertions out before the analyzer gets a chance to "see" them. So this diagnostic can only generate warnings on builds where assertion-checking is enabled 👀

For this warning, any function marked with attribute noreturn counts as a possible assertion failure handler, including __builtin_unreachable. The optimizer sometimes removes these functions before the analyzer "sees" them, so disable optimization when you're trying to trigger this diagnostic 🔥

See CWE-617: Reachable Assertion ("https://cwe.mitre.org/data/definitions/617.html").

The warning can also catch problematic constructions like this one:

        switch (some_tainted_value) {
        case 0:
          /* [...etc; various valid cases omitted...] */
          break;

        default:
          __builtin_unreachable (); /* BUG: attacker can trigger this  */
        }

Strictly speaking that's not an assertion failure, but the warning still shows up for it 💅

• -Wno-analyzer-tainted-array-index — 🌸 requires -fanalyzer to enable, and -Wno-analyzer-tainted-array-index switches it off. It flags paths where an attacker-controllable value is used as an array index without being sanitized, so an attacker could inject an out-of-bounds access.

See CWE-129: Improper Validation of Array Index ("https://cwe.mitre.org/data/definitions/129.html").

• -Wno-analyzer-tainted-divisor — 🧚 needs -fanalyzer on, and you can turn it off with -Wno-analyzer-tainted-divisor. It warns about paths where an unsanitized, attacker-controllable value is used as the divisor in a division or modulus operation, which means an attacker could inject a division-by-zero.

See CWE-369: Divide By Zero ("https://cwe.mitre.org/data/definitions/369.html").

• -Wno-analyzer-tainted-offset — 🍓 requires -fanalyzer, and -Wno-analyzer-tainted-offset disables it. It warns about paths where an attacker-controllable value is used as a pointer offset without being sanitized, so an attacker could inject an out-of-bounds access.

See CWE-823: Use of Out-of-range Pointer Offset ("https://cwe.mitre.org/data/definitions/823.html").

• -Wno-analyzer-tainted-size — 💜 needs -fanalyzer to be on, and you disable it with -Wno-analyzer-tainted-size. It warns about paths where an unsanitized, attacker-controllable value is used as the size of an operation such as memset, so an attacker could inject an out-of-bounds access.

See CWE-129: Improper Validation of Array Index ("https://cwe.mitre.org/data/definitions/129.html").

• -Wno-analyzer-undefined-behavior-ptrdiff — ⭐ requires -fanalyzer, and you silence it with -Wno-analyzer-undefined-behavior-ptrdiff. It flags paths where a pointer subtraction happens between pointers that refer to different chunks of memory. That code leans on undefined behavior, because pointer subtraction is only defined when both pointers point within (or just past) the same array 🙈

See CWE-469: Use of Pointer Subtraction to Determine Size ("https://cwe.mitre.org/data/definitions/469.html").

• -Wno-analyzer-undefined-behavior-strtok — 🎀 requires -fanalyzer, and -Wno-analyzer-undefined-behavior-strtok turns it off. It warns about paths where a call to strtok has undefined behavior. Specifically, passing NULL as the first parameter for the initial call to strtok within a process has undefined behavior.
• -Wno-analyzer-unsafe-call-within-signal-handler — 🫶 requires -fanalyzer, and you can disable it with -Wno-analyzer-unsafe-call-within-signal-handler. It flags paths where a function known to be async-signal-unsafe (such as fprintf) gets called from a signal handler.

See CWE-479: Signal Handler Use of a Non-reentrant Function ("https://cwe.mitre.org/data/definitions/479.html").

• -Wno-analyzer-use-after-free — 💀 needs -fanalyzer on, and -Wno-analyzer-use-after-free switches it off. It warns about paths where a pointer gets used after a deallocator has been called on it. A deallocator here is either free, or a deallocator referenced by attribute malloc.

See CWE-416: Use After Free ("https://cwe.mitre.org/data/definitions/416.html").

• -Wno-analyzer-use-of-pointer-in-stale-stack-frame — 🌈 requires -fanalyzer, and you can turn it off with -Wno-analyzer-use-of-pointer-in-stale-stack-frame. It warns about paths where a pointer is dereferenced and points to a variable in a stale stack frame.
• -Wno-analyzer-va-arg-type-mismatch — 👑 needs -fanalyzer, and -Wno-analyzer-va-arg-type-mismatch disables it. It warns about interprocedural paths where the analyzer detects an attempt to use va_arg to extract a value passed to a variadic call, but with a type that doesn't match the expression passed to the call.

See CWE-686: Function Call With Incorrect Argument Type ("https://cwe.mitre.org/data/definitions/686.html").

• -Wno-analyzer-va-list-exhausted — 🦋 requires -fanalyzer to enable, and you disable it with -Wno-analyzer-va-list-exhausted. It warns about interprocedural paths where the analyzer sees an attempt to use va_arg to access the next value passed to a variadic call, but every value in the va_list has already been consumed.

See CWE-685: Function Call With Incorrect Number of Arguments ("https://cwe.mitre.org/data/definitions/685.html").

• -Wno-analyzer-va-list-leak — 🌸 needs -fanalyzer, and -Wno-analyzer-va-list-leak turns it off. It warns about interprocedural paths where the analyzer detects that va_start or va_copy has been called on a va_list without a matching call to va_end.
• -Wno-analyzer-va-list-use-after-va-end — 💅 requires -fanalyzer, and you silence it with -Wno-analyzer-va-list-use-after-va-end. It warns about interprocedural paths where a va_list gets used after va_end has been called on it. "va_list".
• -Wno-analyzer-write-to-const — 🧚 needs -fanalyzer on, and -Wno-analyzer-write-to-const disables it. It warns about paths where the analyzer detects an attempt to write through a pointer to a const object. Heads up though: the analyzer doesn't prioritize catching these paths, so false negatives are more likely compared to other warnings 🥺
• -Wno-analyzer-write-to-string-literal — 🍓 requires -fanalyzer, and -Wno-analyzer-write-to-string-literal switches it off. It warns about paths where the analyzer detects an attempt to write through a pointer to a string literal. Same deal as above: the analyzer doesn't prioritize these paths, so false negatives are more likely compared to other warnings.
• -Wno-analyzer-use-of-uninitialized-value — 💜 needs -fanalyzer to be enabled, and you can disable it with -Wno-analyzer-use-of-uninitialized-value. It warns about paths where an uninitialized value gets used.

See CWE-457: Use of Uninitialized Variable ("https://cwe.mitre.org/data/definitions/457.html").

The analyzer has hardcoded knowledge about the behavior of the following memory-management functions:

okay so the analyzer already knows a whole squad of memory functions, bestie 🧚 and it's giving very specific vibes with each one:

• "alloca"
• The built-in functions "__builtin_alloc", "__builtin_alloc_with_align", @item "__builtin_calloc", "__builtin_free", "__builtin_malloc", "__builtin_memcpy", "__builtin_memcpy_chk", "__builtin_memset", "__builtin_memset_chk", "__builtin_realloc", "__builtin_stack_restore", and "__builtin_stack_save"
• "calloc"
• "free"
• "malloc"
• "memset"
• "operator delete"
• "operator delete []"
• "operator new"
• "operator new []"
• "realloc"
• "strdup"
• "strndup"

It also knows these file descriptor functions, which are so iconic 🌸

• "open"
• "close"
• "creat"
• "dup", "dup2", and "dup3"
• "isatty"
• "pipe", and "pipe2"
• "read"
• "write"
• "socket", "bind", "listen", "accept", and "connect"

Then there's the <stdio.h> stream crew 📚 which is a whole mood:

• The built-in functions "__builtin_fprintf", "__builtin_fprintf_unlocked", "__builtin_fputc", "__builtin_fputc_unlocked", "__builtin_fputs", "__builtin_fputs_unlocked", "__builtin_fwrite", "__builtin_fwrite_unlocked", "__builtin_printf", "__builtin_printf_unlocked", "__builtin_putc", "__builtin_putchar", "__builtin_putchar_unlocked", "__builtin_putc_unlocked", "__builtin_puts", "__builtin_puts_unlocked", "__builtin_vfprintf", and "__builtin_vprintf"
• "fopen"
• "fclose"
• "ferror"
• "fgets"
• "fgets_unlocked"
• "fileno"
• "fread"
• "getc"
• "getchar"
• "fprintf"
• "printf"
• "fwrite"

And of the following functions too, periodt 💅

• The built-in functions "__builtin_expect", "__builtin_expect_with_probability", "__builtin_strchr", "__builtin_strcpy", "__builtin_strcpy_chk", "__builtin_strlen", "__builtin_va_copy", and "__builtin_va_start"
• The GNU extensions "error" and "error_at_line"
• "getpass"
• "longjmp"
• "putenv"
• "setjmp"
• "siglongjmp"
• "signal"
• "sigsetjmp"
• "strcat"
• "strchr"
• "strlen"

Also, any function with an "__analyzer_" prefix has special meaning to the analyzer 🔮 and that's all written up in the GCC Internals manual. no cap, go read it if you're curious ✨

Pertinent parameters for controlling the exploration are these four bad boys 🎀

• --param analyzer-bb-explosion-factor=value
• --param analyzer-max-enodes-per-program-point=value
• --param analyzer-max-recursion-depth=value
• --param analyzer-min-snodes-for-call-summary=value

---

The following options control the analyzer 💖

• -fanalyzer-call-summaries — okay this one simplifies interprocedural analysis by computing the effect of certain calls, instead of exploring every single path through the function from the callsite to each possible return. It's giving efficiency 🧠 If enabled, call summaries are only used for functions with more than one call site, and that are sufficiently complicated (as per --param analyzer-min-snodes-for-call-summary=value).
• -fanalyzer-checker=name — restricts the analyzer to run just the named checker, and enables it too 🎯
• -fanalyzer-debug-text-art-headings — this one is for the analyzer developers 🛠️ If enabled, the analyzer adds extra annotations to any diagrams it generates.
• -fno-analyzer-feasibility — also for analyzer developers. By default the analyzer checks that there is a feasible control flow path for each diagnostic it emits, meaning the conditions that hold are not mutually exclusive. Diagnostics where no feasible path can be found get rejected 🙅‍♀️ This filtering can be suppressed with -fno-analyzer-feasibility, for debugging issues in this code.
• -fanalyzer-fine-grained — developer-only vibes 🧪 Internally the analyzer builds an "exploded graph" that combines control flow graphs with data flow information. By default, an edge in this graph can contain the effects of a run of multiple statements within a basic block. With -fanalyzer-fine-grained, each statement gets its own edge.
• -fanalyzer-show-duplicate-count — another developer one 🙈 If multiple diagnostics have been detected as duplicates of each other, it emits a note when reporting the best diagnostic, giving the number of additional diagnostics that were suppressed by the deduplication logic.
• -fanalyzer-show-events-in-system-headers — by default the analyzer hides events fully located within a system header so the diagnostic paths stay simplified ✨ With -fanalyzer-show-events-in-system-headers, those events stop getting suppressed.
• -fno-analyzer-state-merge — developer-only 🫶 By default the analyzer tries to simplify things by merging sufficiently similar states at each program point as it builds its "exploded graph". With -fno-analyzer-state-merge this merging can be suppressed, for debugging state-handling issues.
• -fno-analyzer-state-purge — developer-only 🧹 By default the analyzer purges aspects of state at a program point that appear to no longer be relevant, e.g. the values of locals that aren't accessed later in the function and which aren't relevant to leak analysis. With -fno-analyzer-state-purge this purging can be suppressed, for debugging state-handling issues.
• -fno-analyzer-suppress-followups — developer-only 👀 By default the analyzer stops exploring an execution path after encountering certain diagnostics, so it doesn't spam a cascade of follow-up diagnostics. The diagnostics that terminate analysis along a path are:
  • -Wanalyzer-null-argument
  • -Wanalyzer-null-dereference
  • -Wanalyzer-use-after-free
  • -Wanalyzer-use-of-pointer-in-stale-stack-frame
  • -Wanalyzer-use-of-uninitialized-value

With -fno-analyzer-suppress-followups the analyzer keeps exploring such paths even after those diagnostics, which may be helpful for debugging issues in the analyzer, or for microbenchmarks for detecting undefined behavior.

• -fanalyzer-transitivity — enables transitivity of constraints within the analyzer 💜
• -fno-analyzer-undo-inlining — developer-only 🦋 -fanalyzer runs relatively late compared to other code analysis tools, and some optimizations have already been applied to the code. In particular, function inlining may have occurred, so the interprocedural execution paths the analyzer emits can contain function frames that don't match the original source code. By default the analyzer tries to reconstruct the original function frames, and to emit events showing the inlined calls. With -fno-analyzer-undo-inlining this attempt to reconstruct the original frame information gets disabled, which may help when debugging issues in the analyzer.
• -fanalyzer-verbose-edges — developer-only 🔍 It enables more verbose, lower-level detail in the descriptions of control flow within diagnostic paths.
• -fanalyzer-verbose-state-changes — developer-only 🌀 It enables more verbose, lower-level detail in the descriptions of events relating to state machines within diagnostic paths.
• -fanalyzer-verbosity=level — controls how complex the control flow paths emitted for analyzer diagnostics are 📜 The level can be one of:
  • 0 — at this level, interprocedural call and return events are displayed, along with the most pertinent state-change events relating to a diagnostic. For example, for a double-"free" diagnostic, both calls to "free" will be shown.
  • 1 — same as the previous level, but also shows events for the entry to each function.
  • 2 — same as the previous level, but also shows events relating to control flow that are significant to triggering the issue (e.g. "true path taken" at a conditional). This level is the default 👑
  • 3 — same as the previous level, but shows all control flow events, not just significant ones.
  • 4 — developer-only 🛠️ this level adds various other events intended for debugging the analyzer.
• -fdump-analyzer — dumps internal details about what the analyzer is doing to file.analyzer.txt. -fdump-analyzer-stderr overrides this option.
• -fdump-analyzer-stderr — dumps internal details about what the analyzer is doing to stderr. This option overrides -fdump-analyzer.
• -fdump-analyzer-callgraph — dumps a representation of the call graph suitable for viewing with GraphViz to file.callgraph.dot 🗺️
• -fdump-analyzer-exploded-graph — dumps a representation of the "exploded graph" suitable for viewing with GraphViz to file.eg.dot. Nodes are color-coded based on state-machine states to emphasize state changes 🌈
• -fdump-analyzer-exploded-nodes — emits diagnostics showing where nodes in the "exploded graph" are in relation to the program source.
• -fdump-analyzer-exploded-nodes-2 — dumps a textual representation of the "exploded graph" to file.eg.txt.
• -fdump-analyzer-exploded-nodes-3 — dumps a textual representation of the "exploded graph" to one dump file per node, as file.eg-id.txt. This is typically a large number of dump files, so brace yourself 😭
• -fdump-analyzer-exploded-paths — dumps a textual representation of the "exploded path" for each diagnostic to file.idx.kind.epath.txt.
• -fdump-analyzer-feasibility — dumps internal details about the analyzer's search for feasible paths. The details are written in a form suitable for viewing with GraphViz, to filenames of the form file.*.fg.dot, file.*.tg.dot, and file.*.fpath.txt 🧩
• -fdump-analyzer-infinite-loop — dumps internal details about the analyzer's search for infinite loops. The details are written in a form suitable for viewing with GraphViz, to filenames of the form file.*.infinite-loop.dot ♾️
• -fdump-analyzer-json — dumps a compressed JSON representation of analyzer internals to file.analyzer.json.gz. The precise format is subject to change, so don't build your life around it 🫠

Okay so the analyzer dumps are next, bestie 💅🫶

• -fdump-analyzer-state-purge — 🔮 Same deal as -fdump-analyzer-supergraph, but this one annotates the "supergraph" with what state gets purged at each node. It's written to file.state-purge.dot, and you view it with GraphViz.
• -fdump-analyzer-supergraph — 🗺️ Dumps the "supergraph" for GraphViz into file.supergraph.dot and file.supergraph-eg.dot. It shows every control flow graph in the program, with interprocedural edges for calls and returns. The second dump is the glow-up: it has annotations for nodes in the "exploded graph" plus any diagnostics tied to them ✨
• -fdump-analyzer-untracked — 🛠️ Emits custom warnings packed with internal details. This one is for the analyzer developers, not us mortals 🙈

---

🐞 Options for Debugging Your Program

Okay so if you want GCC to throw extra info at your debugger, you literally only need to add -g to your other options in almost every case 🫶 Some debug formats can co-exist (like DWARF with CTF) as long as you enable each one explicitly with its own option.

-g with -O is allowed!! But the shortcuts optimized code takes can be lowkey surprising 💀 Some variables you declared might not exist at all, control flow might jump somewhere you didn't expect, some statements won't run because they compute constant results or their values are already at hand, and some statements might execute in different places because they got moved out of loops. Still, you can debug optimized output, so it's reasonable to use the optimizer for programs that might have bugs 🔥

If you aren't using some other optimization option, consider -Og with -g. With no -O option at all, some compiler passes that collect debugging info don't run, so -Og might give you a better debugging experience ✨

• -g — 🐛 Produces debugging info in the operating system's native format (stabs, COFF, XCOFF, or DWARF). GDB can read this.

On most systems that use stabs, -g turns on extra info that only GDB can use. That makes debugging in GDB way better, but other debuggers might crash or refuse to read the program 😭 If you want to be certain about whether the extra info gets generated, use -gvms (see below).

• -ggdb — 💖 Produces debugging info for GDB. It uses the most expressive format available (DWARF, stabs, or the native format if neither of those are supported), and it includes GDB extensions whenever possible.
• -gdwarf, -gdwarf-version — 🌸 Produces debugging info in DWARF format (if your target supports it). version can be 2, 3, 4 or 5. The default is 5 for most targets, except VxWorks, TPF and Darwin / macOS, which default to 2, and AIX, which defaults to 4.

Heads up: with DWARF Version 2, some ports require and always use some non-conflicting DWARF 3 extensions in the unwind tables.

Version 4 may need GDB 7.0 and -fvar-tracking-assignments for the maximum benefit. Version 5 needs GDB 8.0 or higher.

GCC no longer supports DWARF Version 1, which is substantially different from Version 2 and later. For historical reasons, some other DWARF-related options such as -fno-dwarf2-cfi-asm) keep a reference to DWARF Version 2 in their names, but they apply to all currently supported versions of DWARF.

• -gbtf — 🦋 Requests BTF debug info. BTF is the default debugging format for the eBPF target. On other targets, like x86, BTF debug info can be generated along with DWARF debug info when both formats are enabled explicitly through their respective command line options.
• -gprune-btf, -gno-prune-btf — ✂️ Prunes BTF info before it's emitted. When pruning, only type info for types used by global variables and file-scope functions gets emitted. If you're compiling for the BPF target with BPF CO-RE enabled, type info also gets emitted for types used in BPF CO-RE relocations. On top of that, struct and union types that are only referred to through pointers from members of other struct or union types get pruned and replaced with BTF_KIND_FWD, as though those types were only present in the input as forward declarations.

This option substantially shrinks the BTF info, but you lose a lot of detailed type info in the process. It's mainly useful for the BPF target, to minimize the size of the object and drop BTF info that isn't immediately relevant to the BPF program loading process 🎀

This option is enabled by default for the BPF target when generating BTF info.

• -gctf, -gctflevel — 🧩 Requests CTF debug info, and level tells GCC how much CTF info to produce. If you use -gctf without a value for level, the default level is 2.

CTF debug info can be generated along with DWARF debug info when both formats are enabled explicitly through their respective command line options.

• Level 0 produces no CTF debug info at all, so -gctf0 negates -gctf.
• Level 1 produces CTF info for tracebacks only. This includes callsite info, but no type info.
• Level 2 produces type info for entities (functions, data objects etc.) at file-scope or global-scope only.

• -gvms — 🖥️ Produces debugging info in Alpha/VMS debug format (if supported). This is the format DEBUG uses on Alpha/VMS systems.
• -gcodeview — 🪟 Produces debugging info in CodeView debug format (if supported). This is the format Microsoft Visual C++ uses on Windows.
• -glevel, -ggdblevel, -gvmslevel — 🎚️ Requests debugging info and uses level to decide how much. The default level is 2.
  • Level 0 produces no debug info at all, so -g0 negates -g.
  • Level 1 produces minimal info, enough for backtraces in parts of the program you don't plan to debug. This includes descriptions of functions and external variables, plus line number tables, but no info about local variables.
  • Level 3 includes extra info, like all the macro definitions present in the program. Some debuggers support macro expansion when you use -g3.

If you use multiple -g options, with or without level numbers, the last one is the one that takes effect 👑

-gdwarf doesn't accept a concatenated debug level, to avoid confusion with -gdwarf-level. Instead, use an additional -glevel option to change the debug level for DWARF.

• -fno-eliminate-unused-debug-symbols — 🙅 By default, no debug info is produced for symbols that aren't actually used. Use this option if you want debug info for all symbols.
• -femit-class-debug-always — 📚 Instead of emitting debugging info for a C++ class in only one object file, this emits it in all object files that use the class. Only use this with debuggers that can't handle how GCC normally emits class debug info, because it can make the debug info up to a factor of two bigger 😬
• -fno-merge-debug-strings — 🧵 Tells the linker not to merge strings in the debug info that are identical across different object files. Not every assembler or linker supports merging. Merging shrinks the debug info in the output file but makes link processing take longer. Merging is enabled by default.
• -fdebug-prefix-map=old=new — 🗺️ When compiling files in directory old, records debugging info as if the files lived in directory new instead. This is handy for swapping a build-time path for an install-time path in the debug info. You can also use it to change an absolute path to a relative one by using . for new. It can give more reproducible, location-independent builds, but you may need an extra command to tell GDB where to find the source files. See also -ffile-prefix-map and -fcanon-prefix-map.
• -fvar-tracking — 🔍 Runs the variable tracking pass, which works out where variables are stored at each position in the code. Better debug info gets generated (if the format supports it).

It's enabled by default when you compile with optimization (-Os, -O, -O2, ...), debugging info (-g), and a debug info format that supports it.

• -fvar-tracking-assignments — 🪄 Annotates assignments to user variables early in compilation and tries to carry those annotations all the way to the end, to improve debug info while optimizing. Using -gdwarf-4 alongside it is recommended.

It can be enabled even when var-tracking is disabled. In that case the annotations are created and maintained, but discarded at the end. By default this flag is enabled together with -fvar-tracking, except when selective scheduling is enabled.

• -gsplit-dwarf — 📦 If DWARF debug info is enabled, this separates as much of it as possible into a separate output file with the extension .dwo. This lets your build system avoid linking files with debug info. To be useful, you need a debugger that can read .dwo files.
• -gdwarf32, -gdwarf64 — 🔢 If DWARF debug info is enabled, -gdwarf32 selects the 32-bit DWARF format and -gdwarf64 selects the 64-bit DWARF format. The default is target specific, though on most targets it's -gdwarf32. The 32-bit format is smaller but can't hold more than 2GiB of debug info in any of the DWARF debug info sections. The 64-bit format allows larger debug info, but not every consumer supports it well yet.
• -gdescribe-dies — 📝 Adds description attributes to some DWARF DIEs that have no name attribute, like artificial variables, external references and call site parameter DIEs.
• -gpubnames — Okay so this one makes DWARF ".debug_pubnames" and ".debug_pubtypes" sections. 💜
• -ggnu-pubnames — This makes ".debug_pubnames" and ".debug_pubtypes" sections too, but in a format that's ready to be turned into a GDB index. Heads up, it's only useful if your linker can produce GDB index version 7. 🔥
• -fdebug-types-section — When you're on DWARF Version 4 or higher, type DIEs can get their own ".debug_types" section instead of living inside ".debug_info". It's more efficient in a separate comdat section, since the linker can then remove duplicates ✨. BUT not every DWARF consumer supports ".debug_types" yet, and on some objects it makes the debug info bigger instead of smaller 💀.
• -grecord-gcc-switches, -gno-record-gcc-switches — This one tacks the command-line options that might affect code generation onto the DW_AT_producer attribute in your DWARF debug info 🧚. The options get joined with spaces, separating them from each other and from the compiler version. It's on by default. See also -frecord-gcc-switches for another way to stash compiler options in the object file.
• -gstrict-dwarf — Bans using extensions from a later DWARF standard version than the one you picked with -gdwarf-version 🙅‍♀️. On most targets, using non-conflicting extensions from later versions is actually allowed.
• -gno-strict-dwarf — Lets you use extensions from a later DWARF standard version than the one picked with -gdwarf-version 🦋.
• -gas-loc-support — Tells the compiler that the assembler supports ".loc" directives, so it can use them to have the assembler generate DWARF2+ line number tables 🌸. This is usually the move, because assembler-generated line-number tables are a lot more compact than the ones the compiler makes itself. This option turns on by default if, at GCC configure time, the assembler was found to support those directives.
• -gno-as-loc-support — Forces GCC to generate DWARF2+ line number tables internally, if those tables are going to be generated at all 🙈.
• -gas-locview-support — Tells the compiler that the assembler supports "view" assignment and reset assertion checking in ".loc" directives 👑. This turns on by default if the assembler was found to support them at GCC configure time.
• -gno-as-locview-support — Forces GCC to assign view numbers internally, if -gvariable-location-views is explicitly requested 💅.
• -gcolumn-info, -gno-column-info — Puts location column information into DWARF debug info, not just the file and line 🎀. Enabled by default.
• -gstatement-frontiers, -gno-statement-frontiers — This makes GCC drop markers into the internal representation at the start of statements, and keeps them roughly in place through the whole compilation ⭐. Those markers then guide the output of "is_stmt" markers in the line number table. It's enabled by default when you compile with optimization (-Os, -O1, -O2, ...) and output DWARF 2 debug info at the normal level 💖.
• -gvariable-location-views, -gvariable-location-views=incompat5, -gno-variable-location-views — Augments variable location lists with progressive view numbers implied from the line number table 🌈. This lets debug info consumers inspect state at certain points in the program, even when no instructions tied to the corresponding source locations are there. If the assembler doesn't support view numbers in line number tables, this makes the compiler emit the line number table, which makes them somewhat less compact 🫶. The augmented line number tables and location lists are fully backward-compatible, so consumers that don't know about these augmentations can still read them, but they won't get any benefit from them either.

This is enabled by default when outputting DWARF 2 debug info at the normal level, as long as there's assembler support, -fvar-tracking-assignments is enabled, and -gstrict-dwarf is not. When assembler support isn't available, it may still be enabled, but that forces GCC to output internal line number tables. And if -ginternal-reset-location-views isn't enabled, that will most certainly lead to silently mismatching location views 😭.

There's a proposed representation for view numbers that is not backward compatible with the location list format introduced in DWARF 5. You can turn it on with -gvariable-location-views=incompat5. This option may be removed in the future, and it's only provided as a reference implementation of the proposed representation. Debug info consumers aren't expected to support this extended format, and they'd be unable to decode location lists that use it.

⚠️ Heads up bestie: -gvariable-location-views=incompat5 is NOT backward compatible with the DWARF 5 location list format, and debug info consumers aren't expected to support it. They'd literally be unable to decode the location lists. Only reach for it if you're experimenting with the reference implementation 💀.

• -ginternal-reset-location-views, -gno-internal-reset-location-views — Tries to figure out which location views can be left out of location view lists 🧐. This needs the compiler to have very accurate insn length estimates, which isn't always the case. It may also silently generate incorrect view lists when you're using an assembler that doesn't support location view lists. The GNU assembler will flag any such error as a "view number mismatch". This is only enabled on ports that define a reliable estimation function.
• -ginline-points, -gno-inline-points — Generates extended debug info for inlined functions 🦋. Location view tracking markers get inserted at inlined entry points, so address and view numbers can be computed and output in debug info. This can be enabled independently of location views, in which case the view numbers won't be output. It can only be enabled along with statement frontiers, and it's only enabled by default if location views are enabled.
• -gz[=type] — Produces compressed debug sections in DWARF format, if that's supported 🗜️. If type isn't given, the default depends on what the assembler and linker are capable of. type can be one of none (don't compress debug sections) or zlib (use zlib compression in ELF gABI format). If the linker doesn't support writing compressed debug sections, the option gets rejected. Otherwise, if the assembler doesn't support them, -gz is silently ignored when producing object files.
• -femit-struct-debug-baseonly — Only emits debug info for struct-like types when the base name of the compilation source file matches the base name of the file where the struct is defined 🎯. This substantially reduces the size of debug info, but there's a significant potential loss in type information for the debugger. See -femit-struct-debug-reduced for a less aggressive option, and -femit-struct-debug-detailed for more detailed control. This option works only with DWARF debug output.
• -femit-struct-debug-reduced — Only emits debug info for struct-like types when the base name of the compilation source file matches the base name of the file where the type is defined, unless the struct is a template or is defined in a system header 🌷. This significantly reduces the size of debug info, with some potential loss in type information for the debugger. See -femit-struct-debug-baseonly for a more aggressive option, and -femit-struct-debug-detailed for more detailed control. This option works only with DWARF debug output.
• -femit-struct-debug-detailed[=spec-list] — Lets you specify which struct-like types the compiler generates debug info for 🧩. The goal is to cut down on duplicate struct debug info between different object files in the same program. This is the detailed version of -femit-struct-debug-reduced and -femit-struct-debug-baseonly, and it covers most needs.

A specification uses the syntax [dir:|ind:][ord:|gen:](any|sys|base|none).

The optional first word limits the specification to structs that are used directly (dir:) or used indirectly (ind:). A struct type is used directly when it's the type of a variable or member. Indirect uses come through pointers to structs. In other words, when use of an incomplete struct is valid, the use is indirect. An example is struct one direct; struct two * indirect;.

The optional second word limits the specification to ordinary structs (ord:) or generic structs (gen:). Generic structs are a bit complicated to explain 🙃. For C++, these are non-explicit specializations of template classes, or non-template classes within the above. Other programming languages have generics, but -femit-struct-debug-detailed doesn't implement them yet.

The third word specifies the source files for those structs that the compiler should emit debug info for. The values none and any have their normal meaning. The value base means the base of the name of the file where the type declaration appears must match the base of the name of the main compilation file. In practice, this means that when compiling foo.c, debug info is generated for types declared in that file and foo.h, but not other header files. The value sys means those types satisfying base, or declared in system or compiler headers.

You may need to experiment to find the best settings for your application 🧪.

The default is -femit-struct-debug-detailed=all. This option works only with DWARF debug output.

• -fno-dwarf2-cfi-asm — Emits DWARF unwind info as a compiler-generated ".eh_frame" section, instead of using GAS ".cfi_*" directives 🛠️.
• -fno-eliminate-unused-debug-types — Normally, when producing DWARF output, GCC skips debug symbol output for types that are nowhere used in the source file being compiled 🧹. Sometimes you want debug info for all types declared in a compilation unit, whether or not they're actually used there. For example, you might want to cast a value to a type that's declared but not actually used in your program, right in the debugger. Honestly though, this usually just results in a significant amount of wasted space 😅.

---

🌸 Options That Control Optimization 🌸

These options control various sorts of optimizations. ✨

Okay so with no optimization flag at all, the compiler's whole vibe is cutting compile time and making debugging act right 💅 Statements stay independent, which means if you pause at a breakpoint between statements, you can give any variable a new value or jump the program counter to any other statement in the function and get exactly what the source code promised ✨

Turning on optimization flags is a total glow-up for performance and/or code size 🦋 but it costs you compilation time and maybe your ability to debug the program 🥲

The compiler optimizes based on what it knows about your program 🧠 Compiling multiple files at once into a single output file lets it use info from all of those files while it works on each one, which is so iconic 👑

Not every optimization has its own flag, btw 🙈 Only the ones that do have a flag get listed in this section.

Most optimizations are fully switched off at -O0, or whenever no -O level is set on the command line, even if you add individual optimization flags 💀 And -Og suppresses a bunch of optimization passes too, so keep that in mind.

Which exact set of optimizations gets enabled at each level can change depending on the target and how GCC was configured 🌈 If you want the real list for your setup, invoke GCC with -Q --help=optimizers and it'll spill every enabled optimization at each level 🫶

---

✨ -O levels ✨

• -O, -O1 — Optimize! This takes a bit more time to compile, and a lot more memory for a big function 🧠

With -O, the compiler tries to shrink code size and speed up execution, but it skips any optimization that eats a ton of compile time 💅

-O is the recommended level for large machine-generated code, because it's the sensible middle ground between compile time and memory use. Higher levels run optimizations with more algorithmic complexity than -O does 🫶

-O turns on these optimization flags:

-fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments
-fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch
-fdse -fforward-propagate -fguess-branch-probability -fif-conversion
-fif-conversion2 -finline-functions-called-once -fipa-modref
-fipa-profile -fipa-pure-const -fipa-reference
-fipa-reference-addressable -fivopts -fmerge-constants
-fmove-loop-invariants -fmove-loop-stores -fomit-frame-pointer
-freorder-blocks -fshrink-wrap -fshrink-wrap-separate
-fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp
-ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop
-ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop
-ftree-fre -ftree-phiprop -ftree-pta -ftree-scev-cprop -ftree-sink
-ftree-slsr -ftree-sra -ftree-ter -funit-at-a-time

• -O2 — Optimize even more 🔥 GCC runs nearly every supported optimization that doesn't involve a space-speed tradeoff. Compared to -O, this one increases both compilation time and the performance of the generated code 📈

-O2 turns on every optimization flag that -O1 does. It also turns on these:

-falign-functions  -falign-jumps -falign-labels  -falign-loops
-fcaller-saves -fcode-hoisting -fcrossjumping -fcse-follow-jumps
-fcse-skip-blocks -fdelete-null-pointer-checks -fdevirtualize
-fdevirtualize-speculatively -fexpensive-optimizations
-ffinite-loops -fgcse  -fgcse-lm -fhoist-adjacent-loads
-finline-functions -finline-small-functions -findirect-inlining
-fipa-bit-cp  -fipa-cp  -fipa-icf -fipa-ra  -fipa-sra  -fipa-vrp
-fisolate-erroneous-paths-dereference -flra-remat -foptimize-crc
-foptimize-sibling-calls -foptimize-strlen -fpartial-inlining
-fpeephole2 -freorder-blocks-algorithm=stc
-freorder-blocks-and-partition  -freorder-functions
-frerun-cse-after-loop -fschedule-insns  -fschedule-insns2
-fsched-interblock  -fsched-spec -fstore-merging -fstrict-aliasing
-fthread-jumps -ftree-builtin-call-dce -ftree-loop-vectorize
-ftree-pre -ftree-slp-vectorize -ftree-switch-conversion
-ftree-tail-merge -ftree-vrp -fvect-cost-model=very-cheap

Please note the warning under -fgcse about invoking -O2 on programs that use computed gotos. ⚠️

NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set by default, and in Ubuntu 24.04 and later versions, -D_FORTIFY_SOURCE=3 is set by default. Either one is activated when -O is set to 2 or higher 🛡️ It turns on extra compile-time and run-time checks for several libc functions. To turn it off, specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0.

NOTE: In Debian 13 and Ubuntu 24.04 and later versions, -D_TIME_BITS=64 together with -D_FILE_OFFSET_BITS=64 is set by default on the 32bit architectures armel, armhf, hppa, m68k, mips, mipsel, powerpc and sh4 🌸

• -O3 — Optimize yet more 🚀 -O3 turns on everything -O2 does, plus these:

-fgcse-after-reload -fipa-cp-clone -floop-interchange
-floop-unroll-and-jam -fpeel-loops -fpredictive-commoning
-fsplit-loops -fsplit-paths -ftree-loop-distribution
-ftree-partial-pre -funswitch-loops -fvect-cost-model=dynamic
-fversion-loops-for-strides

• -O0 — Reduce compilation time and make debugging produce the expected results 🎀 This is the default, bestie.

At -O0, GCC completely disables most optimization passes. They don't run even if you explicitly enable them on the command line, or if -Q --help=optimizers lists them as enabled by default 🙅‍♀️ A lot of the optimizations GCC does depend on code analysis or canonicalization passes that only -O turns on, so running individual passes in isolation wouldn't be useful anyway.

• -Os — Optimize for size 🧸 -Os enables all the -O2 optimizations except the ones that often make code bigger:

-falign-functions  -falign-jumps -falign-labels  -falign-loops
-fprefetch-loop-arrays  -freorder-blocks-algorithm=stc

It also enables -finline-functions, makes the compiler tune for code size instead of execution speed, and runs extra optimizations designed to shrink code 📉

• -Ofast — Disregard strict standards compliance 😤 -Ofast enables all -O3 optimizations, plus optimizations that aren't valid for every standard-compliant program. It turns on -ffast-math, -fallow-store-data-races, and the Fortran-specific -fstack-arrays (unless -fmax-stack-var-size is specified), and -fno-protect-parens. It turns off -fsemantic-interposition 💀
• -Og — Optimize the debugging experience 🔍 -Og should be your go-to level for the standard edit-compile-debug cycle. It offers a reasonable amount of optimization while keeping compilation fast and debugging smooth 🫶 It's a better pick than -O0 for debuggable code, because some compiler passes that collect debug information are disabled at -O0.

Like -O0, -Og completely disables a number of optimization passes, so the individual options that control them have no effect. Otherwise, -Og enables all the -O1 optimization flags except the ones that can get in the way of debugging:

-fbranch-count-reg  -fdelayed-branch -fdse  -fif-conversion
-fif-conversion2 -finline-functions-called-once
-fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt
-ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra

• -Oz — Optimize aggressively for size rather than speed 🐣 This may increase the number of instructions executed if those instructions need fewer bytes to encode. -Oz behaves similarly to -Os, including enabling most -O2 optimizations.

If you use multiple -O options, with or without level numbers, the last one is the one that takes effect 🙃

---

✨ -f flags ✨

Options of the form -fflag are machine-independent flags 🦋 Most flags have both a positive and a negative form, and the negative form of -ffoo is -fno-foo. The table below only lists one of the forms, the one you'll typically use. You can figure out the other one by either removing no- or adding it 💜

The following options control specific optimizations. They're either activated by -O options or related to ones that are. You can use these flags in the rare cases when "fine-tuning" the optimizations to be performed is needed 🎯

• -fno-defer-pop — For machines that have to pop arguments after a function call, this always pops the arguments as soon as each function returns 🧹 At -O1 and higher, -fdefer-pop is the default, which lets the compiler let arguments pile up on the stack across several function calls and pop them all at once.
• -fforward-propagate — Performs a forward propagation pass on RTL ✨ The pass tries to combine two instructions and checks whether the result can be simplified. If loop unrolling is active, two passes run, and the second one is scheduled after loop unrolling.

This option is enabled by default at optimization levels -O1, -O2, -O3, -Os.

• -favoid-store-forwarding, -fno-avoid-store-forwarding — Many CPUs stall for many cycles when a load partially depends on previous smaller stores 😩 This pass tries to detect those cases and dodge the penalty by changing the order of the load and store, then fixing up the loaded value.

Disabled by default.

• -ffp-contract=style — -ffp-contract=off disables floating-point expression contraction. -ffp-contract=fast enables it, such as forming fused multiply-add operations when the target has native support for them. -ffp-contract=on enables contraction if the language standard allows it. This is implemented for C and C++, where it enables contraction within one expression, but not across different statements 🧮

The default is -ffp-contract=off for C in a standards compliant mode (-std=c11 or similar), and -ffp-contract=fast otherwise.

• -fomit-frame-pointer — Omits the frame pointer in functions that don't need one 🌙 This skips the instructions that save, set up, and restore the frame pointer, and on many targets it also frees up an extra register.

On some targets this flag does nothing, because the standard calling sequence always uses a frame pointer, so it can't be omitted 🙈

Note that -fno-omit-frame-pointer doesn't guarantee the frame pointer is used in all functions. Several targets always omit the frame pointer in leaf functions.

Enabled by default at -O1 and higher. 💖

• -foptimize-crc — okay so this one is 🔥. GCC hunts down loops that do CRC calculations (that polynomial long division thing) and swaps them for a much faster version. It can spot 8, 16, 32, and 64 bit CRCs with a constant polynomial that doesn't include the leading 1 bit, in both bit-forward and bit-reversed flavours. If your target has a CRC instruction and the polynomial in your code matches the one that instruction uses, GCC generates that instruction. If not, but the target has a carry-less-multiplication instruction, it generates CRC with that. Otherwise, it falls back to a table-based CRC. 💅

Enabled by default at -O2 and higher. ✨

• -foptimize-sibling-calls — optimizes sibling and tail recursive calls. Main character energy 👑

Enabled at levels -O2, -O3, -Os. 🌸

• -foptimize-strlen — makes various standard C string functions (like "strlen", "strchr" or "strcpy") and their "_FORTIFY_SOURCE" counterparts run faster by swapping in quicker alternatives. 🧚

Enabled at levels -O2, -O3. 🫶

• -finline-stringops[=fn] — expands memory and string operations inline (for now, only "memset"), even when the length is variable or big enough that it'd normally need a loop. This is most useful alongside -ffreestanding and -fno-builtin. 🍓

Sometimes it can use known alignment and length multipliers to make nicer code, but even then it might be less efficient than optimized runtime implementations. It can also bloat your code size so much that a slower but shared implementation actually runs faster, thanks to better use of code caches. 😭 This option is disabled by default.

• -fno-inline — don't expand any functions inline, except the ones marked with the "always_inline" attribute. This is the default when you're not optimizing. 🙈

You can exempt individual functions from inlining by marking them with the "noinline" attribute. 🦋

• -finline-small-functions — integrates functions into their callers when their body is smaller than the code for the function call itself, so the overall program gets smaller. GCC heuristically decides which functions are simple enough to be worth it. This applies to all functions, even ones not declared inline. ✨

Enabled at levels -O2, -O3, -Os. 💖

• -findirect-inlining — also inlines indirect calls that become known at compile time thanks to earlier inlining. This only has an effect when inlining is turned on by -finline-functions or -finline-small-functions. 🔥

Enabled at levels -O2, -O3, -Os. 🌈

• -finline-functions — considers all functions for inlining, even if they aren't declared inline. GCC heuristically decides which ones are worth integrating. 🧚

If every call to a given function gets integrated and the function is declared "static", then it's normally not output as assembler code on its own. Iconic. 👑

Enabled at levels -O2, -O3, -Os. Also enabled by -fprofile-use and -fauto-profile. 💅

• -finline-functions-called-once — considers all "static" functions that get called once for inlining into their caller, even if they aren't marked "inline". If the call gets integrated, the function isn't output as assembler code by itself. 🎀

Enabled at levels -O1, -O2, -O3 and -Os, but not -Og. 🙈

• -fearly-inlining — inlines functions marked by "always_inline", plus functions whose body seems smaller than the function call overhead, early, before the -fprofile-generate instrumentation and the real inlining pass. Doing this makes profiling way cheaper and usually makes inlining faster for programs with big chains of nested wrapper functions. 🦋

Enabled by default. ✨

• -fipa-sra — performs interprocedural scalar replacement of aggregates, removes unused parameters, and swaps parameters passed by reference for parameters passed by value. 🌸

Enabled at levels -O2, -O3 and -Os. 💜

• -finline-limit=n — by default GCC limits the size of functions that can be inlined. This flag gives you coarse control over that limit. n is the size of functions that can be inlined, measured in pseudo instructions. 🧚

Inlining is actually controlled by a bunch of parameters, which you can set one at a time with --param name=value. The -finline-limit=n option sets some of them like this:

• max-inline-insns-single — is set to n/2.
• max-inline-insns-auto — is set to n/2.

See below for documentation on the individual parameters controlling inlining and for their defaults. 🫶

Note: there may be no value of -finline-limit that results in default behavior. 💀

Note: "pseudo instruction" here is just an abstract measurement of a function's size. It in no way counts assembly instructions, so its exact meaning might change from one release to another. 🙈

• -fno-keep-inline-dllexport — a more fine-grained version of -fkeep-inline-functions, which only applies to functions declared with the "dllexport" attribute or declspec. 🌈
• -fkeep-inline-functions — in C, emits "static" functions declared "inline" into the object file, even if they've been inlined into all of their callers. This switch doesn't affect functions using the "extern inline" extension in GNU C90. In C++, it emits any and all inline functions into the object file. 💖
• -fkeep-static-functions — emits "static" functions into the object file, even if they're never used. 🍓
• -fkeep-static-consts — emits variables declared "static const" when optimization isn't turned on, even if they aren't referenced. 💜

GCC enables this one by default. If you want the compiler to check whether a variable is referenced, regardless of optimization, use -fno-keep-static-consts. 👀

• -fmerge-constants — tries to merge identical constants (string constants and floating-point constants) across compilation units. 🫶

This is the default for optimized compilation if the assembler and linker support it. Use -fno-merge-constants to stop this from happening. Enabled at levels -O1, -O2, -O3, -Os. ✨

• -fmerge-all-constants — tries to merge identical constants and identical variables. 🔥

This option implies -fmerge-constants. On top of that, it also considers things like constant initialized arrays, or initialized constant variables with integral or floating-point types. Careful, bestie! C and C++ require each variable, including multiple instances of the same variable in recursive calls, to have distinct locations, so using this option results in non-conforming behavior. 💀

• -fmodulo-sched — performs swing modulo scheduling right before the first scheduling pass. It looks at innermost loops and reorders their instructions by overlapping different iterations. 🧚
• -fmodulo-sched-allow-regmoves — performs more aggressive SMS-based modulo scheduling with register moves allowed. Setting this flag deletes certain anti-dependence edges, which triggers the generation of reg-moves based on life-range analysis. 🦋

This option only works when -fmodulo-sched is also enabled. 🌸

• -fno-branch-count-reg — disables the optimization pass that looks for chances to use "decrement and branch" instructions on a count register, instead of instruction sequences that decrement a register, compare it against zero, and then branch based on the result. This only matters on architectures that support those instructions, which include x86, PowerPC, IA-64 and S/390. 🎀

Heads up: -fno-branch-count-reg doesn't remove decrement and branch instructions that other optimization passes already put into the instruction stream. 🙈

The default is -fbranch-count-reg at -O1 and higher, except for -Og. 💅

• -fno-function-cse — doesn't put function addresses in registers. Instead, every instruction that calls a constant function contains the function's address explicitly. 🌈

This gives you less efficient code, but some strange hacks that alter the assembler output might get confused by the optimizations performed when this option is not used. 😭

The default is -ffunction-cse

• -fno-zero-initialized-in-bss — if the target supports a BSS section, GCC by default puts variables initialized to zero into BSS, which can save space in the resulting code. ✨

This option turns that behavior off, because some programs explicitly rely on variables going to the data section, e.g. so the resulting executable can find the beginning of that section and/or make assumptions based on it. 🫶

The default is -fzero-initialized-in-bss except in Ada. 💜

• -fthread-jumps — performs optimizations that check whether a jump branches to a location where another comparison, subsumed by the first, is found. If so, the first branch gets redirected to either the destination of the second branch or a point right after it, depending on whether the condition is known to be true or false. 🧚

Enabled at levels -O1, -O2, -O3, -Os. 🌸

• -fsplit-wide-types — when using a type that occupies multiple registers, like "long long" on a 32-bit system, GCC splits the registers apart and allocates them independently. This usually generates better code for those types, but it may make debugging harder. 🔥

Enabled at levels -O1, -O2, -O3, -Os. 💅

• -fsplit-wide-types-early — fully splits wide types early, instead of very late. This option does nothing unless -fsplit-wide-types is turned on. 🎀

This is the default on some targets. 👑

• -fcse-follow-jumps — during common subexpression elimination (CSE), scans through jump instructions when the jump's target isn't reached by any other path. For example, when CSE meets an "if" statement with an "else" clause, it follows the jump when the condition tested is false. 👀

Enabled at levels -O2, -O3, -Os. 💖

• -fcse-skip-blocks — similar to -fcse-follow-jumps, but this makes CSE follow jumps that conditionally skip over blocks. When CSE meets a simple "if" statement with no "else" clause, -fcse-skip-blocks makes CSE follow the jump around the body of the "if". 🦋

Okay so this next batch is all about the -f flags that squeeze extra juice out of your code 🧃✨ Keep reading, bestie, it's giving optimization main character energy 💅

Enabled at levels -O2, -O3, -Os. 🌸

• -frerun-cse-after-loop — okay so this one re-runs common subexpression elimination after the loop optimizations are done, because why not do it twice, periodt 🔁

Enabled at levels -O2, -O3, -Os. 💖

• -fgcse — this one runs a global common subexpression elimination pass 🔥 It also handles global constant and copy propagation too, so it's pulling double duty.

Note: if you're compiling a program that uses computed gotos (a GCC extension, not standard C, so be aware 👀), you might get better run-time performance by turning off this pass. Just add -fno-gcse to your command line.

Enabled at levels -O2, -O3, -Os. ✨

• -fgcse-lm — when this one is on, global common subexpression elimination tries to move loads that only get killed by stores into themselves 🧚 That means a loop with a load/store sequence can be rearranged so the load happens outside the loop, and a copy/store happens inside it.

Enabled by default when -fgcse is enabled. 🦋

• -fgcse-sm — this one turns on a store motion pass after global common subexpression elimination 🎀 It tries to pull stores out of loops. Team it up with -fgcse-lm and loops with a load/store sequence can become a load before the loop and a store after it, iykyk 🫶

Not enabled at any optimization level. 🙈

• -fgcse-las — with this one on, the global common subexpression elimination pass gets rid of redundant loads that come right after stores to the same memory location. It catches both partial and full redundancies, so it's thorough af 💅

Not enabled at any optimization level. 🙈

• -fgcse-after-reload — when enabled, this one runs a redundant load elimination pass after reload 🧹 Its whole purpose is to clean up redundant spilling, very much a tidy-up girl.

Enabled by -O3, -fprofile-use and -fauto-profile. ⭐

• -faggressive-loop-optimizations — this one tells the loop optimizer to use language constraints to work out bounds for the number of iterations of a loop 🧠 It assumes your loop code doesn't invoke undefined behavior, like causing signed integer overflows or out-of-bound array accesses. Those bounds then guide loop unrolling, loop peeling and loop exit test optimizations.

This option is enabled by default. 👑

• -funconstrained-commons — this tells the compiler that variables declared in common blocks (for example in Fortran) might later be overridden with longer trailing arrays 🌈 Because of that, it stops certain optimizations that depend on knowing the array bounds. Bit of a trade-off, bestie.
• -fcrossjumping — this performs the cross-jumping transformation, which unifies equivalent code and saves code size 📦 Heads up though: the resulting code may or may not perform better than without cross-jumping, so it's a vibe check, not a guarantee 🤷‍♀️

Enabled at levels -O2, -O3, -Os. 💜

• -fauto-inc-dec — this combines increments or decrements of addresses with memory accesses 🍓 This pass is always skipped on architectures that don't have instructions to support it.

Enabled by default at -O1 and higher on architectures that support this. ✨

• -fdce — performs dead code elimination (DCE) on RTL 🗑️ Bye bye, useless code.

Enabled by default at -O1 and higher. 🌸

• -fdse — performs dead store elimination (DSE) on RTL 💀 Stores that nobody reads? Gone.

Enabled by default at -O1 and higher. 🌸

• -fif-conversion — this tries to transform conditional jumps into branch-less equivalents 🪄 It includes conditional moves, min, max, set flags and abs instructions, plus some tricks you can do with standard arithmetic. Whether conditional execution gets used on chips that support it is controlled by -fif-conversion2.

Enabled at levels -O1, -O2, -O3, -Os, but not with -Og. 🎀

• -fif-conversion2 — uses conditional execution (where available) to transform conditional jumps into branch-less equivalents 💫

Enabled at levels -O1, -O2, -O3, -Os, but not with -Og. 🎀

• -fdeclone-ctor-dtor — okay this one is a whole story 📖 The C++ ABI needs multiple entry points for constructors and destructors: one for a base subobject, one for a complete object, and one for a virtual destructor that calls operator delete afterwards. For a hierarchy with virtual bases, the base and complete variants are clones, which means two copies of the function. With this option, those two variants become thunks that call a common implementation, so you only keep one real copy 🧚‍♀️

Enabled by -Os. 💅

• -fdelete-null-pointer-checks — this one assumes programs can't safely dereference null pointers, and that no code or data element lives at address zero 🙅‍♀️ It enables simple constant folding optimizations at all optimization levels. Other passes in GCC use this flag to control global dataflow analyses that get rid of useless null pointer checks. Those analyses assume that a memory access to address zero always results in a trap, so if a pointer gets checked after it's already been dereferenced, it can't be null.

Careful, bestie: in some environments this assumption isn't true. If your program depends on that behavior, use -fno-delete-null-pointer-checks to turn this optimization off 🚨

This option is enabled by default on most targets. On AVR and MSP430, this option is completely disabled. 😭

Passes that use the dataflow information are enabled independently at different optimization levels. 🌈

• -fdevirtualize — tries to convert calls to virtual functions into direct calls 🎯 This happens both within a procedure and interprocedurally, as part of indirect inlining (-findirect-inlining) and interprocedural constant propagation (-fipa-cp).

Enabled at levels -O2, -O3, -Os. ✨

• -fdevirtualize-speculatively — this one tries to convert calls to virtual functions into speculative direct calls 🔮 Based on the analysis of the type inheritance graph, it figures out the set of likely targets for a given call. If that set is small, ideally of size 1, the call becomes a conditional that picks between a direct call and an indirect call. Those speculative calls unlock more optimizations, like inlining. If they seem useless after further optimization, they get converted back into their original form.
• -fdevirtualize-at-ltrans — this streams extra information needed for aggressive devirtualization when the link-time optimizer runs in local transformation mode 🚛 It enables more devirtualization, but it significantly increases the size of the streamed data. For that reason it's disabled by default.
• -fexpensive-optimizations — performs a number of minor optimizations that are relatively expensive 💸

Enabled at levels -O2, -O3, -Os. 💖

• -free — attempts to remove redundant extension instructions 🧼 This is especially helpful for the x86-64 architecture, which implicitly zero-extends in 64-bit registers after writing to their lower 32-bit half.

Enabled for Alpha, AArch64, LoongArch, PowerPC, RISC-V, SPARC, h83000 and x86 at levels -O2, -O3, -Os. 🌟

• -fno-lifetime-dse — in C++, an object's value only gets affected by changes within its lifetime 🕰️ When the constructor begins, the object has an indeterminate value, and any changes during its lifetime are dead once it's destroyed. Normally dead store elimination takes advantage of this. If your code relies on the object storage persisting beyond the object's lifetime, use this flag to disable the optimization. To keep stores made before the constructor starts (for example, because your operator new clears the object storage) but still treat the object as dead after the destructor, you can use -flifetime-dse=1. The default behavior can be explicitly selected with -flifetime-dse=2. And -flifetime-dse=0 is equivalent to -fno-lifetime-dse. 🫶
• -flive-range-shrinkage — attempts to decrease register pressure through register live range shrinkage 🌬️ It's helpful for fast processors with small or moderate size register sets.
• -fira-algorithm=algorithm — picks the coloring algorithm for the integrated register allocator 🎨 The algorithm argument can be priority, which specifies Chow's priority coloring, or CB, which specifies Chaitin-Briggs coloring. Chaitin-Briggs coloring isn't implemented for all architectures, but on the targets that do support it, it's the default because it generates better code 👑
• -fira-region=region — lets you choose the regions the integrated register allocator uses 🗺️ The region argument should be one of the following:
  • all — uses all loops as register allocation regions. This can give the best results for machines with a small and/or irregular register set 💜
  • mixed — uses all loops except for loops with small register pressure as the regions. This value usually gives the best results in most cases and for most architectures, and it's enabled by default when compiling with optimization for speed (-O, -O2, ...) 🔥
  • one — uses all functions as a single region. This typically results in the smallest code size, and it's enabled by default for -Os or -O0 🍓
• -fira-hoist-pressure — uses IRA to evaluate register pressure in the code hoisting pass when deciding whether to hoist expressions 🏗️ This option usually results in smaller code, but it can slow the compiler down.

This option is enabled at level -Os for all targets. 🌸

• -fira-loop-pressure — uses IRA to evaluate register pressure in loops when deciding whether to move loop invariants 🔁 This usually results in faster and smaller code on machines with large register files (>= 32 registers), but it can slow the compiler down too.

This option is enabled at level -O3 for some targets. ✨

• -fno-ira-share-save-slots — disables sharing of stack slots used for saving call-used hard registers that live through a call 🙅‍♀️ Each hard register gets its own stack slot, so function stack frames end up larger.
• -fno-ira-share-spill-slots — disables sharing of stack slots allocated for pseudo-registers 🙅‍♀️ Each pseudo-register that doesn't get a hard register gets its own stack slot, so, yep, the stack frames are larger.
• -flra-remat — enables CFG-sensitive rematerialization in LRA 🧙‍♀️ Instead of loading values of spilled pseudos, LRA tries to rematerialize (recalculate) them when that's profitable.

Enabled at levels -O2, -O3, -Os. 💅

• -fdelayed-branch — 🧚 If the target machine supports it, the compiler tries to shuffle instructions around so they fill the empty slots right after delayed branch instructions. Enabled at levels -O1, -O2, -O3, -Os, but not at -Og. 💅
• -fschedule-insns — ✨ If the target supports it, the compiler reorders instructions so the CPU isn't left twiddling its thumbs waiting for data that isn't ready yet. This is a lifesaver on machines with slow floating point or memory loads, because other instructions can get issued while the load or float op is still cooking. Conventionally enabled at -O2 and -O3. However, many targets override this. For example, on x86 it's disabled at all levels, while on AArch64 it's only enabled at -O3. 🙈
• -fschedule-insns2 — 🎀 Basically the same vibe as -fschedule-insns, but this one asks for an extra scheduling pass after register allocation is done. It's especially useful on machines with a relatively small number of registers, where memory loads take more than one cycle. Enabled at levels -O2, -O3, -Os. 🔥
• -fno-sched-interblock — 🚫 Turns off instruction scheduling across basic blocks. This is normally on when scheduling happens before register allocation, i.e. with -fschedule-insns or at -O2 or higher. 🦋
• -fno-sched-spec — 🙅‍♀️ Turns off speculative motion of non-load instructions. This is normally on when scheduling happens before register allocation, i.e. with -fschedule-insns or at -O2 or higher. 💜
• -fsched-pressure — 🌸 Turns on register pressure sensitive instruction scheduling before register allocation. This only makes sense when that kind of scheduling is on, i.e. with -fschedule-insns or at -O2 or higher. Using it can improve the generated code and shrink its size, because it stops register pressure from climbing above the number of available hard registers, which means fewer spills during register allocation. 👑
• -fsched-spec-load — 🍓 Lets the compiler speculatively move some load instructions. Again, this only makes sense when scheduling happens before register allocation, i.e. with -fschedule-insns or at -O2 or higher. ✨
• -fsched-spec-load-dangerous — 😭 Lets the compiler speculatively move more load instructions. Same deal: it only makes sense when scheduling happens before register allocation, i.e. with -fschedule-insns or at -O2 or higher. This one is spicy, bestie, so proceed with care. 💀
• -fsched-stalled-insns, -fsched-stalled-insns=n — 🧚 Decides how many instructions (if any) can be yanked early from the queue of stalled instructions and dropped into the ready list during the second scheduling pass. -fno-sched-stalled-insns means no instructions get moved early. -fsched-stalled-insns=0 means there's no limit at all on how many queued instructions can be moved early. Using -fsched-stalled-insns with no value is the same as -fsched-stalled-insns=1. ⭐
• -fsched-stalled-insns-dep, -fsched-stalled-insns-dep=n — 🔍 Sets how many instruction groups (cycles) get checked for a dependency on a stalled instruction that's a candidate for being moved early. This only has an effect during the second scheduling pass, and only if -fsched-stalled-insns is being used. -fno-sched-stalled-insns-dep is the same as -fsched-stalled-insns-dep=0. Using -fsched-stalled-insns-dep with no value is the same as -fsched-stalled-insns-dep=1. 🫶
• -fsched2-use-superblocks — 🌈 When scheduling after register allocation, this uses superblock scheduling. That lets instructions move across basic block boundaries, which can give you faster schedules. ⚠️ This option is experimental, because not all machine descriptions used by GCC model the CPU closely enough to avoid unreliable results from the algorithm, so it's not guaranteed to be trustworthy yet. It only makes sense when scheduling after register allocation, i.e. with -fschedule-insns2 or at -O2 or higher. 🧪

⚠️ Heads up, bestie: -fsched2-use-superblocks is experimental. Some machine descriptions don't model the CPU closely enough, so the results can be unreliable. Use it with your eyes open. 👀

• -fsched-group-heuristic — 💖 Turns on the group heuristic in the scheduler. This heuristic favors the instruction that belongs to a schedule group. It's enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. 🎀
• -fsched-critical-path-heuristic — 🛤️ Turns on the critical-path heuristic in the scheduler. This one favors instructions that sit on the critical path. It's enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. 👑
• -fsched-spec-insn-heuristic — 🦄 Turns on the speculative instruction heuristic in the scheduler. It favors speculative instructions with greater dependency weakness. Enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. ✨
• -fsched-rank-heuristic — 🏅 Turns on the rank heuristic in the scheduler. It favors the instruction living in a basic block with greater size or frequency. Enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. 🌸
• -fsched-last-insn-heuristic — 🎯 Turns on the last-instruction heuristic in the scheduler. It favors the instruction that is less dependent on the last instruction scheduled. Enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. 💅
• -fsched-dep-count-heuristic — 📈 Turns on the dependent-count heuristic in the scheduler. It favors the instruction that has more instructions depending on it. Enabled by default whenever scheduling is enabled, i.e. with -fschedule-insns, -fschedule-insns2, or at -O2 or higher. 🫶
• -freschedule-modulo-scheduled-loops — 🔁 Modulo scheduling happens before the traditional scheduling. If a loop gets modulo scheduled, later scheduling passes are allowed to change its schedule. Use this option to control that behavior. 🧚
• -fselective-scheduling — 🎀 Schedules instructions using the selective scheduling algorithm. Selective scheduling runs instead of the first scheduler pass. 💜
• -fselective-scheduling2 — 🦋 Schedules instructions using the selective scheduling algorithm too, but this time it runs instead of the second scheduler pass. 🌈
• -fsel-sched-pipelining — 🌀 Enables software pipelining of innermost loops during selective scheduling. This does nothing unless -fselective-scheduling or -fselective-scheduling2 is turned on. 🍓
• -fsel-sched-pipelining-outer-loops — 🪆 When pipelining loops during selective scheduling, this also pipelines the outer loops. It has no effect unless -fsel-sched-pipelining is turned on. ✨
• -fsemantic-interposition — 🧐 Some object formats, like ELF, let the dynamic linker interpose symbols. That means that for symbols exported from the DSO, the compiler can't do interprocedural propagation, inlining, or other optimizations, because the function or variable might get swapped out at runtime. Interposition is useful, for example, when you want to replace memory allocation functions with a debugging implementation, but it costs you a lot in code quality. With -fno-semantic-interposition, the compiler assumes that if interposition happens for functions, the overwriting function will have precisely the same semantics (and side effects). Similarly, if interposition happens for variables, the constructor of the variable will be the same. This flag has no effect on functions explicitly declared inline (where interposition is never allowed to change semantics), and it has no effect on symbols explicitly declared weak. 💜
• -fshrink-wrap — 🎁 Emits function prologues only before the parts of the function that actually need them, instead of at the very top of the function. Enabled by default at -O and higher. ✨
• -fshrink-wrap-separate — ✂️ Shrink-wraps the separate parts of the prologue and epilogue on their own, so those parts only run when they're needed. This option is on by default, but it has no effect unless -fshrink-wrap is also turned on and the target supports this. 🌸
• -fcaller-saves — 💾 Lets the compiler allocate values to registers that get clobbered by function calls, by emitting extra instructions to save and restore those registers around such calls. That allocation only happens when it seems to produce better code. This option is always enabled by default on certain machines, usually the ones with no call-preserved registers to use instead. Enabled at levels -O2, -O3, -Os. 🫶
• -fcombine-stack-adjustments — 🥞 Tracks stack adjustments (pushes and pops) and stack memory references, then tries to find ways to combine them. Enabled by default at -O1 and higher. 🦄
• -fipa-ra — 🧠 Lets the compiler use caller-save registers for allocation if those registers aren't used by any called function. In that case, there's no need to save and restore them around calls. This is only possible if the called functions are part of the same compilation unit as the current function and they're compiled before it. Enabled at levels -O2, -O3, -Os. However, the option is disabled if the generated code will be instrumented for profiling (-p, or -pg), or if the callee's register usage can't be known exactly (which happens on targets that don't expose prologues and epilogues in RTL). 🔍
• -fconserve-stack — 🪶 Tries to minimize stack usage. The compiler works to use less stack space, even if that makes the program slower. This option implies setting the large-stack-frame parameter to 100 and the large-stack-frame-growth parameter to 400. 🌙
• -ftree-reassoc — 🌳 Performs reassociation on trees. Enabled by default at -O1 and higher. 💅
• -fcode-hoisting — 🏗️ Performs code hoisting. This tries to move the evaluation of expressions that run on all paths to the function exit as early as possible. It's especially useful as a code size optimization, but it often helps code speed too. Enabled by default at -O2 and higher. ✨
• -ftree-pre — 🔮 Performs partial redundancy elimination (PRE) on trees. Enabled by default at -O2 and -O3. 🎀
• -ftree-partial-pre — 🔥 Makes partial redundancy elimination (PRE) more aggressive. Enabled by default at -O3. 👑
• -ftree-forwprop — ➡️ Performs forward propagation on trees. Enabled by default at -O1 and higher. 🦋
• -ftree-fre — okay so this one does full redundancy elimination (FRE) on trees 💅. The difference between FRE and PRE is that FRE only looks at expressions that are computed on all paths leading to the redundant computation. It's faster than PRE, though it catches fewer redundancies 🫶. This flag is enabled by default at -O1 and higher ✨.
• -ftree-phiprop — this one hoists loads from conditional pointers on trees 🦋. It's enabled by default at -O1 and higher.
• -fhoist-adjacent-loads — ngl this one is so cute 🎀. It speculatively hoists loads from both branches of an if-then-else, but only when the loads come from adjacent locations in the same structure and the target architecture has a conditional move instruction. It's enabled by default at -O2 and higher.
• -ftree-copy-prop — copy propagation on trees, bestie 🧚. It gets rid of unnecessary copy operations. Enabled by default at -O1 and higher.
• -fipa-pure-const — this one figures out which functions are pure or constant 🔮. Enabled by default at -O1 and higher.
• -fipa-reference — this one finds out which static variables don't escape the compilation unit 🌸. Enabled by default at -O1 and higher.
• -fipa-reference-addressable — this one discovers read-only, write-only and non-addressable static variables 💜. Enabled by default at -O1 and higher.
• -fipa-reorder-for-locality — main character energy 👑. It groups call chains close together in the binary layout, which improves code locality and shortens jump distances between functions that get called a lot 🌈. Unlike -freorder-functions, this pass looks at the call chains between functions and clusters them together, instead of sorting everything into separate hot/normal/cold/never-executed sections. Unlike -fprofile-reorder-functions, it's going for locality across the whole runtime of the program, not just startup 🚀.

This option is incompatible with an explicit -flto-partition= option, since it enforces its own custom partitioning scheme. If you use it, it's recommended to also use profile feedback, but this option is not enabled by default otherwise 💀.

• -fipa-stack-alignment — reduces stack alignment on call sites when it's possible ✨. Enabled by default.
• -fipa-pta — interprocedural pointer analysis plus interprocedural modification and reference analysis 🧐.

This one can cause excessive memory and compile-time usage on large compilation units, so be careful 😭. It is not enabled by default at any optimization level.

• -fipa-profile — interprocedural profile propagation 🍓. Functions that are only called from cold functions get marked as cold, and functions that run once (like "cold", "noreturn", static constructors or destructors) get identified too. Cold functions, plus the loop-less parts of functions that run once, then get optimized for size. Enabled by default at -O1 and higher.
• -fipa-modref — interprocedural mod/ref analysis 💖. It analyzes the side effects of functions (the memory locations they modify or reference), which allows better optimization across the function call boundary. Enabled by default at -O1 and higher.
• -fipa-cp — interprocedural constant propagation 🔥. It figures out when values passed to functions are constants, then optimizes accordingly. This can seriously boost performance if your app passes constants into functions. Enabled by default at -O2, -Os and -O3, and also enabled by -fprofile-use and -fauto-profile.
• -fipa-cp-clone — function cloning to make interprocedural constant propagation stronger 🦋. When enabled, it clones externally visible functions that can be called with constant arguments. Since this can create multiple copies of functions, it may significantly increase code size (see --param ipa-cp-unit-growth=value) ⚠️. Enabled by default at -O3, and also enabled by -fprofile-use and -fauto-profile.
• -fipa-bit-cp — when enabled, does interprocedural bitwise constant propagation 🎀. Enabled by default at -O2, and also by -fprofile-use and -fauto-profile. It requires that -fipa-cp is enabled.
• -fipa-vrp — when enabled, does interprocedural propagation of value ranges 📏. Enabled by default at -O2. It requires that -fipa-cp is enabled.
• -fipa-icf — Identical Code Folding for functions and read-only variables 🧊. It shrinks code size, but it can mess with unwind stacks, because a function gets replaced by an equivalent one with a different name 🙈. It works better with link-time optimization turned on.

Although it's similar to the Gold Linker's ICF optimization, GCC's ICF works on different levels, so the optimizations aren't the same. Some equivalences are only found by GCC, and some are only found by Gold 🤓.

This flag is enabled by default at -O2 and -Os.

• -flate-combine-instructions — turns on two instruction combination passes that run pretty late in compilation 🧩. One runs before register allocation and the other runs after it. The main goal is to substitute definitions into all their uses. Most targets enable this by default at -O2 and -Os.
• -flive-patching=level — controls GCC's optimizations so the output is suitable for live-patching 🩹.

So here's the deal: if an optimization uses a function's body (or info pulled from its body) to optimize a different function, that other function is called an impacted function of the first one. If a function gets patched, its impacted functions should be patched too 🫶. Impacted functions are determined by the compiler's interprocedural optimizations. For example, a caller is impacted when a function gets inlined into it, when a function gets cloned and its caller is changed to call the clone, or when a function's pureness/constness info gets used to optimize its direct or indirect callers.

Usually, the more IPA optimizations you have enabled, the more impacted functions each function ends up with. To keep that number under control and make the list easier to compute, IPA optimizations can be partially enabled at two different levels 🌸.

The level argument should be one of the following:

• inline-clone — only inlining and cloning optimizations get enabled. That includes inlining, cloning, interprocedural scalar replacement of aggregates and partial inlining. So when you patch a function, all its callers and its clones' callers are impacted, and need patching too. This disables the following optimization flags: -fwhole-program -fipa-pta -fipa-reference -fipa-ra -fipa-icf -fipa-icf-functions -fipa-icf-variables -fipa-bit-cp -fipa-vrp -fipa-pure-const -fipa-reference-addressable -fipa-stack-alignment -fipa-modref
• inline-only-static — only inlining of static functions is enabled 🌙. So when you patch a static function, all its callers are impacted and need patching too. On top of everything inline-clone disables, -flive-patching=inline-only-static also disables these: -fipa-cp-clone -fipa-sra -fpartial-inlining -fipa-cp

When -flive-patching is specified without any value, the default value is inline-clone. This flag is disabled by default.

Note that -flive-patching is not supported with link-time optimization (-flto) 🚫.

• -fisolate-erroneous-paths-dereference — detects paths that trigger erroneous or undefined behavior by dereferencing a null pointer 🕵️‍♀️. It isolates those paths from the main control flow and turns the statement with the erroneous or undefined behavior into a trap. Enabled by default at -O2 and higher, and it depends on -fdelete-null-pointer-checks also being enabled.
• -fisolate-erroneous-paths-attribute — detects paths that trigger erroneous or undefined behavior because a null value is used in a way that a returns_nonnull or nonnull attribute forbids 🙅‍♀️. It isolates those paths and turns the statement into a trap, same as above. This one is not currently enabled, but it may be enabled by -O2 in the future 👀.
• -ftree-sink — forward store motion on trees 🛼. Enabled by default at -O1 and higher.
• -ftree-bit-ccp — sparse conditional bit constant propagation on trees, plus propagation of pointer alignment information 🧠. This pass only operates on local scalar variables. It's enabled by default at -O1 and higher, except for -Og, and it requires that -ftree-ccp is enabled.
• -ftree-ccp — sparse conditional constant propagation (CCP) on trees 💫. This pass only operates on local scalar variables, and it's enabled by default at -O1 and higher.
• -fssa-backprop — propagates info about how a value gets used back up the definition chain so the definitions can be simplified 🪄. For example, this pass strips sign operations if the sign of a value never matters. Enabled by default at -O1 and higher.
• -fssa-phiopt — pattern matching on SSA PHI nodes to optimize conditional code 🎯. Enabled by default at -O1 and higher, except for -Og.
• -ftree-switch-conversion — turns simple initializations in a switch into initializations from a scalar array 🍭. Enabled by default at -O2 and higher.
• -ftree-tail-merge — looks for identical code sequences, and when it finds them, replaces one with a jump to the other 🧵. This is known as tail merging or cross jumping. Enabled by default at -O2 and higher. The compilation time for this pass can be limited with the max-tail-merge-comparisons parameter and the max-tail-merge-iterations parameter.
• -ftree-cselim — conditional store elimination on trees 🌷. Enabled by default at -O1 and higher, on targets that have conditional move instructions.

Okay bestie, let's keep going with the optimization flags 💅✨

• -ftree-dce — 🧹 Does dead code elimination (DCE) on trees, aka it yeets code that never actually does anything. This one's switched on by default at -O1 and higher, so you get it for free 💖
• -ftree-builtin-call-dce — 🎀 Does conditional DCE for calls to built-in functions that might set errno but otherwise have no side effects. It's on by default at -O2 and higher, but only if -Os isn't also specified. Main character energy, but make sure you're not stacking -Os in there 🙈
• -ffinite-loops — 🔁 Tells the compiler to assume that a loop with an exit will eventually take that exit and won't loop forever. That lets it remove loops that have no side effects, and it doesn't count eventual endless looping as a side effect. This is turned on by default at -O2 for C++ with -std=c++11 or higher 👑
• -ftree-dominator-opts — 🧼 Runs a bunch of simple scalar cleanups based on a dominator tree traversal: constant/copy propagation, redundancy elimination, range propagation, and expression simplification. It also does jump threading, which reduces jumps to jumps ✨ Enabled by default at -O1 and higher.
• -ftree-dse — 🗑️ Does dead store elimination (DSE) on trees. A dead store is a store into a memory location that gets overwritten by another store later on with no loads in between, so the earlier store can be deleted 🦋 Enabled by default at -O1 and higher.
• -ftree-ch — 🔄 Does loop header copying on trees. It's super beneficial because it makes code motion optimizations more effective, and it also saves one jump 🌸 Enabled by default at -O1 and higher, but NOT for -Os, since it usually bumps up code size.
• -ftree-loop-optimize — 🌀 Does loop optimizations on trees. Enabled by default at -O1 and higher 💜
• -ftree-loop-linear, -floop-strip-mine, -floop-block — 🧩 Loop nest optimizations. These are the same as -floop-nest-optimize. To actually use this transformation, GCC has to be configured with --with-isl so the Graphite loop transformation infrastructure gets turned on 🛠️
• -fgraphite-identity — 🪞 Enables the identity transformation for Graphite. For every SCoP, it builds the polyhedral representation and transforms it back into GIMPLE. This is how you can check the costs or benefits of the GIMPLE -> GRAPHITE -> GIMPLE round trip 🔍 Along the way the isl code generator does some minimal optimizations too, like index splitting and dead code elimination in loops.
• -floop-nest-optimize — 🌟 Turns on the isl-based loop nest optimizer. It's a generic one based on the Pluto optimization algorithms, and it calculates a loop structure that's optimized for data locality and parallelism. Heads up: this option is experimental ⚠️
• -floop-parallelize-all — 🧵 Uses the Graphite data dependence analysis to find loops that can be parallelized. It parallelizes ALL the loops that can be analyzed as having no loop carried dependences, and it does this without checking whether parallelizing them is actually profitable 💀
• -ftree-coalesce-vars — 🤝 When the program is being transformed out of SSA representation, this tries to cut down on copying by coalescing versions of different user-defined variables, not just compiler temporaries. Fair warning: this can severely limit your ability to debug an optimized program compiled with -fno-var-tracking-assignments 😭 In the negated form, this flag stops SSA coalescing of user variables. It's enabled by default if optimization is enabled, and it does very little otherwise.
• -ftree-loop-if-convert — 🪄 Tries to transform conditional jumps in the innermost loops into branch-less equivalents. The goal is to get rid of control flow in the innermost loops so the vectorization pass can handle them better. It's enabled by default if vectorization is enabled ✨
• -ftree-loop-distribution — ✂️ Performs loop distribution. This can improve cache performance on big loop bodies and lets further loop optimizations, like parallelization or vectorization, happen. Here's the vibe with a Fortran loop:

DO I = 1, N
  A(I) = B(I) + C
  D(I) = E(I) * F
ENDDO

It gets split into this:

DO I = 1, N
   A(I) = B(I) + C
ENDDO
DO I = 1, N
   D(I) = E(I) * F
ENDDO

This is enabled by default at -O3. It's also enabled by -fprofile-use and -fauto-profile 🌈

• -ftree-loop-distribute-patterns — 📚 Does loop distribution for patterns that can be code generated as calls to a library. It's enabled by default at -O2 and higher, and by -fprofile-use and -fauto-profile too. This pass distributes the initialization loops and generates a call to memset zero. Check out this loop:

DO I = 1, N
  A(I) = 0
  B(I) = A(I) + I
ENDDO

It becomes:

DO I = 1, N
   A(I) = 0
ENDDO
DO I = 1, N
   B(I) = A(I) + I
ENDDO

And then the initialization loop gets turned into a call to memset zero 🧸

• -floop-interchange — 🔀 Performs loop interchange outside of Graphite. This can improve cache performance on loop nests and lets further loop optimizations, like vectorization, take place. Like this C loop:

for (int i = 0; i < N; i++)
  for (int j = 0; j < N; j++)
    for (int k = 0; k < N; k++)
      c[i][j] = c[i][j] + a[i][k]*b[k][j];

gets flipped into this:

for (int i = 0; i < N; i++)
  for (int k = 0; k < N; k++)
    for (int j = 0; j < N; j++)
      c[i][j] = c[i][j] + a[i][k]*b[k][j];

This is enabled by default at -O3, and also by -fprofile-use and -fauto-profile 🫶

• -floop-unroll-and-jam — 🥪 Applies unroll and jam transformations on feasible loops. In a loop nest, this unrolls the outer loop by some factor and fuses the resulting multiple inner loops together. Enabled by default at -O3, and also by -fprofile-use and -fauto-profile 🔥
• -ftree-loop-im — 🚚 Performs loop invariant motion on trees. This pass only moves invariants that are hard to handle at the RTL level, like function calls and operations that expand into nontrivial sequences of insns. With -funswitch-loops, it also moves operands of conditions that are invariant out of the loop, so that trivial invariantness analysis can be used in loop unswitching. The pass also includes store motion 🧠
• -ftree-loop-ivcanon — 🔢 Creates a canonical counter for the number of iterations in loops where figuring out the iteration count takes complicated analysis. Later optimizations can then figure out the number easily. It's especially useful alongside unrolling 🌷
• -ftree-scev-cprop — 🎯 Performs final value replacement. If a variable gets modified in a loop in such a way that its value when exiting the loop can be determined using only its initial value and the number of loop iterations, then uses of the final value get replaced by that computation, as long as it's sufficiently cheap. This reduces data dependencies and may allow further simplifications. Enabled by default at -O1 and higher 💅
• -fivopts — 📈 Performs induction variable optimizations on trees: strength reduction, induction variable merging, and induction variable elimination. Enabled by default at -O1 and higher 🦄
• -ftree-parallelize-loops=n — 🧶 Parallelizes loops by splitting their iteration space so it runs in n threads. This is only possible for loops whose iterations are independent and can be arbitrarily reordered. It's only really profitable on multiprocessor machines, and only for CPU-intensive loops rather than loops that are constrained by something like memory bandwidth. This option implies -pthread, so it's only supported on targets that support -pthread 🧵
• -ftree-pta — 🔍 Performs function-local points-to analysis on trees. It's enabled by default at -O1 and higher, except for -Og 🌸
• -ftree-sra — 🪓 Performs scalar replacement of aggregates. This pass swaps structure references out for scalars, so structures don't get committed to memory too early. Enabled by default at -O1 and higher, except for -Og 💖
• -fstore-merging — 🧱 Merges narrow stores to consecutive memory addresses. It takes contiguous stores of immediate values that are narrower than a word and combines them into fewer, wider stores to cut down on instructions. Enabled by default at -O2 and higher, as well as -Os ✨
• -ftree-ter — 🔁 Performs temporary expression replacement during the SSA->normal phase. Single use/single def temporaries get replaced at their use location with their defining expression. This results in non-GIMPLE code, but it gives the expanders much more complex trees to work with, which leads to better RTL generation 🧚 Enabled by default at -O1 and higher.
• -ftree-slsr — 📐 Performs straight-line strength reduction on trees. It recognizes related expressions involving multiplications and swaps them for less expensive calculations when possible. Enabled by default at -O1 and higher 🌈
• -ftree-vectorize — 🚀 Performs vectorization on trees. This flag enables -ftree-loop-vectorize and -ftree-slp-vectorize if they aren't explicitly specified already 💜
• -ftree-loop-vectorize — 🏋️ Performs loop vectorization on trees. Enabled by default at -O2, and also by -ftree-vectorize, -fprofile-use, and -fauto-profile 🎀
• -ftree-slp-vectorize — 🍓 Performs basic block vectorization on trees. Enabled by default at -O2, and also by -ftree-vectorize, -fprofile-use, and -fauto-profile 🫧

✨ -ftrivial-auto-var-init=choice ✨

okay so this one is about initializing automatic variables 🎀 to make your program safer and more predictable by stopping uninitialized memory from leaking out or getting used 😭. GCC still treats an automatic variable with no explicit initializer as uninitialized, so -Wuninitialized and -Wanalyzer-use-of-uninitialized-value will still flag them 🚩, and the optimizer still treats them as uninitialized too. With this option, GCC also zeroes any padding in automatic variables that are structs or unions 🫶. bestie, the catch is that the current implementation can't initialize automatic variables declared between the controlling expression and the first case of a "switch" statement 💀. Use -Wtrivial-auto-var-init to report all such cases.

The three values of choice are:

• uninitialized — doesn't initialize any automatic variables at all. This is C and C++'s default 💅.
• pattern — initializes automatic variables with values that will likely turn logic bugs into crashes down the line 💥. They're easy to spot in a crash dump and aren't values programmers can rely on for real program semantics ✨. The current value is a byte-repeatable pattern with the byte 0xFE. The values used for pattern initialization might change in the future 👀.
• zero — initializes automatic variables with zeroes 🌸.

The default is uninitialized 🦋.

Note that the initializer values, whether zero or pattern, refer to the data representation (in memory or machine registers), not to how the value gets interpreted as a number 🧚. This distinction matters a lot in languages that support types with biases or implicit multipliers, and with extensions like hardbool 🔥. For example, a variable that uses 8 bits to represent (biased) quantities in the "range 160..400" will be initialized with the bit patterns 0x00 or 0xFE, depending on choice. That's true whether or not those representations stand for values in that range, and even if they do, the interpretation of the held value depends on the bias 🙈. A hardbool variable that uses say "0X5A" and 0xA5 for "false" and "true", respectively, will trap with either choice of trivial initializer. So zero initialization won't convert to the representation for "false", even though it would for a "static" variable of the same type 💀. This means the initializer pattern doesn't generally depend on the type of the initialized variable. One notable exception: (non-hardened) boolean variables that fit in registers are initialized with "false" (zero), even when pattern is requested 🫶.

You can control this behavior for a specific variable by using the variable attribute "uninitialized" 💖.

✨ -fvect-cost-model=model ✨

this one changes the cost model used for vectorization 🌈. The model argument should be one of unlimited, dynamic, cheap or very-cheap. With unlimited, the vectorized code path is assumed to be profitable 💪. With dynamic, a runtime check guards the vectorized code path so it only runs for iteration counts that will likely execute faster than the original scalar loop 🏃‍♀️. cheap disables vectorization of loops where doing so would be cost prohibitive, like when it needs runtime checks for data dependence or alignment, but otherwise it's the same as dynamic 🧁. very-cheap disables vectorization of loops whenever any runtime check for data dependence or alignment is required. It also disables vectorization of epilogue loops, but otherwise it's the same as cheap 🥲.

The default cost model depends on other optimization flags and is either dynamic or cheap ⭐.

✨ -fsimd-cost-model=model ✨

this one is like the one above, but for loops marked with the OpenMP simd directive 🦋. The model argument should be one of unlimited, dynamic, cheap. All values of model mean the same thing as described in -fvect-cost-model, and by default, a cost model defined with -fvect-cost-model is used 🫶.

✨ -ftree-vrp ✨

this turns on Value Range Propagation on trees 🌿. It's kind of like the constant propagation pass, except instead of propagating values, it propagates ranges of values ✨. That lets the optimizers remove unnecessary range checks, like array bound checks and null pointer checks 🧠. It's enabled by default at -O2 and higher. Null pointer check elimination only happens if -fdelete-null-pointer-checks is enabled 🙈.

✨ -fsplit-paths ✨

this splits paths that lead to loop backedges 🛤️. It can improve dead code elimination and common subexpression elimination 🧹. It's enabled by default at -O3 and above 🔥.

✨ -fsplit-ivs-in-unroller ✨

this lets the compiler express the values of induction variables in later iterations of an unrolled loop using the value from the first iteration 🧮. That breaks up long dependency chains, which makes the scheduling passes more efficient 🚀.

A combination of -fweb and CSE is often enough to get the same effect 💅. But that isn't reliable when the loop body is more complicated than a single basic block 😬. It also doesn't work at all on some architectures because of restrictions in the CSE pass 💀.

This optimization is enabled by default 💖.

✨ -fvariable-expansion-in-unroller ✨

with this option, the compiler makes multiple copies of some local variables when it unrolls a loop, which can result in superior code 👑.

This optimization is enabled by default for PowerPC targets, but disabled by default otherwise 🌸.

✨ -fpartial-inlining ✨

this inlines parts of functions 🧩. It only has any effect when inlining itself is turned on by the -finline-functions or -finline-small-functions options 🙃.

Enabled at levels -O2, -O3, -Os 🎀.

✨ -fpredictive-commoning ✨

this performs predictive commoning, which means reusing computations (especially memory loads and stores) that were done in previous iterations of loops 🔁.

This option is enabled at level -O3 🔥. It's also enabled by -fprofile-use and -fauto-profile 💜.

✨ -fprefetch-loop-arrays ✨

if the target machine supports it, this generates instructions to prefetch memory, which can speed up loops that access large arrays 🏎️.

This option may generate better or worse code 🫠. The results depend heavily on the structure of the loops in your source code 🙈.

Disabled at level -Os 😭.

✨ -fno-printf-return-value ✨

this stops GCC from substituting constants for the known return value of formatted output functions like "sprintf", "snprintf", "vsprintf", and "vsnprintf" (but not "printf" or "fprintf") 🙅‍♀️. That transformation lets GCC optimize or even eliminate branches based on the known return value of these functions, when they're called with arguments that are either constant or known to be in a range that makes the exact return value possible 🧠. For example, when -fprintf-return-value is in effect, both the branch and the body of the "if" statement (but not the call to "snprint") can be optimized away when i is a 32-bit or smaller integer, because the return value is guaranteed to be at most 8 🎯.

char buf[9];
if (snprintf (buf, "%08x", i) >= sizeof buf)
  ...

The -fprintf-return-value option relies on other optimizations and gives the best results with -O2 and above 💅. It works in tandem with the -Wformat-overflow and -Wformat-truncation options 🫶. The -fprintf-return-value option is enabled by default ✨.

✨ -fno-peephole and -fno-peephole2 ✨

these disable any machine-specific peephole optimizations 🔍. The difference between -fno-peephole and -fno-peephole2 is how they're implemented in the compiler 🛠️. Some targets use one, some use the other, and a few use both 🤷‍♀️.

-fpeephole is enabled by default. -fpeephole2 is enabled at levels -O2, -O3, -Os 🌈.

✨ -fno-guess-branch-probability ✨

this stops GCC from guessing branch probabilities with heuristics 🙅‍♀️.

GCC uses heuristics to guess branch probabilities when they aren't provided by profiling feedback (-fprofile-arcs) 🔮. These heuristics are based on the control flow graph 🗺️. If some branch probabilities are specified by "__builtin_expect", then the heuristics guess the probabilities for the rest of the control flow graph, taking the "__builtin_expect" info into account 🧠. The interactions between the heuristics and "__builtin_expect" can get really complex, so in some cases it might help to disable the heuristics so the effects of "__builtin_expect" are easier to understand 🥹.

You can also specify the expected probability of an expression with the "__builtin_expect_with_probability" built-in function 💖.

The default is -fguess-branch-probability at levels -O, -O2, -O3, -Os 🌸.

✨ -freorder-blocks ✨

this reorders basic blocks in the compiled function to reduce the number of taken branches and improve code locality 🧩.

Enabled at levels -O1, -O2, -O3, -Os 🎀.

✨ -freorder-blocks-algorithm=algorithm ✨

this picks the algorithm used for basic block reordering 🧭. The algorithm argument can be simple, which doesn't increase code size (except sometimes because of secondary effects like alignment) 🤏. Or it can be stc, the "software trace cache" algorithm, which tries to put all the often-executed code together and minimizes the number of branches executed by making extra copies of code 🏃‍♀️.

The default is simple at levels -O1 and -Os, and stc at levels -O2 and -O3 🌟.

✨ -freorder-blocks-and-partition ✨

in addition to reordering basic blocks in the compiled function to reduce taken branches, this partitions hot and cold basic blocks into separate sections of the assembly and .o files 🧊🔥. The goal is better paging and cache locality performance 📈.

This optimization is automatically turned off in the presence of exception handling or unwind tables (on targets using setjump/longjump or a target-specific scheme) 🙅‍♀️. It's also off for linkonce sections, for functions with a user-defined section attribute, and on any architecture that doesn't support named sections 💀. When -fsplit-stack is used, this option isn't enabled by default (to avoid linker errors), but you can still turn it on explicitly if you're using a working linker 🛠️.

Enabled for x86 at levels -O2, -O3, -Os 👑.

• -freorder-functions: okay so this one shuffles the functions in your object file around to boost code locality ✨. Unlike -fipa-reorder-for-locality, it keeps every function in the same category (hot/normal/cold/never-executed) grouped together 🫶. It does this with special subsections: ".text.hot" for the most frequently executed functions and ".text.unlikely" for the unlikely ones. The linker does the actual reordering, so your object file format has to support named sections and the linker has to place them in a reasonable way 💅.

This option isn't effective unless you either provide profile feedback (see -fprofile-arcs for details) or manually annotate functions with "hot" or "cold" attributes 🙈.

Enabled at levels -O2, -O3, -Os.

• -fstrict-aliasing: this one lets the compiler assume the strictest aliasing rules that apply to the language being compiled 🔥. For C (and C++), it turns on optimizations based on the type of expressions. The main idea is that an object of one type is assumed never to live at the same address as an object of a different type, unless the types are almost the same. For example, an "unsigned int" can alias an "int", but not a "void*" or a "double". A character type may alias any other type 💜.

Pay special attention to code like this:

union a_union {
  int i;
  double d;
};

int f() {
  union a_union t;
  t.d = 3.0;
  return t.i;
}

Reading from a different union member than the one most recently written to (called "type-punning") is super common 😭. Even with -fstrict-aliasing, type-punning is allowed, as long as the memory is accessed through the union type. So, the code above works as expected. However, this code might not:

int f() {
  union a_union t;
  int* ip;
  t.d = 3.0;
  ip = &t.i;
  return *ip;
}

Accessing memory by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior, even if the cast uses a union type. For example: int f() { double d = 3.0; return ((union a_union *) &d)->i; }

The -fstrict-aliasing option is enabled at levels -O2, -O3, -Os.

• -fipa-strict-aliasing: controls whether the rules of -fstrict-aliasing get applied across function boundaries 🦋. Heads up: if multiple functions get inlined into a single function, the memory accesses are no longer considered to be crossing a function boundary.

The -fipa-strict-aliasing option is enabled by default and is effective only in combination with -fstrict-aliasing.

• -falign-functions, -falign-functions=n, -falign-functions=n:m, -falign-functions=n:m:n2, -falign-functions=n:m:n2:m2: this lines up the start of functions to the next power-of-two that's greater than or equal to n, skipping up to m-1 bytes 🌸. That way at least the first m bytes of the function can be fetched by the CPU without crossing an n-byte alignment boundary. It's a code performance optimization, and alignment gets ignored for functions considered cold. If you need alignment for all functions, use -fmin-function-alignment instead ✨.

If m isn't specified, it defaults to n.

Examples: -falign-functions=32 aligns functions to the next 32-byte boundary, -falign-functions=24 aligns to the next 32-byte boundary only if this can be done by skipping 23 bytes or less, -falign-functions=32:7 aligns to the next 32-byte boundary only if this can be done by skipping 6 bytes or less.

The second pair of n2:m2 values lets you set a secondary alignment: -falign-functions=64:7:32:3 aligns to the next 64-byte boundary if this can be done by skipping 6 bytes or less, otherwise it aligns to the next 32-byte boundary if this can be done by skipping 2 bytes or less. If m2 isn't specified, it defaults to n2 🎀.

Some assemblers only support this flag when n is a power of two; in that case, it gets rounded up.

-fno-align-functions and -falign-functions=1 are equivalent and both mean that functions are not aligned.

If n isn't specified or is zero, the compiler uses a machine-dependent default. The maximum allowed n option value is 65536.

Enabled at levels -O2, -O3.

• -flimit-function-alignment: when this is enabled, the compiler tries to avoid overaligning functions for no reason 🧚. It tries to tell the assembler to align by the amount specified by -falign-functions, but without skipping more bytes than the size of the function.
• -falign-labels, -falign-labels=n, -falign-labels=n:m, -falign-labels=n:m:n2, -falign-labels=n:m:n2:m2: aligns all branch targets to a power-of-two boundary 🍓.

The parameters of this option work the same way as they do for -falign-functions. -fno-align-labels and -falign-labels=1 are equivalent and mean that labels are not aligned.

If -falign-loops or -falign-jumps apply and are greater than this value, then their values get used instead.

If n isn't specified or is zero, the compiler uses a machine-dependent default, which is very likely to be 1, meaning no alignment. The maximum allowed n option value is 65536.

Enabled at levels -O2, -O3.

• -falign-loops, -falign-loops=n, -falign-loops=n:m, -falign-loops=n:m:n2, -falign-loops=n:m:n2:m2: aligns loops to a power-of-two boundary 🌈. If the loops run many times, this makes up for the cost of executing the dummy padding instructions. It's a code performance optimization, and alignment is ignored for loops considered cold.

If -falign-labels is greater than this value, then its value is used instead.

The parameters of this option work the same way as they do for -falign-functions. -fno-align-loops and -falign-loops=1 are equivalent and mean that loops are not aligned. The maximum allowed n option value is 65536.

If n isn't specified or is zero, the compiler uses a machine-dependent default.

Enabled at levels -O2, -O3.

• -falign-jumps, -falign-jumps=n, -falign-jumps=n:m, -falign-jumps=n:m:n2, -falign-jumps=n:m:n2:m2: aligns branch targets to a power-of-two boundary, but only for branch targets that can only be reached by jumping 🦋. In this case, no dummy operations need to be executed. It's a code performance optimization, and alignment is ignored for jumps considered cold.

If -falign-labels is greater than this value, then its value is used instead.

The parameters of this option work the same way as they do for -falign-functions. -fno-align-jumps and -falign-jumps=1 are equivalent and mean that loops are not aligned 🙈.

If n isn't specified or is zero, the compiler uses a machine-dependent default. The maximum allowed n option value is 65536.

Enabled at levels -O2, -O3.

• -fmin-function-alignment: specifies the minimal alignment of functions to the next power-of-two greater than or equal to n 💅. Unlike -falign-functions, this alignment is applied to all functions, even the ones considered cold. The alignment also isn't affected by -flimit-function-alignment.
• -fno-allocation-dce: do not remove unused C++ allocations (using operator "new" and operator "delete") during dead code elimination 💀.

See also -fmalloc-dce.

• -fallow-store-data-races: lets the compiler perform optimizations that might introduce new data races on stores, without proving that the variable can't be accessed by other threads at the same time 🔥. It doesn't affect optimization of local data. It's safe to use this option if you know that global data won't be accessed by multiple threads.

Examples of optimizations enabled by -fallow-store-data-races include hoisting or if-conversions that might cause a value already in memory to be rewritten with that same value. That kind of rewriting is safe in a single-threaded context, but may be unsafe in a multi-threaded one. Note that on some processors, if-conversions may be required in order to enable vectorization ✨.

Enabled at level -Ofast.

• -funit-at-a-time: this one is only kept around for compatibility reasons 🫶. -funit-at-a-time has no effect, while -fno-unit-at-a-time implies -fno-toplevel-reorder and -fno-section-anchors.

Enabled by default.

• -fno-toplevel-reorder: do not reorder top-level functions, variables, and "asm" statements 👑. Output them in the same order they appear in the input file. When this option is used, unreferenced static variables are not removed. It's meant to support existing code that relies on a particular ordering. For new code, it's better to use attributes when possible.

-ftoplevel-reorder is the default at -O1 and higher, and also at -O0 if -fsection-anchors is explicitly requested. Additionally, -fno-toplevel-reorder implies -fno-section-anchors.

• -funreachable-traps: with this option, the compiler turns calls to "__builtin_unreachable" into traps, instead of using them for optimization 😭. This also affects any such calls the compiler generates implicitly.

This option has the same effect as -fsanitize=unreachable -fsanitize-trap=unreachable, but it doesn't affect the values of those options. If -fsanitize=unreachable is enabled, that option takes priority over this one.

This option is enabled by default at -O0 and -Og.

• -fweb: constructs webs as commonly used for register allocation purposes, and assigns each web its own individual pseudo register 🧚. This lets the register allocation pass work on pseudos directly, and it also strengthens several other optimization passes, such as CSE, the loop optimizer and the trivial dead code remover. It can, however, make debugging impossible, since variables no longer stay in a "home register" 🥺.

Enabled by default with -funroll-loops.

• -fwhole-program: assumes that the current compilation unit represents the whole program being compiled 💖. All public functions and variables, with the exception of main and those merged by the attribute externally_visible, become static functions, and in effect get optimized more aggressively by interprocedural optimizers 🌸.

With -flto this option has limited use, bestie 🥺 Most of the time the linker plugin already knows exactly which symbols get used or exported from the binary, and it passes that info to the link-time optimizer. It's still useful if no linker plugin is used, or during an incremental link step where the final code gets produced (with -flto -flinker-output=nolto-rel). 🦋

✨ -flto[=n] ✨

okay so this one is the standard link-time optimizer and it's giving main character 👑 When you feed it source code, it generates GIMPLE (one of GCC's internal representations) and writes it into special ELF sections in the object file. Then when the object files get linked together, all the function bodies are read back out of those ELF sections and instantiated as if they had been part of the same translation unit. iconic, right? 💅

To use the link-time optimizer, -flto and your optimization options should be specified at compile time AND during the final link. It's recommended that you compile every file in the same link with the same options, and also specify those options at link time. For example:

gcc -c -O2 -flto foo.c
gcc -c -O2 -flto bar.c
gcc -o myprog -flto -O2 foo.o bar.o

The first two invocations to GCC save a bytecode representation of GIMPLE into special ELF sections inside foo.o and bar.o. The final invocation reads the GIMPLE bytecode from foo.o and bar.o, merges the two files into a single internal image, and compiles the result as usual. Since both foo.o and bar.o get merged into one image, all the interprocedural analyses and optimizations in GCC work across the two files as if they were a single one 🤯. That means, for example, the inliner can inline functions in bar.o into functions in foo.o and vice-versa. literally so cool.

Another (simpler) way to enable link-time optimization is:

gcc -o myprog -flto -O2 foo.c bar.c

That generates bytecode for foo.c and bar.c, merges them together into a single GIMPLE representation, and optimizes them as usual to produce myprog. 🎀

The important thing to keep in mind is that to enable link-time optimizations you need to use the GCC driver to do the link step. GCC automatically performs link-time optimization if any of the objects involved were compiled with the -flto command-line option. You can always override that automatic decision by passing -fno-lto to the link command. not me needing an override button 🙈

To make whole program optimization effective, you have to make certain whole program assumptions. The compiler needs to know which functions and variables can be accessed by libraries and runtime outside of the link-time optimized unit. When the linker supports it, the linker plugin (see -fuse-linker-plugin) passes info to the compiler about used and externally visible symbols. When the linker plugin isn't available, use -fwhole-program so the compiler can make these assumptions, which leads to more aggressive optimization decisions. ✨

When a file is compiled with -flto but without -fuse-linker-plugin, the generated object file is bigger than a regular one, because it contains GIMPLE bytecodes AND the usual final code (see -ffat-lto-objects). This means object files with LTO information can be linked as normal object files. If -fno-lto is passed to the linker, no interprocedural optimizations get applied. Note that when -fno-fat-lto-objects is enabled, the compile stage is faster, but you cannot perform a regular, non-LTO link on them. 😭

When producing the final binary, GCC only applies link-time optimizations to the files that contain bytecode. So you can mix and match object files and libraries with GIMPLE bytecodes and final object code. GCC automatically picks which files to optimize in LTO mode and which files to link without further processing. 🫶

Generally, options specified at link time override those specified at compile time, although in some cases GCC tries to infer link-time options from the settings used to compile the input files.

If you don't specify an optimization level option -O at link time, GCC uses the highest optimization level used when compiling the object files. Note that it's generally ineffective to specify an optimization level option only at link time and not at compile time, for two reasons. First, compiling without optimization suppresses the compiler passes that gather the information needed for effective optimization at link time. Second, some early optimization passes can only be performed at compile time and not at link time. 💀

There are some code generation flags that GCC preserves when generating bytecodes, since they need to be used during the final link. Right now, the following options and their settings are taken from the first object file that explicitly specifies them: -fcommon, -fexceptions, -fnon-call-exceptions, -fgnu-tm and all the -m target flags. 🌸

The following options -fPIC, -fpic, -fpie and -fPIE are combined based on this scheme:

-fPIC + -fpic = -fpic
-fPIC + -fno-pic = -fno-pic
-fpic/-fPIC + (no option) = (no option)
-fPIC + -fPIE = -fPIE
-fpic + -fPIE = -fpie
-fPIC/-fpic + -fpie = -fpie

Certain ABI-changing flags have to match in all compilation units, and trying to override them at link time with a conflicting value is ignored. This includes options such as -freg-struct-return and -fpcc-struct-return. 🚫

Other options such as -ffp-contract, -fno-strict-overflow, -fwrapv, -fno-trapv or -fno-strict-aliasing are passed through to the link stage and merged conservatively for conflicting translation units. Specifically, -fno-strict-overflow, -fwrapv and -fno-trapv take precedence, and for example -ffp-contract=off takes precedence over -ffp-contract=fast. You can override them at link time. 🔥

Diagnostic options such as -Wstringop-overflow are passed through to the link stage, and their setting matches that of the compile step at function granularity. This only matters for diagnostics emitted during optimization. Also, code transforms such as inlining can lead to warnings being enabled or disabled for regions of code that aren't consistent with the setting at compile time. 🙈

When you need to pass options to the assembler via -Wa or -Xassembler, make sure to either compile those translation units with -fno-lto, or consistently use the same assembler options on all translation units. You can also specify assembler options at LTO link time, as an alternative. 🧚

To enable debug info generation you need to supply -g at compile time. If any of the input files at link time were built with debug info generation enabled, the link will enable debug info generation as well. Any elaborate debug info settings, like the dwarf level -gdwarf-5, need to be explicitly repeated on the linker command line, and mixing different settings in different translation units is discouraged. 💜

If LTO encounters objects with C linkage declared with incompatible types in separate translation units that are being linked together (undefined behavior according to ISO C99 6.2.7), a non-fatal diagnostic may be issued. The behavior is still undefined at run time. Similar diagnostics may be raised for other languages. ⚠️

Another feature of LTO is that you can apply interprocedural optimizations on files written in different languages:

gcc -c -flto foo.c
g++ -c -flto bar.cc
gfortran -c -flto baz.f90
g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran

Notice that the final link is done with g++ to get the C++ runtime libraries, and -lgfortran is added to get the Fortran runtime libraries. In general, when mixing languages in LTO mode, you should use the same link command options as you would when mixing languages in a regular (non-LTO) compilation. 🌈

If object files containing GIMPLE bytecode are stored in a library archive, say libfoo.a, you can extract and use them in an LTO link if you're using a linker with plugin support. To create static libraries suitable for LTO, use gcc-ar and gcc-ranlib instead of ar and ranlib, and to show the symbols of object files with GIMPLE bytecode, use gcc-nm. Those commands require that ar, ranlib and nm have been compiled with plugin support. At link time, use the flag -fuse-linker-plugin to make sure the library participates in the LTO optimization process:

gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo

With the linker plugin enabled, the linker extracts the needed GIMPLE files from libfoo.a and passes them on to the running GCC to make them part of the aggregated GIMPLE image to be optimized. 🦋

If you're not using a linker with plugin support, and/or you don't enable the linker plugin, then the objects inside libfoo.a are extracted and linked as usual, but they do not participate in the LTO optimization process. To make a static library suitable for both LTO optimization and usual linkage, compile its object files with -flto -ffat-lto-objects. 🎀

Link-time optimizations don't require the presence of the whole program to operate. If the program doesn't require any symbols to be exported, you can combine -flto and -fwhole-program to let the interprocedural optimizers use more aggressive assumptions, which may lead to better optimization opportunities. Using -fwhole-program isn't needed when the linker plugin is active (see -fuse-linker-plugin). ✨

The current implementation of LTO makes no attempt to generate bytecode that is portable between different types of hosts. The bytecode files are versioned and there's a strict version check, so bytecode files generated by one version of GCC do not work with an older or newer version of GCC. 🫠

Link-time optimization does not work well with generation of debugging information on systems other than those using a combination of ELF and DWARF. 🌸

If you pass the optional n, the link-time optimization and code generation run in parallel with n jobs, using an installed make program. The MAKE environment variable can be set to override which program gets used. 🧚

You can also say -flto=jobserver to let GNU make's job server decide how many parallel jobs to run. This is super useful when the Makefile calling GCC is already running in parallel 🔥. You have to put a + in front of the command recipe in the parent Makefile for this to work. This option probably only works if MAKE is GNU make. Even without an option value, GCC will try to auto-detect a running GNU make job server, so it's kind of doing the work for you 💅.

Use -flto=auto if you want GNU make's job server when it's available. If it isn't, GCC falls back to auto-detecting how many CPU threads your system has ✨.

---

• -flto-partition=alg — Picks the partitioning algorithm the link-time optimizer uses. The options are 1to1, which mirrors your original source files; balanced, which makes equally sized chunks whenever it can (this is the default 🎀); max, which makes a new partition for every symbol where possible; and cache, which balances chunk sizes while keeping related symbols together so incremental LTO caches better 🦋. Choosing none turns partitioning and streaming off completely 🙈. 1to1 can be used as a workaround for various code ordering issues, but max is intended for internal testing only, so don't go there in real life 💀. The value one means exactly one partition gets used, and none skips partitioning and runs the link-time optimization step straight from the WPA phase.
• -flto-incremental=path — Turns on incremental LTO and stores its cache in the given directory, which has to already exist 🌸. This can seriously shorten your edit-compile cycles with LTO 😭.

When you use LTO (-flto), the output of the translation units inside LTO gets cached. Cached translation units are likely to show up again when you recompile after small code changes, so your recompile times go down 🫶.

Multiple GCC instances can share the same cache in parallel, so no fighting over it 💜.

• -flto-incremental-cache-size=n — Sets how many cache entries incremental LTO keeps before it prunes the old ones. This is a soft limit, so you might briefly have more entries than that 🧹.
• -flto-compression-level=n — Controls how hard the intermediate language written to LTO object files gets compressed. It only matters together with LTO mode (-flto) 🗜️. GCC currently supports two LTO compression algorithms. For zstd, valid values run from 0 (no compression) to 19 (maximum compression), while zlib goes from 0 to 9. Anything outside that range gets clamped to the minimum or maximum of whatever's supported. If you don't give this option, GCC uses a default balanced compression setting 🌈.
• -fuse-linker-plugin — Turns on the linker plugin during link-time optimization 🔌. This relies on plugin support in the linker, which you'll find in gold or in GNU ld 2.21 or newer ✨.

This option lets GCC pull object files with GIMPLE bytecode out of library archives. That's a big glow-up for optimization quality, since it exposes more code to the link-time optimizer 🦋. The plugin also shares which symbols can be accessed externally (from non-LTO objects or during dynamic linking). The code quality gains for binaries (and shared libraries that use hidden visibility) are similar to -fwhole-program. Check out -flto for a description of what this flag does and how to use it 👑.

This option is enabled by default when LTO support is enabled in GCC and GCC was configured for a linker that supports plugins (GNU ld 2.21 or newer, or gold). Main character energy 💅.

• -ffat-lto-objects — Fat LTO objects are object files that hold both the intermediate language and the object code 🍓. That means they work for both LTO linking and normal linking. This option only does anything when you're compiling with -flto, and it's ignored at link time 🫠.
• -fno-fat-lto-objects — Compiles faster than plain LTO, but it needs your whole toolchain to be LTO-aware 🛠️. It needs a linker with linker plugin support for basic functionality. On top of that, nm, ar and ranlib need to support linker plugins for a full-featured build environment (one that can build static libraries and so on). GCC provides the gcc-ar, gcc-nm and gcc-ranlib wrappers to pass the right options to these tools. Without fat LTO, your makefiles need to be modified to use them 🙃.

Heads up: modern binutils have a plugin auto-load mechanism. Installing the linker plugin into $libdir/bfd-plugins has the same effect as using the command wrappers (gcc-ar, gcc-nm and gcc-ranlib) 🧚.

The default is -fno-fat-lto-objects on targets with linker plugin support ✨.

---

• -fcompare-elim — After register allocation and post-register allocation instruction splitting, GCC looks for arithmetic instructions that compute processor flags the way a comparison would. If it can, it removes the explicit comparison entirely 🧼. This pass only applies to certain targets that can't explicitly represent the comparison before register allocation is done 🎯.

Enabled at levels -O1, -O2, -O3, -Os 💖.

• -ffold-mem-offsets, -fno-fold-mem-offsets — Tries to get rid of add instructions by folding them into memory loads and stores 🫶.

Enabled at levels -O2, -O3 🌸.

NOTE: On Debian/Ubuntu this is disabled by default on m68k-linux-gnu 🙈.

• -fcprop-registers — After register allocation and post-register allocation instruction splitting, this does a copy-propagation pass to reduce scheduling dependencies and occasionally eliminate the copy 🍒.

Enabled at levels -O1, -O2, -O3, -Os 💜.

• -fprofile-correction — Profiles collected from an instrumented binary for multi-threaded programs can come out inconsistent because counter updates got missed 😵‍💫. When you use this option, GCC uses heuristics to correct or smooth out those inconsistencies. By default, GCC throws an error message when it detects an inconsistent profile 🚨.

This option is enabled by -fauto-profile 🎀.

• -fprofile-partial-training — With -fprofile-use, every part of the program that wasn't executed during the train run gets optimized aggressively for size instead of speed 📏. Sometimes it isn't practical to train every possible hot path (say your program has functions specific to some hardware, and training can't cover every hardware configuration it runs on 🖥️). With -fprofile-partial-training, profile feedback gets ignored for all functions that weren't executed during the train run. Those functions get optimized as if they were compiled without profile feedback 🧃. This gives better performance when the train run isn't representative, but it also makes the code significantly bigger 📦.
• -fprofile-use, -fprofile-use=path — Turns on profile feedback-directed optimizations, plus the following optimizations, many of which are only really profitable when profile feedback is available 📈:

-fbranch-probabilities  -fprofile-values -funroll-loops
-fpeel-loops  -ftracer  -fvpt -finline-functions  -fipa-cp
-fipa-cp-clone  -fipa-bit-cp -fpredictive-commoning  -fsplit-loops
-funswitch-loops -fgcse-after-reload  -ftree-loop-vectorize
-ftree-slp-vectorize -fvect-cost-model=dynamic
-ftree-loop-distribute-patterns -fprofile-reorder-functions

Before you can use this option, you have to generate profiling information first 📝.

By default, GCC emits an error message if the feedback profiles don't match the source code. You can turn that error into a warning with -Wno-error=coverage-mismatch. Just know this might give you poorly optimized code 😬. Also by default, GCC emits a warning message if the feedback profiles don't exist at all (see -Wmissing-profile) 👀.

If you give a path, GCC looks there to find the profile feedback data files. See -fprofile-dir 📂.

• -fauto-profile, -fauto-profile=path — Turns on sampling-based feedback-directed optimizations, plus the following optimizations, many of which are only really profitable with profile feedback available 🎯:

-fbranch-probabilities  -fprofile-values -funroll-loops
-fpeel-loops  -ftracer  -fvpt -finline-functions  -fipa-cp
-fipa-cp-clone  -fipa-bit-cp -fpredictive-commoning  -fsplit-loops
-funswitch-loops -fgcse-after-reload  -ftree-loop-vectorize
-ftree-slp-vectorize -fvect-cost-model=dynamic
-ftree-loop-distribute-patterns -fprofile-correction

path is the name of a file containing AutoFDO profile information. If you leave it out, it defaults to fbdata.afdo in the current directory 📁.

Making an AutoFDO profile data file means running your program with the perf utility on a supported GNU/Linux target system 🐧. For more info, check out <https://perf.wiki.kernel.org/> 🔗.

E.g.

perf record -e br_inst_retired:near_taken -b -o perf.data \
    -- your_program

Then use the create_gcov tool to convert the raw profile data into a format GCC can use 🔄. You also have to hand this tool the unstripped binary for your program. See <https://github.com/google/autofdo> 🧠.

E.g.

create_gcov --binary=your_program.unstripped --profile=perf.data \
    --gcov=profile.afdo

---

The following options control how the compiler handles floating-point arithmetic. These options trade speed for correctness, so they all have to be turned on specifically 🧁.

• -fexcess-precision=style — Lets you control excess precision on machines where floating-point operations happen in a format with more precision or range than the IEEE standard and interchange floating-point types 🤓. A classic example is x87 floating point on x86 processors, which uses an 80-bit representation internally instead of the 64-bit IEEE format 💫. For most programs the excess precision is harmless, but some programs might rely on the C or C++ language standards' rules for handling IEEE values 🥹.

By default, -fexcess-precision=fast is in effect, which means operations may be carried out in a wider precision than the types in the source if that gives faster code. It's unpredictable when rounding to the source types actually happens 🙈 When compiling C or C++, if you specify -fexcess-precision=standard, excess precision follows the rules in ISO C99 or C++. Casts and assignments both cause values to be rounded to their semantic types, whereas -ffloat-store only affects assignments 💅 This option is enabled by default for C or C++ if a strict conformance option like -std=c99 or -std=c++17 is used. -ffast-math turns on -fexcess-precision=fast by default no matter whether a strict conformance option is used ✨ If you specify -fexcess-precision=16, constants and the results of expressions with the types _Float16 and __bf16 are computed without excess precision.

-fexcess-precision=standard isn't implemented for languages other than C or C++. On x86, it does nothing if you specify -mfpmath=sse or -mfpmath=sse+387. With the former, IEEE semantics apply without excess precision, and with the latter, rounding is unpredictable 🥺

• -ffloat-store — Okay so this one tells GCC not to keep floating-point variables in registers, and it also blocks other options that might change whether a float gets pulled from a register or from memory 🧚 It's mostly been absorbed by -fexcess-precision=standard, which is more general. If you do use -ffloat-store, you might need to rewrite your program so intermediate results go into temporary variables explicitly, because -ffloat-store only handles rounding to IEEE format on assignments and not on casts the way -fexcess-precision=standard does 💀
• -ffast-math — This one is a whole vibe 🔥 It sets -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast all at once. It also causes the preprocessor macro __FAST_MATH__ to be defined 🌸

This option isn't turned on by any -O option besides -Ofast, since it can give incorrect output for programs that depend on an exact implementation of IEEE or ISO rules and specifications for math functions. It may, however, make faster code for programs that don't need those guarantees 🦋

• -fno-math-errno — Don't set errno after calling math functions that run as a single instruction, like sqrt. A program that relies on IEEE exceptions for math error handling might want this flag for speed while keeping IEEE arithmetic compatibility 🫶

Just like before, this isn't turned on by any -O option besides -Ofast, for the same reason: it can give incorrect output for programs that depend on an exact implementation of IEEE or ISO math rules. It might yield faster code for programs that don't need those guarantees.

The default is -fmath-errno.

On Darwin systems, the math library never sets errno. So there's no reason for the compiler to consider that it might, and -fno-math-errno is the default there 🍓

• -funsafe-math-optimizations — Allows optimizations for floating-point arithmetic that (a) assume arguments and results are valid and (b) may violate IEEE or ANSI standards. Used at link time, it may include libraries or startup files that change the default FPU control word or make other similar optimizations 😭

Same deal as before: this isn't turned on by any -O option besides -Ofast, because it can produce incorrect output for programs that depend on an exact implementation of IEEE or ISO rules and specifications for math functions. It may still yield faster code for programs that don't need those guarantees. It enables -fno-signed-zeros, -fno-trapping-math, -fassociative-math and -freciprocal-math.

The default is -fno-unsafe-math-optimizations.

• -fassociative-math — Allows re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing the computation result. ⚠️ Heads up: re-ordering may change the sign of zero, ignore NaNs, and inhibit or create underflow or overflow. So it can't be used on code that relies on rounding behaviour like (x + 2**52) - 2**52. It may also reorder floating-point comparisons, so don't use it when ordered comparisons are required 🥀

This option requires that both -fno-signed-zeros and -fno-trapping-math be in effect. Also, it doesn't make much sense with -frounding-math. For Fortran, the option is automatically enabled when both -fno-signed-zeros and -fno-trapping-math are in effect.

The default is -fno-associative-math.

• -freciprocal-math — Lets the reciprocal of a value be used instead of dividing by the value, if that enables optimizations. For example, x / y can be replaced with x * (1/y), which is handy if (1/y) is subject to common subexpression elimination. Just know this loses precision and increases the number of flops operating on the value 🧮

The default is -fno-reciprocal-math.

• -ffinite-math-only — Allows optimizations for floating-point arithmetic that assume arguments and results are not NaNs or +-Infs ♾️

This one also isn't turned on by any -O option besides -Ofast, since it can give incorrect output for programs that depend on an exact implementation of IEEE or ISO rules and specifications for math functions. It may, however, yield faster code for programs that don't need those guarantees.

The default is -fno-finite-math-only.

• -fno-signed-zeros — Allows optimizations for floating-point arithmetic that ignore the signedness of zero. IEEE arithmetic specifies the behaviour of distinct +0.0 and -0.0 values, which then prohibits simplifying expressions like x+0.0 or 0.0*x, even with -ffinite-math-only. This option implies that the sign of a zero result isn't significant 🌈

The default is -fsigned-zeros.

• -fno-trapping-math — Compiles code assuming that floating-point operations can't generate user-visible traps. These traps include division by zero, overflow, underflow, inexact result and invalid operation. This option requires that -fno-signaling-nans be in effect. Setting it may allow faster code if you rely on "non-stop" IEEE arithmetic, for example ✨

This option isn't turned on by any -O option besides -Ofast, since it can give incorrect output for programs that depend on an exact implementation of IEEE or ISO rules and specifications for math functions.

The default is -ftrapping-math.

Future versions of GCC may offer finer control of this setting using C99's FENV_ACCESS pragma. This command-line option will be used along with -frounding-math to specify the default state for FENV_ACCESS.

• -frounding-math — Disables transformations and optimizations that assume the default floating-point rounding behaviour (round-to-nearest). Use this for programs that change the FP rounding mode dynamically, or that may run with a non-default rounding mode 🎀 It disables constant folding of floating-point expressions at compile time, since that may be affected by rounding mode, and it disables arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes.

The default is -fno-rounding-math.

This option is experimental, and it doesn't currently guarantee that all GCC optimizations affected by rounding mode get disabled. Future versions of GCC may offer finer control of this setting using C99's FENV_ACCESS pragma. This command-line option will be used along with -ftrapping-math to specify the default state for FENV_ACCESS.

• -fsignaling-nans — Compiles code assuming that IEEE signaling NaNs may generate user-visible traps during floating-point operations. Setting this option disables optimizations that may change the number of exceptions visible with signaling NaNs. This option implies -ftrapping-math 🚨

This option causes the preprocessor macro __SUPPORT_SNAN__ to be defined.

The default is -fno-signaling-nans.

This option is experimental, and it doesn't currently guarantee that all GCC optimizations affecting signaling NaN behaviour get disabled.

• -fno-fp-int-builtin-inexact — Doesn't allow the built-in functions ceil, floor, round and trunc, plus their float and long double variants, to generate code that raises the inexact floating-point exception for noninteger arguments. ISO C99 and C11 let these functions raise the inexact exception, but ISO/IEC TS 18661-1:2014, the C bindings to IEEE 754-2008 as integrated into ISO C23, doesn't allow them to do so 🙅‍♀️

The default is -ffp-int-builtin-inexact, which allows the exception to be raised, unless C23 or a later C standard is selected. This option does nothing unless -ftrapping-math is in effect.

Even if -fno-fp-int-builtin-inexact is used, if the functions generate a call to a library function, the inexact exception may still be raised if the library implementation doesn't follow TS 18661.

• -fsingle-precision-constant — Treats floating-point constants as single precision, instead of implicitly converting them to double-precision constants 🍭
• -fcx-limited-range — When enabled, this option says a range reduction step isn't needed when performing complex division. There's also no checking for whether the result of a complex multiplication or division is NaN + I*NaN, and no attempt to rescue the situation in that case 🫠 The default is -fno-cx-limited-range, but -ffast-math enables it.

This option controls the default setting of the ISO C99 CX_LIMITED_RANGE pragma. Even so, the option applies to all languages.

• -fcx-fortran-rules — Complex multiplication and division follow Fortran rules. Range reduction is done as part of complex division, but there's no checking for whether the result of a complex multiplication or division is NaN + I*NaN, and no attempt to rescue the situation in that case 👑

The default is -fno-cx-fortran-rules.

The following options control optimizations that may improve performance, but are not enabled by any -O options. ✨ This section includes experimental options that may produce broken code, so 👀 tread carefully bestie 💀

• -fbranch-probabilities 🌸 — okay so after you run a program built with -fprofile-arcs, you compile it again with -fbranch-probabilities and the optimizations get smarter about how many times each branch was actually taken. When the -fprofile-arcs program exits, it saves arc execution counts to a file called sourcename.gcda for each source file. That data is super dependent on the structure of the generated code, so you must use the same source code and the same optimization options for both compilations. See the file naming details under -fprofile-arcs.
  • With -fbranch-probabilities, GCC puts a REG_BR_PROB note on each JUMP_INSN and CALL_INSN 🧠 These can be used to improve optimization. Right now they're only used in one place: reorg.cc. Instead of guessing which path a branch is most likely to take, the REG_BR_PROB values are used to exactly figure out which path gets taken more often. Iconic.
  • Enabled by -fprofile-use and -fauto-profile ✨
• -fprofile-values 🦋 — if you combine it with -fprofile-arcs, it adds code so data about the values of expressions in your program gets gathered.
  • With -fbranch-probabilities, it reads back that value-profiling data and uses it for optimizations.
  • Enabled by -fprofile-generate, -fprofile-use, and -fauto-profile 💅
• -fprofile-reorder-functions 🚀 — function reordering based on profile instrumentation records the first time each function runs, then orders those functions in ascending order. The goal is faster program startup, since the text segments load more efficiently.
  • Enabled with -fprofile-use 🫶
• -fvpt 🔮 — if combined with -fprofile-arcs, this tells the compiler to add code that gathers info about the values of expressions.
  • With -fbranch-probabilities, it reads back that data and actually performs optimizations based on it. Right now that includes specializing division operations using what it knows about the value of the denominator. Main character energy 👑
  • Enabled with -fprofile-use and -fauto-profile
• -frename-registers 🎀 — attempts to avoid false dependencies in scheduled code by using registers left over after register allocation. This is most helpful for processors with lots of registers.
  • > ⚠️ Depending on the debug information format the target uses, this can make debugging impossible, since variables no longer stay in a "home register" 😭
  • Enabled by default with -funroll-loops
• -fschedule-fusion 🍓 — a target dependent pass over the instruction stream that schedules instructions of the same type together, since the target machine can run them more efficiently when they sit next to each other in the instruction flow.
  • Enabled at levels -O2, -O3, -Os
• -ftracer 🌈 — performs tail duplication to enlarge superblock size. This simplifies the control flow of the function so other optimizations can do a better job.
  • Enabled by -fprofile-use and -fauto-profile
• -funroll-loops 🔁 — unrolls loops whose number of iterations can be determined at compile time or when the loop is entered. -funroll-loops implies -frerun-cse-after-loop, -fweb and -frename-registers. It also turns on complete loop peeling, which means fully removing loops with a small constant number of iterations.
  • > ⚠️ This option makes your code bigger, and it may or may not make it run faster. Vibe check: it's a gamble 🎲
  • Enabled by -fprofile-use and -fauto-profile
• -funroll-all-loops 💀 — unrolls all loops, even if the number of iterations is uncertain when the loop is entered. This usually makes programs run more slowly 🙈 -funroll-all-loops implies the same options as -funroll-loops.
• -fpeel-loops 🧁 — peels loops that don't roll much, based on enough info from profile feedback or static analysis. It also turns on complete loop peeling (fully removing loops with a small constant number of iterations).
  • Enabled by -O3, -fprofile-use, and -fauto-profile
• -fmalloc-dce 🗑️ — controls whether "malloc" (and its variants like "calloc" or "strdup") can be optimized away, as long as its return value is only used as a parameter of a "free" call or compared with "NULL". With -fmalloc-dce=1, only calls to "free" are allowed. With -fmalloc-dce=2, comparisons with the "NULL" pointer are also considered safe to remove.
  • The default is -fmalloc-dce=2. See also -fallocation-dce ✨
• -fmove-loop-invariants 🌷 — enables the loop invariant motion pass in the RTL loop optimizer.
  • Enabled at level -O1 and higher, except for -Og
• -fmove-loop-stores 📦 — enables the loop store motion pass in the GIMPLE loop optimizer. This moves invariant stores to after the end of the loop, in exchange for carrying the stored value in a register across the iteration.
  • Note: for this option to have an effect, -ftree-loop-im has to be enabled as well 🫠
  • Enabled at level -O1 and higher, except for -Og
• -fsplit-loops ✂️ — splits a loop into two if it contains a condition that's always true for one side of the iteration space and false for the other.
  • Enabled by -fprofile-use and -fauto-profile
• -funswitch-loops 🔀 — moves branches with loop invariant conditions out of the loop, with duplicates of the loop on both branches (modified according to the result of the condition).
  • Enabled by -fprofile-use and -fauto-profile
• -fversion-loops-for-strides 🧵 — if a loop iterates over an array with a variable stride, GCC creates another version of the loop that assumes the stride is always one. For example:

for (int i = 0; i < n; ++i)
  x[i * stride] = ...;

becomes:

if (stride == 1)
  for (int i = 0; i < n; ++i)
    x[i] = ...;
else
  for (int i = 0; i < n; ++i)
    x[i * stride] = ...;

This is especially useful for assumed-shape arrays in Fortran, where (for example) it allows better vectorization by assuming contiguous accesses 🫶 This flag is enabled by default at -O3. It's also enabled by -fprofile-use and -fauto-profile.

---

• -ffunction-sections, -fdata-sections 🗂️ — places each function or data item into its own section in the output file, if the target supports arbitrary sections. The name of the function or data item determines the section's name in the output file.
  • Use these on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format have linkers with such optimizations. On AIX, the linker rearranges sections (CSECTs) based on the call graph. The performance impact varies.
  • Together with linker garbage collection (the linker --gc-sections option), these options may lead to smaller statically-linked executables (after stripping) 🌱
  • On ELF/DWARF systems, these options do not degrade the quality of the debug information. There could be issues with other object file or debug info formats.
  • > ⚠️ Only use these options when there are significant benefits from doing so. When you specify them, the assembler and linker create larger object and executable files and are also slower. They also affect code generation: they prevent optimizations by the compiler and assembler that use relative locations inside a translation unit, since those locations aren't known until link time. An example of such an optimization is relaxing calls to short call instructions. Be careful, bestie 🥺
• -fstdarg-opt 🪄 — optimizes the prologue of variadic argument functions with respect to how those arguments are used.
• -fsection-anchors ⚓ — tries to reduce the number of symbolic address calculations by using shared "anchor" symbols to address nearby objects. This transformation can help reduce the number of GOT entries and GOT accesses on some targets.
  • For example, the implementation of the following function foo:

static int a, b, c;
int foo (void) { return a + b + c; }

usually calculates the addresses of all three variables. But if you compile it with -fsection-anchors, it accesses the variables from a common anchor point instead. The effect is similar to this pseudocode (which isn't valid C) 🤓:

int foo (void)
{
  register int *xr = &x;
  return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
}

Not all targets support this option 💅

• -fzero-call-used-regs=choice 🛡️ — zeros the call-used registers at function return to boost program security, either by mitigating Return-Oriented Programming (ROP) attacks or by preventing information leakage through registers.
  • The possible values of choice are the same as for the "zero_call_used_regs" attribute. The default is skip.
  • You can control this behavior for a specific function by using the function attribute "zero_call_used_regs" 🔐
• --param name=value 🎛️ — okay so GCC uses various constants to control how much optimization gets done. For example, GCC won't inline functions that contain more than a certain number of instructions. You can control some of these constants on the command line using the --param option.
  • > ⚠️ The names of specific parameters, and what the values mean, are tied to the compiler's internals. They're subject to change without notice in future releases, so don't get too attached 😭
  • To get the minimal, maximal and default values of a parameter, use --help=param -Q.
  • In each case, the value is an integer. The following choices of name are recognized for all targets:
    • phiopt-factor-max-stmts-live — when factoring statements out of an if/then/else, this is the max number of statements after the defining statement that are allowed to extend the lifetime of a name 🌙
    • predictable-branch-outcome — when a branch is predicted to be taken with a probability lower than this threshold (in percent), it's considered well predictable ✨
• max-rtl-if-conversion-insns — okay so RTL if-conversion 💅 tries to yeet conditional branches around a block and swap them for conditionally executed instructions ✨. This param sets the max number of instructions in a block that get considered for if-conversion. GCC also runs its own heuristics to figure out whether if-conversion is actually worth it 🧠.
• file-cache-files — the max number of files kept in the file cache 📁. The file cache is what GCC uses to print source lines in diagnostics and to run some source checks, like -Wmisleading-indentation 👀.
• file-cache-lines — the max number of lines that get indexed into the file cache 🧾. When this is 0, it gets sized automatically 🪄. Same deal as above: the file cache powers the source lines in diagnostics and checks like -Wmisleading-indentation 💖.
• max-rtl-if-conversion-predictable-cost — same RTL if-conversion idea, where it tries to remove conditional branches and replace them with conditionally executed instructions 🌸. These params cap the cost of the sequence if-conversion would generate. There are two versions, depending on whether the branch is statically determined to be predictable or not 🔮. The units match GCC's internal seq_cost metric 📏. GCC tries to pick a sensible default using the BRANCH_COST target macro 🎯.
• max-crossjump-edges — the max number of incoming edges to consider for cross-jumping 🦋. Heads up, the algorithm behind -fcrossjumping is O(N^2) in the number of incoming edges to each block 😭. Cranking this up means more aggressive optimization, but compile times go up for probably a small win in executable size 🐢.
• min-crossjump-insns — the minimum number of instructions that have to match at the end of two blocks before cross-jumping happens on them 🎀. This value gets ignored when every instruction in the block being cross-jumped from is already matched ✨.
• max-grow-copy-bb-insns — the max code size expansion factor when copying basic blocks instead of jumping 🧩. The expansion is measured relative to a jump instruction 🦘.
• max-goto-duplication-insns — the max number of instructions that can be duplicated into a block that jumps to a computed goto 🌈. To dodge O(N^2) behaviour in a bunch of passes, GCC factors computed gotos early on and unfactors them as late as possible 🫠. Only computed jumps at the end of a basic block with no more than max-goto-duplication-insns get unfactored 🙈.
• max-delay-slot-insn-search — the max number of instructions to look at when hunting for something to fill a delay slot 🔍. Past this arbitrary number, the time saved by filling the slot is basically nothing, so GCC stops searching 💀. Higher values mean more aggressive optimization and longer compile times, for probably a small gain in execution time 🏃‍♀️.
• max-delay-slot-live-search — when filling delay slots, the max number of instructions to check while searching for a block with valid live register information 🔎. Raising this arbitrarily chosen number means more aggressive optimization but slower compiles 🐌. This param should get removed once the delay slot code is rewritten to maintain the control-flow graph 🚧.
• max-gcse-memory — the approximate max amount of memory, in "kB", that can be allocated for the global common subexpression elimination optimization 🧠. If the optimization would need more memory than this, it just doesn't happen 🙅‍♀️.
• max-gcse-insertion-ratio — if the ratio of expression insertions to deletions goes above this value for any expression, RTL PRE inserts or removes the expression instead 🔄. The catch is that it leaves partially redundant computations sitting in the instruction stream 🥲.
• max-pending-list-length — the max number of pending dependencies the scheduler allows before it flushes the current state and starts fresh 🧹. Big functions with few branches or calls can build up huge lists that eat memory and resources for no reason 🫧.
• max-modulo-backtrack-attempts — the max number of backtrack attempts the scheduler makes when modulo scheduling a loop 🔁. Bigger values can blow up compilation time exponentially 📈💀.
• max-inline-functions-called-once-loop-depth — the max loop depth of a call that the inline heuristics will still consider, for the heuristics that try to inline every function called once 🌀.
• max-inline-functions-called-once-insns — the max estimated size of functions produced while inlining functions called once 📐.
• max-inline-insns-single — a bunch of params control GCC's tree inliner, and this one sets the max number of instructions (counted in GCC's internal representation) in a single function that the tree inliner will consider for inlining 💫. It only affects functions declared inline and methods implemented in a class declaration (C++) 💜.
• max-inline-insns-auto — when you use -finline-functions (which is included in -O3), a whole lot of functions that wouldn't normally get considered for inlining get checked out anyway 👀. For those functions, a different, more restrictive limit applies than for functions declared inline 🙃. You can set it with --param max-inline-insns-auto ✨.
• max-inline-insns-small — the bound applied to calls that count as relevant under -finline-small-functions 🦋.
• max-inline-insns-size — the bound applied to calls that are optimized for size 📦. A little growth can be worth it, since it can expose optimization opportunities that inlining unlocks 🌱.
• uninlined-function-insns — the number of instructions the inliner counts as function overhead, like the function prologue and epilogue 🧮.
• uninlined-function-time — the extra time the inliner counts as function overhead, like the time it takes to run the prologue and epilogue ⏱️.
• inline-heuristics-hint-percent — the scale, in percent, applied to inline-insns-single, inline-insns-single-O2, and inline-insns-auto when the inline heuristics hint that inlining is super profitable (it'll enable later optimizations) 💅🔥.
• uninlined-thunk-insns, uninlined-thunk-time — same as --param uninlined-function-insns and --param uninlined-function-time, but these apply to function thunks 🧵.
• inline-min-speedup — when the estimated performance improvement of caller + callee runtime goes over this threshold (in percent), the function can be inlined no matter what the limits on --param max-inline-insns-single and --param max-inline-insns-auto say 🚀👑.
• large-function-insns — the limit that defines really large functions 🐘. For functions bigger than this after inlining, inlining gets constrained by --param large-function-growth 🔒. This param mainly exists to avoid extreme compile times caused by the non-linear algorithms the back end uses 🫠.
• large-function-growth — the max growth of large functions caused by inlining, in percent 📈. For example, a value of 100 limits large function growth to 2.0 times the original size ✌️.
• large-unit-insns — the limit that defines a large translation unit 🗂️. Growth from inlining into units bigger than this is limited by --param inline-unit-growth 🧱. For small units that might be too tight 🥺. Here's the example: a unit with function A (inline) and B, which just calls A three times. If B is small compared to A, the unit growth is 300% and yet that inlining is totally sane 💅. But for really big units full of small inlineable functions, the overall unit growth limit is needed to stop exponential code size explosions 💥. So for smaller units, the size gets bumped up to --param large-unit-insns before --param inline-unit-growth is applied 🪄.
• lazy-modules — the max number of C++ module files that can be open at once when lazy loading 📂.
• inline-unit-growth — the max overall growth of the compilation unit caused by inlining 🌿. For example, a value of 20 limits unit growth to 1.2 times the original size 🫧. Cold functions (marked cold with an attribute, or by profile feedback) don't count toward the unit size 🥶.
• ipa-cp-unit-growth — the max overall growth of the compilation unit caused by interprocedural constant propagation 🧊. For example, a value of 10 limits unit growth to 1.1 times the original size 🌟.
• ipa-cp-large-unit-insns — the size of a translation unit that the IPA-CP pass considers large 📏.
• large-stack-frame — the limit that defines large stack frames 🥞. While inlining, the algorithm tries not to grow past this limit too much 🙏.
• large-stack-frame-growth — the max growth of large stack frames caused by inlining, in percent 🏗️. For example, a value of 1000 limits large stack frame growth to 11 times the original size 🤯.
• max-inline-insns-recursive, max-inline-insns-recursive-auto — the max number of instructions an out-of-line copy of a self-recursive inline function can grow into by doing recursive inlining 🔄🌸.

--param max-inline-insns-recursive applies to functions declared inline. For functions not declared inline, recursive inlining only happens when -finline-functions (included in -O3) is enabled, and then --param max-inline-insns-recursive-auto applies instead 💜.

• max-inline-recursive-depth, max-inline-recursive-depth-auto — the max recursion depth used for recursive inlining 🪞✨.

Okay so --param max-inline-recursive-depth only handles functions you've marked inline 💅. For functions that aren't declared inline, recursive inlining only kicks in when -finline-functions is on (it's part of -O3) ✨. In that case, --param max-inline-recursive-depth-auto takes over instead 🦋.

• min-inline-recursive-probability — Recursive inlining is only worth it for functions that recurse deeply on average 🌸. For functions with shallow recursion, it can backfire by bloating the prologue or making the function body harder for other optimizers to handle 🙈. When profile feedback is available (see -fprofile-generate), the real recursion depth can be guessed from how likely a function is to recurse through a given call expression. This parameter only allows inlining for call expressions whose probability is above the threshold, in percents.
• early-inlining-insns — Controls how much growth the early inliner is allowed to cause. Basically, it lets the early inliner do more inlining for code with a large abstraction penalty 🔥.
• max-early-inliner-iterations — Caps how many iterations the early inliner runs. This bounds how many nested indirect calls it can resolve, and deeper chains get handled by late inlining instead 💜.
• comdat-sharing-probability — The probability (in percent) that C++ inline functions with comdat visibility get shared across multiple compilation units ✨.
• modref-max-bases, modref-max-refs, modref-max-accesses — The maximum number of base pointers, references and accesses that mod/ref analysis stores for a single function 🎀.
• modref-max-tests — The maximum number of tests the alias oracle can run to tell memory locations apart using mod/ref information. This should be bigger than --param modref-max-bases and --param modref-max-refs 🧚.
• modref-max-depth — The maximum depth of the DFS walk used by modref escape analysis. Set it to 0 and the analysis is switched off completely 💀.
• modref-max-escape-points — The maximum number of escape points modref tracks per SSA-name 🍓.
• modref-max-adjustments — The maximum amount the access range can be enlarged during modref dataflow analysis 🌈.
• profile-func-internal-id — Controls whether the function's internal id is used when looking things up in the profile database. If the value is 0, the compiler uses an id based on the function's assembler name and filename instead. That makes old profile data more forgiving of source changes, like function reordering 🫶.
• min-vect-loop-bound — The minimum number of iterations below which loops are not vectorized when -ftree-vectorize is used. The number of iterations after vectorization has to be greater than this value for vectorization to happen 👑.
• gcse-cost-distance-ratio — A scaling factor for the maximum distance an expression can travel during GCSE optimizations. It's only supported in the code hoisting pass 🦋. The bigger the ratio, the more aggressively simple expressions (ones costing less than gcse-unrestricted-cost) get hoisted. Setting it to 0 disables hoisting of simple expressions 🙅‍♀️.
• gcse-unrestricted-cost — The cost, roughly measured as a single typical machine instruction, at which GCSE stops constraining how far an expression can travel. This is also only supported in the code hoisting pass 💅. The lower the cost, the more aggressive the hoisting. Setting it to 0 lets every expression travel unrestricted distances ✨.
• max-hoist-depth — The depth of search in the dominator tree for expressions to hoist. This keeps the hoisting algorithm from going quadratic. A value of 0 means no limit on the search, but it may slow down compilation of huge functions 🐢.
• max-tail-merge-comparisons — The maximum number of similar bbs a bb gets compared with. This keeps tree tail merging from going quadratic 🌸.
• max-tail-merge-iterations — The maximum number of iterations of the pass over the function. It's there to limit compilation time in tree tail merging ⏱️.
• store-merging-allow-unaligned — Lets the store merging pass introduce unaligned stores, but only if that's legal to do 🎀.
• max-stores-to-merge — The maximum number of stores the store merging pass will try to merge into wider stores 🧁.
• max-store-chains-to-track — The maximum number of store chains tracked at the same time while trying to merge them into wider stores in the store merging pass 🦄.
• max-stores-to-track — The maximum number of stores tracked at the same time while trying to merge them into wider stores in the store merging pass 💖.
• max-unrolled-insns — The maximum number of instructions a loop can have and still be unrolled. If a loop does get unrolled, this parameter also decides how many times the loop code is unrolled 🔁.
• max-average-unrolled-insns — The maximum number of instructions, biased by how likely they are to execute, that a loop can have and still be unrolled. If it gets unrolled, this parameter also decides how many times the loop code is unrolled 🌈.
• max-unroll-times — The maximum number of unrollings of a single loop 🔢.
• max-peeled-insns — The maximum number of instructions a loop can have and still be peeled. If a loop is peeled, this parameter also decides how many times the loop code is peeled 🍑.
• max-peel-times — The maximum number of peelings of a single loop 🍑.
• max-peel-branches — The maximum number of branches on the hot path through the peeled sequence 🔥.
• max-completely-peeled-insns — The maximum number of insns in a completely peeled loop ✨.
• max-completely-peel-times — The maximum number of iterations a loop can have and still be suitable for complete peeling 🧚.
• max-completely-peel-loop-nest-depth — The maximum depth of a loop nest suitable for complete peeling 🪆.
• max-unswitch-insns — The maximum number of insns in an unswitched loop 🔀.
• max-unswitch-depth — The maximum depth of a loop nest that can be unswitched 🌊.
• lim-expensive — The minimum cost for an expression to count as expensive during loop invariant motion 💸.
• min-loop-cond-split-prob — When FDO profile information is available, this specifies the minimum probability a semi-invariant condition statement needs before it triggers a loop split 🪄.
• iv-consider-all-candidates-bound — The bound on the number of candidates for induction variables. Below this number, every candidate is considered for each use in induction variable optimizations. Above it, only the most relevant ones get considered, so the time complexity doesn't go quadratic 🧮.
• iv-max-considered-uses — Induction variable optimizations give up on any loop that has more induction variable uses than this 🙃.
• iv-always-prune-cand-set-bound — If the candidate set has fewer members than this value, the compiler always tries to remove unnecessary ivs from the set whenever it adds a new one 🧹.
• avg-loop-niter — The average number of iterations of a loop 🔄.
• dse-max-object-size — The maximum size (in bytes) of objects that dead store elimination tracks bytewise. Bigger values can mean bigger compilation times 📏.
• dse-max-alias-queries-per-store — The maximum number of queries into the alias oracle per store. Bigger values mean longer compilation times, but they may remove more dead stores 🗑️.
• scev-max-expr-size — The bound on the size of expressions used in the scalar evolutions analyzer. Large expressions slow the analyzer down 🐌.
• scev-max-expr-complexity — The bound on how complex the expressions in the scalar evolutions analyzer can be. Complex expressions slow the analyzer down too 🤯.
• max-tree-if-conversion-phi-args — The maximum number of arguments a PHI can have and still be supported by TREE if conversion, unless the loop is marked with a simd pragma 🎀.
• vect-max-layout-candidates — The maximum number of possible vector layouts (such as permutations) to consider when optimizing code that is going to be vectorized 🧩.
• vect-max-version-for-alignment-checks — The maximum number of run-time checks that can be done when the vectorizer does loop versioning for alignment 📐.
• vect-max-version-for-alias-checks — The maximum number of run-time checks that can be done when the vectorizer does loop versioning for alias 🔍.
• vect-max-peeling-for-alignment — The maximum number of loop peels the vectorizer can use to improve access alignment. A value of -1 means there's no limit 🫧.
• max-iterations-to-track — The maximum number of loop iterations the brute-force algorithm for analyzing a loop's iteration count will try to evaluate 🕵️‍♀️.
• hot-bb-count-fraction — The denominator n of the fraction 1/n of the maximal execution count of a basic block in the entire program. A basic block needs at least that much execution to be considered hot. The default is 10000, which means a basic block counts as hot if its execution count is greater than 1/10000 of the maximal execution count. A value of 0 means it's never considered hot. Used in non-LTO mode 🔥.
• hot-bb-count-ws-permille — The number of most-executed permilles, ranging from 0 to 1000, of the profiled execution of the entire program. A basic block's execution count has to be part of that slice to count as hot. The default is 990, which means a basic block is hot if its execution count contributes to the upper 990 permilles, or 99.0%, of the profiled execution of the entire program. A value of 0 means it's never considered hot. Used in LTO mode 👑.
• hot-bb-frequency-fraction — This one is the denominator n of the fraction 1/n of the entry block's execution frequency that a basic block in a function needs to reach before it counts as hot 🔥. The default is 1000, so a basic block is hot if it runs more often than 1/1000 of the entry block's frequency. Setting it to 0 means nothing is ever considered hot 🧊.
• unlikely-bb-count-fraction — Here the denominator n is for the fraction 1/n of the total profiled runs of the whole program. If a basic block's execution count falls below that, it's considered unlikely to run 🙈. The default is 20, which means a block is unlikely if it runs in fewer than 1/20 (that's 5%) of the program's runs. Setting it to 0 means every block is always considered unlikely.
• max-predicted-iterations — The most loop iterations GCC will predict statically ✨. This comes in clutch when a function has one loop with a known bound and another with an unknown bound. The known count gets predicted correctly, but the unknown one averages out to roughly 10, so the unbounded loop looks artificially cold next to the other one 🥶.
• builtin-expect-probability — Controls how likely the expression is to have the specified value 🎯. It takes a percentage, so anywhere from 0 to 100.
• builtin-string-cmp-inline-length — The maximum length of a constant string for a builtin string comparison call that's eligible to be inlined 🧵.
• align-threshold — Picks a fraction of the maximum execution frequency of a basic block within a function, and uses it to decide whether that block gets aligned 📐.
• align-loop-iterations — Any loop that's expected to iterate at least this many times gets aligned 🌀.
• tracer-dynamic-coverage, tracer-dynamic-coverage-feedback — These cap superblock formation once a given percentage of the executed instructions is covered 🧁. It stops the code from bloating for no reason. The -feedback version only matters when profile feedback is available. Real profiles are way less balanced than statically estimated ones, so that threshold can be a bit higher 💅.
• tracer-max-code-growth — Tail duplication stops once code growth hits this percentage 📈. It's kind of an artificial limit, since most duplicates get cleaned up later in cross jumping, so you can set it much higher than the growth you actually want 🤷‍♀️.
• tracer-min-branch-ratio — Reverse growth stops when the reverse probability of the best edge drops below this threshold, given as a percentage 🛑.
• tracer-min-branch-probability, tracer-min-branch-probability-feedback — Forward growth stops if the best edge's probability is lower than this threshold 🚦. Same deal as the dynamic coverage pair: tracer-min-branch-probability-feedback is for compiling with profile feedback, and tracer-min-branch-probability is for compiling without it. The feedback one needs to be more conservative (higher) so the tracer actually does its thing 🎀.
• stack-clash-protection-guard-size — Sets the size of the operating system's stack guard, written as 2 raised to num bytes 🛡️. Bigger values can mean fewer explicit probes.

⚠️ If this value is larger than the operating system's guard, your code is left open to stack clash style attacks. Yikes 😭.

• stack-clash-protection-probe-interval — Stack clash protection probes the stack as space gets allocated 🔍. This param controls the maximum distance between those probes, written as 2 raised to num bytes. Bigger values can cut down on explicit probes too.

⚠️ Same warning here: if the value is larger than the operating system's guard, the code stays vulnerable to stack clash style attacks 💀.

• max-cse-path-length — The maximum number of basic blocks on a path that CSE looks at 🛤️.
• max-cse-insns — The maximum number of instructions CSE processes before it flushes 🚿.
• ggc-min-expand — GCC has its own garbage collector for managing memory 🗑️. This sets the minimum percentage the collector's heap can grow between collections. Tuning it might speed up compilation, but it has zero effect on code generation 🙌.

The default is 30% + 70% * (RAM/1GB), with an upper bound of 100% when RAM is at least 1GB. If "getrlimit" is available, "RAM" means the smaller of actual RAM and RLIMIT_DATA or RLIMIT_AS. If GCC can't work out RAM on a platform, it falls back to the lower bound of 30%. Setting this and ggc-min-heapsize both to zero forces a full collection every single chance it gets. That's extremely slow, but it can be useful for debugging 🐢.

• ggc-min-heapsize — The minimum heap size the garbage collector lets build up before it starts collecting 🧹. The first collection happens once the heap grows by ggc-min-expand% past ggc-min-heapsize. Again, this can speed up compilation but doesn't touch code generation.

The default is the smaller of RAM/8, RLIMIT_RSS, or a limit meant to keep RLIMIT_DATA or RLIMIT_AS from being exceeded. The lower bound is 4096 (four megabytes) and the upper bound is 131072 (128 megabytes). If GCC can't calculate RAM on a platform, the lower bound gets used. Setting this super large effectively turns garbage collection off 🚫. Setting it and ggc-min-expand to zero triggers a full collection at every opportunity.

• max-reload-search-insns — How far back reload looks for an equivalent register, counted in instructions 🔙. Higher values mean more aggressive optimization, and compilation takes longer for probably slightly better performance 🏃‍♀️.
• max-cselib-memory-locations — The maximum number of memory locations cselib considers 🧠. Higher values mean more aggressive optimization, which slows compilation down for probably slightly better performance 📚.
• max-sched-ready-insns — The maximum number of ready-to-issue instructions the scheduler looks at any given time during the first scheduling pass 📋. Higher values mean more thorough searches, which makes compilation slower for probably very little benefit 🐌.
• max-sched-region-blocks — The maximum number of blocks in a region that can be considered for interblock scheduling 🧩.
• max-pipeline-region-blocks — The maximum number of blocks in a region that can be considered for pipelining in the selective scheduler 🎢.
• max-sched-region-insns — The maximum number of insns in a region that can be considered for interblock scheduling 🧃.
• max-pipeline-region-insns — The maximum number of insns in a region that can be considered for pipelining in the selective scheduler 🌊.
• min-spec-prob — The minimum probability, in percent, of reaching a source block for interblock speculative scheduling 🎲.
• max-sched-extend-regions-iters — The maximum number of trips through the CFG when extending regions 🔁. Setting this to 0 disables region extensions 🙅‍♀️.
• max-sched-insn-conflict-delay — The maximum conflict delay an insn can have and still be considered for speculative motion 🕰️.
• sched-spec-prob-cutoff — The minimum probability of speculation success, in percent, needed before speculative insns get scheduled 🎯.
• sched-state-edge-prob-cutoff — The minimum probability an edge needs to have before the scheduler saves its state across it 💾.
• sched-mem-true-dep-cost — The minimum distance, in CPU cycles, between a store and a load that target the same memory locations 🧠⏱️.
• selsched-max-lookahead — The maximum size of the lookahead window in selective scheduling 👀. It's the depth of the search for available instructions.
• selsched-max-sched-times — The maximum number of times an instruction gets scheduled during selective scheduling 🔄. This caps how many iterations the instruction can be pipelined through.
• selsched-insns-to-rename — The maximum number of best instructions in the ready list that get considered for renaming in the selective scheduler ✏️.
• sms-min-sc — The minimum stage count that the swing modulo scheduler generates 🎡.
• max-last-value-rtl — The maximum size, measured in RTLs, that the combiner can record in an expression as the last known value of a pseudo register 📝.
• max-combine-insns — The maximum number of instructions the RTL combiner tries to combine 🧷.
• max-combine-search-insns — The maximum number of instructions the RTL combiner searches to find the next use of a given register definition 🔎. If it hits this limit without finding a use, the combiner stops trying to optimize that definition 🛑.

Right now this limit only kicks in after certain successful combination attempts, but it could get extended to other cases in the future 🔮.

• integer-share-limit — Small integer constants can use a shared data structure, which saves memory and speeds things up 🏎️. This sets the maximum value of a shared integer constant.
• ssp-buffer-size — The minimum size of buffers (arrays, basically) that get stack smashing protection when -fstack-protector is used 🛡️.

Before Ubuntu 10.10 this default was "8". Currently it's "4", so more functions get protected by the stack protector 💖.

• min-size-for-stack-sharing — 🧚 The smallest size a variable needs to be before it can join in on stack slot sharing when you're not optimizing. Tiny variables are left out. 🌸
• max-jump-thread-duplication-stmts — 💅 The max number of statements a block can have when it needs to get duplicated during jump threading. Any bigger and it's a no from the compiler. 🙅‍♀️
• max-jump-thread-paths — 🦋 The max number of paths the compiler will check while hunting for jump threading chances. When it reaches a block, it only looks at incoming edges if (paths searched so far) × (incoming edges) doesn't blow past this limit. Not every edge gets a turn, bestie. 💜
• max-fields-for-field-sensitive — ✨ The max number of fields in a structure that get treated in a field sensitive way during pointer analysis. 🫶
• prefetch-latency — ⏰ An estimate of how many instructions run on average before a prefetch finishes. The distance the prefetch reaches ahead is proportional to this number. Crank it up and you may end up with fewer streams getting prefetched (see simultaneous-prefetches). 🔥
• simultaneous-prefetches — 🏃‍♀️ The max number of prefetches that can run at the same time. 🌈
• l1-cache-line-size — 🍓 How big one cache line is in the L1 data cache, in bytes. 📏
• l1-cache-size — 🎀 How big the L1 data cache is, in kilobytes. 🧁
• l2-cache-size — 🎀 How big the L2 data cache is, in kilobytes. 💖
• prefetch-dynamic-strides — 🌸 Decides whether the loop array prefetch pass should slap on software prefetch hints for strides that aren't constant. Sometimes that's a total win, but a non-constant stride makes it hard to tell when the hints are actually worth it, so it's a bit of a gamble. 🎲

Set it to 1 if you want prefetch hints issued for non-constant strides. Set it to 0 if you only want hints for strides that are known to be constant and below prefetch-minimum-stride. 🫶

• prefetch-minimum-stride — 🦄 The smallest constant stride, in bytes, where prefetch hints start kicking in. If the stride is below this threshold, no prefetch hints get issued. 🙈

This one is a big deal for processors with hardware prefetchers, since the hardware and software prefetchers can end up fighting each other. If the hardware prefetchers have a max stride they can handle, put that number here so the software prefetchers don't step on their toes. 💅

A value of -1 means there's no threshold at all, so prefetch hints can be issued for any constant stride. ✨

Heads up: this setting only matters for strides that are known and constant. 🧐

• destructive-interference-size, constructive-interference-size — 👑 These are the values behind the C++17 variables std::hardware_destructive_interference_size and std::hardware_constructive_interference_size. 🤯

The destructive interference size is the minimum recommended offset between two independent objects that get accessed concurrently. The constructive interference size is the maximum recommended size of contiguous memory that gets accessed together. Usually both match the size of an L1 cache line for the target, in bytes. For a generic target that covers a whole range of L1 cache line sizes, the constructive size is typically the small end of the range and the destructive size is the large end. 🌈

The destructive interference size is meant for layout, so it has ABI impact. Its default isn't expected to stay stable, and on some targets it changes with -mtune. So using it somewhere ABI stability really matters, like a library's public interface, is strongly discouraged. If you do use it there anyway, you can lock the value in with this option. 🚨

The constructive interference size is way less sensitive, since it's usually only used in a static_assert to make sure a type fits inside a cache line. 💖

See also -Winterference-size. 👀

• loop-interchange-max-num-stmts — 🔁 The max number of statements a loop can have and still get interchanged. 🌸
• loop-interchange-stride-ratio — 📐 The minimum ratio between the strides of two loops for interchange to be worth it. 💜
• min-insn-to-prefetch-ratio — 🧮 The minimum ratio between the number of instructions and the number of prefetches needed to turn prefetching on in a loop. 🦋
• prefetch-min-insn-to-mem-ratio — 🧮 The minimum ratio between the number of instructions and the number of memory references needed to turn prefetching on in a loop. 🍓
• use-canonical-types — 🧠 Decides whether the compiler uses the "canonical" type system. This should always be 1, since it's a much more efficient internal way to compare types in C++ and Objective-C++. 💅

But if bugs in the canonical type system are breaking your compilation, set it to 0 to turn canonical types off. 🙏

• switch-conversion-max-branch-ratio — 🔀 Switch initialization conversion won't build arrays bigger than switch-conversion-max-branch-ratio times the number of branches in the switch. Too big and it just says no. 🙅‍♀️
• switch-lower-slow-alg-max-cases — 🐢 The max number of cases that the slow switch lowering algorithms are allowed to handle. 🫠
• max-partial-antic-length — 🌊 The max length of the partial antic set computed during tree partial redundancy elimination (-ftree-pre) when you're optimizing at -O3 and up. For some kinds of source code, the enhanced partial redundancy elimination can totally run away and eat all the memory on the host machine. This param caps the length of those sets so it can't go wild. 💀

Setting it to 0 lets the set length be unlimited, so no cap at all. 🔓

• rpo-vn-max-loop-depth — 🪆 The max loop depth that gets value-numbered optimistically. When the limit gets hit, the innermost rpo-vn-max-loop-depth loops and the outermost loop in the loop nest get value-numbered optimistically, and the remaining ones don't. ✨
• sccvn-max-alias-queries-per-access — 🔍 The max number of alias-oracle queries the compiler will run while hunting for redundancies in loads and stores. If the limit gets hit, the search is aborted and that load or store doesn't count as redundant. The number of queries is algorithmically capped at the number of stores on all paths from the load to the function entry. 🧵
• ira-max-loops-num — 🔄 IRA uses regional register allocation by default. If a function has more loops than this number, only the given number of the most frequently executed loops end up forming regions for regional register allocation. 🏆
• ira-max-conflict-table-size — 🗂️ IRA has a fancy algorithm for compressing the conflict table, but huge functions can still need a ton of memory for it. If the conflict table for a function could be bigger than this many MB, the register allocator switches to a faster, simpler, and lower-quality algorithm that doesn't build a pseudo-register conflict table at all. 🥲
• ira-loop-reserved-regs — 🧺 IRA can estimate register pressure more accurately inside loops, which helps when deciding whether to move loop invariants (see -O3). This param sets how many available registers are reserved for other purposes. The default is the best value found from loads of experiments. 🧪
• ira-consider-dup-in-all-alts — 🎯 Tells IRA to really weigh a matching constraint (a duplicated operand number) across every available alternative for the preferred register class. If it's set to zero, IRA only respects the matching constraint when it's the only available alternative with a suitable register class. Otherwise, IRA checks every available alternative for the preferred register class, even after it's found one that works, and still respects the qualified matching constraint it found. 🧩
• ira-simple-lra-insn-threshold — 📊 The approximate number of function insns, in units of 1K, that triggers simple local RA. ✅
• lra-inheritance-ebb-probability-cutoff — 🧬 LRA tries to reuse values that were reloaded into registers in later insns. This is called inheritance, and it uses the EBB as the region for the optimization. This param sets the minimum fall-through edge probability, as a percentage, for adding a BB to an inheritance EBB in LRA. The default was picked from loads of SPEC2000 runs on x86-64. 🏋️‍♀️
• loop-invariant-max-bbs-in-loop — 🏗️ Loop invariant motion can get super expensive, both in compile time and in compile-time memory, when loops are huge. Any loop with more basic blocks than this param won't get loop invariant motion done on it. 🚫
• loop-max-datarefs-for-datadeps — 🔗 Building data dependencies is expensive for really big loops. This param limits how many data references in a loop get considered for data dependence analysis. Loops that are too large for that aren't handled by the optimizations that use loop data dependencies. 🙅‍♀️
• max-vartrack-size — 🕵️‍♀️ Sets the max number of hash table slots that can be used during variable tracking dataflow analysis for any function. If that limit gets exceeded while variable tracking at assignments is enabled, the analysis for that function gets retried without it, after all debug insns are removed from the function. If it's still too big even without debug insns, var tracking analysis is completely disabled for that function. Setting this to zero makes it unlimited. 🌟

⚠️ Heads up: the destructive interference size's default can shift between targets and with -mtune, so don't lean on it for ABI-sensitive stuff. Pin it down with the option instead. 💖

• max-vartrack-expr-depth — 💖 okay so this one sets how many recursion levels the compiler can dig through when it tries to map variable names or debug temporaries to value expressions. It's a trade: more compile time for more complete debug info ✨. Set it too low and value expressions that could've made it into the debug info just get skipped 😭. Set it higher and the compiler can find fancier debug expressions, but compile time and memory use may grow 🫠.
• max-debug-marker-count — 🎀 this is a cap on how many debug markers (like begin stmt markers) you're allowed to have, so things don't blow up during inlining or expansion to RTL 💀. If a function has more of these gimple stmts than the limit, they get dropped from the inlined copy of the function and from its RTL expansion. Main character energy, but make it reasonable 💅.
• min-nondebug-insn-uid — 🧚 uids start counting from this number for nondebug insns. Everything below it is reserved exclusively for debug insns created by -fvar-tracking-assignments. BUT if that reserved range runs out, debug insns can still get (non-overlapping) uids above the line 🙈.
• ipa-sra-deref-prob-threshold — 🦋 IPA-SRA only swaps a pointer that's known not to be NULL for one or more new parameters when the probability of it being dereferenced is higher than this value. The probability is in percent, relative to function entry 📈.
• ipa-sra-ptr-growth-factor — 🌸 IPA-SRA only replaces a pointer to an aggregate with one or more new parameters when their cumulative size is less than or equal to ipa-sra-ptr-growth-factor times the size of the original pointer parameter. No bloating allowed, bestie 🙅‍♀️.
• ipa-sra-ptrwrap-growth-factor — 🍓 this is the extra growth allowed on top of that, for total size of the new parameters. It applies when IPA-SRA replaces a pointer to an aggregate that points to a local variable the caller only writes to and passes along as an argument to other functions 🫶.
• ipa-sra-max-replacements — 💜 the max number of pieces of an aggregate that IPA-SRA tracks. Because of that, it's also the max number of replacements of a formal parameter ✨.
• sra-max-scalarization-size-Ospeed, sra-max-scalarization-size-Osize — 🔥 so the two Scalar Reduction of Aggregates passes (SRA and IPA-SRA) are obsessed with swapping scalar parts of aggregates for uses of independent scalar variables. These two params control the max size, in storage units, of an aggregate that's even considered for replacement. The first one is for when you're compiling for speed, the second is for when you're compiling for size 🌈.
• sra-max-propagations — 👑 the max number of artificial accesses that Scalar Replacement of Aggregates (SRA) will track per local variable, so it can do copy propagation 🧠.
• tm-max-aggregate-size — 🌷 when copying thread-local variables inside a transaction, this sets the size in bytes after which variables get saved with the logging functions instead of save/restore code sequence pairs. This only matters when using -fgnu-tm 🎀.
• graphite-max-nb-scop-params — 🧁 to avoid exponential effects in the Graphite loop transforms, the number of parameters in a Static Control Part (SCoP) is bounded. Set it to 0 if you want to lift the bound 🔓. A variable whose value is unknown at compile time and defined outside a SCoP counts as a parameter of the SCoP ✨.
• hardcfr-max-blocks — 🛡️ this one turns off -fharden-control-flow-redundancy for functions with more blocks than the value you set. 0 removes any limit at all 🫡.
• hardcfr-max-inline-blocks — ⚡ this forces -fharden-control-flow-redundancy to use out-of-line checking for functions with more basic blocks than the value you set 🌸.
• loop-block-tile-size — 🍭 loop blocking or strip mining transforms (enabled with -floop-block or -floop-strip-mine) strip mine each loop in the loop nest by a given number of iterations. You can change that strip length using this parameter 💅.
• ipa-jump-function-lookups — 🔍 this specifies the number of statements visited during jump function offset discovery. Very detective behavior 🕵️‍♀️.
• ipa-cp-value-list-size — 📚 IPA-CP tries to track every possible value and type passed to a function's parameter so it can propagate them and perform devirtualization. This is the max number of values and types it stores per one formal parameter of a function 💖.
• ipa-cp-eval-threshold — 🧮 IPA-CP calculates its own score for cloning profitability heuristics, then performs the cloning opportunities whose scores exceed ipa-cp-eval-threshold 🎯.
• ipa-cp-max-recursive-depth — 🔁 the max depth of recursive cloning for a self-recursive function. Don't spiral 🌀.
• ipa-cp-min-recursive-probability — 🎲 recursive cloning only happens when the probability of the call being executed exceeds this parameter 🫧.
• ipa-cp-profile-count-base — 📊 when you use -fprofile-use, IPA-CP looks at the measured execution count of a call graph edge at this percentage position in its histogram, and uses that as the basis for its heuristics calculation 🍰.
• ipa-cp-recursive-freq-factor — 🔄 the number of times interprocedural copy propagation expects recursive functions to call themselves. Iconic self-reference behavior 🙈.
• ipa-cp-recursion-penalty — 😤 a percentage penalty that recursive functions get when they're evaluated for cloning. Not it 💀.
• ipa-cp-single-call-penalty — 📞 a percentage penalty for functions containing a single call to another function, applied when they're evaluated for cloning 🫠.
• ipa-max-agg-items — 🎁 IPA-CP can also propagate a number of scalar values passed in an aggregate. This one controls the max number of those values per one parameter 💜.
• ipa-cp-loop-hint-bonus — 🏆 when IPA-CP figures out that a cloning candidate would make the number of loop iterations known, it adds a bonus of ipa-cp-loop-hint-bonus to that candidate's profitability score 🌟.
• ipa-max-loop-predicates — 🔮 the max number of different predicates IPA uses to describe when loops in a function have known properties ✨.
• ipa-max-aa-steps — 🧭 while analyzing function bodies, IPA-CP uses alias analysis to track values pointed to by function parameters. So it doesn't spend forever on huge functions, it gives up and treats all memory as clobbered after examining ipa-max-aa-steps statements that modify memory 🥱.
• ipa-max-switch-predicate-bounds — 🔀 the max number of boundary endpoints of case ranges in a switch statement. For a switch that goes over this limit, IPA-CP won't build the cloning cost predicate used to estimate cloning benefit for the switch's default case 🙅‍♀️.
• ipa-max-param-expr-ops — 🧩 IPA-CP analyzes conditional statements that reference a function parameter to estimate cloning benefit for a certain constant value. But if a parameter expression has more operations than ipa-max-param-expr-ops, it's considered too complicated and isn't handled by IPA analysis 😵‍💫.
• lto-partitions — 🧱 the desired number of partitions produced during WHOPR compilation. The number of partitions should be more than the number of CPUs used for compilation 🖥️.
• lto-min-partition — 🪶 the size of the minimal partition for WHOPR (in estimated instructions). This keeps you from splitting very small programs into way too many partitions 🙄.
• lto-max-partition — 🏰 the size of the max partition for WHOPR (in estimated instructions), giving an upper bound for the individual size of a partition. It's only meant for use with balanced partitioning ⚖️.
• lto-partition-locality-frequency-cutoff — ✂️ the denominator n of the fraction 1/n of the execution frequency of a callee to be cloned for a particular caller. The special value 0 means always clone, no cut-off 🫶.
• lto-partition-locality-size-cutoff — 📏 the size cut-off for a callee, including inlined calls, to be cloned for a particular caller 💅.
• lto-max-locality-partition — 🗺️ the maximal size of a locality partition for LTO (in estimated instructions). A value of 0 means the default value gets used 🌷.
• lto-max-streaming-parallelism — 🌊 the maximal number of parallel processes used for LTO streaming. Teamwork makes the dream work 👯‍♀️.
• cxx-max-namespaces-for-diagnostic-help — 📖 the max number of namespaces to check for suggestions when C++ name lookup fails for an identifier. Helpful but please don't overdo it 🙈.
• sink-frequency-threshold — 🌊 the max relative execution frequency (in percent) of the target block, compared to a statement's original block, that still allows that statement to be sunk. Bigger numbers mean more aggressive statement sinking. Statements with memory operands get a small positive adjustment, because they're even more profitable to sink 💰.
• max-stores-to-sink — 🛁 the max number of conditional store pairs that can be sunk. Set it to 0 if either vectorization (-ftree-vectorize) or if-conversion (-ftree-loop-if-convert) is disabled 🚫.
• case-values-threshold — 🪜 the smallest number of different values for which it's best to use a jump-table instead of a tree of conditional branches. If the value is 0, the default for the machine is used 🎯.
• jump-table-max-growth-ratio-for-size — 📦 the max code size growth ratio when expanding into a jump table (in percent). This param is used when optimizing for size 🤏.
• jump-table-max-growth-ratio-for-speed — 🏎️ the max code size growth ratio when expanding into a jump table (in percent). This param is used when optimizing for speed 💨.
• tree-reassoc-width — 🎶 sets the max number of instructions executed in parallel in a reassociated tree. If it has a non-zero value, this overrides the target-dependent heuristics that are used by default ✨.
• sched-pressure-algorithm: okay so this one lets you pick between the two versions of -fsched-pressure 💅 Algorithm 1 is the OG and is the more likely to stop instructions from getting reordered 🙈 Algorithm 2 was built as a compromise between algorithm 1's pretty cautious energy and the rather aggressive default scheduler 🔥 It leans harder on having a regular register file and accurate register pressure classes ✨ See haifa-sched.cc in the GCC sources for the full tea. The default choice depends on the target 🎀
• max-slsr-cand-scan: caps how many existing candidates get checked when hunting for a basis for a new straight-line strength reduction candidate 🧚
• asan-globals: turns on buffer overflow detection for global objects 🌸 This is on by default when you use -fsanitize=address. To turn off global objects protection, use --param asan-globals=0.
• asan-stack: buffer overflow detection for stack objects, and it's on by default with -fsanitize=address 💖 To disable stack protection, use --param asan-stack=0 option.
• asan-instrument-reads: buffer overflow detection for memory reads 👀 Also on by default with -fsanitize=address. To turn off memory reads protection, use --param asan-instrument-reads=0.
• asan-instrument-writes: buffer overflow detection for memory writes ✍️ On by default with -fsanitize=address. To turn off memory writes protection, use --param asan-instrument-writes=0 option.
• asan-memintrin: detection for built-in functions 🦋 On by default with -fsanitize=address. To turn off built-in functions protection, use --param asan-memintrin=0.
• asan-use-after-return: detection of use-after-return 🫶 On by default with the -fsanitize=address option. To turn it off, use --param asan-use-after-return=0.

Note: By default the check is disabled at run time 😭 To turn it on, add "detect_stack_use_after_return=1" to the ASAN_OPTIONS environment variable.

• asan-instrumentation-with-call-threshold: if the number of memory accesses in the function being instrumented is greater than or equal to this number, ASan uses callbacks instead of inline checks 💅 E.g. to skip the inline code entirely, use --param asan-instrumentation-with-call-threshold=0.
• asan-kernel-mem-intrinsic-prefix: if nonzero, calls to "memcpy", "memset" and "memmove" get prefixed with __asan_ or __hwasan_ for -fsanitize=kernel-address or -fsanitize=kernel-hwaddress, respectively 🧚
• hwasan-instrument-stack: hwasan instrumentation for statically sized stack-allocated variables ✨ It's on by default with -fsanitize=hwaddress and off by default with -fsanitize=kernel-hwaddress. To turn it off, use --param hwasan-instrument-stack=0, and to turn it on, use --param hwasan-instrument-stack=1.
• hwasan-random-frame-tag: when you're using stack instrumentation, tags for stack variables come from a deterministic sequence that starts at a random tag for each frame 🌈 With this unset, the tags use the same sequence but start from 1. It's enabled by default for -fsanitize=hwaddress and unavailable for -fsanitize=kernel-hwaddress. To disable it, use --param hwasan-random-frame-tag=0.
• hwasan-instrument-allocas: hwasan instrumentation for dynamically sized stack-allocated variables 🍓 It's on by default with -fsanitize=hwaddress and off by default with -fsanitize=kernel-hwaddress. To turn it off, use --param hwasan-instrument-allocas=0, and to turn it on, use --param hwasan-instrument-allocas=1.
• hwasan-instrument-reads: hwasan checks on memory reads 👑 Enabled by default for both -fsanitize=hwaddress and -fsanitize=kernel-hwaddress. To stop checking memory reads, use --param hwasan-instrument-reads=0.
• hwasan-instrument-writes: hwasan checks on memory writes ✨ Enabled by default for both -fsanitize=hwaddress and -fsanitize=kernel-hwaddress. To stop checking memory writes, use --param hwasan-instrument-writes=0.
• hwasan-instrument-mem-intrinsics: hwasan instrumentation for builtin functions 💜 Enabled by default for both -fsanitize=hwaddress and -fsanitize=kernel-hwaddress. To turn off instrumentation of builtin functions, use --param hwasan-instrument-mem-intrinsics=0.
• use-after-scope-direct-emission-threshold: if a local variable's size in bytes is smaller than or equal to this number, shadow memory gets poisoned (or unpoisoned) directly instead of going through run-time callbacks 🎀
• tsan-distinguish-volatile: emits special instrumentation for accesses to volatiles 🔥
• tsan-instrument-func-entry-exit: emits instrumentation calls to __tsan_func_entry() and __tsan_func_exit() 🦋
• max-fsm-thread-path-insns: the maximum number of instructions to copy when duplicating blocks on a finite state automaton jump thread path 💅
• threader-debug: threader-debug=[none|all] turns on verbose dumping of the threader solver 🧠
• parloops-chunk-size: chunk size of the omp schedule for loops parallelized by parloops 🌸
• parloops-schedule: schedule type of the omp schedule for loops parallelized by parloops, which can be static, dynamic, guided, auto, or runtime 🍓
• parloops-min-per-thread: the minimum number of iterations per thread of an innermost parallelized loop where the parallel version beats the single-threaded one 🧚 Heads up that for a parallelized loop nest, the minimum number of iterations of the outermost loop per thread is two.
• max-ssa-name-query-depth: the maximum recursion depth when querying properties of SSA names in things like fold routines 💖 One level of recursion means following one use-def chain.
• max-speculative-devirt-maydefs: the maximum number of may-defs we analyze while looking for a must-def that specifies the dynamic type of an object invoking a virtual call we might be able to speculatively devirtualize 👀
• ranger-debug: sets the type of debug output issued for ranges 🫶
• unroll-jam-min-percent: the minimum percentage of memory references that must be optimized away for unroll-and-jam to count as profitable ✨
• unroll-jam-max-unroll: the maximum number of times the outer loop gets unrolled by unroll-and-jam 🌈
• max-rtl-if-conversion-unpredictable-cost: the maximum permissible cost for the sequence the RTL if-conversion pass would generate for a branch that's considered unpredictable 💀
• max-variable-expansions-in-unroller: if -fvariable-expansion-in-unroller is used, this is the maximum number of times an individual variable gets expanded during loop unrolling 🍓
• partial-inlining-entry-probability: the maximum probability of the entry BB of a split region (as a percent relative to the function's entry BB) that still lets partial inlining happen 🎀
• max-tracked-strlens: the maximum number of strings the strlen optimization pass will track string lengths for 🧚
• gcse-after-reload-partial-fraction: the threshold ratio for performing partial redundancy elimination after reload 🔥
• gcse-after-reload-critical-fraction: the threshold ratio of critical edges' execution count that allows redundancy elimination after reload 💜
• max-loop-header-insns: the maximum number of insns in a loop header duplicated by the copy loop headers pass 👑
• vect-epilogues-nomask: enables loop epilogue vectorization using a smaller vector size 🦋
• vect-partial-vector-usage: controls when the loop vectorizer considers partial vector loads and stores as an alternative to falling back to scalar code 💅 The parameter only has an effect on targets that support partial vector loads and stores. The values mean:
  • 0: the vectorizer never uses partial vector loads and stores ❌
  • 1: partial vector loads and stores are allowed if vectorization removes the need for the code to iterate ✨
  • 2: partial vector loads and stores are allowed in all loops 🌸
• vect-inner-loop-cost-factor: the maximum factor the loop vectorizer applies to the cost of statements in an inner loop, relative to the loop being vectorized 🧠 The factor applied is the maximum of the estimated number of iterations of the inner loop and this parameter. The default value of this parameter is 50.
• vect-induction-float: enables loop vectorization of floating point inductions 🌈
• vect-force-slp: forces the use of SLP when vectorizing, and fails if that isn't possible 🔥
• vrp-block-limit: the maximum number of basic blocks before VRP switches to a lower-memory algorithm 🧚
• vrp-sparse-threshold: the maximum number of basic blocks before VRP uses a sparse bitmap cache 🫶
• vrp-switch-limit: the maximum number of outgoing edges in a switch before VRP won't process it 💀
• vrp-vector-threshold: the maximum number of basic blocks for VRP to use a basic cache vector 🍓
• avoid-fma-max-bits: the maximum number of bits for which we avoid creating FMAs 💖

Okay so bestie, we're picking up right where the --param list was getting spicy 🌶️✨

• fully-pipelined-fma — 🦋 This is a target setting that says whether the chip fully pipelines FMA instructions. If it's non-zero, reassociation weighs the perks of splitting FMA's multiplication part and addition part apart, assuming FMUL and FMA share the same units that can also handle FADD. Main character energy 👑
• sms-loop-average-count-threshold — 🌸 A threshold on the average loop count that the swing modulo scheduler looks at.
• sms-dfa-history — 💜 The number of cycles the swing modulo scheduler peeks at when it checks for conflicts using DFA.
• graphite-allow-codegen-errors — 🙈 Decides whether codegen errors should be ICEs when -fchecking is on. ICE alert 🧊
• sms-max-ii-factor — ✨ A factor for tuning the upper bound the swing modulo scheduler uses when it schedules a loop.
• lra-max-considered-reload-pseudos — 🎀 The max number of reload pseudos that get considered while spilling a non-reload pseudo. So many pseudos, so little time 💀
• max-pow-sqrt-depth — 🧚 The maximum depth of sqrt chains allowed when synthesizing exponentiation by a real constant.
• max-dse-active-local-stores — 🍓 The maximum number of active local stores in RTL dead store elimination. Bye bye, useless stores 👋
• asan-instrument-allocas — 🛡️ Turns on asan protection for allocas and VLAs. Stay safe, bestie 🫶
• max-iterations-computation-cost — 🌈 The bound on how costly an expression can be when computing the number of iterations.
• max-isl-operations — 💅 The maximum number of isl operations. 0 means unlimited, which is giving no limits energy 🔥
• graphite-max-arrays-per-scop — 🦋 The maximum number of arrays per scop.
• max-vartrack-reverse-op-size — ⭐ The max size of a loc list for which reverse ops should be added.
• fsm-scale-path-stmts — 💖 A scale factor applied to the number of statements in a threading path that crosses a loop backedge, when it gets compared against --param=max-jump-thread-duplication-stmts. Math-heavy but iconic 🧮
• uninit-control-dep-attempts — 🌸 The maximum number of nested calls used to hunt for control dependencies during uninitialized variable analysis.
• uninit-max-chain-len — 💜 The maximum number of predicates anded together for each predicate ored in the normalized predicate chain.
• uninit-max-num-chains — ✨ The maximum number of predicates ored together in the normalized predicate chain.
• uninit-max-prune-work — 🎀 The maximum amount of work spent pruning paths where the variable is always initialized. Don't overdo it, queen 👑
• sched-autopref-queue-depth — 🧚 A control flag for the hardware autoprefetcher scheduler model. It's the number of lookahead cycles the model peeks into. At ' ', it only enables the instruction sorting heuristic 🍓
• loop-versioning-max-inner-insns — 🌈 The maximum number of instructions an inner loop can have before the loop versioning pass says "nope, too big to copy" 🙅‍♀️
• loop-versioning-max-outer-insns — 🦋 The maximum number of instructions an outer loop can have before the loop versioning pass calls it too big to copy. Any instructions in inner loops that directly benefit from versioning get discounted, so they don't count against it ✨
• ssa-name-def-chain-limit — ⭐ The maximum number of SSA_NAME assignments to follow when figuring out a property of a variable, like its value. This caps how many iterations or recursive calls GCC makes while optimizing certain statements or checking whether they're valid before it issues diagnostics. Boundaries are self-care 💖
• store-merging-max-size — 💜 The maximum size of a single store merging region, in bytes.
• store-forwarding-max-distance — 🌸 The maximum instruction distance that a small store forwarded to a larger load may stall. Setting '0' disables the cost checks for the avoid-store-forwarding pass 🙈
• hash-table-verification-limit — 🎀 The number of elements that get hash table verification for each searched element.
• max-find-base-term-values — 🧚 The maximum number of VALUEs handled during a single find_base_term call.
• analyzer-max-enodes-per-program-point — 🔥 The maximum number of exploded nodes per program point within the analyzer. Once that's hit, analysis of that point wraps up 🛑
• analyzer-max-constraints — 💅 The maximum number of constraints per state.
• analyzer-min-snodes-for-call-summary — 🍓 The minimum number of supernodes within a function before the analyzer even considers summarizing its effects at call sites.
• analyzer-max-enodes-for-full-dump — 🌈 The maximum depth of exploded nodes that should show up in a dot dump before it switches to a less verbose format 📉
• analyzer-max-recursion-depth — 🦋 The maximum number of times a callsite can show up in a call stack within the analyzer. Once that's reached, analysis of a call that would recurse deeper gets terminated. Not today, recursion 🔁
• analyzer-max-svalue-depth — ✨ The maximum depth of a symbolic value. Past that, the value gets approximated as unknown 🤷‍♀️
• analyzer-max-infeasible-edges — ⭐ The maximum number of infeasible edges to reject before a diagnostic gets declared infeasible.
• gimple-fe-computed-hot-bb-threshold — 💖 The number of executions a basic block needs before it counts as hot. This parameter is only used in the GIMPLE FE 🧪
• analyzer-bb-explosion-factor — 💜 The maximum number of after supernode exploded nodes within the analyzer per supernode, before analysis terminates 💥
• analyzer-text-art-string-ellipsis-threshold — 🎀 The number of bytes at which string literals get ellipsized in analyzer text art diagrams 🎨
• analyzer-text-art-ideal-canvas-width — 🌸 The ideal width, in characters, of text art diagrams generated by the analyzer 📏
• analyzer-text-art-string-ellipsis-head-len — 🧚 The number of literal bytes shown at the head of a string literal in text art when it gets ellipsized ✂️
• analyzer-text-art-string-ellipsis-tail-len — 🍓 The number of literal bytes shown at the tail of a string literal in text art when it gets ellipsized ✂️
• ranger-logical-depth — 🌈 The maximum depth of logical expression evaluation that ranger looks through when it evaluates outgoing edge ranges 🧠
• ranger-recompute-depth — 🦋 The maximum depth of instruction chains to consider for recomputation in the outgoing range calculator ♻️
• relation-block-limit — ⭐ The maximum number of relations the oracle will register in a basic block 🧷
• transitive-relations-work-bound — 💅 A work bound for when transitive relations get discovered from existing relations 🔍
• min-pagesize — 🔥 The minimum page size used for warning and early break vectorization purposes 📄
• openacc-kernels — 🧪 Specifies the mode for handling OpenACC kernels constructs. With --param=openacc-kernels=decompose, OpenACC kernels constructs get broken into parts, a sequence of compute constructs, and each part gets handled on its own. This one's still work in progress 🚧 With --param=openacc-kernels=parloops, OpenACC kernels constructs are handled en bloc by the parloops pass. This is the current default ✅
• openacc-privatization — 🙊 Controls whether the -fopt-info-omp-note and applicable -fdump-tree-*-details options emit OpenACC privatization diagnostics. With --param=openacc-privatization=quiet, nothing gets diagnosed. This is the current default. With --param=openacc-privatization=noisy, diagnostics do get emitted 📣
• cycle-accurate-model — 🎯 Says whether GCC should assume the scheduling description is mostly a cycle-accurate model of the target processor the code is meant to run on, when there are no cache misses. Nonzero means the selected scheduling model is accurate and probably describes an in-order processor, and scheduling should aggressively spill to fill any pipeline bubbles. This is the current default. Zero means the scheduling description might be unavailable or inaccurate, or maybe not applicable at all, like for modern out-of-order processors 🌀

The following choices of name are available on AArch64 targets:

• aarch64-vect-compare-costs — 🧮 When vectorizing, GCC can try several different approaches and let the cost model pick the cheapest one. That includes:
  • Trying both SVE and Advanced SIMD, when SVE is available.
  • Trying to use 64-bit Advanced SIMD vectors for the smallest data elements, rather than using 128-bit vectors for everything.
  • Trying to use "unpacked" SVE vectors for smaller elements. This includes storing smaller elements in larger containers and accessing elements with extending loads and truncating stores.
• aarch64-float-recp-precision — 🦋 The number of Newton iterations for calculating the reciprocal for the float type. The precision of division is proportional to this param when division approximation is enabled. The default value is 1 ✨
• aarch64-double-recp-precision — 💖 The number of Newton iterations for calculating the reciprocal for the double type. The precision of division is proportional to this param when division approximation is enabled. The default value is 2 💜
• aarch64-autovec-preference — 👑 Forces an ISA selection strategy for auto-vectorization. The choices are:
  • default — uses the default heuristics.
  • asimd-only — uses only Advanced SIMD for auto-vectorization.
  • sve-only — uses only SVE for auto-vectorization.
  • prefer-asimd — uses both Advanced SIMD and SVE, but prefers Advanced SIMD when the costs are deemed equal.
  • prefer-sve — uses both Advanced SIMD and SVE, but prefers SVE when the costs are deemed equal.
• aarch64-ldp-policy — 🌈 A fine-grained policy for load pairs. With --param=aarch64-ldp-policy=default, the policy of the tuning structure gets used. This is the current default. With --param=aarch64-ldp-policy=always, ldp gets emitted regardless of alignment. With --param=aarch64-ldp-policy=never, ldp is not emitted. With --param=aarch64-ldp-policy=aligned, ldp only gets emitted if the source pointer is aligned to at least double the alignment of the type 🫶

aarch64-stp-policy is the fine-grained knob for store pairs 💅. With --param=aarch64-stp-policy=default, you get whatever the tuning structure says, which is also the current default ✨. With --param=aarch64-stp-policy=always, GCC emits stp no matter what the alignment looks like 🔥. With --param=aarch64-stp-policy=never, GCC does not emit stp at all 🙈. With --param=aarch64-stp-policy=aligned, GCC only emits stp if the source pointer is aligned to at least double the alignment of the type 🎀.

• aarch64-ldp-alias-check-limit — this caps how many alias checks the AArch64 load/store pair fusion pass does when it tries to form an ldp/stp 🦋. Higher numbers make the pass more aggressive about re-ordering loads over stores, but compile time goes up to pay for it 🥲.
• aarch64-ldp-writeback — this controls which writeback opportunities the AArch64 load/store pair fusion pass bothers with 🌸. A value of 0 turns writeback handling off completely 🚫. A value of 1 means it tries to form pairs that involve one or more existing individual writeback accesses wherever it can 🫶. A value of 2 means it also goes out of its way to opportunistically create writeback opportunities by folding in trailing destructive updates of the base register used by a pair 💜.
• aarch64-loop-vect-issue-rate-niters — some AArch64 CPUs tuning tries to weigh both latencies and issue rates when deciding whether a loop should be vectorized with SVE, vectorized with Advanced SIMD, or not vectorized at all 🧠. If you set this to n, GCC skips that heuristic for loops that are known to run in fewer than n Advanced SIMD iterations ⭐.
• aarch64-vect-unroll-limit — the vectorizer checks the available tuning info to decide whether unrolling the main vectorized loop would help, and by how much 🌈. This param sets the upper bound on how much it's allowed to unroll that main loop 📏. The default value is four 🍓.

The following choices of name are available on GCN targets 🧚:

• gcn-preferred-vectorization-factor — the preferred vectorization factor 💖. Your options are default, 32, or 64 ✨.

The following choices of name are available on i386 and x86_64 targets 💅:

• x86-stlf-window-ninsns — the number of instructions above which the STFL stall penalty can be compensated 🫧.
• x86-stv-max-visits — the maximum number of use and def visits allowed while discovering a STV chain before the discovery gets aborted 🛑.

---

🦋 Program Instrumentation Options 🦋

okay so GCC has a whole bunch of command-line options that bolt run-time instrumentation onto the code it normally generates 💖. Instrumentation can be for collecting profiling stats so you can find your program's hot spots, doing code coverage analysis, or running profile-guided optimizations 📊. Another class is adding run-time checks that catch programming errors like invalid pointer dereferences or out-of-bounds array accesses, plus sneaky deliberate attacks like stack smashing or C++ vtable hijacking 🛡️. And there's also a general hook you can use to implement other kinds of tracing or function-level instrumentation for debugging or program analysis 🔍.

• -p, -pg — these generate extra code that writes profile information for the analysis program prof (with -p) or gprof (with -pg) 📈. You have to use this option when compiling the source files you want data about, and you have to use it when linking too, no skipping 🙅‍♀️.

You can use the function attribute "no_instrument_function" to stop profiling of individual functions when you're compiling with these options 🙈.

• -fprofile-arcs — this adds code so program flow arcs get instrumented 🌊. While the program runs, it records how many times each branch and call is executed, and how many times each one is taken or returns 🔁. On targets that support constructors with priority support, profiling handles constructors, destructors, and C++ constructors (and destructors) of classes used as the type of a global variable properly 💜.

When the compiled program exits, it saves this data to a file called auxname.gcda for each source file 💾. That data can be used for profile-directed optimizations (-fbranch-probabilities) or for test coverage analysis (-ftest-coverage) 🎀. Each object file's auxname comes from the name of the output file if you explicitly specified one and it isn't the final executable; otherwise it's the basename of the source file 🧁. Either way, any suffix gets removed. So foo.gcda is made for input file dir/foo.c, or dir/foo.gcda for an output file specified as -o dir/foo.o 🦋.

Heads up bestie: if a command line directly links source files, the matching .gcda files get prefixed with the unsuffixed name of the output file 🫶. For example, gcc a.c b.c -o binary would generate binary-a.gcda and binary-b.gcda files 📁.

• -fcondition-coverage — this adds code so program conditions get instrumented 🔍. While the program runs, it records which terms in a conditional contribute to a decision 🧩. That lets you check that all terms in a Boolean function are tested and have an independent effect on the outcome of a decision ✅. You can read the result with "gcov --conditions" 📖.
• -fpath-coverage — this adds code so the paths taken get tracked 🛤️. While the program runs, it records the prime paths taken 🌟. The number of paths grows super fast with complexity, so to avoid exploding compile times, GCC gives up on instrumentation if the approximate number of paths goes over the limit set by -fpath-coverage-limit 😭. You can read the result with "gcov --prime-paths --prime-paths-lines --prime-paths-source", 💅.
• -fpath-coverage-limit=limit — this is the threshold where -fpath-coverage throws in the towel on instrumenting a function 🏳️. The limit is approximate and conservative, since GCC uses a pessimistic heuristic that slightly overcounts the running number of paths, and it gives up if the threshold is hit before all the paths are found 🤏. This option is not for fine-grained control over which functions get instrumented; it's there to limit the effect of path explosion and keep compile times reasonable ⏱️. The default is 250000 🍓.
• --coverage — this is the one-stop shop for compiling and linking code instrumented for coverage analysis 🌈. It's a synonym for -fprofile-arcs -ftest-coverage (when compiling) and -lgcov (when linking) ✨. Check the docs for those options if you want the deets 📚.

Here's the full routine, step by step:

• Compile the source files with -fprofile-arcs plus your optimization and code generation options. For test coverage analysis, add the extra -ftest-coverage option too. You don't need to profile every single source file in a program 🙌.
• Compile the source files additionally with -fprofile-abs-path so it creates absolute path names in the .gcno files. That lets gcov find the correct sources in projects where compilations happen from different working directories 🗺️.
• Link your object files with -lgcov or -fprofile-arcs (the latter implies the former) 🔗.
• Run the program on a representative workload to generate the arc profile information 🏃‍♀️. You can repeat this any number of times 🔁. You can run concurrent instances of your program, and as long as the file system supports locking, the data files will be correctly updated 🔒. Unless a strict ISO C dialect option is in effect, fork calls are detected and handled correctly without double counting 🍴.

Also, an object file can be recompiled multiple times, and the corresponding .gcda file merges as long as the source file and the compiler options stay unchanged 🧩.

• For profile-directed optimizations, compile the source files again with the same optimization and code generation options plus -fbranch-probabilities 🚀.
• For test coverage analysis, use gcov to produce human-readable info from the .gcno and .gcda files 📝. Check the gcov documentation for more deets 💖.

With -fprofile-arcs, for each function of your program GCC creates a program flow graph and then finds a spanning tree for that graph 🌳. Only the arcs that are not on the spanning tree have to be instrumented: the compiler adds code to count how many times those arcs get executed 🧮. When an arc is the only exit or the only entrance to a block, the instrumentation code can go into the block; otherwise, a new basic block has to be created to hold it 🧱.

With -fcondition-coverage, for each conditional in your program GCC creates a bitset and records the exercised boolean values that have an independent effect on the outcome of that expression 🎯.

With -fpath-coverage, GCC finds, enumerates, and records the taken prime paths of each function, unless the number of paths would exceed the limit set by -fpath-coverage-limit 🛤️. If the limit is exceeded, the function is not instrumented, just as if -fpath-coverage wasn't used 🙃. A prime path is the longest sequence of unique blocks, except possibly the first and last, that is not a subpath of any other path 🌟.

• -ftest-coverage — this produces a notes file that the gcov code-coverage utility can use to show program coverage 📒. Each source file's note file is called auxname.gcno 🗂️. Check the -fprofile-arcs description above for what auxname means and how to generate test coverage data 🔍. Coverage data matches the source files more closely if you don't optimize 🙏.
• -fprofile-abs-path — this automatically converts relative source file names to absolute path names in the .gcno files 🗺️. That lets gcov find the correct sources in projects where compilations happen from different working directories 🫶.
• -fprofile-dir=path — okay so this one tells GCC where to hunt for profile data files 🗂️✨ It only affects profile data made by -fprofile-generate, -ftest-coverage, and -fprofile-arcs, and is used by -fprofile-use, -fbranch-probabilities, and their related options. Absolute and relative paths both work 💅

By default GCC uses the current directory as path, so the profile data file lands in the same directory as the object file. To stop file names from clashing, if the object file name isn't an absolute path, GCC mangles the absolute path of the sourcename.gcda file and uses that as the name of the .gcda file. Check -fprofile-arcs for the full details on file naming, and see the similar -fprofile-note option 🦋

When your executable runs in a massive parallel environment, it's recommended to save profiles to different folders 🌸 You can do that with variables inside path that get exported at run-time:

• %p — the process ID 🆔
• %q{VAR} — the value of the environment variable VAR 🌈
• -fprofile-generate, -fprofile-generate=path — this one turns on the stuff you usually need for instrumenting an app so it spits out a profile that's useful for recompiling later with profile feedback based optimization 🔥 You have to use -fprofile-generate both when compiling AND when linking, no skipping either one 🫶

Turning it on also enables -fprofile-arcs, -fprofile-values, -finline-functions, and -fipa-bit-cp ✨ If you give it a path, GCC looks there for the profile feedback data files. See -fprofile-dir for that 🧚

When you're ready to actually optimize using all that collected profile info, use -fprofile-use 👑

• -fprofile-info-section, -fprofile-info-section=name — this registers the profile information in a specific section instead of using a constructor/destructor 🎀 The section is called name if you give one, otherwise it defaults to ".gcov_info". A pointer to the profile information generated by -fprofile-arcs gets placed in that section for each translation unit. This option turns off the profile registration through a constructor AND turns off profile processing through a destructor 🙈

Heads up: this is NOT meant for hosted environments like GNU/Linux 💀 It targets freestanding environments (think embedded systems) with limited resources that don't support constructors/destructors or C library file I/O.

The linker can collect the input sections into one continuous memory block and define start and end symbols. Here's a GNU linker script example that defines a linker output section:

          .gcov_info      :
          {
            PROVIDE (__gcov_info_start = .);
            KEEP (*(.gcov_info))
            PROVIDE (__gcov_info_end = .);
          }

Your program can then dump the profiling information registered in that linker set, for example like this:

        #include <gcov.h>
        #include <stdio.h>
        #include <stdlib.h>

        extern const struct gcov_info *const __gcov_info_start[];
        extern const struct gcov_info *const __gcov_info_end[];

        static void
        dump (const void *d, unsigned n, void *arg)
        {
          const unsigned char *c = d;

          for (unsigned i = 0; i < n; ++i)
            printf ("%02x", c[i]);
        }

        static void
        filename (const char *f, void *arg)
        {
          __gcov_filename_to_gcfn (f, dump, arg );
        }

        static void *
        allocate (unsigned length, void *arg)
        {
          return malloc (length);
        }

        static void
        dump_gcov_info (void)
        {
          const struct gcov_info *const *info = __gcov_info_start;
          const struct gcov_info *const *end = __gcov_info_end;

          /* Obfuscate variable to prevent compiler optimizations.  */
          __asm__ ("" : "+r" (info));

          while (info != end)
          {
            void *arg = NULL;
            __gcov_info_to_gcda (*info, filename, dump, allocate, arg);
            putchar ('\n');
            ++info;
          }
        }

        int
        main (void)
        {
          dump_gcov_info ();
          return 0;
        }

The merge-stream subcommand of gcov-tool can deserialize the data stream generated by the "__gcov_filename_to_gcfn" and "__gcov_info_to_gcda" functions and merge that profile information into .gcda files on the host filesystem 🧠💜

• -fprofile-note=path — if you give it a path, GCC saves the .gcno file into that location 📝 Heads up: if you combine this with multiple source files, the .gcno file gets overwritten 😭
• -fprofile-prefix-path=path — this one pairs with profile-generate=profile_dir and profile-use=profile_dir to tell GCC where the base directory of your built source tree is 🌳 By default, profile_dir holds files with mangled absolute paths of all object files in the built project, which is NOT ideal if the directory you built the instrumented binary in differs from the one you used for the optimized build, because then the profile data won't be found 🥲 Setting -fprofile-prefix-path=path with path pointing at the base build directory strips the irrelevant part of the path and keeps every file name relative to the main build directory 🫶
• -fprofile-prefix-map=old=new — when compiling files living in directory old, GCC records profiling information (with --coverage) describing them as if they lived in directory new instead 🗺️ See also -ffile-prefix-map and -fcanon-prefix-map 💅
• -fprofile-update=method — this changes the update method for an app instrumented for profile feedback based optimization ⚡ The method argument should be one of single, atomic, or prefer-atomic. The first is great for single-threaded apps, while the second keeps your profile from getting corrupted by emitting thread-safe code 🧵

Warning: if an application doesn't properly join all threads (or creates a detached thread), a profile file can still get corrupted. Yikes 💀

Using prefer-atomic becomes either atomic, when the target supports it, or single otherwise 🤷‍♀️ The GCC driver automatically selects prefer-atomic when -pthread is on the command line; otherwise the default method is single ✨

If atomic is selected, the profile information gets updated using atomic operations on a best-effort basis 💖 Ideally those atomic operations happen in hardware. If the target platform doesn't support the required atomic operations in hardware, but libatomic is available, the profile information gets updated through calls to libatomic 🌟 If the target platform supports neither the hardware atomics nor libatomic, the profile information is NOT atomically updated and a warning is issued. In that case, the profiling info may be corrupt for multi-threaded apps 😬

For performance reasons, if 64-bit counters are used for the profiling information and the target only supports 32-bit atomic operations in hardware, the performance-critical profiling updates are done using two 32-bit atomic operations for each counter update 🏎️ If a signal interrupts those two operations while updating a counter, the profiling information may end up in an inconsistent state 🙈

• -fprofile-filter-files=regex — instruments only functions from files whose name matches any of the regular expressions (separated by semi-colons) 🔍

For example, -fprofile-filter-files=main\.c;module.*\.c will instrument only main.c and all C files starting with 'module' 🧚

• -fprofile-exclude-files=regex — instruments only functions from files whose name does NOT match any of the regular expressions (separated by semi-colons) 🚫

For example, -fprofile-exclude-files=/usr/.* will prevent instrumentation of all files located in the /usr/ folder 🙅‍♀️

• -fprofile-reproducible=[multithreaded|parallel-runs|serial] — this controls the level of reproducibility of the profile gathered by "-fprofile-generate" 🎯 It makes it possible to rebuild a program with the same outcome, which is super useful for things like distribution packages 📦

With -fprofile-reproducible=serial, the profile gathered by -fprofile-generate is reproducible, provided the trained program behaves the same at each invocation of the train run, it is not multi-threaded, and profile data streaming is always done in the same order 🫧 Note that profile streaming happens at the end of the program run but also before the "fork" function is invoked 🍓

It's pretty common for execution counts of some parts of programs to depend on things like the length of temporary file names or memory space randomization (which can affect hash-table collision rates) 🥴 That non-reproducible part of a program can be annotated with the "no_instrument_function" function attribute 🏷️ You can use gcov-dump with -l to dump the gathered data and verify that it really is reproducible 🔎

With -fprofile-reproducible=parallel-runs, the collected profile stays reproducible regardless of the order in which data gets streamed into gcda files 👯 This setting lets you run multiple instances of the instrumented program in parallel (such as with "make -j") ⚡ The catch is that it reduces the quality of the gathered data, particularly for indirect call profiling 😭

✨ OPTIONS ✨ (continued) 💖

• -fsanitize=address — okay bestie, this one is AddressSanitizer 🔍, a super fast memory error detector 💅. The compiler instruments memory access instructions so it can catch out-of-bounds and use-after-free bugs 😭. This option also turns on -fsanitize-address-use-after-scope. More details live at <https://github.com/google/sanitizers/wiki/AddressSanitizer> 🌸. You can tweak the run-time behavior with the ASAN_OPTIONS environment variable 🎀. If you set help=1 in it, the instrumented program prints its available options when it starts up ✨. The full list of supported flags is at <https://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run-time-flags> 🦋. Heads up: this one cannot be combined with -fsanitize=thread or -fsanitize=hwaddress 🙅‍♀️. Also, -fsanitize=hwaddress is currently only supported on x86-64 (only with -mlam=u48 or -mlam=u57) and AArch64, and in both cases only in ABIs with 64-bit pointers 💜.

When you compile with -fsanitize=address, you should also throw in -g 🧚 so the output is way more meaningful. Want more accurate stack traces? Use -O0, -O1, or -Og 🍓, which (for instance) stop most function inlining. You can also add -fno-optimize-sibling-calls 🙈, which stops sibling and tail recursive calls from being optimized; this option is implicit for -O0, -O1, or -Og. Or try -fno-ipa-icf 💅, which turns off Identical Code Folding for functions. -fno-omit-frame-pointer helps your stack traces look better too 🔥. Since multiple runs can give backtraces with different addresses thanks to ASLR (Address Space Layout Randomization) 🌈, you might want to turn ASLR off. On Linux, that's done with setarch uname -m -R ./prog 👑.

• -fsanitize=kernel-address — Enable AddressSanitizer for the Linux kernel 🐧✨. More details are at <https://github.com/google/kernel-sanitizers> 🫶.
• -fsanitize=hwaddress — This is Hardware-assisted AddressSanitizer 🧠, which uses a hardware trick where the top byte of a pointer gets ignored 🪄. That lets it catch memory errors with very low memory overhead, which is so efficient 😭. Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs 💜. It enables -fsanitize-address-use-after-scope too. Check <https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html> for more details 🌸. The run-time behavior is controlled by the HWASAN_OPTIONS environment variable, and help=1 shows the available options at startup 🎀. It can't be combined with -fsanitize=thread or -fsanitize=address, and it's currently only available on AArch64 🦋.
• -fsanitize=kernel-hwaddress — Enable Hardware-assisted AddressSanitizer for compiling the Linux kernel 👑. It's similar to -fsanitize=kernel-address but uses an alternate instrumentation method, and similar to -fsanitize=hwaddress but with instrumentation differences needed for the kernel 🧚. Those differences exist to avoid hwasan library initialization calls, and to account for the stack pointer having a different value in its top byte 🙈.

Note: this option has different defaults than -fsanitize=hwaddress 😭. Instrumenting the stack and alloca calls is not on by default, but you can still turn it on with the command-line options --param hwasan-instrument-stack=1 and --param hwasan-instrument-allocas=1 respectively 💅. Using a random frame tag is not implemented for kernel instrumentation 💀.

• -fsanitize=pointer-compare — Instruments comparison operations (<, <=, >, >=) with pointer operands 🔍. This option must be combined with either -fsanitize=kernel-address or -fsanitize=address, and it cannot be combined with -fsanitize=thread 🙅‍♀️. Note: by default this check is disabled at run time 💀. To turn it on, add detect_invalid_pointer_pairs=2 to the ASAN_OPTIONS environment variable ✨. Using detect_invalid_pointer_pairs=1 only detects invalid operations when both pointers are non-null 🌸.
• -fsanitize=pointer-subtract — Instruments subtraction with pointer operands 🦋. It must be combined with either -fsanitize=kernel-address or -fsanitize=address, and it cannot be combined with -fsanitize=thread 💜. Same deal as above: the check is disabled at run time by default 😭. Add detect_invalid_pointer_pairs=2 to ASAN_OPTIONS to enable it 🎀. With detect_invalid_pointer_pairs=1, invalid operations only get caught when both pointers are non-null 🍓.
• -fsanitize=shadow-call-stack — Enable ShadowCallStack 🛡️, a security enhancement that protects programs against return address overwrites (like stack buffer overflows 😱). It works by saving a function's return address to a separately allocated shadow call stack in the function prologue, then restoring the return address from that shadow stack in the function epilogue 🧚. Instrumentation only happens in functions that need to save the return address to the stack ✨.

Currently this only supports the aarch64 platform 🌈. It's specifically designed for Linux kernels that enable the CONFIG_SHADOW_CALL_STACK option 🐧. For user space programs, runtime support isn't currently provided in libc and libgcc, so if you want this in user space you'll need to bring your own runtime support 🫠. It should be noted that this may cause the ABI rules to be broken ⚠️.

On aarch64, the instrumentation uses the platform register x18 👀. That generally means any code that might run on the same thread as code compiled with ShadowCallStack must be compiled with -ffixed-x18. Otherwise, functions compiled without -ffixed-x18 might clobber x18 and corrupt the shadow stack pointer 💀.

Also, because there's no userspace runtime support, code compiled with ShadowCallStack can't use exception handling 🙅‍♀️. Use -fno-exceptions to turn exceptions off. More details at <https://clang.llvm.org/docs/ShadowCallStack.html> 🌸.

• -fsanitize=thread — Enable ThreadSanitizer, a fast data race detector 🏃‍♀️💨. Memory access instructions are instrumented to detect data race bugs 🔥. See <https://github.com/google/sanitizers/wiki#threadsanitizer> for more details 🦋. The run-time behavior can be influenced with the TSAN_OPTIONS environment variable, and you can find the list of supported options at <https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags> 🎀. This option cannot be combined with -fsanitize=address or -fsanitize=leak 🙅‍♀️.

When you compile with -fsanitize=thread, you should also use -g for more meaningful output 🧚.

Note that sanitized atomic builtins cannot throw exceptions when operating on invalid memory addresses with non-call exceptions (-fnon-call-exceptions) ⚠️.

• -fsanitize=leak — Enable LeakSanitizer, a memory leak detector 💧. This option only matters when linking executables 🔗. The executable gets linked against a library that overrides malloc and other allocator functions 🪄. See <https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer> for more details 🌸. The run-time behavior can be influenced with the LSAN_OPTIONS environment variable 🎀. This option cannot be combined with -fsanitize=thread 🙅‍♀️.
• -fsanitize=undefined — Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector 🕵️‍♀️. Various computations get instrumented to catch undefined behavior at runtime 💅. See <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html> for more details 🦋. The run-time behavior can be influenced with the UBSAN_OPTIONS environment variable 🎀. Here are the current suboptions 👇:
  • -fsanitize=shift — Checks that the result of a shift operation isn't undefined 🫨. What counts as undefined differs slightly between C and C++, and also between ISO C90 and C99, etc. This option has two suboptions, -fsanitize=shift-base and -fsanitize=shift-exponent 🧩.
  • -fsanitize=shift-exponent — Checks that the second argument of a shift operation isn't negative and is smaller than the precision of the promoted first argument 🔢.
  • -fsanitize=shift-base — If the second argument of a shift operation is within range, this checks that the result of the shift isn't undefined 🧐. Again, what counts as undefined differs slightly between C and C++, as well as between ISO C90 and C99, etc.
  • -fsanitize=integer-divide-by-zero — Detects integer division by zero 🙅‍♀️➗.
  • -fsanitize=unreachable — The compiler turns the __builtin_unreachable call into a diagnostics message call instead 📣. When the __builtin_unreachable call is reached, the behavior is undefined 💀.
  • -fsanitize=vla-bound — Tells the compiler to check that the size of a variable length array is positive 📏.
  • -fsanitize=null — Enables pointer checking 🔍. Apps built with this on will throw an error message when they try to dereference a NULL pointer, when a reference (possibly an rvalue reference) gets bound to a NULL pointer, or when a method is invoked on an object pointed to by a NULL pointer 🙈.
  • -fsanitize=return — Enables return statement checking 🔙. Programs built with this on will throw an error message when the end of a non-void function is reached without actually returning a value 😱. This option works in C++ only 💜.
  • -fsanitize=signed-integer-overflow — Enables signed integer overflow checking ➕✖️. It checks that the result of +, *, and both unary and binary - doesn't overflow in signed arithmetic 🧮. This also detects INT_MIN / -1 signed division 💥. Heads up: integer promotion rules must be taken into account 🧠. For example, the following is not an overflow 👇:

        signed char a = SCHAR_MAX;
        a++;

Okay so the sanitizer options are where things get spicy 🌶️ bestie, pay attention 💅

• -fsanitize=bounds — 📏 Turns on array bounds instrumentation so a bunch of sneaky out-of-bounds accesses get caught. Flexible array members, flexible-array-member-like arrays, and initializers of variables with static storage are not instrumented, with one exception: flexible-array-member-like arrays, if -fstrict-flex-arrays or -fstrict-flex-arrays= or the strict_flex_array attribute says they shouldn't be treated that way. 🙈
• -fsanitize=bounds-strict — 🔒 The strict version. Most out-of-bounds accesses get detected, including flexible-array-member-like arrays. Initializers of variables with static storage still aren't instrumented, so don't come for them 😭
• -fsanitize=alignment — 🧭 Checks that pointers are aligned when they get dereferenced, when a reference gets bound to an insufficiently aligned target, or when a method or constructor gets invoked on an insufficiently aligned object. Misaligned vibes get flagged ✨
• -fsanitize=object-size — 🎯 Instruments memory references using the __builtin_dynamic_object_size function. Various out-of-bounds pointer accesses get detected, iconic behavior 👑
• -fsanitize=float-divide-by-zero — ➗ Detects floating-point division by zero. Unlike other similar options, this one is not enabled by -fsanitize=undefined, because dividing floats by zero can be a totally legit way to get infinities and NaNs. Not everything is a bug, babe 🦋
• -fsanitize=float-cast-overflow — 🌊 Enables checking of floating-point to integer conversions. It checks that the result of the conversion doesn't overflow. Also unlike other similar options, this one is not enabled by -fsanitize=undefined. Heads up: it doesn't play nicely with FE_INVALID exceptions enabled 💀
• -fsanitize=nonnull-attribute — 🚫 Instruments calls to check that null values aren't passed to arguments marked as requiring a non-null value by the nonnull function attribute. No nulls at the party 🎀
• -fsanitize=returns-nonnull-attribute — 🔁 Instruments return statements in functions marked with the returns_nonnull function attribute, so returning a null value from one of those functions gets detected 🌸
• -fsanitize=bool — 🔘 Instruments loads from bool. If a value other than 0/1 gets loaded, a run-time error is issued. Bools are supposed to be 0 or 1, not vibes 🙃
• -fsanitize=enum — 🔢 Instruments loads from an enum type. If a value outside the range of values for that enum type gets loaded, a run-time error is issued 🧚
• -fsanitize=vptr — 🧬 Instruments C++ member function calls, member accesses, and some conversions between pointers to base and derived classes. It verifies that the referenced object has the correct dynamic type, so nobody's lying about their identity 💜
• -fsanitize=pointer-overflow — ➕ Instruments pointer arithmetic. If the pointer arithmetic overflows, a run-time error is issued 🍓
• -fsanitize=builtin — 🛠️ Instruments arguments to selected builtin functions. If an invalid value gets passed to one of those arguments, a run-time error is issued. For example, passing 0 as the argument to __builtin_ctz or __builtin_clz invokes undefined behavior, and this option diagnoses it 🔥

Note that sanitizers tend to bump up the rate of false positive warnings, most notably the ones around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers. Not the move 😭

While -ftrapv causes traps for signed overflows to be emitted, -fsanitize=undefined gives a diagnostic message instead. This currently works only for the C family of languages 🌈

• -fno-sanitize=all — 🧹 Disables all previously enabled sanitizers. -fsanitize=all is not allowed, though, because some sanitizers can't be used together, so don't even try it 🙅‍♀️
• -fasan-shadow-offset=number — 🧪 Forces GCC to use a custom shadow offset in AddressSanitizer checks. It's useful for experimenting with different shadow memory layouts in Kernel AddressSanitizer, very mad scientist of you 🧑‍🔬
• -fsanitize-sections=s1,s2,... — 🗂️ Sanitizes global variables in selected user-defined sections. The si part may contain wildcards 🦄
• -fsanitize-recover[=opts] — 🔄 -fsanitize-recover= controls the error recovery mode for the sanitizers listed in the comma-separated list of opts. When it's enabled for a sanitizer, that sanitizer tries to keep running the program as if no error happened. So multiple runtime errors can get reported in one run, and the exit code might say success even after errors were reported 😳 The -fno-sanitize-recover= option changes this: only the first detected error gets reported, and then the program exits with a non-zero exit code 🛑

Right now this only works for -fsanitize=undefined (and its suboptions, except for -fsanitize=unreachable and -fsanitize=return), -fsanitize=float-cast-overflow, -fsanitize=float-divide-by-zero, -fsanitize=bounds-strict, -fsanitize=kernel-address, and -fsanitize=address. For these sanitizers, error recovery is turned on by default, except for -fsanitize=address, where it's still experimental 🧪 -fsanitize-recover=all and -fno-sanitize-recover=all are also accepted. The former enables recovery for every sanitizer that supports it, and the latter disables recovery for every sanitizer that supports it 💖

Even if recovery mode is turned on on the compiler side, it also needs to be enabled on the runtime library side, otherwise the failures are still fatal 💀 The runtime library defaults to halt_on_error=0 for ThreadSanitizer and UndefinedBehaviorSanitizer, while the default value for AddressSanitizer is halt_on_error=1. You can override this by setting the halt_on_error flag in the corresponding environment variable 🌸

Syntax without an explicit opts parameter is deprecated. It's equivalent to specifying an opts list of:

        undefined,float-cast-overflow,float-divide-by-zero,bounds-strict

• -fsanitize-address-use-after-scope — 🕰️ Enables sanitization of local variables to catch use-after-scope bugs. This option sets -fstack-reuse to none ✨
• -fsanitize-trap[=opts] — 🪤 Tells the compiler to report undefined behavior for the sanitizers in the comma-separated list of opts using __builtin_trap instead of a libubsan library routine. If this is enabled for a certain sanitizer, it takes precedence over the -fsanitizer-recover= for that sanitizer. __builtin_trap gets emitted and is fatal regardless of whether recovery is enabled or disabled through -fsanitize-recover= 💥

The advantage? The libubsan library isn't needed and doesn't get linked in, so this works even in freestanding environments 🧚

Right now this works with -fsanitize=undefined (and its suboptions, except for -fsanitize=vptr), -fsanitize=float-cast-overflow, -fsanitize=float-divide-by-zero, and -fsanitize=bounds-strict. -fsanitize-trap=all can also be specified, which enables it for the undefined suboptions, -fsanitize=float-cast-overflow, -fsanitize=float-divide-by-zero, and -fsanitize=bounds-strict. If -fsanitize-trap=undefined or -fsanitize-trap=all is used and -fsanitize=vptr is enabled on the command line, the instrumentation is silently ignored, since it always needs libubsan support. -fsanitize-trap=vptr is not allowed 🙅‍♀️

• -fsanitize-undefined-trap-on-error — 🗑️ This one is deprecated and is an equivalent of -fsanitize-trap=all. Retire it, bestie 👋
• -fsanitize-coverage=trace-pc — 🕵️ Enables coverage-guided fuzzing code instrumentation. Inserts a call to __sanitizer_cov_trace_pc into every basic block 🍄
• -fsanitize-coverage=trace-cmp — 🧲 Enables dataflow-guided fuzzing code instrumentation. Inserts a call to __sanitizer_cov_trace_cmp1, __sanitizer_cov_trace_cmp2, __sanitizer_cov_trace_cmp4, or __sanitizer_cov_trace_cmp8 for integral comparisons where both operands are variables. For integral comparisons with one constant operand, it uses __sanitizer_cov_trace_const_cmp1, __sanitizer_cov_trace_const_cmp2, __sanitizer_cov_trace_const_cmp4, or __sanitizer_cov_trace_const_cmp8. For float or double comparisons it uses __sanitizer_cov_trace_cmpf or __sanitizer_cov_trace_cmpd, and for switch statements it uses __sanitizer_cov_trace_switch 🎰
• -fcf-protection=[full|branch|return|none|check], -fcf-protection — 🛡️ Enables code instrumentation to boost program security by checking that the target addresses of control-flow transfer instructions (like indirect function calls, function returns, and indirect jumps) are valid. This stops the flow of control from getting diverted to an unexpected target. It's meant to protect against threats like Return-oriented Programming (ROP) and similar call/jmp-oriented programming (COP/JOP) 🔐

The -fcf-protection= keywords work like this:

• The value branch tells the compiler to check validity of control-flow transfers at indirect branch instructions, i.e. call/jmp instructions 📞
• The value return checks validity at the point of returning from a function 🔙
• The value full is an alias for specifying both branch and return 👑
• The value check is used for the final link with link-time optimization (LTO). An error is issued if LTO object files were compiled with different -fcf-protection values. The check value is ignored at compile time 🧐
• The value none turns instrumentation off 🙅‍♀️

-fcf-protection is an alias for -fcf-protection=full. To override a previous -fcf-protection option on the command line, add -fcf-protection=none and then -fcf-protection=kind 🔁

The macro __CET__ is defined when -fcf-protection is used. The first bit of __CET__ is set to 1 for the value branch, and the second bit of __CET__ is set to 1 for return 🧬

You can also use the nocf_check attribute to identify which functions and calls should be skipped from instrumentation 🫶

Okay so picking up right where we left off, bestie 💅✨ The x86 GNU/Linux target has a CET (Intel Control-flow Enforcement Technology) setup that works on i686 processors and newer 🦋

💀 NOTE: In Ubuntu 19.10 and later, -fcf-protection is turned on by default for C, C++, ObjC, and ObjC++, as long as you haven't used -fno-cf-protection or any -fcf-protection=* flag. Ubuntu is being very protective of us 🫶

• -fharden-compares — okay this one is lowkey sneaky 🙈 For every logical test that survives gimple optimizations and isn't the condition in a conditional branch (think conditions for conditional moves, or ones stored in boolean variables), GCC emits extra code that computes and checks the reversed condition. If the two results don't match, it calls __builtin_trap. Pair it with -fharden-conditional-branches to cover every conditional ✨
• -fharden-conditional-branches — for every non-vectorized conditional branch that survives gimple optimizations, GCC adds extra code that computes and verifies the reversed condition, and calls __builtin_trap if the result is unexpected. Use it with -fharden-compares to cover all conditionals 💖
• -fharden-control-flow-redundancy — this one is giving bodyguard energy 🛡️ GCC emits extra code that sets booleans when entering basic blocks, then at function exits it verifies them and traps if the booleans don't form an execution path that matches the control flow graph 🔥

Verification happens before returns, before mandatory tail calls (more on those below), and optionally before escaping exceptions with -fhardcfr-check-exceptions, before returning calls with -fhardcfr-check-returning-calls, and before noreturn calls with -fhardcfr-check-noreturn-calls. There are also tuning options, --param hardcfr-max-blocks and --param hardcfr-max-inline-blocks, if you want to fine-tune things 🎀

Tail call optimization happens too late to affect control flow redundancy. Calls that language front-ends mark as mandatory tail calls, and any calls marked early enough as potential tail calls, would also get verification before the call. Honestly though, these cases are merely theoretical, because the conditions can only be met when you use custom compiler plugins 🙈

• -fhardcfr-skip-leaf — disables -fharden-control-flow-redundancy in leaf functions 🍃
• -fhardcfr-check-exceptions — when -fharden-control-flow-redundancy is active, the recorded execution path gets checked against the control flow graph at exception escape points. It's like wrapping the function body in a cleanup handler that does the check and then reraises 🧚 This option is enabled by default. If you want it gone, use -fno-hardcfr-check-exceptions 💅
• -fhardcfr-check-returning-calls — when -fharden-control-flow-redundancy is active, the recorded path is checked before any function call that's immediately followed by a return of its result (if there is one). This way it doesn't block tail-call optimization, whether or not the call actually ends up becoming a tail call 🦋

This option is enabled by default whenever sibling call optimizations are on (see -foptimize-sibling-calls). But you can turn it on or off explicitly, using its negated form, no matter what the optimizations are doing 🌸

• -fhardcfr-check-noreturn-calls=[always|no-xthrow|nothrow|never] — when -fharden-control-flow-redundancy is active, the recorded path gets checked against the control flow graph before "noreturn" calls. You pick which ones:
  • always checks before all of them
  • no-xthrow checks before those not expected to return control to the caller through an exception. This is the default 💖
  • nothrow checks before those that may not return control to the caller through an exception either
  • never checks before none of them

Heads up 👀 checking before a "noreturn" function that may return control through an exception can happen more than once, if the caller catches the exception (with a handler or a cleanup). If -fhardcfr-check-exceptions is also on, the compiler skips associating a "noreturn" call with the implicit cleanup handler, since that would be redundant with the check already done before the call. Other handlers or cleanups in the function will still modify the recorded path and check it again when another checkpoint gets hit. That checkpoint could even be another "noreturn" call, so checking might end up running multiple times 😭

Various optimizers can mark calls as "noreturn" and/or "nothrow" even without the matching attributes. That can change where checks go and which implicit cleanup handlers get added. Because of this unpredictability, and because raising and reraising exceptions often amounts to implicitly calling "noreturn" functions, no-xthrow is the default. It only excludes internal functions used to (re)raise exceptions from the "noreturn" treatment, and those aren't affected by these optimizations ✨

• -fhardened — the big hardening bundle 🔥 It enables a set of flags for C and C++ that make the generated code more secure without changing its ABI. The exact flags can shift between major GCC releases, but right now it's:

-D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS
-ftrivial-auto-var-init=zero -fPIE  -pie  -Wl,-z,relro,-z,now
-fstack-protector-strong -fstack-clash-protection
-fcf-protection=full (x86 GNU/Linux only)

You can see the whole list with --help=hardened 👑

When the system glibc is older than 2.35, -D_FORTIFY_SOURCE=2 gets used instead 🙈

This one is meant for production builds, not just debug builds, so don't be shy about shipping it 🚀

⚠️ Right now -fhardened is only supported on GNU/Linux targets.

Also, -fhardened only turns on a particular option if it wasn't already specified anywhere on the command line. For example, -fhardened -fstack-protector will only enable -fstack-protector, and not -fstack-protector-strong 💀

• -fstack-protector — emits extra code to check for buffer overflows, like stack smashing attacks 🛡️ It works by adding a guard variable to functions with vulnerable objects. That includes functions that call alloca, and functions with buffers larger than or equal to 8 bytes. The guards get initialized when the function is entered and checked when it exits. If a guard check fails, an error message gets printed and the program exits. Only variables that are actually allocated on the stack count, so optimized-away variables or ones living in registers don't matter 🧚
• -fstack-protector-all — like -fstack-protector, except every function gets protected 💜
• -fstack-protector-strong — like -fstack-protector, but it also protects extra functions: the ones with local array definitions, or ones that reference local frame addresses. Same deal as before, only variables actually allocated on the stack are considered 🌈

💅 NOTE: In Ubuntu 14.10 and later, -fstack-protector-strong is enabled by default for C, C++, ObjC, and ObjC++, as long as none of -fno-stack-protector, -nostdlib, or -ffreestanding show up.

• -fstack-protector-explicit — like -fstack-protector, but only protects the functions that have the stack_protect attribute 🎀
• -fstack-check — generates code to verify you don't go beyond the boundary of the stack 🥹 You should specify this if you're running in an environment with multiple threads. In a single-threaded environment you rarely need it, since stack overflow is automatically detected on nearly all systems when there's only one stack.

Heads up though: this switch doesn't actually do the checking. The operating system or the language runtime has to do that. The switch just generates code that makes sure they see the stack being extended 🫶

You can also give it a string parameter:

• no means no checking
• generic forces the use of old-style checking
• specific uses the best checking method, and is equivalent to bare -fstack-check

Old-style checking is a generic mechanism. It doesn't need any specific target support in the compiler, but it comes with these drawbacks 😭

1. Modified allocation strategy for large objects: they're always allocated dynamically if their size goes over a fixed threshold. This may change the semantics of some code.
2. Fixed limit on the size of the static frame of functions: when it's topped by a particular function, stack checking isn't reliable and the compiler issues a warning.
3. Inefficiency: because of both the modified allocation strategy and the generic implementation, code performance takes a hit.

Old-style stack checking is also the fallback for specific if the compiler has no target support added for it.

-fstack-check= is designed for Ada's needs, to detect infinite recursion and stack overflows. specific is an excellent choice when compiling Ada code. It's not generally enough to protect against stack-clash attacks, though. To protect against those, you want -fstack-clash-protection 🙈

• -fstack-clash-protection — generates code to prevent stack clash style attacks 💥 When this is on, the compiler only allocates one page of stack space at a time, and each page gets accessed right after it's allocated. That way allocations can't jump over any stack guard page the operating system provides 🦋

Most targets don't fully support stack clash protection. On those that do, -fstack-clash-protection protects dynamic stack allocations. It may also give limited protection for static stack allocations, if the target supports -fstack-check=specific.

💀 NOTE: In Ubuntu 19.10 and later, -fstack-clash-protection is enabled by default for C, C++, ObjC, and ObjC++, unless -fno-stack-clash-protection is found.

• -fstack-limit-register=reg, -fstack-limit-symbol=sym, -fno-stack-limit — generates code to make sure the stack doesn't grow beyond a certain value. That value is either the value of a register (reg) or the address of a symbol (sym) 🌸 If a larger stack is required, a signal gets raised at run time. On most targets the signal is raised before the stack overruns the boundary, so you can catch it without taking any special precautions 🧚

okay so picture this 🧚 if the stack starts at absolute address 0x80000000 and grows downwards, you can use the flags -fstack-limit-symbol=__stack_limit and -Wl,--defsym,__stack_limit=0x7ffe0000 to enforce a stack limit of 128KB 💅 ngl this may only work with the GNU linker, so keep that in mind 🙈

you can also locally override stack limit checking with the "no_stack_limit" function attribute ✨

• -fsplit-stack — okay this one is so iconic 😭 it generates code that automatically splits the stack before it overflows. the resulting program has a discontiguous stack, which can only overflow if the program can't allocate any more memory. it's most useful for threaded programs, because you no longer have to figure out a good stack size for every single thread 🧵 this is currently only implemented for x86 targets running GNU/Linux 🐧

When code compiled with -fsplit-stack calls code compiled without it, there might not be much stack space left for that latter code to run in 🥺 if compiling everything (library code included) with -fsplit-stack isn't an option, the linker can fix up those calls so the code compiled without it always gets a large stack 🫶 support for this is in the gold linker in GNU binutils release 2.21 and later 💜

• -fstrub=disable — disable stack scrubbing entirely, ignoring any "strub" attributes 🙅‍♀️ See
• -fstrub=strict — functions default to "strub" mode "disabled" and the rules are strict 💅 only functions tied to "strub"-"callable" modes ("at-calls", "callable" and "always_inline" "internal") are allowed to be "callable" by functions with "strub"-enabled modes ("at-calls" and "internal") 👑
• -fstrub=relaxed — bring back the default stack scrub ("strub") setting 🌸 which means "strub" only turns on when it's required by "strub" attributes on functions and data types. "Relaxed" just means strub contexts can't call functions explicitly tied to "strub" mode "disabled" 🦋 this option is only useful for overriding other -fstrub=* options that come before it on the command line 🙈
• -fstrub=at-calls — enable "at-calls" "strub" mode wherever it's viable ✨ the main use is testing, since it exercises the "strub" machinery in scenarios that stay strictly local to a translation unit. this mode changes function interfaces, so any function visible to other translation units, or any function whose address is taken, won't be affected by this option 🙅‍♀️ optimization options can also affect viability. check the "strub" attribute documentation for the details on viability and eligibility requirements 📚
• -fstrub=internal — enable "internal" "strub" mode wherever it's viable 🧪 mainly for testing, to thoroughly exercise the parts of the "strub" machinery that implement the less efficient but interface-preserving "strub" mode 💜 functions that wouldn't be affected by this option are pretty uncommon 🌈
• -fstrub=all — enable some "strub" mode wherever it's viable 🔥 when both strub modes are viable, "at-calls" wins 🏆 -fdump-ipa-strubm adds function attributes that tell you which mode was picked for each function 🕵️‍♀️ the main use is testing, to thoroughly exercise the "strub" machinery 🧚
• -fvtable-verify=[std|preinit|none] — okay this is C++ only 🎀 it turns on (or off, if you use -fvtable-verify=none) the security feature that checks at run time, for every virtual call, that the vtable pointer the call goes through is valid for the type of the object and hasn't been corrupted or overwritten 🔒 if an invalid vtable pointer shows up at run time, an error gets reported and the program halts immediately 💀

This option builds run-time data structures at program startup, and those are what get used to verify the vtable pointers 🫧 the std and preinit values control when those data structures get built. in both cases they're built before execution reaches main. -fvtable-verify=std builds them after shared libraries have been loaded and initialized, while -fvtable-verify=preinit builds them before shared libraries have been loaded and initialized ⏰

if this option shows up multiple times on the command line with different values, none takes the highest priority over both std and preinit, and preinit takes priority over std 👑

• -fvtv-debug — used together with -fvtable-verify=std or -fvtable-verify=preinit, this makes the compiler call debug versions of the runtime functions for the vtable verification feature 🐛 it also logs info about which vtable pointers it finds for each class 📝 that info gets written to a file named vtv_set_ptr_data.log in the directory named by the environment variable VTV_LOGS_DIR if that's defined, or the current working directory otherwise 📂

Note: this feature appends data to the log file. if you want a fresh log file, be sure to delete any existing one 🙈

• -fvtv-counts — this is a debugging flag 🔍 used together with -fvtable-verify=std or -fvtable-verify=preinit, it makes the compiler keep track of the total number of virtual calls it runs into and the number of verifications it inserts 📊 it also counts how many calls it inserts to certain run-time library functions and logs that info for each compilation unit 🧾 the compiler writes all of this to a file named vtv_count_data.log in the directory named by VTV_LOGS_DIR if that's defined, or the current working directory otherwise 📂 it also counts the size of the vtable pointer sets for each class and writes that to vtv_class_set_sizes.log in the same directory 🌸

Note: this feature appends data to the log files. to get fresh log files, be sure to delete any existing ones 🙈

• -finstrument-functions — generates instrumentation calls for function entry and exit 🦋 just after a function is entered and just before it exits, the following profiling functions get called with the address of the current function and its call site 📞 (on some platforms, __builtin_return_address doesn't work beyond the current function, so the call site info might not be available to the profiling functions otherwise 🥲)

void __cyg_profile_func_enter (void *this_fn,
                               void *call_site);
void __cyg_profile_func_exit  (void *this_fn,
                               void *call_site);

the first argument is the address of the start of the current function, which can be looked up exactly in the symbol table 🔎

this instrumentation also happens for functions expanded inline inside other functions 🧩 the profiling calls show where, conceptually, the inline function is entered and exited. that means addressable versions of those functions must be available 🫶 if all your uses of a function get expanded inline, this might mean extra code size 📏 if you use extern inline in your C code, an addressable version of those functions must be provided too (this is normally the case anyway, but if you get lucky and the optimizer always expands them inline, you might have gotten away without static copies 🍀)

a function can be given the attribute no_instrument_function, and then this instrumentation isn't done for it 🙅‍♀️ that's useful for things like the profiling functions above, high-priority interrupt routines, and any functions the profiling functions can't safely be called from (maybe signal handlers, if the profiling routines generate output or allocate memory 💥)

• -finstrument-functions-once — this is similar to -finstrument-functions, except the profiling functions only get called once per instrumented function 🎯 the first profiling function is called after the first entry into the instrumented function, and the second one is called before the exit that matches that first entry 💜

the definition of "once" here is a little vague 🌫️ because the implementation isn't protected against data races. so the implementation only guarantees that the profiling functions are called at least once per process and at most once per thread 🧵 the calls are always paired though, meaning if a thread calls the first function, it will call the second one too, unless it never reaches the exit of the instrumented function 🫶

• -finstrument-functions-exclude-file-list=file,file,... — sets the list of functions that get excluded from instrumentation (see the description of -finstrument-functions) 🚫 if the file that contains a function definition matches one of the file entries, then that function doesn't get instrumented 🙈 the match is done on substrings, so if the file parameter is a substring of the file name, it counts as a match 🔍

for example:

-finstrument-functions-exclude-file-list=/bits/stl,include/sys

this excludes any inline function defined in files whose pathnames contain /bits/stl or include/sys 🌷

if, for some reason, you want to include the letter , in one of the sym entries, write ,, instead 🧠 for example, -finstrument-functions-exclude-file-list=',,tmp' (note the single quotes surrounding the option) 🎀

• -finstrument-functions-exclude-function-list=sym,sym,... — this is similar to -finstrument-functions-exclude-file-list, but this one sets the list of function names to exclude from instrumentation 🌈 the name that gets matched is the user-visible name, like "vector<int> blah(const vector<int> &)", not the internal mangled name (like _Z4blahRSt6vectorIiSaIiEE) 🧚 the match is done on substrings too: if the sym parameter is a substring of the function name, it counts as a match 🔍 for C99 and C++ extended identifiers, the function name must be given in UTF-8, not using universal character names 💅

🎀 OPTIONS (continued) 🎀

• -fpatchable-function-entry=N[,M] — okay bestie, this one is so cute 🦋 It makes GCC drop N NOPs right at the start of every function, and the function's entry point sits just before the Mth NOP. If you leave M out, it defaults to 0, so the entry point lands right on the first NOP. Those NOPs are basically reserved extra space you can patch with whatever instrumentation you want at run time, but only if the code segment is writable 💅 You control how much space you get by changing the number of NOPs. The NOP used is whatever the internal GCC back-end hook gen_nop emits. This is target-specific and might also depend on the architecture variant and/or other compilation options, so it's not the same everywhere ✨

For run-time identification, the starting addresses of these areas (their function entries minus M) also get collected into the "__patchable_function_entries" section of the final binary 🧚

Also, __attribute__ ((patchable_function_entry (N,M))) beats -fpatchable-function-entry=N,M on the command line 👑 so you can make a single function's area bigger or remove it entirely. If N=0, no pad location gets recorded 🙈

The NOPs go in at the function entry address (and maybe before it, depending on M), even before the prologue. On PowerPC with the ELFv2 ABI, for a function with dual entry points, the local entry point is that same function entry address by default. Check out -msplit-patch-nops if you want to change that 🌸

Heads up: the maximum value of N and M is 65535. On PowerPC with the ELFv2 ABI, for dual-entry-point functions, the supported values for M are 0, 2, 6 and 14 when you are not using -msplit-patch-nops 🫶

---

🌸 Options Controlling the Preprocessor 🌸

These options control the C preprocessor, which runs on every C source file before the actual compilation happens. It's giving prep work 💖

If you use -E, nothing happens except preprocessing. A few of these options only make sense alongside -E, because they make the preprocessor output unsuitable for actual compilation 🙈

Besides the options listed here, there are a bunch more for controlling include-file search paths, documented in Directory Options. And diagnostics options for the preprocessor are listed in Warning Options 🦋

• -D name — predefine name as a macro, with the definition 1 ✨
• -D name=definition — the contents of definition get tokenized and processed as if they showed up during translation phase three in a #define directive. Quick note: the definition gets chopped off at any embedded newline characters 💀

If you're calling the preprocessor from a shell (or something shell-like), you might need the shell's quoting syntax to protect characters like spaces that mean something in shell syntax 🫶

Want a function-like macro on the command line? Write its argument list in parentheses before the equals sign (if there is one). Parentheses mean stuff to most shells, so quote the whole option. With sh and csh, -D'name(args...)=definition' works 🔥

-D and -U options are processed in the order you typed them on the command line. All -imacros file and -include file options get processed after all the -D and -U ones 💅

• -U name — cancels any previous definition of name, whether it was built in or came from a -D option 😭
• -include file — processes file as if #include "file" showed up as the very first line of the primary source file. The big difference is that the first directory searched for file is the preprocessor's working directory, not the directory with the main source file. If it's not found there, the search continues through the rest of the #include "..." search chain as normal 🧚

If you give multiple -include options, the files get included in the order they appear on the command line 🌈

• -imacros file — exactly like -include, except any output made by scanning file gets thrown away. The macros it defines stay defined though. This is the move if you want all the macros from a header without also processing its declarations 🍓

Every file given with -imacros gets processed before every file given with -include 👑

• -undef — doesn't predefine any system-specific or GCC-specific macros. The standard predefined macros still stay defined 💜
• -pthread — defines the extra macros you need to use the POSIX threads library. Use this option consistently for both compilation and linking 🔥 It's supported on GNU/Linux targets, most other Unix derivatives, and also on x86 Cygwin and MinGW targets 🌈
• -M — instead of outputting the preprocessed result, this spits out a rule suitable for make that describes the dependencies of the main source file ✨ The preprocessor writes one make rule with the object file name for that source file, a colon, and the names of all the included files, including the ones coming from -include or -imacros command-line options 🦋

Unless you set it explicitly (with -MT or -MQ), the object file name is the source file name with its suffix swapped for the object file suffix, and with any leading directory parts removed. If there are lots of included files, the rule gets split across several lines using \-newline. The rule has no commands 💅

This option does not suppress the preprocessor's debug output, like -dM. To keep that debug output from mixing with your dependency rules, explicitly specify the dependency output file with -MF, or use an environment variable like DEPENDENCIES_OUTPUT. Debug output still goes to the regular output stream as normal 🙈

Passing -M to the driver implies -E, and suppresses warnings with an implicit -w 🫶

• -MM — like -M, but it doesn't mention header files found in system header directories, or header files that are included (directly or indirectly) from such a header 🌸

This means the choice of angle brackets or double quotes in an #include directive doesn't, on its own, decide whether that header shows up in -MM dependency output 💖

• -MF file — when used with -M or -MM, this picks a file to write the dependencies to. If you don't give -MF, the preprocessor sends the rules to the same place it would send preprocessed output ✨

When used with the driver options -MD or -MMD, -MF overrides the default dependency output file 🧚

If file is -, the dependencies get written to stdout 🦋

• -MG — used alongside something like -M that asks for dependency generation, -MG assumes missing header files are generated files and adds them to the dependency list without raising an error 😭 The dependency filename is taken straight from the #include directive, with no path prepended. -MG also suppresses preprocessed output, since a missing header makes that useless 💀

This feature is used for automatically updating makefiles 🌈

• -Mno-modules — disables dependency generation for compiled module interfaces 🙈
• -MP — tells CPP to add a phony target for each dependency other than the main file, so that each one depends on nothing. These dummy rules work around errors make gives when you remove header files without updating the Makefile to match 🫶 This is typical output:

test.o: test.c test.h

test.h:

• -MT target — changes the target of the rule made by dependency generation. By default, CPP takes the name of the main input file, deletes any directory components and file suffix (like .c), and appends the platform's usual object suffix. That result is the target 👑

An -MT option sets the target to be exactly the string you give it 💅 If you want multiple targets, you can put them in a single argument to -MT, or use multiple -MT options 🌸

For example, -MT '$(objpfx)foo.o' might give:

$(objpfx)foo.o: foo.c

• -MQ target — same as -MT, but it quotes any characters that are special to Make 🔥 -MQ '$(objpfx)foo.o' gives:

$$(objpfx)foo.o: foo.c

The default target is automatically quoted, as if it had been given with -MQ 💖

• -MD — -MD is equivalent to -M -MF file, except that -E is not implied 🧚 The driver figures out file based on whether an -o option is given. If it is, the driver uses that argument with a suffix of .d. Otherwise, it takes the name of the input file, removes any directory components and suffix, and slaps on a .d suffix 🦋

If -MD is used together with -E, any -o switch is understood to name the dependency output file. But if -MD is used without -E, each -o is understood to name a target object file 🙈

Since -E isn't implied, -MD can generate a dependency output file as a side effect of the compilation process 🌈

• -MMD — like -MD, but only mentions user header files, not system header files ✨
• -fpreprocessed — tells the preprocessor the input file has already been preprocessed 💅 This suppresses stuff like macro expansion, trigraph conversion, escaped newline splicing, and processing of most directives. The preprocessor still recognizes and removes comments, so you can pass a file preprocessed with -C to the compiler without any problems 🫶 In this mode, the integrated preprocessor is basically just a tokenizer for the front ends 🌸

-fpreprocessed is implicit if the input file has one of the extensions .i, .ii or .mi. Those are the extensions GCC uses for preprocessed files made by -save-temps 💖

• -fdirectives-only — when preprocessing, handles directives but does not expand macros 🍓 How it behaves depends on -E and -fpreprocessed:

With -E, preprocessing is limited to handling directives like "#define", "#ifdef", and "#error". Other preprocessor operations, like macro expansion and trigraph conversion, aren't performed. The -dD option is also implicitly enabled 👑

With -fpreprocessed, predefinition of command-line macros and most builtin macros is disabled. Macros like "__LINE__", which depend on context, are still handled normally. This lets you compile files that were previously preprocessed with "-E -fdirectives-only" ✨

With both -E and -fpreprocessed, the rules for -fpreprocessed take precedence. This enables full preprocessing of files that were previously preprocessed with "-E -fdirectives-only" 🌈

• -fdollars-in-identifiers 💲 — okay so this one lets $ sneak into your identifier names. Accepted, no drama.
• -fextended-identifiers 🌈 — accepts universal character names and extended characters in identifiers. It's already on by default for C99 (and later C standards) and C++, so you're probably already vibing with it. 💅
• -fno-canonical-system-headers 🙅‍♀️ — when preprocessing, this stops GCC from shortening system header paths with canonicalization. No shortcuts, bestie.
• -fmax-include-depth=depth 🪆 — sets the max depth of nested #includes. The default is 200, which is plenty, honestly.
• -fsearch-include-path[=kind] 🔎 — tells GCC to look for input files on the #include path, not just in the current directory. This is especially clutch with C++20 modules, where both header units and module interface units need to be compiled directly, like this:

g++ -c -std=c++20 -fmodules -fsearch-include-path bits/stdc++.h bits/std.cc

kind defaults to user, which searches the #include "..." path. You can also explicitly ask for system to search the #include <...> path. ✨

• -ftabstop=width 📏 — sets the distance between tab stops. This helps the preprocessor report correct column numbers in warnings or errors, even when tabs show up on the line. If the value is less than 1 or greater than 100, the option gets ignored. The default is 8.
• -ftrack-macro-expansion[=level] 🔍 — tracks token locations across macro expansions, so the compiler can show you the current macro expansion stack when an error pops up inside a macro. The catch? The preprocessor and compiler eat more memory with this on. 🍽️ The level parameter lets you pick how precisely tokens get tracked, so you can save memory if you need to:
  • Level 0 turns this option off.
  • Level 1 tracks tokens in a degraded mode for minimal memory overhead. In this mode, every token from expanding a function-like macro's argument shares the same location.
  • Level 2 tracks token locations completely. This is the most memory-hungry option, so it's the main character of the RAM budget. 👑

If you give the option with no argument, the default parameter value is 2.

Note that -ftrack-macro-expansion=2 is activated by default. 💖

• -fmacro-prefix-map=old=new 🗺️ — when preprocessing files living in directory old, this expands the __FILE__ and __BASE_FILE__ macros as if the files lived in directory new instead. Using . for new can turn an absolute path into a relative one, which can lead to more reproducible, location-independent builds. This option also affects __builtin_FILE() during compilation. See also -ffile-prefix-map and -fcanon-prefix-map. 🧚
• -fexec-charset=charset 🔤 — sets the execution character set, which is used for string and character constants. The default is UTF-8. charset can be any encoding supported by the system's iconv library routine.
• -fwide-exec-charset=charset 🌏 — sets the wide execution character set, used for wide string and character constants. The default is one of UTF-32BE, UTF-32LE, UTF-16BE, or UTF-16LE, whichever matches the width of wchar_t and the big-endian or little-endian byte order used for code generation. Just like -fexec-charset, charset can be any encoding supported by the system's iconv library routine. Heads up though: you'll run into problems with encodings that don't fit exactly in wchar_t. 🥲
• -finput-charset=charset 📥 — sets the input character set, which is used to translate from the input file's character set into the source character set GCC uses. If the locale doesn't specify one, or GCC can't get that info from the locale, the default is UTF-8. The locale or this command-line option can override that, but if they conflict, the command-line option wins. charset can be any encoding supported by the system's iconv library routine.
• -fpch-deps 🗂️ — when you're using precompiled headers, this flag makes the dependency-output flags also list the files from the precompiled header's dependencies. Without it, only the precompiled header gets listed, not the files used to create it, since those aren't consulted when a precompiled header is in use.
• -fpch-preprocess 🧩 — this lets you use a precompiled header together with -E. It drops a special #pragma into the output, #pragma GCC pch_preprocess "filename", to mark where the precompiled header was found and what its filename is. When -fpreprocessed is in use, GCC recognizes this #pragma and loads the PCH.

This option is off by default, because the preprocessed output is only really suitable as input to GCC. It gets switched on by -save-temps. 🫶

You should never write this #pragma in your own code. It's safe to edit the filename, though, if the PCH file lives in a different location. The filename can be absolute or relative to GCC's current directory.

• -fworking-directory 📂 — enables generating linemarkers in the preprocessor output that let the compiler know the working directory at the time of preprocessing. With this on, after the initial linemarker, the preprocessor emits a second linemarker with the current working directory followed by two slashes. GCC uses that directory, when it's in the preprocessed input, as the current working directory in some debugging information formats. This option is implicitly enabled when debugging info is enabled, but you can block it with the negated form -fno-working-directory. If the -P flag is in the command line, this option does nothing, since no #line directives get emitted whatsoever. 🙈
• -A predicate=answer 🙋 — makes an assertion with the predicate predicate and the answer answer. This form is preferred over the older -A predicate(answer) form, which is still supported, because it doesn't use shell special characters.
• -A -predicate=answer 🚫 — cancels an assertion with the predicate predicate and the answer answer.
• -C 💬 — do not discard comments. All comments get passed through to the output file, except for comments in processed directives, which are deleted along with the directive.

⚠️ Be prepared for side effects when using -C. It makes the preprocessor treat comments as tokens in their own right. For example, a comment at the start of what would be a directive line turns that line into an ordinary source line, since the first token on the line is no longer a #.

• -CC 💬✨ — do not discard comments, including during macro expansion. This is like -C, except comments inside macros also get passed through to the output file wherever the macro is expanded.

On top of the side effects of -C, -CC converts all C++-style comments inside a macro into C-style comments. That way, later use of the macro can't accidentally comment out the rest of the source line. 🛡️

The -CC option is generally used to support lint comments.

• -P 🚫📍 — inhibits generating linemarkers in the preprocessor output. This might be handy when you're running the preprocessor on something that isn't C code and will be sent to a program that could get confused by the linemarkers.
• -traditional, -traditional-cpp 🕰️ — tries to imitate pre-standard C preprocessors, instead of ISO C preprocessors. See the GNU CPP manual for details.

Note that GCC doesn't otherwise try to emulate a pre-standard C compiler, and these options only work with the -E switch, or when you invoke CPP explicitly.

• -trigraphs 🔺 — supports ISO C trigraphs. These are three-character sequences, all starting with ??, that ISO C defines to stand for single characters. For example, ??/ stands for \, so '??/n' is a character constant for a newline.

The nine trigraphs and their replacements are:

Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??'  ??!  ??-
Replacement:      [    ]    {    }    #    \    ^    |    ~

By default, GCC ignores trigraphs, but in standard-conforming modes it converts them. See the -std and -ansi options. 🧐

• -remap 🗃️ — enables special code to work around file systems that only allow really short file names, such as MS-DOS.
• -H 🌳 — prints the name of each header file used, along with the other normal activities. Each name is indented to show how deep it sits in the #include stack. Precompiled header files get printed too, even when they turn out to be invalid. An invalid precompiled header gets printed with ...x, and a valid one with ...!.
• -dletters 🧪 — makes debugging dumps during compilation, as specified by letters. The flags documented here are the ones relevant to the preprocessor. Other letters are interpreted by the compiler proper, or reserved for future versions of GCC, so they get silently ignored. If you specify letters whose behaviors conflict, the result is undefined. 💀
  • -dM 📜 — instead of the normal output, generates a list of #define directives for all the macros defined during preprocessing, including predefined macros. This is a great way to find out what's predefined in your version of the preprocessor. Assuming you have no file foo.h, this command:

touch foo.h; cpp -dM foo.h

shows all the predefined macros.

If you use -dM without the -E option, -dM is interpreted as a synonym for -fdump-rtl-mach. 🤓

• -dD 📚 — like -dM, except it outputs both the #define directives and the result of preprocessing. Both kinds of output go to the standard output file.
• -dN ✂️ — like -dD, but only emits the macro names, not their expansions.
• -dI 📎 — outputs #include directives in addition to the result of preprocessing.
• -dU ⏳ — like -dD, except only macros that get expanded, or whose definedness is tested in preprocessor directives, are output. The output is delayed until the macro is used or tested. #undef directives are also output for macros that get tested but are undefined at that time. 🦋

🎀 Preprocessor and Assembler Passthrough 🎀

• -fdebug-cpp 🙈 — This one is only useful if you're debugging GCC itself. When it's used from CPP or alongside -E, it dumps debugging info about location maps, and every token in the output gets the dump of whichever map its location belongs to. 🔍

When you use it from GCC without -E, it does absolutely nothing. 💀

• -Wp,option 🧚 — This lets you skip the compiler driver and send option straight to the preprocessor. If option has commas in it, it gets split into multiple options at each comma. 🔪

Heads up, though: a lot of options get modified, translated, or interpreted by the driver before they reach the preprocessor, and -Wp forcibly skips that step. The preprocessor's direct interface is undocumented and can change at any time, so whenever you can, let the driver handle your options and avoid -Wp. 🙅‍♀️

• -Xpreprocessor option 🌸 — Passes option along to the preprocessor. This is your go-to for system-specific preprocessor options that GCC doesn't recognize. ✨

If the option you want takes an argument, you need to use -Xpreprocessor twice: once for the option itself and once for the argument. 💅

• -no-integrated-cpp 🦋 — Runs preprocessing as its own separate pass before compilation. By default, GCC does preprocessing as part of input tokenization and parsing, all integrated and cute. 🫶

With this option, the right language front end (cc1 for C, cc1plus for C++, or cc1obj for Objective-C) gets invoked twice instead: once for preprocessing only, and once for actually compiling the preprocessed input. 🌈 This can be super handy alongside -B or -wrapper if you want an alternate preprocessor or extra processing of your source between the normal preprocessing and compilation. 🔥

---

🎀 Passing Options to the Assembler 🎀

Okay so you can pass options to the assembler too. 🧁

• -Wa,option 💜 — Passes option along as an option to the assembler. If option has commas, it gets split into multiple options at those commas. 🪄
• -Xassembler option ✨ — Also passes option to the assembler. Use this for system-specific assembler options that GCC doesn't recognize. 🦋

If you want to pass an option that takes an argument, you have to use -Xassembler twice, one time for the option and one time for the argument. 🙈

---

🌷 Options for Linking 🌷

These options come into play when the compiler links object files into an executable output file. They're meaningless if the compiler isn't doing a link step, so don't waste your energy on them then. 😭

• object-file-name 🍓 — Any file name that doesn't end in a special recognized suffix is treated as an object file or library. The linker tells objects and libraries apart by looking at the file contents. If linking happens, these files get fed into the linker as input. 🧚
• -c, -S, -E 🛑 — If you use any of these, the linker doesn't run at all, so you shouldn't pass object file names as arguments. 🙅‍♀️
• -flinker-output=type 🧠 — This controls code generation for the link-time optimizer. By default, the linker plugin figures out the linker output type automatically. But if you're debugging the compiler, or you want incremental linking with a non-LTO object file, it can be useful to set the type yourself. 🔧

Here's what each type does:

• exec makes code generation produce a static binary. In this case, -fpic and -fpie are both disabled. 🧊
• dyn makes code generation produce a shared library. Here -fpic or -fPIC gets preserved, but it isn't turned on automatically. This lets you build shared libraries without position-independent code on architectures where that's possible, which means x86. 💫
• pie makes code generation produce an -fpie executable. You get similar optimizations to exec, except -fpie doesn't get disabled if you specified it at compilation time. 👑
• rel tells the compiler to assume incremental linking is happening. The sections holding intermediate code for link-time optimization get merged, pre-optimized, and output to the resulting object file. If you also specify -ffat-lto-objects, binary code gets produced for future non-LTO linking. The object file from incremental linking is smaller than a static library made from the same object files, and at link time it loads faster than that static library, as long as most of the objects in the library actually get used. 🌸
• nolto-rel configures the compiler for incremental linking where code generation is forced, a final binary is produced, and the intermediate code for later link-time optimization gets stripped. When multiple object files are linked together, the result is better optimized than with link-time optimizations disabled (cross-module inlining happens, yay), but most of the benefits of whole program optimizations are lost. 😤

During the incremental link (by -r), the linker plugin defaults to rel. Right now, with the current interfaces to GNU Binutils, it's not possible to incrementally link LTO objects and non-LTO objects into a single mixed object file. If any object file in an incremental link can't be used for link-time optimization, the linker plugin warns you and uses nolto-rel. To keep whole program optimization, it's recommended to link those objects into a static library instead. Alternatively, you can use H.J. Lu's binutils, which supports mixed objects. 🥹

⚠️ Mixing LTO and non-LTO objects in an incremental link isn't possible with the current GNU Binutils interfaces. The plugin will warn you and fall back to nolto-rel, so static library is the safer move if you want whole program optimization. 💀

• -fuse-ld=bfd 🐣 — Uses the bfd linker instead of the default one. 🔗
• -fuse-ld=gold 🌟 — Uses the gold linker instead of the default one. ✨
• -fuse-ld=lld 💜 — Uses the LLVM lld linker instead of the default one. 🦋
• -fuse-ld=mold 🚀 — Uses the Modern Linker (mold) instead of the default one. 🔥
• -llibrary, -l library 📚 — Searches the library named library when linking. The second version, with the library as a separate argument, only exists for POSIX compliance, and honestly you shouldn't use it. 🙄

GCC passes -l straight through to the linker, so check your linker's docs for the exact details. The general description below applies to the GNU linker. 🧐

The linker searches a standard list of directories for the library. That includes several standard system directories, plus anything you add with -L. 🗺️

Static libraries are archives of object files, and they have names like liblibrary.a. Some targets also support shared libraries, which usually look like liblibrary.so. If both kinds are found, the linker prefers the shared library, unless you use the -static option. 💅

Where you put this option in the command actually matters, because the linker searches and processes libraries and object files in the order they're specified. So foo.o -lz bar.o searches library z after foo.o but before bar.o. If bar.o refers to functions in z, those functions might not get loaded. 😭

• -lobjc 🍒 — You need this special case of -l to link an Objective-C or Objective-C++ program. 🌈
• -nostartfiles 🙈 — Don't use the standard system startup files when linking. The standard system libraries are still used normally, unless -nostdlib, -nolibc, or -nodefaultlibs is used. 🌷
• -nodefaultlibs 🫧 — Don't use the standard system libraries when linking. Only the libraries you specify get passed to the linker, and options that set up linkage of the system libraries, like -static-libgcc or -shared-libgcc, get ignored. The standard startup files are still used normally, unless -nostartfiles is used. 🧸

The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These are usually resolved by entries in libc. When you use this option, those entry points need to be supplied some other way. ⚠️

• -nolibc 🌙 — Don't use the C library, or the system libraries tightly coupled with it, when linking. You'll still link with the startup files, libgcc, and any toolchain-provided language support libraries such as libgnat, libgfortran, or libstdc++, unless options preventing their inclusion are used as well. This typically removes -lc from the link command line, along with system libraries that normally go with it and become meaningless when you're assuming there's no C library, like -lpthread or -lm in some configurations. This is meant for bare-board targets where there genuinely is no C library available. 🤖
• -nostdlib 🪐 — Don't use the standard system startup files or libraries when linking. No startup files get used, and only the libraries you specify get passed to the linker. Options specifying linkage of the system libraries, like -static-libgcc or -shared-libgcc, get ignored. 🚫

The compiler may generate calls to "memcmp", "memset", "memcpy" and "memmove". These are usually resolved by entries in libc, so when this option is specified, those entry points need to be supplied some other way. 🥺

One of the standard libraries bypassed by -nostdlib and -nodefaultlibs is libgcc.a. It's a library of internal subroutines that GCC uses to get around shortcomings of particular machines, or special needs of some languages. 🧩

Honestly, you usually still need libgcc.a even when you want to avoid the other standard libraries. So when you specify -nostdlib or -nodefaultlibs, you should usually add -lgcc as well. That way you won't end up with unresolved references to internal GCC library subroutines. (An example of one of those internal subroutines is "__main", which makes sure C++ constructors get called.) 💖

• -nostdlib++ 🦢 — Don't implicitly link with the standard C++ libraries. 🫶
• -e entry, --entry=entry 🎯 — Sets the program entry point to entry. The linker interprets the argument, and the GNU linker accepts either a symbol name or an address. 📍
• -pie 👑 — Produces a dynamically linked position independent executable on targets that support it. For predictable results, you also have to specify the same set of options you used for compilation (-fpie, -fPIE, or model suboptions) when you use this linker option. 🌌
• -no-pie 🙅‍♀️ — Doesn't produce a dynamically linked position independent executable. 💤
• -static-pie — ✨ Makes a static position independent executable on targets that support it. It's like a regular static executable, except it can be loaded at any address without a dynamic linker 🧚. For predictable results, you also need to use the same options you used for compilation (-fpie, -fPIE, or model suboptions) when you pass this linker option 💅.
• -pthread — 🧵 Links with the POSIX threads library. This works on GNU/Linux targets, most other Unix derivatives, and x86 Cygwin and MinGW targets. On some targets it also sets flags for the preprocessor, so use it consistently for both compiling and linking 🫶.
• -r — 🧩 Produces a relocatable object as output. This is also called partial linking.
• -rdynamic — 🌈 Passes the flag -export-dynamic to the ELF linker, on targets that support it. The linker then adds all symbols to the dynamic symbol table, not just the ones that get used 👑. This option is needed for some uses of dlopen, or if you want backtraces from inside a program 🔥.
• -s — 🫧 Strips all symbol table and relocation information out of the executable.
• -static — 🧊 On systems that support dynamic linking, this overrides -pie and stops linking with shared libraries. On other systems it does nothing 💀.
• -shared — 🦋 Produces a shared object that can be linked with other objects to form an executable. Not every system supports this one 🙈. For predictable results, you also need the same options used for compilation (-fpic, -fPIC, or model suboptions) when you pass this linker option[1] ✨.
• -shared-libgcc, -static-libgcc — 🎀 On systems that ship libgcc as a shared library, these force the shared or static version, respectively. If no shared version of libgcc got built when the compiler was configured, these do nothing 🌸.

There are a few situations where an app should use the shared libgcc instead of the static one. The biggest one is when the app wants to throw and catch exceptions across different shared libraries. In that case, every one of those libraries and the app itself should use the shared libgcc 😭.

So the G++ driver automatically adds -shared-libgcc whenever you build a shared library or a main executable, since C++ programs usually use exceptions. That's the right move, periodt 💅.

If you use the GCC driver to make shared libraries instead, they might not always get linked with the shared libgcc 🤔. If GCC figures out at configuration time that you have a non-GNU linker, or a GNU linker that doesn't support option --eh-frame-hdr, it links the shared version of libgcc into shared libraries by default. Otherwise, it takes advantage of the linker and skips linking with the shared libgcc, so it links with the static version by default. This lets exceptions propagate through those shared libraries without paying relocation costs at library load time ⭐.

⚠️ However, if a library or main executable is supposed to throw or catch exceptions, you have to link it using the G++ driver, or use the option -shared-libgcc, so it gets linked with the shared libgcc. Don't skip this one bestie 😭.

• -static-libasan — 🛡️ When -fsanitize=address is used to link a program, the GCC driver automatically links against libasan. If libasan is available as a shared library and -static isn't used, it links the shared version. This option tells the GCC driver to link libasan statically, without necessarily linking other libraries statically 🍓.
• -static-libtsan — 🧵 When -fsanitize=thread is used to link a program, the GCC driver automatically links against libtsan. If libtsan is a shared library and -static isn't used, it links the shared version. This option tells the GCC driver to link libtsan statically, without necessarily linking other libraries statically 💜.
• -static-liblsan — 🕵️ When -fsanitize=leak is used to link a program, the GCC driver automatically links against liblsan. If liblsan is a shared library and -static isn't used, it links the shared version. This option tells the GCC driver to link liblsan statically, without necessarily linking other libraries statically 🌷.
• -static-libubsan — 🐚 When -fsanitize=undefined is used to link a program, the GCC driver automatically links against libubsan. If libubsan is a shared library and -static isn't used, it links the shared version. This option tells the GCC driver to link libubsan statically, without necessarily linking other libraries statically 🎀.
• -static-libstdc++ — 📚 When the g++ program links a C++ program, it normally links against libstdc++ automatically. If libstdc++ is a shared library and -static isn't used, it links the shared version, which is usually fine 👌. But sometimes you want to freeze the libstdc++ version your program uses without going all the way to a fully static link. This option tells the g++ driver to link libstdc++ statically, without necessarily linking other libraries statically 🫶.
• -symbolic — 🔗 Binds references to global symbols when building a shared object. It warns about any unresolved references (unless you override that with the link editor option -Xlinker -z -Xlinker defs). Only a few systems support this one 🥹.
• -T script — 📜 Uses script as the linker script. Most systems using the GNU linker support this. On some targets, like bare-board targets with no operating system, -T may be needed when linking to avoid references to undefined symbols 💫.
• -Xlinker option — 🎁 Passes option along to the linker as an option. Handy for system-specific linker options that GCC doesn't recognize 🧠.

If you want to pass an option that takes a separate argument, you need to use -Xlinker twice: once for the option and once for the argument. For example, to pass -assert definitions, you write -Xlinker -assert -Xlinker definitions. Writing -Xlinker "-assert definitions" does not work, because that sends the whole string as one argument, and the linker doesn't want that 🙅‍♀️.

With the GNU linker it's usually easier to pass arguments using the option=value syntax instead of separate arguments. For example, you can write -Xlinker -Map=output.map instead of -Xlinker -Map -Xlinker output.map. Other linkers might not support this syntax for command-line options 🤷‍♀️.

• -Wl,option — 🌟 Also passes option to the linker. If option has commas in it, it gets split into multiple options at each comma. You can use this syntax to pass an argument to an option. For example, -Wl,-Map,output.map passes -Map output.map to the linker. With the GNU linker you can also get the same effect with -Wl,-Map=output.map 🍭.

📢 NOTE: In Ubuntu 8.10 and later, for LDFLAGS, the option -Wl,-z,relro is used. To turn that off, use -Wl,-z,norelro 🙈.

• -u symbol — 🎣 Pretends the symbol symbol is undefined, which forces the linking of library modules that define it. You can use -u multiple times with different symbols to force loading of more library modules 🧲.
• -z keyword — ⚙️ -z gets passed straight to the linker along with the keyword. Check the documentation for your linker to see the permitted values and what they mean 📖.

---

✨ Options for Directory Search ✨

These options tell GCC which directories to search for header files, libraries, and parts of the compiler 🗂️:

• -I dir
• -iquote dir
• -isystem dir
• -idirafter dir — 📁 Adds the directory dir to the list of directories searched for header files during preprocessing. If dir starts with = or $SYSROOT, that = or $SYSROOT gets swapped out for the sysroot prefix. See --sysroot and -isysroot for more on that 🌸.

Directories given with -iquote only apply to the quote form of the directive, "#include "file"". Directories given with -I, -isystem, or -idirafter apply to lookups for both "#include "file"" and "#include <file>" 💖.

You can mix and match any number of these options on the command line to search for headers in lots of places at once 🦋. The lookup order goes like this:

1. For the quote form of the include directive, the directory of the current file gets searched first.
2. For the quote form, the directories from -iquote options get searched left to right, in the order they show up on the command line.
3. Directories from -I options get scanned left to right.
4. Directories from -isystem options get scanned left to right.
5. Standard system directories get scanned.
6. Directories from -idirafter options get scanned left to right.

You can use -I to override a system header file and swap in your own version, since those directories get searched before the standard system header directories 🫢. Just don't use this option to add directories full of vendor-supplied system headers. Use -isystem for that 🚫.

The -isystem and -idirafter options also mark the directory as a system directory, so it gets the same special treatment as the standard system directories 👑.

If a standard system include directory, or a directory given with -isystem, is also given with -I, the -I option gets ignored. The directory still gets searched, but as a system directory in its normal spot in the system include chain. This keeps GCC's fix-up for buggy system headers and the ordering for the #include_next directive from getting messed up by accident 😭. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options 🧚.

• -I- — Splitting the include path, ya know? ✂️ This one is deprecated, so please don't reach for it. Use -iquote for any -I directories that come before the -I-, and then drop the -I- altogether. 🙅‍♀️

Any -I directories placed before -I- only get searched for headers pulled in with #include "file". They're skipped for #include <file>. Any -I directories placed after the -I- get searched for every #include directive. 🗺️

On top of that, -I- stops the directory of the current file from being used as the first place to look for #include "file". And there's no way to undo that effect of -I-, so choose wisely, bestie. 💀

• -iprefix prefix — Sets prefix as the prefix that later -iwithprefix options will use. 🎀 If the prefix is a directory, make sure you end it with a final /. 📂
• -iwithprefix dir, -iwithprefixbefore dir — Tacks dir onto the prefix you set earlier with -iprefix, then adds the result to the include search path. ✨

-iwithprefixbefore slots it in the same spot -I would. -iwithprefix puts it where -idirafter would. 🧚

• -isysroot dir — Basically the same vibe as --sysroot, but it only applies to header files. 📚 The exception is Darwin targets, where it covers both header files and libraries. 🍎 Check out the --sysroot option for the full tea. ☕
• -imultilib dir — Uses dir as a subdirectory of the directory that holds the target-specific C++ headers. 🌸
• -nostdinc — Tells the compiler to skip the standard system directories when hunting for header files. 🙈 Only the directories you explicitly give with -I, -iquote, -isystem, and/or -idirafter get searched (plus the directory of the current file, if that makes sense for the situation). 💅
• -nostdinc++ — Skips the C++-specific standard directories when searching for headers, but still checks the other standard directories. 🫶 (This one is used when building the C++ library, so it's giving behind-the-scenes energy. 🔥)
• --embed-dir=dir — Adds the dir directory to the list of places searched by the #embed preprocessing directive or the __has_embed macro. 🦋 There are no default directories for #embed, so you gotta add your own. 😭

If dir starts with = or $SYSROOT, that = or $SYSROOT gets swapped out for the sysroot prefix. Peep --sysroot and -isysroot for more on that. 👑

• -iplugindir=dir — Sets the directory where plugins are searched for when they're passed with -fplugin=name instead of -fplugin=path/name.so. 🔌 This one isn't really meant for you to use directly. It's only passed along by the driver, so let the driver handle it. 🤖
• -Ldir — Adds the directory dir to the list of directories searched for -l libraries. 📦
• -Bprefix — This is where you tell the compiler where to find its own executables, libraries, include files, and data files. 🗂️

The compiler driver runs one or more of these subprograms: cpp, cc1, as, and ld. 🛠️ For each one it runs, it tries prefix as a prefix, both with and without machine/version/ for the matching target machine and compiler version. 🌈

For each subprogram, the driver checks the -B prefix first (if you gave one). If that doesn't turn anything up, or if -B wasn't specified, it tries two standard prefixes: /usr/lib/gcc/ and /usr/local/lib/gcc/. 🔍 If none of those produce a file that actually exists, the plain program name gets searched for using the directories listed in your PATH environment variable. 🫠

The compiler checks whether the path you passed to -B is a directory. If it is, the compiler adds a directory separator character at the end if it's needed. 📁

-B prefixes that act like directory names also apply to libraries in the linker, because the compiler turns those options into -L options for the linker. 🔗 They also apply to include files in the preprocessor, because the compiler turns them into -isystem options for the preprocessor. In that case the compiler appends include to the prefix. 💖

The runtime support file libgcc.a can also be searched for using the -B prefix, if needed. If it's not found there, only the two standard prefixes above get tried, and that's the whole list. 🙃 If it's still missing after all that, it gets left out of the link. 💀

Another way to set a prefix that works like the -B prefix is the environment variable GCC_EXEC_PREFIX. 🌷

Okay, here's the lowkey kludge 🧸: if the path given to -B is [dir/]stageN/, where N is a number from 0 to 9, it gets replaced with [dir/]include. This is there to help with bootstrapping the compiler. 🥾

• -no-canonical-prefixes — Don't expand any symbolic links, don't resolve references to /../ or /./, and don't make the path absolute when generating a relative prefix. 🧭
• --sysroot=dir — Makes dir the logical root directory for headers and libraries. 🌳 For example, if the compiler normally looks for headers in /usr/include and libraries in /usr/lib, it'll look in dir/usr/include and dir/usr/lib instead. 🪄

If you use this option and the -isysroot option, then --sysroot applies to libraries, while -isysroot applies to header files. 🤝

The GNU linker (starting with version 2.16) has the support needed for this option. If your linker doesn't support it, the header file part of --sysroot still works, but the library part doesn't. 😤

• --no-sysroot-suffix — For some targets, a suffix gets added to the root directory set with --sysroot, depending on what other options you used. So headers might get found in dir/suffix/usr/include instead of dir/usr/include. 🧩 This option turns off adding that suffix. 🚫

---

✨ Options for Code Generation Conventions ✨

These machine-independent options control the interface conventions the compiler uses during code generation. 🧠

Most of them come in positive and negative forms. The negative form of -ffoo is -fno-foo. 🔄 In the list below, only one form is shown, the one that is not the default. You can work out the other one by either removing no- or adding it. 🪞

• -fstack-reuse=reuse-level — This option controls stack space reuse for user-declared local/auto variables and compiler-generated temporaries. 🥞 reuse_level can be all, named_vars, or none. all turns on stack reuse for every local variable and temporary. named_vars only turns on reuse for user-defined local variables that have names. none turns stack reuse off completely. The default is all. 💜

You'd need this option when a program stretches the lifetime of a scoped local variable or a compiler-generated temporary past the end point the language defines. ⏳ When a variable's lifetime ends and it lives in memory, the optimizing compiler is free to reuse its stack space for other temporaries or scoped local variables whose live range doesn't overlap with it. 🫧 Legacy code that stretches local lifetimes is likely to break with the stack reuse optimization. 💀

For example,

                  int *p;
                  {
                    int local1;

                    p = &local1;
                    local1 = 10;
                    ....
                  }
                  {
                     int local2;
                     local2 = 20;
                     ...
                  }

                  if (*p == 10)  // out of scope use of local1
                    {

                    }

Another example:

                  struct A
                  {
                      A(int k) : i(k), j(k) { }
                      int i;
                      int j;
                  };

                  A *ap;

                  void foo(const A& ar)
                  {
                     ap = &ar;
                  }

                  void bar()
                  {
                     foo(A(10)); // temp object's lifetime ends when foo returns

                     {
                       A a(20);
                       ....
                     }
                     ap->i+= 10;  // ap references out of scope temp whose space
                                  // is reused with a. What is the value of ap->i?
                  }

The C++ standard clearly defines the lifetime of a compiler-generated temporary. 📜 When that lifetime ends and the temporary lives in memory, the optimizing compiler can reuse its stack space for other temporaries or scoped local variables whose live range doesn't overlap. 🌪️ But some legacy code depends on older compilers, where temporaries' stack space was never reused, so the aggressive reuse can lead to runtime errors. 😱 This option is what lets you control that temporary stack reuse optimization. 🎛️

• -ftrapv — Generates traps for signed overflow on addition, subtraction, and multiplication operations. 🚨 The options -ftrapv and -fwrapv override each other, so -ftrapv -fwrapv on the command line means -fwrapv is the one that's effective. 🫠 Only active options override, though, so -ftrapv -fwrapv -fno-wrapv on the command line means -ftrapv is the one that's effective. 🤯
• -fwrapv — Tells the compiler to assume that signed arithmetic overflow from addition, subtraction, and multiplication wraps around using two's-complement representation. 🔁 This flag enables some optimizations and disables others. 🎭 The options -ftrapv and -fwrapv override each other, so -ftrapv -fwrapv on the command line means -fwrapv is effective. 💅 Only active options override, so -ftrapv -fwrapv -fno-wrapv on the command line means -ftrapv is effective. ✨
• -fwrapv-pointer — Tells the compiler to assume that pointer arithmetic overflow on addition and subtraction wraps around using two's-complement representation. 🌀 This flag disables some optimizations that assume pointer overflow is invalid. 🙅‍♀️
• -fstrict-overflow — This option implies -fno-wrapv -fno-wrapv-pointer, and when it's negated, it implies -fwrapv -fwrapv-pointer. 🦄
• -fexceptions — okay so this turns on exception handling 💖 It generates the extra code needed to propagate exceptions. On some targets it also makes GCC emit frame unwind info for every function, which can bloat your data size a lot (it doesn't slow anything down though 🫶). If you don't say anything, GCC turns it on for languages like C++ that normally need it and leaves it off for languages like C that don't. Still, you might need to flip it on when your C code has to play nicely with exception handlers written in C++ 🎀 And if you're compiling older C++ programs that never use exception handling, you may want to switch it off. ✨
• -fnon-call-exceptions — this one lets trapping instructions throw exceptions 🔥 Heads up, it needs platform-specific runtime support that doesn't exist everywhere, so check before you get attached. It only lets trapping instructions (memory references or floating-point instructions) throw. It does not let exceptions come out of arbitrary signal handlers like "SIGALRM" 🙈 Also, it turns on -fexceptions automatically.
• -fdelete-dead-exceptions — this basically says instructions that might throw but don't actually contribute to the program's execution can get optimized away 🧹 It doesn't touch calls to functions, except the ones marked with the "pure" or "const" attributes. It's on by default for the Ada and C++ compilers, since the language specs allow it. Which optimization passes actually remove dead exceptions depends on the optimization level, and each pass is enabled on its own schedule. 💅
• -funwind-tables — similar to -fexceptions, except it only generates the static data that's needed and leaves the actual generated code alone 🦋 You usually don't have to turn this on yourself, because any language processor that needs this handling switches it on for you. Bestie, you're covered. 🫶
• -fasynchronous-unwind-tables — generates an unwind table in DWARF format, as long as the target machine supports it ✨ The table is exact at every instruction boundary, which means it can be used for stack unwinding during asynchronous events, like when a debugger or a garbage collector shows up mid-run 👑
• -fno-gnu-unique — okay this one is a little dramatic 😭 On systems with a recent GNU assembler and C library, the C++ compiler uses the "STB_GNU_UNIQUE" binding so that template static data members and static local variables in inline functions stay unique, even with "RTLD_LOCAL" in the mix. That matters because otherwise a library used by two different "RTLD_LOCAL" plugins could end up disagreeing about what a symbol binds to. The catch is that this makes dlclose get ignored for the affected DSOs. If your program relies on reinitializing a DSO through dlclose and dlopen, reach for -fno-gnu-unique 🌸
• -fpcc-struct-return — returns "short" "struct" and "union" values in memory, just like the longer ones, instead of in registers 🧺 It's less efficient, but it lets code compiled by GCC play nicely with files compiled by other compilers, especially the Portable C Compiler (pcc) 🫶

The exact convention for returning structures in memory depends on the target configuration macros, so it's not one-size-fits-all.

Short structures and unions are the ones whose size and alignment match some integer type. Cute and specific, iykyk. 🎀

Warning: code compiled with -fpcc-struct-return is not binary compatible with code compiled with -freg-struct-return. Only use it when you need to conform to a non-default application binary interface. 💀

• -freg-struct-return — returns "struct" and "union" values in registers whenever it's possible 🚀 For small structures this is more efficient than -fpcc-struct-return.

If you don't specify either -fpcc-struct-return or -freg-struct-return, GCC just goes with whatever convention is standard for the target. If there's no standard convention, GCC defaults to -fpcc-struct-return, except on targets where GCC is the principal compiler. In those cases, GCC gets to pick the standard, and it picked the more efficient register return option. Main character energy 👑

Warning: code compiled with -freg-struct-return is not binary compatible with code compiled with -fpcc-struct-return. Only use it when you need to conform to a non-default application binary interface. 💀

• -fshort-enums — gives an "enum" type only as many bytes as it needs to hold its declared range of possible values 🍓 To be precise, the "enum" type becomes the smallest integer type with enough room. This does nothing for an enumeration type that has a fixed underlying type.

Warning: -fshort-enums makes GCC generate code that is not binary compatible with code generated without that switch. Only use it to conform to a non-default application binary interface. ⚠️

• -fshort-wchar — overrides the underlying type of "wchar_t" so it's "short unsigned int" instead of the target's default 🌈 This one is handy for building programs that run under WINE.

Warning: -fshort-wchar makes GCC generate code that is not binary compatible with code generated without that switch. Only use it to conform to a non-default application binary interface. 💀

• -fcommon — in C code, this option controls where global variables defined without an initializer get placed. Those are called tentative definitions in the C standard 🧚 They're different from declarations of a variable with the "extern" keyword, which don't allocate any storage.

The default is -fno-common, which means the compiler puts uninitialized global variables in the BSS section of the object file. This stops the linker from merging tentative definitions, so you'll get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit. Honestly, that error is saving you. 🫶

-fcommon puts uninitialized global variables in a common block instead. That lets the linker resolve all the tentative definitions of the same variable across different compilation units to the same object, or to a non-tentative definition. The downside: this behavior is inconsistent with C++, and on many targets it costs some speed and code size on global variable references. It's mainly useful for getting legacy code to link without errors 🥲

• -fno-ident — tells GCC to ignore the #ident directive 🙈
• -finhibit-size-directive — don't output a .size assembler directive, or anything else that would cause trouble if the function gets split in the middle with the two halves placed far apart in memory 💜 This is used when compiling crtstuff.c. You shouldn't need it for anything else, bestie.
• -fverbose-asm — puts extra commentary into the generated assembly so it's easier to read 📖 This is really only useful for people who actually need to read the generated assembly, like when they're debugging the compiler itself 🤓

-fno-verbose-asm, which is the default, leaves that extra info out. That's the one you want when you're comparing two assembler files. 💅

The added comments include:

• information on the compiler version and command-line options,
• the source code lines associated with the assembly instructions, in the form FILENAME:LINENUMBER:CONTENT OF LINE,
• hints on which high-level expressions correspond to the various assembly instruction operands.

Here's an example. Say you have this C source file:

        int test (int n)
        {
          int i;
          int total = 0;

          for (i = 0; i < n; i++)
            total += i * i;

          return total;
        }

Compiling it to (x86_64) assembly with -S, and sending the result straight to stdout with -o -:

gcc -S test.c -fverbose-asm -Os -o -

gives output similar to this:

                .file   "test.c"
        # GNU C11 (GCC) version 7.0.0 20160809 (experimental) (x86_64-pc-linux-gnu)
          [...snip...]
        # options passed:
          [...snip...]

                .text
                .globl  test
                .type   test, @function
        test:
        .LFB0:
                .cfi_startproc
        # test.c:4:   int total = 0;
                xorl    %eax, %eax      # <retval>
        # test.c:6:   for (i = 0; i < n; i++)
                xorl    %edx, %edx      # i
        .L2:
        # test.c:6:   for (i = 0; i < n; i++)
                cmpl    %edi, %edx      # n, i
                jge     .L5     #,
        # test.c:7:     total += i * i;
                movl    %edx, %ecx      # i, tmp92
                imull   %edx, %ecx      # i, tmp92
        # test.c:6:   for (i = 0; i < n; i++)
                incl    %edx    # i
        # test.c:7:     total += i * i;
                addl    %ecx, %eax      # tmp92, <retval>
                jmp     .L2     #
        .L5:
        # test.c:10: }
                ret
                .cfi_endproc
        .LFE0:
                .size   test, .-test
                .ident  "GCC: (GNU) 7.0.0 20160809 (experimental)"
                .section        .note.GNU-stack,"",@progbits

The comments are meant for humans rather than machines, so the precise format is subject to change. Don't build your life on it 🦋

• -frecord-gcc-switches — this records the command line you used to invoke the compiler into the object file being created 📼 It's only implemented on some targets, and the exact format depends on the target and binary file format. Usually it takes the form of a section containing ASCII text. This one is related to -fverbose-asm, but that switch only puts info into the assembler output as comments, so it never makes it into the object file. If you want another way to store compiler options in the object file, check out -grecord-gcc-switches ✨
• -fpic — 💖 Generates position-independent code (PIC) that's ready for a shared library, as long as your target machine supports it. All constant addresses get accessed through a global offset table (GOT), and the dynamic loader fills in those GOT entries when the program starts. (The dynamic loader isn't part of GCC, it's part of the operating system, so don't blame GCC for it 🙄.) If the GOT for your linked executable goes over a machine-specific maximum, the linker throws an error saying -fpic doesn't work, and then you should recompile with -fPIC instead. The maximums are 8k on the SPARC, 28k on AArch64, and 32k on the m68k and RS/6000. The x86 has no such limit 🦋.

PIC needs special support, so it only works on certain machines. For the x86, GCC supports PIC for System V but not for the Sun 386i 💀. Code generated for the IBM RS/6000 is always position-independent ✨.

When this flag is set, the macros __pic__ and __PIC__ are defined to 1 🌸.

• -fPIC — 🔥 If your target machine supports it, this emits position-independent code that's suitable for dynamic linking and doesn't have any limit on the size of the global offset table. It makes a real difference on AArch64, m68k, PowerPC and SPARC.

PIC needs special support, so it only works on certain machines 💅.

When this flag is set, the macros __pic__ and __PIC__ are defined to 2 💜.

• -fpie, -fPIE — 🧚 These are basically the same vibe as -fpic and -fPIC, except the position-independent code they generate can only be linked into executables. Usually you'd use them to compile code that's going to get linked with the -pie GCC option 🎀.

-fpie and -fPIE both define the macros __pie__ and __PIE__. Those macros have the value 1 for -fpie and 2 for -fPIE ✨.

• -fno-plt — 👑 Don't use the PLT for external function calls in position-independent code. Instead, the callee address gets loaded at the call sites from the GOT, and then the code branches to it. This is more efficient because it gets rid of PLT stubs and exposes GOT loads to optimizations 🔥. On architectures like 32-bit x86, where PLT stubs expect the GOT pointer in one specific register, this gives the compiler more register allocation freedom 🙌. Heads up: lazy binding needs the PLT, so with -fno-plt, all external symbols get resolved at load time ⭐.

If you only want to skip the PLT for specific external functions, use the function attribute noplt instead 🫶.

In position-dependent code, a few targets will also turn calls to functions marked to not use the PLT into calls through the GOT instead 🌈.

• -fno-jump-tables — 🙈 Don't use jump tables for switch statements, even when they'd be more efficient than other code generation strategies. This is handy alongside -fpic or -fPIC when you're building code that's part of a dynamic linker and can't reference the address of a jump table 🧚. On some targets, jump tables don't need a GOT, so you don't need this option there 💅.
• -fno-bit-tests — 🍓 Don't use bit tests for switch statements, even if they'd be more efficient than other code generation strategies ✨.
• -ffixed-reg — 🔒 Treat the register named reg as a fixed register. The generated code should never touch it (unless it's maybe being used as a stack pointer, frame pointer, or some other fixed role) 🎀.

reg has to be an actual register name. The names you can use depend on the machine, and they're defined in the REGISTER_NAMES macro in the machine description macro file 🤓.

This flag doesn't have a negative form, because it's a three-way choice 💫.

• -fcall-used-reg — 🦋 Treat the register named reg as an allocable register that gets clobbered by function calls. It can be allocated for temporaries or for variables that don't live across a call. Functions compiled this way do not save and restore the register reg 😭.

It's an error to use this flag with the frame pointer or stack pointer 🚫. Using it on other registers with fixed, pervasive roles in the machine's execution model gives disastrous results 💀.

This flag doesn't have a negative form either, since it's a three-way choice 💅.

• -fcall-saved-reg — 🛡️ Treat the register named reg as an allocable register that's saved by functions. It can be allocated even for temporaries or variables that live across a call. Functions compiled this way save and restore reg if they use it 🫶.

Same deal as before: it's an error to use this with the frame pointer or stack pointer ❌. Using it on other registers with fixed, pervasive roles in the machine's execution model produces disastrous results 😱.

A different kind of disaster happens if you use this flag on a register where function values get returned 🙈.

Again, no negative form, because it's a three-way choice ✨.

• -fpack-struct[=n] — 📦 With no value, this packs all structure members together with no holes. When you give it a value, which has to be a small power of two, structure members get packed according to that value, which represents the maximum alignment. Objects whose default alignment requirements are bigger than this get output potentially unaligned at the next fitting location 🌸.

⚠️ Warning: -fpack-struct makes GCC generate code that is not binary compatible with code generated without that switch. It also makes the code suboptimal 💀. Only use it to conform to a non-default application binary interface 🙏.

• -fleading-underscore — 🎀 This one and its counterpart, -fno-leading-underscore, forcibly change how C symbols are represented in the object file. One use for it is linking with legacy assembly code 🧸.

⚠️ Warning: -fleading-underscore makes GCC generate code that is not binary compatible with code generated without that switch. Only use it to conform to a non-default application binary interface. Also, not every target fully supports this switch 😬.

• -ftls-model=model — 🧵 Changes the thread-local storage model. The model argument should be one of global-dynamic, local-dynamic, initial-exec or local-exec. The choice is subject to optimization, though: the compiler might pick a more efficient model for symbols that aren't visible outside the translation unit, or if -fpic isn't given on the command line ✨.

Without -fpic, the default is initial-exec. With -fpic, the default is global-dynamic 💖.

• -ftrampolines — 🪄 For targets that normally need trampolines for nested functions, this always generates them instead of using descriptors. For targets that don't need them, like HP-PA or IA-64, it does nothing 🌈.

A trampoline is a tiny bit of code created at run time on the stack when the address of a nested function is taken. It gets used to call the nested function indirectly. Because of that, the stack has to be made executable for the program to work properly 🔓.

-fno-trampolines is enabled by default on a language-by-language basis, so the compiler can avoid generating trampolines when it works out that it's safe, and replace them with descriptors instead 🧠. Descriptors are made up of data only, but the generated code has to be ready to deal with them. As of this writing, -fno-trampolines is enabled by default only for Ada 👑.

Heads up: code compiled with -ftrampolines and code compiled with -fno-trampolines are not binary compatible if nested functions are present. So this option has to be used program-wide, and you need to handle it with extreme care 🫣.

For languages other than Ada, the -ftrampolines and -fno-trampolines options currently have no effect, and trampolines are always generated on platforms that need them for nested functions 💅.

• -ftrampoline-impl=[stack|heap] — 🏠 By default, trampolines are generated on the stack. But some platforms, like the Apple M1, don't allow an executable stack 🙅. Compiling with -ftrampoline-impl=heap makes GCC generate calls to __gcc_nested_func_ptr_created and __gcc_nested_func_ptr_deleted so that trampoline space gets allocated and deallocated on the executable heap. These functions are implemented in libgcc, and they'll only be provided on specific targets: x86_64 Darwin, and x86_64 and aarch64 Linux 🌸.

🚨 PLEASE NOTE: Heap trampolines are not guaranteed to be correctly deallocated if you setjmp, instantiate nested functions, and then longjmp back to a state prior to having allocated those nested functions 😭.

• -fvisibility=[default|internal|hidden|protected] — 👀 Sets the default ELF image symbol visibility to the option you specify. Every symbol gets marked with this unless it's overridden within the code. This can really improve linking and load times for shared object libraries, produce more optimized code, give you near-perfect API export, and prevent symbol clashes. It's strongly recommended that you use it in any shared objects you distribute 🫶.

Despite the name, default always means public, i.e., available to be linked against from outside the shared object 🤔. protected and internal are pretty useless in real-world usage, so the only other commonly used option is hidden. If you don't specify -fvisibility, the default is default, meaning every symbol is public 🌈.

For a good explanation of why ELF symbols should have the correct visibility, check out "How To Write Shared Libraries" by Ulrich Drepper, which you can find at <https://www.akkadia.org/drepper/> 📚. But here's the superior move this option makes possible: instead of marking things hidden when the default is public, make the default hidden and mark things public. This is the norm with DLLs on Windows. With -fvisibility=hidden and __attribute__ ((visibility("default"))) in place of __declspec(dllexport), you get almost identical semantics with identical syntax. This is a huge win for anyone working on cross-platform projects 💜✨.

For those adding visibility support to existing code, #pragma GCC visibility is a total lifesaver 🫶. You wrap the declarations you want to style with something like #pragma GCC visibility push(hidden), and then close it with #pragma GCC visibility pop. ✨ Now, bestie, symbol visibility is part of the API interface contract, so all new code should always spell out visibility whenever it isn't the default. Declarations that are only used inside the local DSO should be marked hidden explicitly, so you skip the PLT indirection overhead 💅. Being this clear also makes the code easier to read and basically documents itself 📖💖. One thing to know: because of ISO C++ spec requirements, operator new and operator delete must always have default visibility 🚫.

Be careful with headers from outside your project, like system headers and headers from any other library you use 🙈. They may not expect to be compiled with anything other than the default visibility. You might need to say #pragma GCC visibility push(default) before including them.

extern declarations aren't affected by -fvisibility, so a ton of code can be recompiled with -fvisibility=hidden with zero changes 🦋. The catch is that calls to extern functions with no explicit visibility go through the PLT. So it's way more effective to use __attribute ((visibility)) and/or #pragma GCC visibility to tell the compiler which extern declarations should be treated as hidden 👑.

Also, -fvisibility does affect C++ vague linkage entities 👀. For example, an exception class that gets thrown between DSOs must be explicitly marked with default visibility, so the type_info nodes get unified between the DSOs 😭.

If you want an overview of these techniques, what they do for you, and how to use them, check out <https://gcc.gnu.org/wiki/Visibility> 🌸.

---

✨ -fstrict-volatile-bitfields ✨

• -fstrict-volatile-bitfields — Use this when accesses to volatile bit-fields (or other structure fields, though the compiler usually respects those types anyway) should be a single access at the width of the field's type, aligned to natural alignment if possible 🎀. For example, targets with memory-mapped peripheral registers might need every access to be 16 bits wide. With this flag, you can declare all the peripheral bit-fields as unsigned short (assuming short is 16 bits on those targets) to force GCC to use 16-bit accesses instead of a potentially more efficient 32-bit access 💖.

If this option is disabled, the compiler goes for whatever is most efficient 🏎️. In the example above, that could be a 32-bit load, even though it touches bytes that don't contain any part of the bit-field, or memory-mapped registers unrelated to the one being updated 😬.

In some cases, like when the packed attribute is applied to a structure field, it might not be possible to access the field with one correctly aligned read or write for the target machine 🥺. When that happens, GCC falls back to generating multiple accesses, instead of code that would fault or truncate the result at run time. Honestly, that's the responsible move 🫶.

Note: Due to restrictions of the C/C++11 memory model, write accesses are not allowed to touch non bit-field members. So it's recommended to define all bits of the field's type as bit-field members 📝.

The default value of this option is determined by the application binary interface for the target processor 🧚.

✨ -fsync-libcalls ✨

• -fsync-libcalls — This controls whether any out-of-line instance of the __sync family of functions may be used to implement the C++11 __atomic family of functions 🔁.

The default is enabled, so the only useful form of this option is -fno-sync-libcalls 💅. This option is used in the implementation of the libatomic runtime library 📚.

✨ -fzero-init-padding-bits=value ✨

• -fzero-init-padding-bits=value — This guarantees zero initialization of padding bits in automatic variable initializers 🧸. Some languages promise zero-initialized padding bits in certain cases. For example, C23 does this when you use empty initializers ({}), and C++ does it with zero-initialization. Also, C guarantees that fields not specified in an initializer have their padding bits zero initialized. This option lets you change when padding bits in initializers are guaranteed to be zero initialized 🌈.

The default is -fzero-init-padding-bits=standard, which makes no further guarantees than the matching standard does. Here's an example, bestie 👇:

struct A { char a; unsigned long long b; char c; };
union B { char a; unsigned long long b; };
struct A a = {}; // C23 guarantees padding bits are zero.
struct A b = { 1, 2, 3 }; // No guarantees.
union B c = {}; // C23 guarantees padding bits are zero.
union B d = { 1 }; // No guarantees.

-fzero-init-padding-bits=unions guarantees zero initialization of padding bits in unions, on top of what the standards already guarantee 🍓. This happens if the initializer of a union is empty (then all bits of the union are zero initialized), or if the initialized member of the union is smaller than the size of the union (then padding bits outside the initialized member are guaranteed to be zero initialized). This was the GCC behavior before GCC 15 🕰️. In the example above, it guarantees zero initialization of the last sizeof (unsigned long long) - 1 bytes in the union 💜.

-fzero-init-padding-bits=all also guarantees zero initialization of padding bits in other aggregates 🌸. That covers the padding in between b.a and b.b (if there is any), and the tail padding in the structure (if there is any) ✨.

NOTE: In Ubuntu 25.10 and later versions, -fzero-init-padding-bits=all is enabled by default for C, C++, ObjC, and ObjC++, unless -fzero-init-padding-bits=standard is found 🚨.

---

✨ GCC Developer Options ✨

This section covers command-line options that are mainly for GCC developers 🧑‍💻. That includes options for compiler testing, digging into compiler bugs, and looking at compile-time performance problems 🔍. It also covers options that produce debug dumps at various points in the compilation, print stats like memory use and execution time, and print info about GCC's configuration, like where it searches for libraries 📊. Honestly, you'll rarely need any of these for ordinary compiling and linking 🙈.

A lot of developer options that make GCC dump output to a file take an optional =filename suffix. You can say stdout or - to dump to standard output, and stderr for standard error 💻.

If =filename is left out, GCC builds a default dump file name by concatenating the base dump file name, a pass number, a phase letter, and the pass name 🧩. The base dump file name is the name of the output file the compiler produced, if you explicitly specified one and it's not an executable. Otherwise, it's the source file name. The pass number comes from the order passes are registered with the compiler's pass manager 🔢. That's usually the same as the execution order, but passes registered by plugins, target-specific passes, or passes that get registered late are numbered higher than the pass named final, even if they run earlier 🤯. The phase letter is one of i (inter-procedural analysis), l (language-specific), r (RTL), or t (tree) 🔤. The files get created in the directory of the output file 📁.

• -fcallgraph-info, -fcallgraph-info=MARKERS — This makes the compiler output callgraph information for your program, one per object file 🕸️. The info is generated in the common VCG format. You can decorate it with extra per-node and/or per-edge information by passing a comma-separated list of markers. If the su marker is included, the callgraph gets stack usage info, which is the same as -fstack-usage. If the da marker is included, the callgraph gets info about dynamically allocated objects 🧠.

When you compile with -flto, no callgraph info gets output along with the object file 🙅. At LTO link time, -fcallgraph-info may generate multiple callgraph info files next to the intermediate LTO output files 📂.

• -dletters, -fdump-rtl-pass, -fdump-rtl-pass=filename — This tells GCC to make debugging dumps during compilation at the times specified by the letters 🔎. It's used for debugging the RTL-based passes of the compiler 🛠️.

Some -dletters switches mean something different when -E is used for preprocessing 🧐.

Debug dumps can be enabled with a -fdump-rtl switch or with some -d option letters 💡. Here are the possible letters you can use in pass and letters, and what they mean 👇:

• -fdump-rtl-alignments — Dumps after branch alignments have been computed 📐.
• -fdump-rtl-asmcons — Dumps after fixing RTL statements that have unsatisfied in/out constraints 🧷.
• -fdump-rtl-auto_inc_dec — Dumps after auto-inc-dec discovery. This pass only runs on architectures that have auto inc or auto dec instructions 🤖.
• -fdump-rtl-barriers — Dumps after cleaning up the barrier instructions 🧹.
• -fdump-rtl-bbpart — Dumps after partitioning hot and cold basic blocks 🔥🧊.
• -fdump-rtl-bbro — Dumps after block reordering 🔀.
• -fdump-rtl-btl1, -fdump-rtl-btl2 — These enable dumping after the two branch target load optimization passes 🎯.
• -fdump-rtl-bypass — Dumps after jump bypassing and control flow optimizations 🛣️.
• -fdump-rtl-combine — Dumps after the RTL instruction combination pass 🧩.
• -fdump-rtl-compgotos — Dumps after duplicating the computed gotos 🦘.
• -fdump-rtl-ce1, -fdump-rtl-ce2, -fdump-rtl-ce3 — These enable dumping after the three if conversion passes 🔀✨.
• -fdump-rtl-cprop_hardreg — Dumps after hard register copy propagation 📋.
• -fdump-rtl-csa — Dumps after combining stack adjustments 🥞.
• -fdump-rtl-cse1, -fdump-rtl-cse2 — These enable dumping after the two common subexpression elimination passes 🪞.
• -fdump-rtl-dce — Dumps after the standalone dead code elimination passes 💀.
• -fdump-rtl-dbr — Dumps after delayed branch scheduling ⏳.

Okay so bestie, we're picking up right where the RTL dump flags leave off 💅✨

• -fdump-rtl-dce1, -fdump-rtl-dce2 — 🧹 these two turn on dumping after the two dead store elimination passes. Dead stores get yeeted, and you get to see the receipts.
• -fdump-rtl-eh — 🛡️ dumps after the finalization of the EH handling code.
• -fdump-rtl-eh_ranges — 🗺️ dumps after the conversion of the EH handling range regions.
• -fdump-rtl-expand — 🌱 dumps after RTL generation.
• -fdump-rtl-fwprop1, -fdump-rtl-fwprop2 — ➡️ turn on dumping after the two forward propagation passes.
• -fdump-rtl-gcse1, -fdump-rtl-gcse2 — 🔁 turn on dumping after global common subexpression elimination. No more doing the same math twice, periodt.
• -fdump-rtl-init-regs — 🎬 dumps after the registers get initialized.
• -fdump-rtl-initvals — 🧮 dumps after the initial value sets are computed.
• -fdump-rtl-into_cfglayout — 🧱 dumps right after converting to cfglayout mode.
• -fdump-rtl-ira — 🎯 dumps after iterated register allocation.
• -fdump-rtl-jump — 🦘 dumps after the second jump optimization.
• -fdump-rtl-loop2 — 🔄 turns on dumping after the RTL loop optimization passes.
• -fdump-rtl-mach — 🔧 dumps after the machine dependent reorganization pass, if that pass actually exists on your target.
• -fdump-rtl-mode_sw — 🔀 dumps after redundant mode switches are removed.
• -fdump-rtl-rnreg — 🏷️ dumps after register renumbering.
• -fdump-rtl-outof_cfglayout — 📤 dumps after converting from cfglayout mode.
• -fdump-rtl-peephole2 — 🔍 dumps after the peephole pass.
• -fdump-rtl-postreload — 🔁 dumps after the post-reload optimizations.
• -fdump-rtl-pro_and_epilogue — 🎁 dumps after the function prologues and epilogues get generated.
• -fdump-rtl-sched1, -fdump-rtl-sched2 — 📅 turn on dumping after the basic block scheduling passes.
• -fdump-rtl-ree — ✂️ dumps after sign/zero extension elimination.
• -fdump-rtl-seqabstr — 🧩 dumps after common sequence discovery.
• -fdump-rtl-shorten — 📏 dumps after branches get shortened.
• -fdump-rtl-split1, -fdump-rtl-split2, -fdump-rtl-split3, -fdump-rtl-split4, -fdump-rtl-split5 — ✂️ these enable dumping after five rounds of instruction splitting. Five whole rounds, bestie 😭
• -fdump-rtl-sms — 🌀 dumps after modulo scheduling. Heads up: this pass only runs on some architectures, so it might not show up for you.
• -fdump-rtl-stack — 🥞 dumps after GCC's "flat register file" registers get converted into the x87's stack-like registers. This pass only runs on x86 variants, so it's x86-only energy.
• -fdump-rtl-subreg1, -fdump-rtl-subreg2 — 🧬 turn on dumping after the two subreg expansion passes.
• -fdump-rtl-vartrack — 👀 dumps after variable tracking.
• -fdump-rtl-vregs — 🔁 dumps after virtual registers get converted to hard registers.
• -fdump-rtl-web — 🕸️ dumps after live range splitting.
• -fdump-rtl-regclass, -fdump-rtl-subregs_of_mode_init, -fdump-rtl-subregs_of_mode_finish, -fdump-rtl-dfinit, -fdump-rtl-dfinish — 🫥 these dumps are defined but they always produce empty files. Not a bug, just vibes with nothing in them.
• -da, -fdump-rtl-all — 🌟 produce all the dumps listed above. Everything, all at once, no cap.
• -dA — 🏷️ annotates the assembler output with miscellaneous debugging information.
• -dD — 📜 dumps all macro definitions at the end of preprocessing, on top of the normal output.
• -dH — 💀 produces a core dump whenever an error occurs. Dramatic, but it works.
• -dp — 💬 annotates the assembler output with a comment showing which pattern and alternative got used. The length and cost of each instruction get printed too.
• -dP — 🎀 dumps the RTL in the assembler output as a comment before each instruction. It also turns on -dp annotation, so it's a whole package deal.
• -dx — 🧪 just generates RTL for a function instead of compiling it. Usually paired with -fdump-rtl-expand.

---

• -fdump-debug — 🐞 dumps the debugging information generated during the debug generation phase.
• -fdump-earlydebug — 🌅 dumps the debugging information generated during the early debug generation phase. Early bird gets the debug info.
• -fdump-noaddr — 🙈 when doing debugging dumps, this suppresses address output. That makes it way easier to diff dumps from compiler invocations using different compiler binaries and/or different text / bss / data / heap / stack / dso start locations.
• -freport-bug — 🚨 collects and dumps debug information into a temporary file if an internal compiler error (ICE) occurs. Oops moment, but make it useful.
• -fdump-unnumbered — 🔢 when doing debugging dumps, this suppresses instruction numbers and address output. Super handy for diff-ing dumps from invocations with different options, especially with and without -g.
• -fdump-unnumbered-links — 🔗 when doing debugging dumps (see the -d option above), this suppresses instruction numbers for the links to the previous and next instructions in a sequence.
• -fdump-ipa-switch, -fdump-ipa-switch-options — 🧭 control the dumping at various stages of inter-procedural analysis language tree to a file. The file name is generated by appending a switch specific suffix to the source file name, and the file gets created in the same directory as the output file. Here are the dumps you can ask for:
  • all — 🌈 enables all inter-procedural analysis dumps.
  • cgraph — 🕸️ dumps info about call-graph optimization, unused function removal, and inlining decisions.
  • inline — 📦 dumps after function inlining.
  • strubm — 🎚️ dumps after selecting "strub" modes, and records the selections as function attributes.
  • strub — 🧼 dumps "strub" transformations: interface changes, function wrapping, and insertion of builtin calls for stack scrubbing and watermarking.

Also, you can tack on -optimized, -missed, -note, and -all. They mean the same thing as they do for -fopt-info, and the default is -optimized.

For example, -fdump-ipa-inline-optimized-missed will emit info on callsites that were inlined, along with callsites that were not inlined. Main character energy 👑

By default, the dump includes messages about successful optimizations (same as -optimized) together with low-level details about the analysis. 🔍

• -fdump-ipa-clones — 🐑 creates a dump file with info about call graph node clones being created, and call graph nodes being removed, during inter-procedural optimizations and transformations. Its main purpose is so tools that make live-patches can figure out which functions need to be live-patched to fully replace a particular function (see -flive-patching). The file name is made by appending the suffix ipa-clones to the source file name, and it lives in the same directory as the output file. Each entry sits on its own line with semicolon separated fields.

For call graph clone creation, the fields are:

1. String "Callgraph clone".
2. Name of the function being cloned, as the assembler sees it.
3. A number that uniquely identifies the function being cloned in the call graph. It's only unique within a compilation unit or within whole-program analysis, and it's likely to be different between the two phases.
4. The file name of the source file where the function is defined.
5. The line where the function definition is located.
6. The column where the function definition is located.
7. Name of the new function clone, as the assembler sees it.
8. A number that uniquely identifies the new function clone in the call graph. Same deal: only unique within a compilation unit or whole-program analysis, and likely different in the two phases.
9. The file name of the source file that the new clone's source code location points to.
10. The line that the new clone's source code location points to.
11. The column that the new clone's source code location points to.
12. A string that says the reason for cloning.

For call graph clone removal, the fields are:

1. String "Callgraph removal".
2. Name of the function being removed, as it would be presented to the assembler.
3. A number that uniquely identifies the function being cloned in the call graph. Again, unique only within a compilation unit or whole-program analysis, and likely different in the two phases.
4. The file name of the source file where the function is defined.
5. The line where the function definition is located.
6. The column where the function definition is located.

• -fdump-lang — 🗣️ dumps language-specific info. The file name is made by appending .lang to the source file name.
• -fdump-lang-all, -fdump-lang-switch, -fdump-lang-switch-options, -fdump-lang-switch-options=filename — 🗂️ control the dumping of language-specific info. The options and filename parts work the same way they do for -fdump-tree. These switch values are accepted:
  • all — 🌸 enables all language-specific dumps.
  • class — 🏛️ dumps class hierarchy info. Virtual table info gets emitted unless slim is specified. This one is C++ only.
  • module — 📦 dumps module info. The options lineno (locations), graph (reachability), blocks (clusters), uid (serialization), alias (mergeable), asmname (Elrond), eh (mapper) & vops (macros) may add extra info. This one is C++ only too.
  • raw — 🧾 dumps the raw internal tree data. C++ only, bestie.
• -fdump-passes — 🖨️ prints on stderr the list of optimization passes that are turned on and off by your current command-line options. Perfect for checking what's actually running ✨

✨ OPTIONS ✨ (continued) 🎀

-fdump-statistics-option 📊 — okay so this one turns on pass statistics dumping and lets you control it, and the stats land in their own file! 🧚 The file name is your source file name with a suffix ending in .statistics stuck on the end, and it gets created in the same directory as your output file 📁. If you use the -option form, -stats sums the counters over the whole compilation unit, while -details dumps every single event as the passes generate them 👀. With no option at all, it just sums the counters for each function compiled. Simple and iconic 💅

-fdump-tree-all, -fdump-tree-switch, -fdump-tree-switch-options, -fdump-tree-switch-options=filename 🌳 — these are your tree dump switches! They control dumping at the various stages where GCC processes the intermediate language tree, into a file. If you use the -options form, options is a list of - separated options that tune the details of the dump. Not every option works with every dump, so the ones that don't make sense just get ignored, no drama 🙄 Here's the lineup:

• address 📍 — prints the address of each node. Usually this isn't very meaningful since it changes depending on the environment and source file, but its main use is tying a dump file to a debug environment.
• asmname 🏷️ — if DECL_ASSEMBLER_NAME has been set for a given decl, this uses that in the dump instead of DECL_NAME. The main perk is working backward from mangled names in the assembly file, which is so helpful 🫶
• slim 🥗 — when dumping front-end intermediate representations, this stops members of a scope or a function body from being dumped just because that scope was reached. Only items directly reachable by some other path get dumped. When dumping pretty-printed trees, it skips the bodies of control structures. When dumping RTL, it prints the RTL in slim (condensed) form instead of the default LISP-like representation.
• raw 🧾 — prints a raw representation of the tree. By default, trees get pretty-printed into a C-like representation, so this is the un-glammed version.
• details 🔍 — enables more detailed dumps (not honored by every dump option) and also includes info from the optimization passes.
• stats 📈 — enables dumping various statistics about the pass (again, not honored by every dump option).
• blocks 🧱 — shows basic block boundaries. This one is disabled in raw dumps, so no sneaking it in there!
• graph 🕸️ — for each of the other indicated dump files (-fdump-rtl-pass), this dumps a representation of the control flow graph to file.passid.pass.dot, suitable for viewing with GraphViz. Each function in the file is pretty-printed as a subgraph, so GraphViz can render them all in one single plot. This only works for RTL dumps, and the RTL is always dumped in slim form.
• vops 🎯 — shows virtual operands for every statement.
• lineno 🔢 — shows line numbers for statements.
• uid 🆔 — shows the unique ID (DECL_UID) for each variable.
• verbose 🗣️ — shows the tree dump for each statement.
• eh 🛟 — shows the EH region number holding each statement.
• scev 🧮 — shows scalar evolution analysis details.
• optimized ⚡ — shows optimization information (only available in certain passes).
• missed 🙃 — shows missed optimization information (only available in certain passes).
• note 📝 — shows other detailed optimization information (only available in certain passes).
• all 🌈 — turns on all options except raw, slim, verbose and lineno. Not everything, bestie, be picky!
• optall 👑 — turns on all the optimization options, which means optimized, missed, and note.

Wondering what tree dumps are available or how to find the dump for a specific pass? Follow these steps, it's giving treasure hunt 🗺️✨

1. Invoke GCC with -fdump-passes and look in the stderr output for a code that matches the pass you care about. For example, the codes tree-evrp, tree-vrp1, and tree-vrp2 correspond to the three Value Range Propagation passes. The number at the end tells apart different invocations of the same pass.
2. To turn on the creation of the dump file, tack the pass code onto the -fdump- option prefix and invoke GCC with it. For example, to get the dump from the Early Value Range Propagation pass, invoke GCC with the -fdump-tree-evrp option. You can optionally name the dump file too. If you don't, GCC makes one as described below.
3. Find the pass dump in a file whose name has three parts separated by periods: the name of the source file GCC was invoked to compile, a numeric suffix for the pass number followed by the letter t for tree passes (or the letter r for RTL passes), and finally the pass code. For example, the Early VRP pass dump might be in a file named myfile.c.038t.evrp in the current working directory. Heads up: the numeric codes are not stable and may change from one version of GCC to another 🙈

-fopt-info, -fopt-info-options, -fopt-info-options=filename 💡 — these control optimization dumps from the various optimization passes. If you use the -options form, options is a list of - separated option keywords that pick the dump details and optimizations.

The options split into three groups: 🧩

1. options describing what kinds of messages should be emitted,
2. options describing how verbose the dump is, and
3. options describing which optimizations should be included.

You can freely mix options from each group since they don't overlap. If there's ever a conflict, the later option wins over the earlier one on the command line 🏁

These options control which kinds of messages get emitted:

• optimized ✅ — prints info when an optimization is successfully applied. It's up to each pass to decide what's relevant. For example, the vectorizer passes print the source location of loops that get successfully vectorized.
• missed ❌ — prints info about missed optimizations. Individual passes decide what goes in the output.
• note 🗒️ — prints verbose info about optimizations, like certain transformations and more detailed messages about decisions.
• all 🎉 — prints detailed optimization info. This includes optimized, missed, and note.

This option controls the dump verbosity:

• internals 🔬 — by default, only "high-level" messages are emitted. This turns on extra, more detailed messages, which are mostly only useful to GCC developers, so it's giving nerd 🤓

These keywords let you pick a whole group of optimizations at once:

• ipa 🧑‍🤝‍🧑 — enables dumps from all interprocedural optimizations.
• loop 🔁 — enables dumps from all loop optimizations.
• inline 📦 — enables dumps from all inlining optimizations.
• omp 🧵 — enables dumps from all OMP (Offloading and Multi Processing) optimizations.
• vec 🚀 — enables dumps from all vectorization optimizations.
• optall 🌟 — enables dumps from all optimizations. This is a superset of the optimization groups listed above.

If options is left out, it defaults to optimized-optall, which means dumping messages about successful optimizations from all the passes, skipping anything treated as "internals" 💖

If you give a filename, the dumps from all the applicable optimizations get concatenated into that file. Otherwise the dump goes to stderr. You can use multiple -fopt-info options, but only one of them can include a filename. If other filenames show up, all but the first such option get ignored, so choose wisely 🫠

Heads up: the output filename gets overwritten when there are multiple translation units. If you want a combined output from multiple translation units, use stderr instead! 🚨

Check out these examples. The first sends the optimization info to stderr:

gcc -O3 -fopt-info

This one outputs the missed optimization report from all the passes into missed.all:

gcc -O3 -fopt-info-missed=missed.all

And this one prints info about missed optimization opportunities from the vectorization passes on stderr. Bonus tea: -fopt-info-vec-missed is equivalent to -fopt-info-missed-vec, and the order of the optimization group names and message types after -fopt-info doesn't matter 🍓

gcc -O2 -ftree-vectorize -fopt-info-vec-missed

Next up, this one outputs info about missed optimizations and optimized locations from all the inlining passes into inline.txt:

gcc -O3 -fopt-info-inline-optimized-missed=inline.txt

Finally, consider this one 👀:

gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt

Here, the two output filenames vec.miss and loop.opt clash, since only one output file is allowed. In this case only the first option takes effect and the rest get ignored. So only vec.miss gets produced, and it contains the dumps from the vectorizer about missed opportunities 😭

-fsave-optimization-record 💾 — writes a SRCFILE.opt-record.json.gz file detailing which optimizations were performed, for the optimizations that support -fopt-info.

Warning: this option is experimental, and the format of the data inside the compressed JSON file is subject to change. Don't build your whole life on it yet! 🧪

It's roughly equivalent to a machine-readable version of -fopt-info-all, as a collection of messages with source file, line number and column number. Each message also comes with the following extra data: ✨

• the execution count of the code being optimized, along with metadata about whether it came from actual profile data or just an estimate, so consumers can prioritize messages by code hotness 🔥,
• the function name of the code being optimized, where applicable 🏷️,
• the "inlining chain" for the code being optimized, so that when a function is inlined into several different places (which might themselves be inlined), the reader can tell the copies apart 🧩,

bestie, the message details are lowkey the best part 💅 each one hands you:

• 🔍 the parts of the message that point at expressions, statements or symbol-table nodes, which kind of thing each one is, and (when GCC knows it ✨) the source code location
• 🛠️ the GCC pass that spat out the message, and
• 📍 the spot in GCC's own code where the message came from

Also, some messages are logically nested inside other messages, because they mirror the little implementation details of the optimization passes 🧚

• -fsched-verbose=n — okay so, on targets that do instruction scheduling 🎀 this one controls how chatty the scheduler is when it writes debugging output to the dump files.

For n greater than zero, it gives you the same info as -fdump-rtl-sched1 and -fdump-rtl-sched2 💖 For n greater than one, it also adds basic block probabilities, detailed ready list info and unit/insn info. For n greater than two, it throws in RTL at the abort point, control-flow and regions info. And for n over four, -fsched-verbose also brings the dependence info 😭🔥

• -fenable-kind-pass, -fdisable-kind-pass=range-list — this is a whole family of options for explicitly turning optimization passes on and off 🦋 They're meant for debugging GCC itself. Regular compiler users should stick to the normal options for enabling and disabling passes instead 🫶
  • -fdisable-ipa-pass — disables the IPA pass called pass, where pass is the pass name 💅 If the same pass gets invoked statically more than once in the compiler, add a sequential number to the name, starting from 1.
  • -fdisable-rtl-pass, -fdisable-rtl-pass=range-list — disables the RTL pass called pass ✨ pass is the pass name, and the same numbering rule applies if it runs more than once. range-list is a comma-separated list of function ranges or assembler names. Each range is a number pair split by a colon, and it's inclusive on both ends 🌸 If the range is trivial, you can shorten the number pair to a single number. If a function's call graph node uid falls inside one of the ranges, the pass gets disabled for that function. You can find the uid in the function header of a dump file, and you can dump the pass names with -fdump-passes 👑
  • -fdisable-tree-pass, -fdisable-tree-pass=range-list — disables the tree pass called pass 💜 Check out -fdisable-rtl for how the option arguments work.
  • -fenable-ipa-pass — the opposite energy: enables the IPA pass called pass 🌈 pass is the pass name, and if it's invoked more than once, the same sequential numbering from 1 applies.
  • -fenable-rtl-pass, -fenable-rtl-pass=range-list — enables the RTL pass called pass 🎀 See -fdisable-rtl for the option argument description and examples.
  • -fenable-tree-pass, -fenable-tree-pass=range-list — enables the tree pass called pass ⭐ Same deal, see -fdisable-rtl for the description of option arguments.

Here are some examples of these options in action 🧚

        # disable ccp1 for all functions
           -fdisable-tree-ccp1
        # disable complete unroll for function whose cgraph node uid is 1
           -fenable-tree-cunroll=1
        # disable gcse2 for functions at the following ranges [1,1],
        # [300,400], and [400,1000]
        # disable gcse2 for functions foo and foo2
           -fdisable-rtl-gcse2=foo,foo2
        # disable early inlining
           -fdisable-tree-einline
        # disable ipa inlining
           -fdisable-ipa-inline
        # enable tree full unroll
           -fenable-tree-unroll

• -fchecking, -fchecking=n — turns on internal consistency checking 🙈 The default depends on how the compiler was configured. -fchecking=2 goes further and enables extra internal consistency checking that might affect code generation, so keep that in mind 💀
• -frandom-seed=string — this gives GCC a seed to use instead of random numbers when it generates certain symbol names that have to be unique in every compiled file 🦋 It's also used to stamp coverage data files and the object files that produce them. Pair it with -frandom-seed to get reproducibly identical object files, and that's a whole mood 🫶

The string can be a number (decimal, octal or hex) or an arbitrary string. If it's an arbitrary string, GCC converts it to a number by computing CRC32 🔢

⚠️ the string should be different for every file you compile, bestie!

• -save-temps — stores the usual "temporary" intermediate files permanently 🗂️ They get named as auxiliary output files, as specified under -dumpbase and -dumpdir.

When you use it together with the -x command-line option, -save-temps is smart enough to avoid overwriting an input source file that has the same extension as an intermediate file 🧠 If you want the intermediate file, rename the source file before using -save-temps.

• -save-temps=cwd — equivalent to -save-temps -dumpdir ./ 📂
• -save-temps=obj — equivalent to -save-temps -dumpdir outdir/, where outdir/ is the directory of the output file given after the -o option, including any directory separators 🌷 If you don't use -o, then -save-temps=obj behaves just like -save-temps=cwd ✨
• -time[=file] — reports the CPU time each subprocess in the compilation sequence takes ⏱️ For C source files, that's the compiler proper and the assembler (plus the linker if linking happens) 🧁

Without an output file specified, the output looks like this:

        # cc1 0.12 0.01
        # as 0.00 0.01

The first number on each line is the "user time", which is the time spent running the program itself 💅 The second number is the "system time", the time spent in operating system routines on the program's behalf. Both numbers are in seconds 🕰️

With an output file specified, the output gets appended to that named file and looks like this:

        0.12 0.01 cc1 <options>
        0.00 0.01 as <options>

The "user time" and "system time" get moved in front of the program name, and the options passed to the program are shown too 🪄 That way you can later tell which file was being compiled and with which options 📝

• -fdump-final-insns[=file] — dumps the final internal representation (RTL) to file 🌟 If the optional argument is left out (or if file is "."), the dump file's name comes from appending ".gkd" to the dump base name, see -dumpbase.
• -fcompare-debug[=opts] — if no error happens during compilation, this runs the compiler a second time, adding opts and -fcompare-debug-second to the arguments for that second run 🪞 It dumps the final internal representation in both compilations and prints an error if they differ. Iconic debugging energy 😭

If the equal sign is omitted, the default -gtoggle is used.

The environment variable GCC_COMPARE_DEBUG, if it's defined, non-empty and nonzero, implicitly enables -fcompare-debug 🌈 If GCC_COMPARE_DEBUG is defined to a string starting with a dash, that string is used for opts. Otherwise the default -gtoggle is used.

-fcompare-debug=, with the equal sign but without opts, is the same as -fno-compare-debug 🙅 That turns off dumping the final representation and the second compilation, and it even stops GCC_COMPARE_DEBUG from taking effect.

To verify full coverage during -fcompare-debug testing, set GCC_COMPARE_DEBUG to say -fcompare-debug-not-overridden. GCC rejects that as an invalid option in any actual compilation (rather than preprocessing, assembly or linking) 🙈 If you only want a warning instead, setting GCC_COMPARE_DEBUG to -w%n-fcompare-debug not overridden will do the trick ✨

• -fcompare-debug-second — this one gets passed to the compiler implicitly for the second compilation requested by -fcompare-debug 🫧 It comes along with options that silence warnings, and it leaves out any other options that would make the compiler write output to files or to standard output as a side effect. Dump files and preserved temporary files get renamed to include the ".gk" extra extension during that second compilation, so they don't overwrite the ones from the first run 🗃️

When you pass this option to the compiler driver, the first compilation gets skipped. That makes it pretty useful for basically nothing except debugging the compiler proper 🤓

• -gtoggle — turns off debug info generation if leaving out this option would generate it, or turns it on at level 2 otherwise 🔁 Its position on the command line doesn't matter. It takes effect after all other options are processed, and it only does so once, no matter how many times you give it. It's mainly meant to be used with -fcompare-debug 💜
• -fvar-tracking-assignments-toggle — toggles -fvar-tracking-assignments 🎀 It works the same way that -gtoggle toggles -g.
• -Q — when you use it on the command line before --help=, -Q acts as a modifier for the help output 🧾

Otherwise, this option makes the compiler print out each function name as it gets compiled, and print some statistics about each pass when it finishes 📊

• -ftime-report — makes the compiler print some statistics to stderr about the time each pass consumed when it finishes ⏳

If SARIF output of diagnostics was requested with -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr, then the -ftime-report information gets emitted as JSON inside the SARIF output instead 🧩 The precise format of that JSON data is subject to change, and the values may not exactly match what goes to stderr, since they're written out at a slightly different place within the compiler 🙃

• -ftime-report-details — records the time consumed by infrastructure parts separately for each pass 🔬
• -fira-verbose=n — controls how verbose the dump file for the integrated register allocator is 🌸 The default value is 5. If n is greater than or equal to 10, the dump output gets sent to stderr using the same format as n minus 10 💖
• -flto-report — okay so this one's a total gossip sesh for the compiler 🕵️‍♀️ It prints a report with internal details on how the link-time optimizer is working. The contents change from version to version, so don't get too attached to the exact format. It's mainly for GCC developers poking around when processing object files in LTO mode (via -flto) 🦋

Disabled by default 💅

• -flto-report-wpa — same tea as -flto-report, but it only spills during the WPA phase of link-time optimization 🫖
• -fmem-report — the compiler gives you a little stats recap about permanent memory allocation once it's totally finished 📊✨
• -fmem-report-wpa — same memory stats moment, but only for the WPA phase 🧠
• -fpre-ipa-mem-report, -fpost-ipa-mem-report — the compiler spills permanent memory allocation stats either before or after interprocedural optimization. Pick your timeline bestie 🕰️💜
• -fmultiflags — this one is lowkey iconic 👑 It lets multilib-aware TFLAGS build target libraries with options that are different from the ones the compiler is configured to use by default. It works through specs set up by compiler internals, by the target, or by builders at configure time.

Like TFLAGS, it means the target libraries can be built for portable baseline environments, while the compiler's defaults stay more demanding. That's so useful, because users can easily override the compiler's defaults for their own programs if those aren't ideal for their target environment. Rebuilding the runtime libraries is usually not as easy or desirable, so this is a whole vibe 🌸

Unlike TFLAGS, specs let different flags get picked for different multilibs. The way to make that happen is to build with make TFLAGS=-fmultiflags, after configuring with --with-specs=%{fmultiflags:...}.

⚠️ This option gets discarded by the driver once it's done processing driver self spec. So it's gone after that, periodt.

It's also handy for checking that TFLAGS are being used to build all the target libraries. You do that by configuring a non-bootstrap compiler with --with-specs='%{!fmultiflags:%emissing TFLAGS}' and then building the compiler and target libraries 🔍

• -fprofile-report — the compiler prints stats about how consistent the (estimated) profile is and what effect each individual pass had 📈
• -fstack-usage — the compiler outputs stack usage info for your program, per function 🥞 The dump file's name is made by appending .su to the auxname. The auxname comes from the name of the output file if you explicitly specified one and it isn't an executable. Otherwise, it's the basename of the source file.

Each entry has three fields:

• The name of the function.
• A number of bytes.
• One or more qualifiers: "static", "dynamic", "bounded".

The "static" qualifier means the function handles the stack statically. A fixed number of bytes gets allocated for the frame on function entry and released on function exit, and no other stack adjustments happen in the function. The second field is that fixed number of bytes 🧱

The "dynamic" qualifier means the function handles the stack dynamically. On top of the static allocation, stack adjustments are made in the function body, like pushing and popping arguments around function calls 🎢 If the "bounded" qualifier is also there, the amount of those adjustments is bounded at compile time, and the second field is an upper bound on the total stack used by the function. If "bounded" isn't present, the amount of adjustments isn't bounded at compile time, and the second field only represents the bounded part.

• -fstats — emits stats about front-end processing at the end of compilation. Only the C++ front end supports this, and the info is mostly only useful to the G++ dev team 🤓
• -fdbg-cnt-list — prints the name and the counter upper bound for every debug counter 🔢
• -fdbg-cnt=counter-value-list — sets the internal debug counter lower and upper bounds. counter-value-list is a comma-separated list of name:lower_bound1-upper_bound1 [:lower_bound2-upper_bound2...] tuples. Each one sets the counter's name and a list of closed intervals. The lower bound is optional and gets zero initialized if it isn't set.

For example, with -fdbg-cnt=dce:2-4:10-11,tail_call:10, dbg_cnt(dce) only returns true for the second, third, fourth, tenth and eleventh invocation. For dbg_cnt(tail_call), true is returned for the first 10 invocations 🎀

• -print-file-name=library — prints the full absolute name of the library file library that would be used when linking, and then stops right there. GCC doesn't compile or link anything with this one, it just spits out the file name 🖨️
• -print-multi-directory — prints the directory name for the multilib selected by any other switches on the command line. That directory is supposed to exist in GCC_EXEC_PREFIX 📂
• -print-multi-lib — prints the mapping from multilib directory names to the compiler switches that enable them. The directory name is separated from the switches by ;. Each switch starts with @ instead of -, and there are no spaces between multiple switches. This is meant to make shell processing easier 🐚
• -print-multi-os-directory — prints the path to OS libraries for the selected multilib, relative to some lib subdirectory. If OS libraries are in the lib subdirectory and no multilibs are used, this is usually just .. If OS libraries are in libsuffix sibling directories, it prints something like ../lib64, ../lib or ../lib32. If they're in lib/subdir subdirectories, it prints something like amd64, sparcv9 or ev6 🌈
• -print-multiarch — prints the path to OS libraries for the selected multiarch, relative to some lib subdirectory 🏛️
• -print-prog-name=program — same vibe as -print-file-name, but it searches for a program like cpp instead 🔎
• -print-libgcc-file-name — same as -print-file-name=libgcc.a ✨

This is useful when you use -nostdlib or -nodefaultlibs but you do want to link with libgcc.a. You can do:

gcc -nostdlib <files>... `gcc -print-libgcc-file-name`

• -print-search-dirs — prints the name of the configured installation directory and a list of the program and library directories gcc searches. Then it stops, no other action 📜

This is a lifesaver when gcc prints the error message installation problem, cannot exec cpp0: No such file or directory. To fix it, you either put cpp0 and the other compiler components where gcc expects to find them, or you set the environment variable GCC_EXEC_PREFIX to the directory where you installed them. And don't forget the trailing /! 🙈

• -print-sysroot — prints the target sysroot directory that's used during compilation. This is the target sysroot specified either at configure time or with the --sysroot option, possibly with an extra suffix that depends on compilation options. If no target sysroot is specified, it prints nothing 🌷
• -print-sysroot-headers-suffix — prints the suffix added to the target sysroot when searching for headers. If the compiler isn't configured with such a suffix, it gives an error instead. Then it stops 🚫
• -dumpmachine — prints the compiler's target machine (for example, i686-pc-linux-gnu) and that's it 🖥️
• -dumpversion — prints the compiler version (for example, 3.0, 6.3.0 or 7) and then stops 🫧 This is the compiler version used in filesystem paths and specs. Depending on how the compiler was configured, it can be a single number (major version), two numbers separated by a dot (major and minor version), or three numbers separated by dots (major, minor and patchlevel version).
• -dumpfullversion — prints the full compiler version and nothing else. The output is always three numbers separated by dots: major, minor and patchlevel version 💯
• -dumpspecs — prints the compiler's built-in specs, then stops. (This one gets used when GCC itself is being built 🛠️)

---

💖 Machine-Dependent Options 💖

Each target machine GCC supports can have its very own options. For example, you can compile for a particular processor variant or ABI, or control optimizations that are specific to that machine. By convention, the names of machine-specific options start with -m 🎀

Some configurations of the compiler also support extra target-specific options. These are usually there for compatibility with other compilers on the same platform 🫶

🦋 AArch64 Options 🦋

These options are defined for AArch64 implementations:

• -mabi=name — generates code for the specified data model. The valid values are ilp32, which is a SysV-like data model where int, long int and pointers are 32 bits, and lp64, which is a SysV-like data model where int is 32 bits but long int and pointers are 64 bits 🧚

The default depends on the specific target configuration. The LP64 and ILP32 ABIs are not link-compatible, so you have to compile your entire program with the same ABI and link it with a compatible set of libraries.

⚠️ The ilp32 model is deprecated. Not the vibe anymore, bestie 💀

• -mbig-endian — generates big-endian code. This is the default when GCC is configured for an aarch64_be-*-* target 🌊
• -mgeneral-regs-only — generates code that only uses the general-purpose registers. This stops the compiler from using floating-point and Advanced SIMD registers, but it doesn't put any restrictions on the assembler 🧘‍♀️
• -mlittle-endian — generates little-endian code. This is the default when GCC is configured for an aarch64-*-* target but not an aarch64_be-*-* target 🍓
• -mcmodel=tiny — generates code for the tiny code model. The program and its statically defined symbols must be within 1MB of each other. Programs can be statically or dynamically linked 🐣
• -mcmodel=small — generates code for the small code model. The program and its statically defined symbols must be within 4GB of each other. Programs can be statically or dynamically linked. This is the default code model 💅
• -mcmodel=large — generates code for the large code model. It makes no assumptions about addresses and sizes of sections. Programs can only be statically linked with this one. Also, -mcmodel=large is incompatible with -mabi=ilp32, -fpic and -fPIC, so don't mix them up 🙈

🎀 OPTIONS (AArch64 cont.) 🎀

-mtp=name lets you pick which system register acts as the thread pointer 🧵. The valid values are tpidr_el0, tpidrro_el0, tpidr_el1, tpidr_el2, and tpidr_el3. For backwards compatibility, the aliases el0, el1, el2, and el3 also work 💅. The default is tpidr_el0. Bestie, please compile everything that needs to interoperate with the same value of this option, or you'll end up grabbing a different thread pointer from the wrong exception level 😭.

• -mstrict-align, -mno-strict-align — ✨ These let you avoid, or allow, memory accesses that might not be aligned on a natural object boundary, as described in the architecture specification 📐.
• -momit-leaf-frame-pointer, -mno-omit-leaf-frame-pointer — 🍃 Omit or keep the frame pointer in leaf functions. Omitting it is the default behaviour, so that's the one you get unless you ask otherwise 🙈.
• -mstack-protector-guard=guard, -mstack-protector-guard-reg=reg, -mstack-protector-guard-offset=offset — 🛡️ These generate stack protection code using a canary at guard. The supported locations are global for a global canary, or sysreg for a canary in an appropriate system register.

With the sysreg choice, -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset decide which system register is the base register for reading the canary, and what offset from that base to read from. There is no default register or offset here, because this is entirely for use within the Linux kernel 🐧. Hands off unless you know what you're doing, periodt 🫶.

• -mtls-dialect=desc — 🧚 Uses TLS descriptors as the thread-local storage mechanism for dynamic accesses of TLS variables. This is the default, so you're already good ✨.
• -mtls-dialect=traditional — 🕰️ Uses traditional TLS as the thread-local storage mechanism for dynamic accesses of TLS variables, instead of descriptors.
• -mtls-size=size — 📏 Sets the bit size of immediate TLS offsets. The valid values are 12, 24, 32, and 48. This option needs binutils 2.26 or newer, so check your toolchain first 🔧.
• -mfix-cortex-a53-835769, -mno-fix-cortex-a53-835769 — 🩹 Enables or disables the workaround for the ARM Cortex-A53 erratum number 835769. It works by inserting a NOP instruction between memory instructions and 64-bit integer multiply-accumulate instructions. This flag gets ignored if an architecture or cpu is specified on the command line that doesn't need the workaround 💜.
• -mfix-cortex-a53-843419, -mno-fix-cortex-a53-843419 — 🩹 Enables or disables the workaround for the ARM Cortex-A53 erratum number 843419. This one is applied at link time, so this flag only passes the corresponding flag to the linker 🔗. It gets ignored too if an architecture or cpu is specified on the command line that doesn't need it.
• -mlow-precision-recip-sqrt, -mno-low-precision-recip-sqrt — ⚡ Enables or disables the reciprocal square root approximation. This only does anything if -ffast-math or -funsafe-math-optimizations is used as well. When enabled, reciprocal square root results drop to about 16 bits of precision for single precision and 32 bits for double precision 📉.
• -mlow-precision-sqrt, -mno-low-precision-sqrt — ⚡ Enables or disables the square root approximation. Again, this only has an effect if -ffast-math or -funsafe-math-optimizations is used as well. Enabling it reduces square root results to about 16 bits for single precision and 32 bits for double precision. If you enable it, it also implies -mlow-precision-recip-sqrt 🔥.
• -mlow-precision-div, -mno-low-precision-div — ⚡ Enables or disables the division approximation. Same deal: it only has an effect with -ffast-math or -funsafe-math-optimizations. Division results get reduced to about 16 bits for single precision and 32 bits for double precision 🙃.
• -mtrack-speculation, -mno-track-speculation — 🕵️ Enables or disables generation of extra code to track speculative execution through conditional branches. That tracking state can then be used by the compiler when expanding calls to "__builtin_speculation_safe_copy", so it can produce a more efficient code sequence 👑.
• -moutline-atomics, -mno-outline-atomics — 🧩 Enables or disables calls to out-of-line helpers that implement atomic operations. These helpers figure out at runtime whether the LSE instructions from ARMv8.1-A can be used. If they can't, they fall back to the load/store-exclusive instructions that are present in the base ARMv8.0 ISA 🧠.

This option only applies when you're compiling for the base ARMv8.0 instruction set. If you're using a later revision, like -march=armv8.1-a or -march=armv8-a+lse, the ARMv8.1-Atomics instructions get used directly. The same goes for -mcpu= when the selected cpu supports the lse feature. This option is on by default 🌈.

• -march=name — 🏛️ Specifies the name of the target architecture and, optionally, one or more feature modifiers. The form is -march=arch{+[no]feature}*.

🌸 The Architecture Lineup 🌸

Here's the table of permissible arch values and the features each one turns on by default 💖. Architecture is in the middle, the defaults are on the end:

• armv8-a (Armv8-A) — includes by default: +fp, +simd
• armv8.1-a (Armv8.1-A) — includes by default: armv8-a, +crc, +lse, +rdma
• armv8.2-a (Armv8.2-A) — includes by default: armv8.1-a
• armv8.3-a (Armv8.3-A) — includes by default: armv8.2-a, +pauth, +fcma, +jscvt
• armv8.4-a (Armv8.4-A) — includes by default: armv8.3-a, +flagm, +fp16fml, +dotprod, +rcpc2
• armv8.5-a (Armv8.5-A) — includes by default: armv8.4-a, +sb, +ssbs, +predres, +frintts, +flagm2
• armv8.6-a (Armv8.6-A) — includes by default: armv8.5-a, +bf16, +i8mm
• armv8.7-a (Armv8.7-A) — includes by default: armv8.6-a, +wfxt, +xs
• armv8.8-a (Armv8.8-a) — includes by default: armv8.7-a, +mops
• armv8.9-a (Armv8.9-a) — includes by default: armv8.8-a
• armv9-a (Armv9-A) — includes by default: armv8.5-a, +sve, +sve2
• armv9.1-a (Armv9.1-A) — includes by default: armv9-a, +bf16, +i8mm
• armv9.2-a (Armv9.2-A) — includes by default: armv9.1-a, +wfxt, +xs
• armv9.3-a (Armv9.3-A) — includes by default: armv9.2-a, +mops
• armv9.4-a (Armv9.4-A) — includes by default: armv9.3-a, +sve2p1
• armv9.5-a (Armv9.4-A) — includes by default: armv9.4-a, cpa, +faminmax, +lut
• armv8-r (Armv8-R) — includes by default: armv8-r

The value native is available on native AArch64 GNU/Linux and tells the compiler to pick the architecture of the host system 🖥️. If the compiler can't recognise the host's architecture, this option does nothing. When you give -march=native and no other -mcpu or -mtune, GCC will pick the host CPU as the CPU to tune for, and also select the architecture features from it. In other words, -march=native gets treated as -mcpu=native 🫧.

The permissible values for feature are listed in the sub-section on aarch64-feature-modifiers,,-march and -mcpu Feature Modifiers. If you specify conflicting feature modifiers, the right-most feature is the one that gets used 👀.

GCC uses name to decide what kind of instructions it can emit when generating assembly code. If -march is specified without -mtune or -mcpu also being specified, the code is tuned to perform well across a range of target processors implementing the target architecture 🌟.

• -mtune=name — 🎯 Specifies the name of the target processor that GCC should tune the performance of the code for. The permissible values are: generic, cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73, cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a65, cortex-a65ae, cortex-a34, cortex-a78, cortex-a78ae, cortex-a78c, ares, exynos-m1, emag, falkor, oryon-1, neoverse-512tvb, neoverse-e1, neoverse-n1, neoverse-n2, neoverse-v1, neoverse-v2, grace, neoverse-v3, neoverse-v3ae, neoverse-n3, olympus, cortex-a725, cortex-x925, qdf24xx, saphira, phecda, xgene1, vulcan, octeontx, octeontx81, octeontx83, octeontx2, octeontx2t98, octeontx2t96, octeontx2t93, octeontx2f95, octeontx2f95n, octeontx2f95mm, a64fx, fujitsu-monaka, thunderx, thunderxt88, thunderxt88p1, thunderxt81, tsv110, thunderxt83, thunderx2t99, thunderx3t110, zeus, cortex-a57.cortex-a53, cortex-a72.cortex-a53, cortex-a73.cortex-a35, cortex-a73.cortex-a53, cortex-a75.cortex-a55, cortex-a76.cortex-a55, cortex-r82, cortex-r82ae, cortex-x1, cortex-x1c, cortex-x2, cortex-x3, cortex-x4, cortex-a510, cortex-a520, cortex-a520ae, cortex-a710, cortex-a715, cortex-a720, cortex-a720ae, ampere1, ampere1a, ampere1b, cobalt-100, apple-m1, apple-m2, apple-m3, and native. 💅

The values cortex-a57.cortex-a53, cortex-a72.cortex-a53, cortex-a73.cortex-a35, cortex-a73.cortex-a53, cortex-a75.cortex-a55, cortex-a76.cortex-a55, apple-m1, apple-m2, apple-m3, and gb10 tell GCC to tune for a big.LITTLE system 🐣🐘.

The value neoverse-512tvb tells GCC to tune for Neoverse cores that (a) implement SVE and (b) have a total vector bandwidth of 512 bits per cycle. In other words, it tells GCC to tune for Neoverse cores that can execute 4 128-bit Advanced SIMD arithmetic instructions a cycle, and that can execute an equivalent number of SVE arithmetic instructions per cycle (2 for 256-bit SVE, 4 for 128-bit SVE). This is more general than tuning for a specific core like Neoverse V1, but more specific than the default tuning described below 🎀.

Additionally, on native AArch64 GNU/Linux systems, the value native tunes performance to the host system. If the compiler can't recognise the processor of the host system, this option does nothing 🖥️.

Where none of -mtune=, -mcpu=, or -march= are specified, the code is tuned to perform well across a range of target processors 🌈.

This option cannot be suffixed by feature modifiers, so don't even try 🙅‍♀️.

• -mcpu=name — 🧠 Specifies the name of the target processor, optionally suffixed by one or more feature modifiers. The form is -mcpu=cpu{+[no]feature}*, where the permissible values for cpu are the same as those available for -mtune. The permissible values for feature are documented in the sub-section on aarch64-feature-modifiers,,-march and -mcpu Feature Modifiers. Conflicting feature modifiers? The right-most one wins 👑.

GCC uses name to determine what kind of instructions it can emit when generating assembly code (as if by -march), and to determine the target processor it should tune for performance (as if by -mtune). If this option is used alongside -march or -mtune, those options take precedence over the matching part of this option 💖.

Okay so the Neoverse thing is lowkey the most iconic flag ever 💅 -mcpu=neoverse-512tvb isn't one specific core, it's a whole group of Neoverse cores that (a) implement SVE and (b) have a total vector bandwidth of 512 bits a cycle 🦋 Unless you override it with -march, it makes code that can run on a Neoverse V1 core, since V1 is the first Neoverse core with both of those properties 🔥 And unless you override it with -mtune, it tunes your code the same way -mtune=neoverse-512tvb would ✨

• -moverride=string — Okay this one is for the tuning nerds 🤓 It overrides the tuning decisions the back-end makes in response to a -mtune= switch. The syntax, semantics, and accepted values for string are not guaranteed to stay the same across releases, so don't get too attached 💀

This option is only intended to be useful when developing GCC. Like, it's for the people building the compiler, bestie 🙈

• -mverbose-cost-dump — Turns on verbose cost model dumping in the debug dump files 🧚 It's here so you can debug the compiler itself, so it's giving compiler-dev energy 💜
• -mpc-relative-literal-loads, -mno-pc-relative-literal-loads — Turn PC-relative literal loads on or off 🌸 With this on, literal pools get accessed with a single instruction and get emitted after each function. The catch is that it caps the maximum size of functions at 1MB 😭 It's on by default for -mcmodel=tiny.
• -msign-return-address=scope — Picks which functions get return address signing 🔐 The valid values are none (turns signing off), non-leaf (signs functions that aren't leaf functions), and all (signs every single function). The default is none.

This option has been deprecated by -mbranch-protection, so maybe use that one instead 💅

• -mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti|gcs — Picks which branch protection features you want 👑
  • none is the default and turns off all branch protection types 🫶
  • standard turns on all the branch protection types. If a feature has extra tuning options, standard sets it to its standard level ✨
  • pac-ret[+leaf] turns on return address signing to its standard level, meaning it signs functions that save the return address to memory (non-leaf functions basically always do this) using the A-key. The optional leaf argument extends the signing to include leaf functions 🌈
  • The optional b-key argument signs the functions with the B-key instead of the A-key 🔑
  • bti turns on the branch target identification mechanism 🎯
  • gcs turns on guarded control stack compatible code generation 🛡️
• -mharden-sls=opts — Enables compiler hardening against straight line speculation (SLS) 💀 opts is a comma-separated list of the following options:
  • retbr
  • blr

-mharden-sls=all enables all SLS hardening, while -mharden-sls=none disables all of it 🙌

• -mearly-ra=scope — Decides when to turn on an early register allocation pass 🧠 This pass runs before instruction scheduling and tries to find a spill-free allocation of floating-point and vector code. It also tries to make use of strided multi-register instructions, like SME2's strided LD1 and ST1 ✨
  • all runs the pass on all functions 🫧
  • strided runs the pass on functions that have access to strided multi-register instructions 🦋
  • none disables the pass 🙃

-mearly-ra=all is the default for -O2 and above, and for -Os. -mearly-ra=none is the default otherwise.

• -mearly-ldp-fusion — Enables the copy of the AArch64 load/store pair fusion pass that runs before register allocation 🍓 It's on by default at -O and above.
• -mlate-ldp-fusion — Enables the copy of the AArch64 load/store pair fusion pass that runs after register allocation 🍓 It's on by default at -O and above too.
• -msve-vector-bits=bits — Sets how many bits are in an SVE vector register 💖 It only does anything when SVE is enabled.

GCC has two flavours of SVE code generation. There's "vector-length agnostic" output that works with any size of vector register, and "vector-length specific" output that lets GCC make assumptions about the vector length when that helps optimisation 🧚 The valid values for bits are scalable, 128, 256, 512, 1024, and 2048. scalable gives you vector-length agnostic output. Right now -msve-vector-bits=128 also makes vector-length agnostic output, but only for big-endian targets 👀 Every other value makes vector-length specific code. These values might change in future releases, so the only one you should count on for code that's portable across different hardware SVE vector lengths is scalable 😭

The default is -msve-vector-bits=scalable, which makes vector-length agnostic code 🌸

• -Wexperimental-fmv-target — Warns you about using experimental Function Multi Versioning 🚨 The Arm C Language Extension spec for FMV is still beta and can change, so any FMV usage is caveated: future behaviour changes and incompatibility are likely 💀

---

✨ -march and -mcpu Feature Modifiers ✨

Feature modifiers used with -march and -mcpu can be any of the following, and each one also has an inverse you can write as nofeature 💅

• crc — Enables the CRC extension 🔥 It's on by default for -march=armv8.1-a.
• crypto — Enables the Crypto extension 🔐 It also turns on Advanced SIMD and floating-point instructions.
• fp — Enables floating-point instructions 💖 It's on by default for all possible values of -march and -mcpu.
• simd — Enables Advanced SIMD instructions 🦋 It also turns on floating-point instructions, and it's on by default for all possible values of -march and -mcpu.
• sve — Enables Scalable Vector Extension instructions 🌊 It also turns on Advanced SIMD and floating-point instructions.
• lse — Enables Large System Extension instructions 🧚 It's on by default for -march=armv8.1-a.
• rdma — Enables Round Double Multiply Accumulate instructions ✨ It's on by default for -march=armv8.1-a.
• fp16 — Enables the FP16 extension 🍓 It also turns on floating-point instructions.
• fp16fml — Enables the FP16 fmla extension 💜 It also enables the FP16 extensions and floating-point instructions. This one is enabled by default for -march=armv8.4-a. Using it with architectures before Armv8.2-A is not supported, so don't do it 🙅‍♀️
• rcpc — Enables the RCpc extension 🌈 This turns on the use of the LDAPR instructions for load-acquire atomic semantics, and passes it along to the assembler so inline asm statements can use instructions from the RCpc extension 🫶
• dotprod — Enables the Dot Product extension 🎀 It also turns on Advanced SIMD instructions.
• aes — Enables the Armv8-a aes and pmull crypto extension 🔐 It also turns on Advanced SIMD instructions.
• sha2 — Enables the Armv8-a sha2 crypto extension 🔐 It also turns on Advanced SIMD instructions.
• sha3 — Enables the sha512 and sha3 crypto extension 🔐 It also turns on Advanced SIMD instructions. Using it with architectures before Armv8.2-A is not supported 🚫
• sm4 — Enables the sm3 and sm4 crypto extension 🔐 It also turns on Advanced SIMD instructions. Using it with architectures before Armv8.2-A is not supported 🚫
• profile — Enables the Statistical Profiling extension 📊 This only turns the extension on at the assembler level, and it does not affect code generation.
• rng — Enables the Armv8.5-a Random Number instructions 🎲 This only turns the extension on at the assembler level, and it does not affect code generation.
• memtag — Enables the Armv8.5-a Memory Tagging Extensions 🏷️ Using it with architectures before Armv8.5-A is not supported.
• sb — Enables the Armv8-a Speculation Barrier instruction 🛑 This only turns the extension on at the assembler level and does not affect code generation. It's enabled by default for -march=armv8.5-a.
• ssbs — Enables the Armv8-a Speculative Store Bypass Safe instruction 🛡️ This only turns the extension on at the assembler level and does not affect code generation. It's enabled by default for -march=armv8.5-a.
• predres — Enables the Armv8-a Execution and Data Prediction Restriction instructions 🙈 This only turns the extension on at the assembler level and does not affect code generation. It's enabled by default for -march=armv8.5-a.
• sve2 — Enables the Armv8-a Scalable Vector Extension 2 🚀 It also turns on SVE instructions.
• sve2-bitperm — Enables SVE2 bitperm instructions 🧩 It also turns on SVE2 instructions.
• sve2-sm4 — Enables SVE2 sm4 instructions 🧩 It also turns on SVE2 instructions.
• sve2-aes — Enables SVE2 aes instructions 🧩 It also turns on SVE2 instructions.
• sve2-sha3 — Enables SVE2 sha3 instructions 🧩 It also turns on SVE2 instructions.
• sve2p1 — Enables SVE2.1 instructions 🚀 It also turns on SVE2 instructions.
• tme — Enables the Transactional Memory Extension 🧵
• i8mm — Enables 8-bit Integer Matrix Multiply instructions 🔢 It also turns on Advanced SIMD and floating-point instructions. This one is enabled by default for -march=armv8.6-a. Using it with architectures before Armv8.2-A is not supported.
• f32mm — Enables 32-bit Floating point Matrix Multiply instructions 🧮 It also turns on SVE instructions. Using it with architectures before Armv8.2-A is not supported.
• f64mm — Enables 64-bit Floating point Matrix Multiply instructions 🧮 It also turns on SVE instructions. Using it with architectures before Armv8.2-A is not supported.
• bf16 — Enables brain half-precision floating-point instructions 🧠 It also turns on Advanced SIMD and floating-point instructions. This one is enabled by default for -march=armv8.6-a. Using it with architectures before Armv8.2-A is not supported.
• ls64 — Enables the 64-byte atomic load and store instructions for accelerators 🚀
• mops — Enables the instructions that speed up memory operations like "memcpy", "memmove", "memset" 💨 This one is enabled by default for -march=armv8.8-a
• flagm — Enables the Flag Manipulation instructions Extension 🏳️
• flagm2 — Enables the FlagM2 flag conversion instructions 🔁
• pauth — Enables the Pointer Authentication Extension 🔐
• cssc — turns on the Common Short Sequence Compression instructions 🗜️✨
• sme — flips on the Scalable Matrix Extension 🧮💖. Bestie, this one only works if sve2 is also enabled 🙈
• sme-i16i64 — enables the FEAT_SME_I16I64 extension to SME 🌸. It also turns on SME instructions.
• sme-f64f64 — enables the FEAT_SME_F64F64 extension to SME 🦋. It also turns on SME instructions.
• sme2 — enables the Scalable Matrix Extension 2 👑. It also turns on SME instructions.
• sme-b16b16 — enables the FEAT_SME_B16B16 extension to SME 💜. It also turns on SME2 and SVE_B16B16 instructions.
• sme-f16f16 — enables the FEAT_SME_F16F16 extension to SME 🧚. It also turns on SME2 instructions.
• sme2p1 — enables the Scalable Matrix Extension version 2.1 🔥. It also turns on SME2 instructions.
• fcma — enables the complex number SIMD extensions 🌈
• jscvt — enables the fjcvtzs JavaScript conversion instruction 🍓
• frintts — enables floating-point round to integral value instructions ⭐
• wfxt — enables the wfet and wfit instructions 🫶
• xs — enables the XS memory attribute extension 🎀
• lse128 — enables the LSE128 128-bit atomic instructions extension 💅. It also turns on LSE instructions.
• d128 — enables support for 128-bit system register read/write instructions ✨. It also turns on the LSE128 extension.
• gcs — enables support for the Armv9.4-a Guarded Control Stack extension 🛡️🌸
• the — enables support for the Armv8.9-a/9.4-a translation hardening extension 🔒
• rcpc2 — enables the RCpc2 extension 💜
• rcpc3 — enables the RCpc3 (Release Consistency) extension 🦋
• fp8 — enables the fp8 (8-bit floating point) extension 🫧
• fp8fma — enables the fp8 (8-bit floating point) multiply accumulate extension 💖
• ssve-fp8fma — enables the fp8 (8-bit floating point) multiply accumulate extension, but in streaming mode 🌊
• fp8dot4 — enables the fp8 (8-bit floating point) to single-precision 4-way dot product extension 🔥
• ssve-fp8dot4 — enables that same fp8 to single-precision 4-way dot product extension, but in streaming mode 🌟
• fp8dot2 — enables the fp8 (8-bit floating point) to half-precision 2-way dot product extension 🍬
• ssve-fp8dot2 — enables that same fp8 to half-precision 2-way dot product extension, but in streaming mode 🎀
• faminmax — enables the Floating Point Absolute Maximum/Minimum extension 📐
• lut — enables the Lookup Table extension 🧾
• cpa — enables the Checked Pointer Arithmetic instructions 🛠️
• sve-b16b16 — enables the SVE non-widening brain floating-point ("bf16") extension 🧠. This only has an effect when sve2 or sme2 are also enabled.

Feature crypto implies aes, sha2, and simd, which implies fp. Conversely, nofp implies nosimd, which implies nocrypto, noaes and nosha2. Main character energy, but make it a chain 🔗💅

---

🐝 Adapteva Epiphany Options

These -m options are defined for Adapteva Epiphany 🐝🌸:

• -mhalf-reg-file — okay so this one stops the compiler from allocating any register in the range r32...r63 🙈. That lets your code run on hardware variants that don't have those registers.
• -mprefer-short-insn-regs — the compiler will prefer registers that allow short instruction generation ✨. Heads up, this can bump the instruction count, so overall code size might go down or up 🤷‍♀️.
• -mbranch-cost=num — sets the cost of branches to roughly num "simple" instructions 💅. This cost is only a heuristic, so it's not guaranteed to give consistent results across releases.
• -mcmove — enables the generation of conditional moves 🦋
• -mnops=num — emits num NOPs before every other generated instruction 😭
• -mno-soft-cmpsf — for single-precision floating-point comparisons, the compiler emits an fsub instruction and tests the flags 🏃‍♀️. This is faster than a software comparison, but it can get incorrect results with NaNs, or when two different small numbers are compared and their difference is calculated as zero 💀. The default is -msoft-cmpsf, which uses slower but IEEE-compliant software comparisons 🫶.
• -mstack-offset=num — sets the offset between the top of the stack and the stack pointer 📚. E.g., a value of 8 means the eight bytes in the range sp+0...sp+7 can be used by leaf functions without stack allocation. Values other than 8 or 16 are untested and unlikely to work 🙃. Also, this option changes the ABI, so compiling a program with a different stack offset than the libraries were compiled with generally does not work.

Heads up, bestie: this option changes the ABI! If you just want to see whether a different stack offset gives better code, this is a fine place to experiment 🧪. But to actually build working programs with a different stack offset, the recommended move is to configure the toolchain with the appropriate --with-stack-offset=num option 🚨.

• -mno-round-nearest — makes the scheduler assume the rounding mode has been set to truncating 🌀. The default is -mround-nearest.
• -mlong-calls — if an attribute doesn't say otherwise, this assumes all calls might be beyond the offset range of the b / bl instructions 📞. So it loads the function address into a register before performing a (otherwise direct) call. This is the default 👑.
• -mshort-calls — if an attribute doesn't say otherwise, this assumes all direct calls are in range of the b / bl instructions, so those instructions get used for direct calls ⚡. The default is -mlong-calls.
• -msmall16 — assumes addresses can be loaded as 16-bit unsigned values 🍓. This does not apply to function addresses where -mlong-calls semantics are in effect.
• -mfp-mode=mode — sets the prevailing mode of the floating-point unit 🎛️. This decides the floating-point mode that is provided and expected at function call and return time. Matching this to the mode you mostly need at function start can make your programs smaller and faster by avoiding unnecessary mode switches 🚀.

mode can be set to one of the following values:

• caller — any mode at function entry is valid, and it gets retained or restored when the function returns and when it calls other functions 🫶. This is handy for compiling libraries or other compilation units you want to drop into programs with different prevailing FPU modes. The convenience of a single object file can outweigh the extra mode-switching overhead compared with a more specific choice of prevailing FPU mode.
• truncate — the mode used for floating-point calculations with truncating (round towards zero) rounding mode 🧊. That includes conversion from floating point to integer.
• round-nearest — the mode used for floating-point calculations with round-to-nearest-or-even rounding mode 🎯
• int — the mode used to perform integer calculations in the FPU, e.g. integer multiply, or integer multiply-and-accumulate 🔢

The default is -mfp-mode=caller 💅

• -mno-split-lohi, -mno-postinc, -mno-postmodify — code generation tweaks that disable, respectively, splitting of 32-bit loads, generation of post-increment addresses, and generation of post-modify addresses 🧩. The defaults are msplit-lohi, -mpost-inc, and -mpost-modify.
• -mnovect-double — changes the preferred SIMD mode to SImode 🎀. The default is -mvect-double, which uses DImode as the preferred SIMD mode.
• -max-vect-align=num — the maximum alignment for SIMD vector mode types 📏. num may be 4 or 8, and the default is 8. Note that this is an ABI change, even though many library function interfaces are unaffected if they don't use SIMD vector modes in places that affect the size and/or alignment of relevant types 🙈.
• -msplit-vecmove-early — splits vector moves into single word moves before reload 🪄. In theory this can give better register allocation, but so far the reverse seems to be the general case 😭.
• -m1reg-reg — specifies a register to hold the constant -1, which makes loading small negative constants and certain bitmasks faster ⚡. Allowable values for reg are r43 and r63, which specify use of that register as a fixed register, and none, which means no register is used for this purpose. The default is -m1reg-none 💖.

---

🎮 AMD GCN Options

These options are defined specifically for the AMD GCN port 🎮🌈

• -march=gpu, -mtune=gpu — sets the architecture type or tuning for gpu 🧠. Supported values for gpu are:
  • gfx900 — compiles for GCN5 Vega 10 devices (gfx900) 🌟
  • gfx902 — compiles for GCN5 Vega gfx902 devices. (Experimental) 🧪
  • gfx904 — compiles for GCN5 Vega gfx904 devices. (Experimental) 🧪
  • gfx906 — compiles for GCN5 Vega 20 devices (gfx906) 💜
  • gfx908 — compiles for CDNA1 Instinct MI100 series devices (gfx908) 🔥
  • gfx909 — compiles for GCN5 Vega gfx909 devices. (Experimental) 🧪
  • gfx90a — compiles for CDNA2 Instinct MI200 series devices (gfx90a) 👑
  • gfx90c — compiles for GCN5 Vega 7 devices (gfx90c) 🍓
  • gfx9-generic — compiles generic code for Vega devices, executable on the following subset of GFX9 devices: gfx900, gfx902, gfx904, gfx906, gfx909 and gfx90c. (Experimental) 🌸
  • gfx1030 — compiles for RDNA2 gfx1030 devices (GFX10 series) 🦋
  • gfx1031 — compiles for RDNA2 gfx1031 devices (GFX10 series). (Experimental) 🧪
  • gfx1032 — compiles for RDNA2 gfx1032 devices (GFX10 series). (Experimental) 🧪
  • gfx1033 — compiles for RDNA2 gfx1033 devices (GFX10 series). (Experimental) 🧪
  • gfx1034 — compiles for RDNA2 gfx1034 devices (GFX10 series). (Experimental) 🧪
  • gfx1035 — compiles for RDNA2 gfx1035 devices (GFX10 series). (Experimental) 🧪
  • gfx1036 — compiles for RDNA2 gfx1036 devices (GFX10 series) 💖
  • gfx10-3-generic — compiles generic code for GFX10-3 devices, executable on gfx1030, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, and gfx1036. (Experimental) ✨
  • gfx1100 — compiles for RDNA3 gfx1100 devices (GFX11 series) 🌊
  • gfx1101 — compiles for RDNA3 gfx1101 devices (GFX11 series). (Experimental) 🧪
  • gfx1102 — compiles for RDNA3 gfx1102 devices (GFX11 series). (Experimental) 🧪
  • gfx1103 — compiles for RDNA3 gfx1103 devices (GFX11 series) 🫧
• gfx1150 — okay so this one's for RDNA3 gfx1150 devices (GFX11 series) 💜 (Experimental) 🧪
• gfx1151 — same energy, but for RDNA3 gfx1151 devices (GFX11 series) ✨ (Experimental)
• gfx1152 — RDNA3 gfx1152 devices (GFX11 series) get the spotlight here 🦋 (Experimental)
• gfx1153 — and RDNA3 gfx1153 devices (GFX11 series) round out the squad 🌸 (Experimental)
• gfx11-generic — this is the generic one, bestie 👑 It compiles generic code for GFX11 devices, and that code can run on gfx1100, gfx1101, gfx1102, gfx1103, gfx1150, gfx1151, gfx1152, and gfx1153. Very inclusive 🫶 (Experimental)
• -msram-ecc=on, -msram-ecc=off, -msram-ecc=any — these pick which SRAM-ECC mode your binaries are built for. on means the device has SRAM-ECC enabled, off means it's disabled, and any means either mode works 🌈 Some devices let you flip this per-process, but the compiled code has to match the device mode, no exceptions 🙈 The default is any, as long as the device actually supports it ✨
• -mstack-size=bytes — this sets how many bytes of stack space each GPU thread (wave-front) gets 🧚 Be careful though, because there can be a lot of threads and not a ton of memory available 😭 The stack size can also affect run-time performance. The default is 32KB when you're using OpenACC or OpenMP, and 1MB otherwise 💅
• -mxnack=on, -mxnack=off, -mxnack=any — this one's about the XNACK feature 🍓 Your binaries can be built for XNACK enabled, XNACK disabled, or either mode. Some devices always need XNACK, and some let the user decide. The compiled code has to match the device mode too. The default is -mxnack=any on devices that support Unified Shared Memory, and -mxnack=no everywhere else 💖

---

✨ ARC Options ✨

Okay bestie, this next batch controls the architecture variant your code gets compiled for 🎀

• -mbarrel-shifter — generates instructions that the barrel shifter supports 🔥 This is the default unless -mcpu=ARC601 or -mcpu=ARCEM is in effect.
• -mjli-always — forces function calls to use the jli_s instruction 💜 This option is only valid for the ARCv2 architecture.
• -mcpu=cpu — this is the big one 👑 It sets the architecture type, register usage, and instruction scheduling parameters for cpu. There are also shortcut alias options around for backward compatibility and convenience 🫶 These are the supported values for cpu:
  • arc600 — compiles for ARC600. Aliases: -mA6, -mARC600 🌸
  • arc601 — compiles for ARC601. Alias: -mARC601 🦋
  • arc700 — compiles for ARC700. Aliases: -mA7, -mARC700. This is the default when you configure with --with-cpu=arc700 ✨
  • arcem — compiles for ARC EM 🧚
  • archs — compiles for ARC HS 💅
  • em — compiles for an ARC EM CPU with no hardware extensions 🍓
  • em4 — compiles for an ARC EM4 CPU 🌈
  • em4_dmips — compiles for an ARC EM4 DMIPS CPU 💖
  • em4_fpus — compiles for an ARC EM4 DMIPS CPU with the single-precision floating-point extension 🔥
  • em4_fpuda — compiles for an ARC EM4 DMIPS CPU with single-precision floating-point and double assist instructions 🎀
  • hs — compiles for an ARC HS CPU with no hardware extensions except the atomic instructions 🙈
  • hs34 — compiles for an ARC HS34 CPU ⭐
  • hs38 — compiles for an ARC HS38 CPU 🦋
  • hs38_linux — compiles for an ARC HS38 CPU with all hardware extensions turned on 👑
  • hs4x — compiles for an ARC HS4x CPU 🌸
  • hs4xd — compiles for an ARC HS4xD CPU ✨
  • hs4x_rel31 — compiles for an ARC HS4x CPU release 3.10a 💜
  • arc600_norm — compiles for an ARC 600 CPU with "norm" instructions enabled 🫶
  • arc600_mul32x16 — compiles for an ARC 600 CPU with "norm" and 32x16-bit multiply instructions enabled 🔥
  • arc600_mul64 — compiles for an ARC 600 CPU with "norm" and "mul64"-family instructions enabled 🌈
  • arc601_norm — compiles for an ARC 601 CPU with "norm" instructions enabled 🍓
  • arc601_mul32x16 — compiles for an ARC 601 CPU with "norm" and 32x16-bit multiply instructions enabled 💖
  • arc601_mul64 — compiles for an ARC 601 CPU with "norm" and "mul64"-family instructions enabled 🎀
  • nps400 — compiles for ARC 700 on the NPS400 chip 🧚
  • em_mini — compiles for the ARC EM minimalist configuration, which features a reduced register set 🙈
• -mdpfp, -mdpfp-compact — generates double-precision FPX instructions, tuned for the compact implementation 💅
• -mdpfp-fast — generates double-precision FPX instructions, tuned for the fast implementation ⚡
• -mno-dpfp-lrsr — disables "lr" and "sr" instructions from using FPX extension aux registers 🙅‍♀️
• -mea — generates extended arithmetic instructions 🧮 Right now only "divaw", "adds", "subs", and "sat16" are supported. This is only valid for -mcpu=ARC700 🔥
• -mno-mpy — doesn't generate "mpy"-family instructions for ARC700 🥀 This option is deprecated, so maybe don't build your whole vibe around it 💀
• -mmul32x16 — generates 32x16-bit multiply and multiply-accumulate instructions ✨
• -mmul64 — generates "mul64" and "mulu64" instructions 🦋 This is only valid for -mcpu=ARC600.
• -mnorm — generates "norm" instructions 🌸 This is the default if -mcpu=ARC700 is in effect.
• -mspfp, -mspfp-compact — generates single-precision FPX instructions, tuned for the compact implementation 💜
• -mspfp-fast — generates single-precision FPX instructions, tuned for the fast implementation 🔥
• -msimd — enables ARC SIMD instructions through target-specific builtins 🧚 This is only valid for -mcpu=ARC700.
• -msoft-float — this one is basically a no-op 🙃 It's only here for compatibility purposes. Software floating-point code is emitted by default, and that default can be overridden by the FPX options: -mspfp, -mspfp-compact, or -mspfp-fast for single precision, and -mdpfp, -mdpfp-compact, or -mdpfp-fast for double precision 🫶
• -mswap — generates "swap" instructions 🌈
• -matomic — enables the locked load/store conditional extension so it can power the atomic memory built-in functions 🔐 This is not available for ARC 6xx or ARC EM cores 🙅‍♀️
• -mdiv-rem — enables "div" and "rem" instructions for ARCv2 cores ➗
• -mcode-density — enables code density instructions for ARC EM 🍓 This option is on by default for ARC HS.
• -mll64 — enables double load/store operations for ARC HS cores 💖
• -mtp-regno=regno — specifies the thread pointer register number 🧵
• -mmpy-option=multo — this picks a multiplier design option for ARCv2 code 🔢 You can specify it with either a string or a numeric value for multo. wlh1 is the default. These are the recognized values:
  • 0 or none — no multiplier available 🥲
  • 1 or w — a 16x16 multiplier, fully pipelined 🌸 These instructions get enabled: "mpyw" and "mpyuw".
  • 2 or wlh1 — a 32x32 multiplier, fully pipelined (1 stage) ✨ These instructions are additionally enabled: "mpy", "mpyu", "mpym", "mpymu", and "mpy_s".
  • 3 or wlh2 — a 32x32 multiplier, fully pipelined (2 stages) 💜 These instructions are additionally enabled: "mpy", "mpyu", "mpym", "mpymu", and "mpy_s".
  • 4 or wlh3 — two 16x16 multipliers, blocking, sequential 🦋 These instructions are additionally enabled: "mpy", "mpyu", "mpym", "mpymu", and "mpy_s".
  • 5 or wlh4 — one 16x16 multiplier, blocking, sequential 🧚 These instructions are additionally enabled: "mpy", "mpyu", "mpym", "mpymu", and "mpy_s".
  • 6 or wlh5 — one 32x4 multiplier, blocking, sequential 🌈 These instructions are additionally enabled: "mpy", "mpyu", "mpym", "mpymu", and "mpy_s".
  • 7 or plus_dmpy — ARC HS SIMD support 🔥
  • 8 or plus_macd — ARC HS SIMD support 💅
  • 9 or plus_qmacw — ARC HS SIMD support 👑

Heads up: this option is only available for ARCv2 cores 🙈

• -mfpu=fpu — turns on support for specific floating-point hardware extensions on ARCv2 cores 🎀 These are the supported values for fpu:
  • fpus — enables single-precision floating-point hardware extensions 🌸
  • fpud — enables double-precision floating-point hardware extensions 💖 The single-precision floating-point extension gets turned on too. Not available for ARC EM 🙅‍♀️
  • fpuda — enables double-precision floating-point hardware extensions using double-precision assist instructions ✨ The single-precision floating-point extension is also enabled. This is only available for ARC EM 🧚
  • fpuda_div — enables double-precision floating-point hardware extensions using double-precision assist instructions 🧮 The single-precision floating-point, square-root, and divide extensions are also enabled. This is only available for ARC EM 🔥
  • fpuda_fma — enables double-precision floating-point hardware extensions using double-precision assist instructions 💜 The single-precision floating-point and fused multiply and add hardware extensions are also enabled. This is only available for ARC EM 🦋
  • fpuda_all — enables double-precision floating-point hardware extensions using double-precision assist instructions 🌈 All single-precision floating-point hardware extensions are also enabled. This is only available for ARC EM 👑
  • fpus_div — enables single-precision floating-point, square-root, and divide hardware extensions ➗
  • fpud_div — enables double-precision floating-point, square-root, and divide hardware extensions 🍓 This option includes fpus_div. Not available for ARC EM 🙅‍♀️
  • fpus_fma — enables single-precision floating-point and fused multiply and add hardware extensions 🌸
  • fpud_fma — enables double-precision floating-point and fused multiply and add hardware extensions 💖 This option includes fpus_fma. Not available for ARC EM 🙅‍♀️
  • fpus_all — enables all single-precision floating-point hardware extensions ✨
  • fpud_all — enables all single- and double-precision floating-point hardware extensions 🎀 Not available for ARC EM 🙅‍♀️

Okay so this batch is all about interrupts and registers, and honestly the chip is doing a lot of babysitting here 🫶✨

• -mirq-ctrl-saved=register-range, blink, lp_count: this tells the processor which general-purpose registers to auto-save and restore on interrupt entry and exit 💅 The register-range is two registers joined by a dash. It always starts at r0, and the upper limit is the fp register. blink and lp_count are optional. Only valid for ARC EM and ARC HS cores 🔥
• -mrgf-banked-regs=number: sets how many registers get copied into the second register bank when a fast interrupt hits 🦋 Fast interrupts are the ones at the highest priority level, P0. They only save the PC and STATUS32 registers so they can skip memory transactions on entry and exit, which is so efficient 😭 Use this when you're doing fast interrupts on an ARC V2 family processor. Permitted values are 4, 8, 16, and 32.
• -mlpc-width=width: specifies the width of the "lp_count" register 🧚 Valid widths are 8, 16, 20, 24, 28, and 32 bits, and the default is fixed at 32 bits. If the width is less than 32, the compiler won't transform your loops to use the zero-delay loop mechanism unless it knows the "lp_count" register can hold the loop counter value. Depending on the width, the compiler and run-time library might still use the loop mechanism for various other needs 🌸 This option also defines the macro "__ARC_LPC_WIDTH__" with the value of width.
• -mrf16: tells the compiler to generate code for a 16-entry register file 💜 It also defines the "__ARC_RF16__" preprocessor macro.
• -mbranch-index: enables the use of bi or bih instructions to build jump tables 🍓

🧚 Passed through to the assembler (and defining macros)

These options get handed down to the assembler, and they also define preprocessor macro symbols, so you can check for them in your code 💖

• -mdsp-packa: enables the DSP Pack A extensions in the assembler 🎀 It also sets the "__Xdsp_packa" preprocessor symbol. This option is deprecated 💀
• -mdvbf: enables the dual Viterbi butterfly extension in the assembler 🦋 It also sets "__Xdvbf". This option is deprecated.
• -mlock: enables the locked load/store conditional extension in the assembler 🔒 It also sets "__Xlock".
• -mmac-d16: passed down to the assembler, and sets "__Xxmac_d16". This option is deprecated.
• -mmac-24: passed down to the assembler, and sets "__Xxmac_24". This option is deprecated.
• -mrtsc: enables the 64-bit time-stamp counter extension instruction in the assembler ⏱️ It also sets "__Xrtsc". This option is deprecated.
• -mswape: enables the swap byte ordering extension instruction in the assembler 🌈 It also sets "__Xswape".
• -mtelephony: enables dual- and single-operand instructions for telephony in the assembler 📞 It also sets "__Xtelephony". This option is deprecated.
• -mxy: enables the XY memory extension in the assembler ✨ It also sets "__Xxy".

🎀 Controlling how assembly gets annotated

The following options control how the assembly code is annotated 📝

• -misize: annotates assembler instructions with estimated addresses 🙈
• -mannotate-align: does nothing, it's just kept around for backward compatibility 🫠

🔗 Passed through to the linker

• -marclinux: passed through to the linker to specify use of the "arclinux" emulation 🌸 This one is turned on by default in toolchains built for the "arc-linux-uclibc" and "arceb-linux-uclibc" targets when profiling is not requested.
• -marclinux_prof: passed through to the linker to specify use of the "arclinux_prof" emulation 📈 This one is turned on by default in toolchains built for the "arc-linux-uclibc" and "arceb-linux-uclibc" targets when profiling is requested.

👑 Controlling the semantics of generated code

• -mlong-calls: generates calls as register indirect calls, which gives you access to the full 32-bit address range 🚀
• -mmedium-calls: doesn't use anything less than a 25-bit addressing range for calls 💫 That's the offset available for an unconditional branch-and-link instruction. Conditional execution of function calls gets suppressed so the 25-bit range can be used, instead of the 21-bit range you'd get with conditional branch-and-link. This is the default for toolchains built for the "arc-linux-uclibc" and "arceb-linux-uclibc" targets.
• -G num: puts definitions of externally-visible data in a small data section, as long as that data is no bigger than num bytes 🧸 The default value of num is 4 for any ARC configuration, or 8 when you have double load/store operations.
• -mno-sdata: stops sdata references from being generated 🙅‍♀️ This is the default for toolchains built for the "arc-linux-uclibc" and "arceb-linux-uclibc" targets.
• -mvolatile-cache: uses ordinarily cached memory accesses for volatile references 💾 This is the default.
• -mno-volatile-cache: enables cache bypass for volatile references 🏃‍♀️

💅 Fine-tuning code generation

The following options fine-tune code generation, so they're kind of the glam squad 💖

• -malign-call: does nothing, preserved for backward compatibility 🫶
• -mauto-modify-reg: enables the use of pre/post modify with register displacement 🪄
• -mbbit-peephole: does nothing, preserved for backward compatibility 🫠
• -mno-brcc: disables a target-specific pass in arc_reorg that generates compare-and-branch ("brcc") instructions 🙃 It has no effect on the generation of these instructions when they're driven by the combiner pass.
• -mcase-vector-pcrel: uses PC-relative switch case tables to enable case table shortening ✂️ This is the default for -Os.
• -mcompact-casesi: enables the compact "casesi" pattern 🗂️ This is the default for -Os, and it's only available for ARCv1 cores. This option is deprecated 💀
• -mno-cond-exec: disables the ARCompact-specific pass that generates conditional execution instructions 🙅‍♀️

Okay real talk about why this one exists 🧠 Delay slot scheduling and the interactions between operand numbers, literal sizes, instruction lengths, and conditional execution support mean the target-independent conditional execution pass is often lacking. So the ARC port keeps a special pass around that hunts for more conditional execution opportunities after register allocation, branch shortening, and delay slot scheduling are done. This pass generally, but not always, improves performance and code size, at the cost of extra compilation time, which is why there's an option to switch it off. If you're having a problem with call instructions exceeding their allowable offset range because they got conditionalized, you should consider using -mmedium-calls instead 😭

• -mearly-cbranchsi: enables pre-reload use of the "cbranchsi" pattern ⏪
• -mexpand-adddi: expands "adddi3" and "subdi3" at RTL generation time into "add.f", "adc" etc. 🧮 This option is deprecated.
• -mindexed-loads: enables the use of indexed loads 📦 Heads up, this can be problematic, because some optimizers then assume indexed stores exist, and they don't in this case.
• -mlra: does nothing, preserved for backward compatibility 🫠
• -mlra-priority-none: doesn't indicate any priority for target registers 🙈
• -mlra-priority-compact: indicates target register priority for r0..r3 / r12..r15 🎯
• -mlra-priority-noncompact: reduces target register priority for r0..r3 / r12..r15 📉
• -mmillicode: when optimizing for size (using -Os), prologues and epilogues that have to save or restore a large number of registers often get shortened by calling a special function in libgcc. That's called a millicode call 🧩 Since these calls can cause performance issues, and/or linking issues when you link in a nonstandard way, this option lets you turn millicode call generation on or off 🔁
• -mcode-density-frame: lets the compiler emit "enter" and "leave" instructions 🚪 These are only valid for CPUs with the code-density feature.
• -mmixed-code: does nothing, preserved for backward compatibility 🫠
• -mq-class: this option is deprecated 💀 It enables q instruction alternatives. This is the default for -Os.
• -mRcq: does nothing, preserved for backward compatibility 🫠
• -mRcw: does nothing, preserved for backward compatibility 🫠
• -msize-level=level: fine-tunes size optimization with regards to instruction lengths and alignment 📏 The recognized values for level are:
  • 0: no size optimization. This level is deprecated and treated like 1.
  • 1: short instructions are used opportunistically ✨
  • 2: in addition, alignment of loops and of code after barriers gets dropped 🌀
  • 3: in addition, optional data alignment gets dropped, and the Os option is enabled 🔥

This defaults to 3 when -Os is in effect. Otherwise, the behavior when this isn't set is equivalent to level 1.

• -mtune=cpu: sets instruction scheduling parameters for cpu, overriding anything implied by -mcpu= 🎛️

Supported values for cpu are:

• ARC600: tunes for the ARC600 CPU 🧁
• ARC601: tunes for the ARC601 CPU 🧁
• ARC700: tunes for the ARC700 CPU with the standard multiplier block 💪
• ARC700-xmac: tunes for the ARC700 CPU with the XMAC block ⚡
• ARC725D: tunes for the ARC725D CPU 🌷
• ARC750D: tunes for the ARC750D CPU 🌷
• core3: tunes for the ARCv2 core3 type CPU. This option enables usage of the "dbnz" instruction 🧠
• release31a: tunes for ARC4x release 3.10a 🎉

• -mmultcost=num: sets the cost to assume for a multiply instruction, with 4 being equal to a normal instruction 🧮
• -munalign-prob-threshold=probability: does nothing, preserved for backward compatibility 🫠

---

🪦 Deprecated, but still here for backward compatibility

The following options are kept around for backward compatibility, but they're now deprecated and will be removed in a future release. So don't build your whole life around them 🥹

• -margonaut: obsolete FPX 🕰️
• -mbig-endian, -EB: compiles code for big-endian targets 🌍 Using these options is now deprecated. Big-endian code is supported by configuring GCC to build the "arceb-elf32" and "arceb-linux-uclibc" targets, and for those, big endian is the default 💜

Okay so bestie, we're picking up right where the ARC deprecated list leaves off 💅✨

• -mlittle-endian, -EL — Okay so these tell GCC to build for little-endian targets 🫶 but they're now deprecated 😭 Little-endian is already handled by configuring GCC to build the arc-elf32 and arc-linux-uclibc targets, and little endian is the default for those 🌸
• -mbarrel_shifter — Replaced by -mbarrel-shifter 🔁
• -mdpfp_compact — Replaced by -mdpfp-compact 🔁
• -mdpfp_fast — Replaced by -mdpfp-fast 🔁
• -mdsp_packa — Replaced by -mdsp-packa 🔁
• -mEA — Replaced by -mea 🔁
• -mmac_24 — Replaced by -mmac-24 🔁
• -mmac_d16 — Replaced by -mmac-d16 🔁
• -mspfp_compact — Replaced by -mspfp-compact 🔁
• -mspfp_fast — Replaced by -mspfp-fast 🔁
• -mtune=cpu — The values arc600, arc601, arc700 and arc700-xmac for cpu are replaced by ARC600, ARC601, ARC700 and ARC700-xmac respectively 💖
• -multcost=num — Replaced by -mmultcost 🔁

---

🌈 ARM Options 🌈

These -m options are defined for the ARM port, so if you're on ARM, this is your moment 🦋

• -mabi=name — Generate code for the specified ABI 🎀 The permissible values are apcs-gnu, atpcs, aapcs, aapcs-linux and iwmmxt
• -mapcs-frame — Generate a stack frame that follows the ARM Procedure Call Standard for all functions 🧚 even when it isn't strictly needed for the code to run correctly. If you pair this with -fomit-frame-pointer, stack frames won't be generated for leaf functions. The default is -mno-apcs-frame, and this option is deprecated 💀
• -mapcs — A synonym for -mapcs-frame, and it's also deprecated 🙈
• -mthumb-interwork — Generate code that supports calling between the ARM and Thumb instruction sets 🔥 Without this option, on pre-v5 architectures, the two instruction sets can't be reliably used inside one program 😭 The default is -mno-thumb-interwork, because slightly larger code gets generated when -mthumb-interwork is specified. In AAPCS configurations this option is meaningless 💅
• -mno-sched-prolog — Stops the reordering of instructions in the function prologue, and also stops those instructions from being merged with the instructions in the function's body ✨ This means every function starts with a recognizable set of instructions (or one from a small set of different prologues), so you can use that info to find where functions start inside an executable chunk of code 🔍 The default is -msched-prolog
• -mfloat-abi=name — Picks which floating-point ABI to use 💜 The permissible values are soft, softfp and hard
  • soft makes GCC generate output with library calls for floating-point operations 📚
  • softfp lets the code use hardware floating-point instructions, but still uses the soft-float calling conventions 🫶
  • hard allows floating-point instructions and uses FPU-specific calling conventions ⚡

The default depends on the specific target configuration. Heads up though, bestie: the hard-float and soft-float ABIs are not link-compatible 😭 You have to compile your entire program with the same ABI and link it with a compatible set of libraries 🙏

• -mgeneral-regs-only — Generate code that only uses the general-purpose registers 🌸 This stops the compiler from using floating-point and Advanced SIMD registers, but it won't put any restrictions on the assembler 🎀
• -mlittle-endian — Generate code for a processor running in little-endian mode 💖 This is the default for all standard configurations 👑
• -mbig-endian — Generate code for a processor running in big-endian mode 🧿 The default is to compile for a little-endian processor, so you have to ask for this one explicitly 🙌
• -mbe8, -mbe32 — When linking a big-endian image, pick between the BE8 and BE32 formats 🍓 These have no effect on little-endian images and get ignored there 🙈 The default depends on the selected target architecture: for ARMv6 and later it's BE8, and for older architectures it's BE32. ARM has deprecated the BE32 format 💀

✨ -march=name[+extension...] ✨

This picks the name of the target ARM architecture 🦋 GCC uses this name to figure out what kinds of instructions it's allowed to emit when generating assembly code. You can use this option together with -mcpu=, or instead of it 💅

The permissible names are armv4t, armv5t, armv5te, armv6, armv6j, armv6k, armv6kz, armv6t2, armv6z, armv6zk, armv7, armv7-a, armv7ve, armv8-a, armv8.1-a, armv8.2-a, armv8.3-a, armv8.4-a, armv8.5-a, armv8.6-a, armv9-a, armv7-r, armv8-r, armv6-m, armv6s-m, armv7-m, armv7e-m, armv8-m.base, armv8-m.main, armv8.1-m.main, iwmmxt and iwmmxt2 🌈

Also, these architectures don't support the Thumb execution state, so they're recognized but support is deprecated 😭 That's just armv4 🙈

Lots of the architectures support extensions, which you add by appending +extension to the architecture name 🧚 Extension options are processed in order and their capabilities stack up. An extension will also turn on any base extensions it depends on. For example, +crypto will always enable +simd 🔥 The exception to the stacking is extensions prefixed with +no...: those disable the option they name, plus any other extensions that depend on it ✋

For example, -march=armv7-a+simd+nofp+vfpv4 is equivalent to writing -march=armv7-a+vfpv4, since +simd gets totally disabled by the +nofp that comes after it 💀

Most extension names are generic, but what they actually do depends on the architecture you apply them to 🦋 For example, +simd works on both armv7-a and armv8-a, but it turns on the original ARMv7-A Advanced SIMD (Neon) extensions for armv7-a, and the ARMv8-A variant for armv8-a 🫶

Here's the table of supported extensions for each architecture, in list form bestie 💖 Architectures not mentioned don't support any extensions.

🌸 armv5te, armv6, armv6j, armv6k, armv6kz, armv6t2, armv6z, armv6zk 🌸

• +fp — The VFPv2 floating-point instructions 🎀 The extension +vfpv2 can be used as an alias for this one
• +nofp — Disables the floating-point instructions 🙅‍♀️

🧚 armv7 🧚

The common subset of the ARMv7-A, ARMv7-R and ARMv7-M architectures ✨

• +fp — The VFPv3 floating-point instructions, with 16 double-precision registers 💜 The extension +vfpv3-d16 can be used as an alias for this one. Heads up: floating-point isn't supported by the base ARMv7-M architecture, but it is compatible with both ARMv7-A and ARMv7-R 🙈
• +nofp — Disables the floating-point instructions 🙅‍♀️

👑 armv7-a 👑

• +mp — The multiprocessing extension 🫶
• +sec — The security extension 🔐
• +fp — The VFPv3 floating-point instructions, with 16 double-precision registers 💖 The extension +vfpv3-d16 can be used as an alias for this one
• +simd — The Advanced SIMD (Neon) v1 and the VFPv3 floating-point instructions 🔥 The extensions +neon and +neon-vfpv3 can be used as aliases for this one
• +vfpv3 — The VFPv3 floating-point instructions, with 32 double-precision registers 🌈
• +vfpv3-d16-fp16 — The VFPv3 floating-point instructions, with 16 double-precision registers and the half-precision floating-point conversion operations 🍓
• +vfpv3-fp16 — The VFPv3 floating-point instructions, with 32 double-precision registers and the half-precision floating-point conversion operations 🍓
• +vfpv4-d16 — The VFPv4 floating-point instructions, with 16 double-precision registers 🦋
• +vfpv4 — The VFPv4 floating-point instructions, with 32 double-precision registers 🦋
• +neon-fp16 — The Advanced SIMD (Neon) v1 and the VFPv3 floating-point instructions, with the half-precision floating-point conversion operations ✨
• +neon-vfpv4 — The Advanced SIMD (Neon) v2 and the VFPv4 floating-point instructions 💅
• +nosimd — Disables the Advanced SIMD instructions (this does not disable floating point) 🙅‍♀️
• +nofp — Disables the floating-point and Advanced SIMD instructions 💀

🦋 armv7ve 🦋

The extended version of the ARMv7-A architecture, with support for virtualization 🧿

• +fp — The VFPv4 floating-point instructions, with 16 double-precision registers 💜 The extension +vfpv4-d16 can be used as an alias for this one
• +simd — The Advanced SIMD (Neon) v2 and the VFPv4 floating-point instructions 🔥 The extension +neon-vfpv4 can be used as an alias for this one
• +vfpv3-d16 — The VFPv3 floating-point instructions, with 16 double-precision registers 🌸
• +vfpv3 — The VFPv3 floating-point instructions, with 32 double-precision registers 🌸
• +vfpv3-d16-fp16 — The VFPv3 floating-point instructions, with 16 double-precision registers and the half-precision floating-point conversion operations 🍓
• +vfpv3-fp16 — The VFPv3 floating-point instructions, with 32 double-precision registers and the half-precision floating-point conversion operations 🍓
• +vfpv4-d16 — The VFPv4 floating-point instructions, with 16 double-precision registers 🦋
• +vfpv4 — The VFPv4 floating-point instructions, with 32 double-precision registers 🦋
• +neon — The Advanced SIMD (Neon) v1 and the VFPv3 floating-point instructions 🎀 The extension +neon-vfpv3 can be used as an alias for this one
• +neon-fp16 — The Advanced SIMD (Neon) v1 and the VFPv3 floating-point instructions, with the half-precision floating-point conversion operations ✨
• +nosimd — okay so this one switches off the Advanced SIMD instructions 🙅‍♀️ but floating point stays on, so it's not a total wipeout 💅 (it does not disable floating point).
• +nofp — bye bye to the floating-point and Advanced SIMD instructions 💀 both get disabled together 😭

armv8-a

• +crc — the Cyclic Redundancy Check (CRC) instructions ✨
• +simd — the ARMv8-A Advanced SIMD and floating-point instructions 🔥
• +crypto — the cryptographic instructions 🔐
• +nocrypto — disables the cryptographic instructions, no cap 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions all at once 💀
• +sb — the Speculation Barrier Instruction 🛑
• +predres — the Execution and Data Prediction Restriction Instructions 🎀

armv8.1-a

• +simd — the ARMv8.1-A Advanced SIMD and floating-point instructions 🌈
• +crypto — the cryptographic instructions 🔐 this one also turns on the Advanced SIMD and floating-point instructions, so it's giving bundle deal 🍓
• +nocrypto — disables the cryptographic instructions 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀
• +sb — the Speculation Barrier Instruction 🛑
• +predres — the Execution and Data Prediction Restriction Instructions 🎀

armv8.2-a and armv8.3-a

• +fp16 — the half-precision floating-point data processing instructions 🌸 this also enables the Advanced SIMD and floating-point instructions too ✨
• +fp16fml — the half-precision floating-point fmla extension 🦋 this also enables the half-precision floating-point extension, plus the Advanced SIMD and floating-point instructions 🫶
• +simd — the ARMv8.1-A Advanced SIMD and floating-point instructions 🌈
• +crypto — the cryptographic instructions 🔐 this also enables the Advanced SIMD and floating-point instructions 🍓
• +dotprod — enables the Dot Product extension 🧚 this also enables Advanced SIMD instructions
• +nocrypto — disables the cryptographic extension 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀
• +sb — the Speculation Barrier Instruction 🛑
• +predres — the Execution and Data Prediction Restriction Instructions 🎀
• +i8mm — the 8-bit Integer Matrix Multiply instructions 💜 this also enables Advanced SIMD and floating-point instructions 🔥
• +bf16 — the Brain half-precision floating-point instructions 🧠 this also enables Advanced SIMD and floating-point instructions 🔥

armv8.4-a

• +fp16 — the half-precision floating-point data processing instructions 🌸 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension and the half-precision floating-point fmla extension 👑
• +simd — the ARMv8.3-A Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🌈
• +crypto — the cryptographic instructions 🔐 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🍓
• +nocrypto — disables the cryptographic extension 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀
• +sb — the Speculation Barrier Instruction 🛑
• +predres — the Execution and Data Prediction Restriction Instructions 🎀
• +i8mm — the 8-bit Integer Matrix Multiply instructions 💜 this also enables Advanced SIMD and floating-point instructions 🔥
• +bf16 — the Brain half-precision floating-point instructions 🧠 this also enables Advanced SIMD and floating-point instructions 🔥

armv8.5-a

• +fp16 — the half-precision floating-point data processing instructions 🌸 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension and the half-precision floating-point fmla extension 👑
• +simd — the ARMv8.3-A Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🌈
• +crypto — the cryptographic instructions 🔐 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🍓
• +nocrypto — disables the cryptographic extension 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀
• +i8mm — the 8-bit Integer Matrix Multiply instructions 💜 this also enables Advanced SIMD and floating-point instructions 🔥
• +bf16 — the Brain half-precision floating-point instructions 🧠 this also enables Advanced SIMD and floating-point instructions 🔥

armv8.6-a

• +fp16 — the half-precision floating-point data processing instructions 🌸 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension and the half-precision floating-point fmla extension 👑
• +simd — the ARMv8.3-A Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🌈
• +crypto — the cryptographic instructions 🔐 this also enables the Advanced SIMD and floating-point instructions, as well as the Dot Product extension 🍓
• +nocrypto — disables the cryptographic extension 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀
• +i8mm — the 8-bit Integer Matrix Multiply instructions 💜 this also enables Advanced SIMD and floating-point instructions 🔥
• +bf16 — the Brain half-precision floating-point instructions 🧠 this also enables Advanced SIMD and floating-point instructions 🔥

armv7-r

• +fp.sp — the single-precision VFPv3 floating-point instructions 🎈 the extension +vfpv3xd can be used as an alias for this extension 🦋
• +fp — the VFPv3 floating-point instructions with 16 double-precision registers 💎 the extension +vfpv3-d16 can be used as an alias for this extension 🦋
• +vfpv3xd-d16-fp16 — the single-precision VFPv3 floating-point instructions with 16 double-precision registers, plus the half-precision floating-point conversion operations 🧚
• +vfpv3-d16-fp16 — the VFPv3 floating-point instructions with 16 double-precision registers, plus the half-precision floating-point conversion operations 🧚
• +nofp — disables the floating-point extension 🙅‍♀️
• +idiv — the ARM-state integer division instructions ➗
• +noidiv — disables the ARM-state integer division extension 🙅‍♀️

armv7e-m

• +fp — the single-precision VFPv4 floating-point instructions 🎈
• +fpv5 — the single-precision FPv5 floating-point instructions 🎈
• +fp.dp — the single- and double-precision FPv5 floating-point instructions 💥
• +nofp — disables the floating-point extensions 🙅‍♀️

armv8.1-m.main

• +dsp — the DSP instructions ⭐
• +mve — the M-Profile Vector Extension (MVE) integer instructions 🎀
• +mve.fp — the M-Profile Vector Extension (MVE) integer and single precision floating-point instructions 💜
• +fp — the single-precision floating-point instructions 🎈
• +fp.dp — the single- and double-precision floating-point instructions 💥
• +nofp — disables the floating-point extension 🙅‍♀️
• +cdecp0, +cdecp1, ... , +cdecp7 — enables the Custom Datapath Extension (CDE) on selected coprocessors, according to the numbers given in the options in the range 0 to 7 🧩
• +pacbti — enables the Pointer Authentication and Branch Target Identification Extension 🔒

armv8-m.main

• +dsp — the DSP instructions ⭐
• +nodsp — disables the DSP extension 🙅‍♀️
• +fp — the single-precision floating-point instructions 🎈
• +fp.dp — the single- and double-precision floating-point instructions 💥
• +nofp — disables the floating-point extension 🙅‍♀️
• +cdecp0, +cdecp1, ... , +cdecp7 — enables the Custom Datapath Extension (CDE) on selected coprocessors, according to the numbers given in the options in the range 0 to 7 🧩

armv8-r

• +crc — the Cyclic Redundancy Check (CRC) instructions ✨
• +fp.sp — the single-precision FPv5 floating-point instructions 🎈
• +simd — the ARMv8-A Advanced SIMD and floating-point instructions 🌈
• +crypto — the cryptographic instructions 🔐
• +nocrypto — disables the cryptographic instructions 🙅‍♀️
• +nofp — disables the floating-point, Advanced SIMD and cryptographic instructions 💀

---

Okay, two special flags you need to know about 🫶

-march=native tells the compiler to auto-detect the architecture of the build computer 🔍 but right now this only works on GNU/Linux, and not every architecture gets recognized 😬 if the auto-detect doesn't work out, the option just has no effect 🙈

-march=unset tells the compiler to ignore any -march=... options that showed up earlier on the command line, and to behave like the option was never passed at all ✨ this is super useful for avoiding warnings about conflicting CPU and architecture options when the two produce different architecture specifications 💅

• -mtune=name — okay bestie, this one tells GCC which target ARM processor to tune your code's performance for ✨ Some ARM chips run noticeably faster when you use it 🚀 The permissible names are arm7tdmi, arm7tdmi-s, arm710t, arm720t, arm740t, strongarm, strongarm110, strongarm1100, strongarm1110, arm8, arm810, arm9, arm9e, arm920, arm920t, arm922t, arm946e-s, arm966e-s, arm968e-s, arm926ej-s, arm940t, arm9tdmi, arm10tdmi, arm1020t, arm1026ej-s, arm10e, arm1020e, arm1022e, arm1136j-s, arm1136jf-s, mpcore, mpcorenovfp, arm1156t2-s, arm1156t2f-s, arm1176jz-s, arm1176jzf-s, generic-armv7-a, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15, cortex-a17, cortex-a32, cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73, cortex-a75, cortex-a76, cortex-a76ae, cortex-a77, cortex-a78, cortex-a78ae, cortex-a78c, cortex-a710, ares, cortex-r4, cortex-r4f, cortex-r5, cortex-r7, cortex-r8, cortex-r52, cortex-r52plus, cortex-m0, cortex-m0plus, cortex-m1, cortex-m3, cortex-m4, cortex-m7, cortex-m23, cortex-m33, cortex-m35p, cortex-m52, cortex-m55, cortex-m85, cortex-x1, cortex-x1c, cortex-m1.small-multiply, cortex-m0.small-multiply, cortex-m0plus.small-multiply, exynos-m1, marvell-pj4, neoverse-n1, neoverse-n2, neoverse-v1, xscale, iwmmxt, iwmmxt2, ep9312, fa526, fa626, fa606te, fa626te, fmp626, fa726te, star-mc1 and xgene1 💖

Also, this option can tune for a big.LITTLE system 🌈 The permissible big.LITTLE names are cortex-a15.cortex-a7, cortex-a17.cortex-a7, cortex-a57.cortex-a53, cortex-a72.cortex-a53, cortex-a72.cortex-a35, cortex-a73.cortex-a53, cortex-a75.cortex-a55 and cortex-a76.cortex-a55 🫶

-mtune=generic-arch is giving "blend of everything" energy 🌸 It tells GCC to tune performance for a mix of processors within the architecture arch. The goal is code that runs well on the most popular chips right now, balancing the optimizations that help some CPUs in the range while dodging the performance pitfalls of others. The effects of this may change in future GCC versions as CPU models come and go, so don't be shocked if it shifts 🦋

-mtune accepts the same extension options as -mcpu, but the extensions don't change how the generated code gets tuned 🧚

-mtune=native makes the compiler auto-detect the CPU of the build computer 👑 Right now this only works on GNU/Linux, and not every architecture is recognized. If the auto-detect doesn't work out, the option has no effect 🙈

• -mcpu=name[+extension...] — this names the target ARM processor, and GCC uses it to figure out two things: the target ARM architecture (as if you'd passed -march) and the processor type to tune for (as if you'd passed -mtune) ✨ If you use this alongside -march or -mtune, those two take precedence over the matching part of this option 💅

Lowkey, a lot of the supported CPUs come with optional architectural extensions 🎀 Those are usually enabled by default. If some implementations don't have an extension, you can use the extension syntax to switch off the ones that are missing 🫠 Floating-point and Advanced SIMD (Neon) instructions also depend on -mfloat-abi and -mfpu. FP and SIMD instructions only get used if -mfloat-abi isn't set to soft, and any -mfpu setting other than auto will override the available floating-point and SIMD extension instructions 😭

For example, cortex-a9 shows up in three main configurations: integer only, with just a floating-point unit, or with floating-point and Advanced SIMD 🔥 By default everything is enabled, but you can use +nosimd to turn off just the SIMD, or +nofp to turn off both SIMD and floating-point 💜

The permissible names for this option are the same as the ones for -mtune 🌈

These extension options are shared by the listed CPUs:

• +nodsp: switches off the DSP instructions on cortex-m33, cortex-m35p, cortex-m52, cortex-m55 and cortex-m85. It also switches off the M-Profile Vector Extension (MVE) integer and single precision floating-point instructions on cortex-m52, cortex-m55 and cortex-m85 🙈
• +nopacbti: switches off the Pointer Authentication and Branch Target Identification Extension on cortex-m52 and cortex-m85 🔐
• +nomve: switches off the M-Profile Vector Extension (MVE) integer and single precision floating-point instructions on cortex-m52, cortex-m55 and cortex-m85 💅
• +nomve.fp: switches off just the M-Profile Vector Extension (MVE) single precision floating-point instructions on cortex-m52, cortex-m55 and cortex-m85 ✨
• +cdecp0, +cdecp1, ... , +cdecp7: enables the Custom Datapath Extension (CDE) on selected coprocessors, based on the numbers given in the options in the range 0 to 7, on cortex-m52, cortex-m55 and star-mc1 🧚
• +nofp: disables the floating-point instructions on arm9e, arm946e-s, arm966e-s, arm968e-s, arm10e, arm1020e, arm1022e, arm926ej-s, arm1026ej-s, cortex-r5, cortex-r7, cortex-r8, cortex-m4, cortex-m7, cortex-m33, cortex-m35p, cortex-m52, cortex-m55 and cortex-m85. On generic-armv7-a, cortex-a5, cortex-a7, cortex-a8, cortex-a9, cortex-a12, cortex-a15, cortex-a17, cortex-a15.cortex-a7, cortex-a17.cortex-a7, cortex-a32, cortex-a35, cortex-a53 and cortex-a55, it disables the floating-point and SIMD instructions 💖
• +nofp.dp: disables the double-precision component of the floating-point instructions on cortex-r5, cortex-r7, cortex-r8, cortex-r52, cortex-r52plus and cortex-m7 🌸
• +nosimd: disables the SIMD (but not floating-point) instructions on generic-armv7-a, cortex-a5, cortex-a7 and cortex-a9 🦋
• +crypto: enables the cryptographic instructions on cortex-a32, cortex-a35, cortex-a53, cortex-a55, cortex-a57, cortex-a72, cortex-a73, cortex-a75, exynos-m1, xgene1, cortex-a57.cortex-a53, cortex-a72.cortex-a53, cortex-a73.cortex-a35, cortex-a73.cortex-a53 and cortex-a75.cortex-a55 🔥

Also, the generic-armv7-a pseudo target defaults to VFPv3 with 16 double-precision registers 👑 It supports these extension options: mp, sec, vfpv3-d16, vfpv3, vfpv3-d16-fp16, vfpv3-fp16, vfpv4-d16, vfpv4, neon, neon-vfpv3, neon-fp16 and neon-vfpv4. They mean the same thing as the extensions to -march=armv7-a 🎀

-mcpu=generic-arch is also allowed, and it's equivalent to -march=arch -mtune=generic-arch. Check -mtune for more info 🫶

-mcpu=native makes the compiler auto-detect the CPU of the build computer 💅 Right now this only works on GNU/Linux, and not every architecture is recognized. If the auto-detect fails, the option has no effect 🙈

-mcpu=unset tells the compiler to ignore any -mcpu=... options that appeared earlier on the command line, and to act like that option was never passed 🧹 This is handy for avoiding warnings about conflicting CPU and architecture options when the two produce different architecture specifications ✨

• -mfpu=name — this specifies what floating-point hardware (or hardware emulation) is available on the target 🌈 The permissible names are auto, vfpv2, vfpv3, vfpv3-fp16, vfpv3-d16, vfpv3-d16-fp16, vfpv3xd, vfpv3xd-fp16, neon-vfpv3, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4, fpv5-d16, fpv5-sp-d16, fp-armv8, neon-fp-armv8 and crypto-neon-fp-armv8. Note that neon is an alias for neon-vfpv3, and vfp is an alias for vfpv2 🍓

auto is the default and it's kind of special 🧚 It makes the compiler pick the floating-point and Advanced SIMD instructions based on the settings of -mcpu and -march ✨

If the floating-point hardware you picked includes the NEON extension (e.g. -mfpu=neon), heads up: floating-point operations aren't generated by GCC's auto-vectorization pass unless -funsafe-math-optimizations is also specified 😭 That's because NEON hardware doesn't fully implement the IEEE 754 standard for floating-point arithmetic (denormal values are treated as zero, in particular), so using NEON instructions may lead to a loss of precision 💀

You can also set the fpu name at function level using the target("fpu=") function attributes or pragmas 🦋

• -mfp16-format=name — specifies the format of the "__fp16" half-precision floating-point type 💜 The permissible names are none, ieee and alternative. The default is none, and in that case the "__fp16" type isn't defined 🙈
• -mstructure-size-boundary=n — the sizes of all structures and unions get rounded up to a multiple of the number of bits set by this option 🎀 Permissible values are 8, 32 and 64. The default value varies for different toolchains. For the COFF targeted toolchain, the default is 8. A value of 64 is only allowed if the underlying ABI supports it 💅

Going bigger can produce faster, more efficient code, but it can also increase the size of your program ✨ Different values are potentially incompatible. Code compiled with one value can't necessarily expect to work with code or libraries compiled with another value, if they exchange information using structures or unions 😬

⚠️ This option is deprecated. Don't build new stuff around it, bestie 💀

• -mabort-on-noreturn — generates a call to the function "abort" at the end of a "noreturn" function 🌸 It's executed if the function tries to return 😳
• -mlong-calls and -mno-long-calls — tells the compiler to perform function calls by first loading the address of the function into a register, and then doing a subroutine call on that register 🦋 You need this switch if the target function lies outside the 64-megabyte addressing range of the offset-based version of the subroutine call instruction 🌈

Even if this switch is enabled, not every function call gets turned into a long call 🎀 The vibe check goes like this: static functions, functions with the "short_call" attribute, functions inside a #pragma no_long_calls scope, and functions whose definitions were already compiled in the current compilation unit all stay short. The exceptions are always long calls, no cap: weak function definitions, functions with the "long_call" or "section" attribute, and functions inside a #pragma long_calls scope 💅

This feature is not enabled by default 🙈 -mno-long-calls brings back the default behavior, and so does wrapping the function calls in a #pragma long_calls_off directive. Also, these switches do nothing for how the compiler handles function calls through function pointers, so don't expect them to ✨

• -msingle-pic-base — okay so this one treats the register used for PIC addressing as read-only 🔒 Instead of loading it in the prologue for every function, the runtime system is the one responsible for setting it to an appropriate value before execution begins 🦋
• -mpic-register=reg — this lets you pick the register used for PIC addressing 💜 For the standard PIC base case, the default is any suitable register the compiler decides on. For the single PIC base case, the default is R9 if the target is EABI based or stack-checking is enabled, and otherwise it's R10 🌸
• -mpic-data-is-text-relative — assume the displacement between the text and data segments is fixed at static link time 🧚 This lets you use PC-relative addressing to access data you know is in the data segment. For non-VxWorks RTP targets this is enabled by default, and if you disable it on those targets, -msingle-pic-base gets enabled by default instead 🫶
• -mpoke-function-name — this one writes the name of each function into the text section, right before the function prologue ✨ The generated code looks kind of like this:

t0
    .ascii "arm_poke_function_name", 0
    .align
t1
    .word 0xff000000 + (t1 - t0)
arm_poke_function_name
    mov     ip, sp
    stmfd   sp!, {fp, ip, lr, pc}
    sub     fp, ip, #4

When you're doing a stack backtrace, the code can check the pc value stored at fp + 0 👀 If the trace function then looks at location pc - 12 and the top 8 bits are set, we know there's a function name embedded right before that location, with length ((pc[-3]) & 0xff000000) 😭

• -mthumb, -marm — pick between generating code that runs in ARM state or Thumb state 🍓 For most configurations the default is ARM state, but you can change that by configuring GCC with the --with-mode=state configure option 💖 You can also override ARM or Thumb mode for each function with the target("thumb") and target("arm") function attributes or pragmas, which is honestly so iconic 👑
• -mflip-thumb — switches ARM and Thumb modes on alternating functions 🌈 This one exists purely for regression testing of mixed Thumb/ARM code generation, so please don't use it to compile your actual code 💀
• -mtpcs-frame — generates a stack frame that follows the Thumb Procedure Call Standard for all non-leaf functions 🦋 (A leaf function is one that doesn't call any other functions.) The default is -mno-tpcs-frame ✨
• -mtpcs-leaf-frame — same energy, but this time it generates a Thumb Procedure Call Standard compliant stack frame for all leaf functions 🌸 (Again, a leaf function is one that doesn't call any other functions.) The default is -mno-apcs-leaf-frame 💅
• -mcallee-super-interworking — gives every externally visible function in the file being compiled an ARM instruction set header 🧚 That header switches to Thumb mode before running the rest of the function, so these functions can be called from non-interworking code. This option is not valid in AAPCS configurations, because interworking is already enabled by default there 🙈
• -mcaller-super-interworking — lets calls through function pointers (including virtual functions) run correctly, no matter whether the target code was compiled for interworking or not 🫶 Heads up, there's a small overhead when executing a function pointer if you turn this on. It's also not valid in AAPCS configurations, since interworking is already enabled by default there 💜
• -mtp=name — specifies the access model for the thread local storage pointer 🔥 The soft model generates calls to __aeabi_read_tp. The other accepted models are tpidrurw, tpidruro, and tpidrprw, which fetch the thread pointer straight from the matching system register (supported from the arm6k architecture and later) ✨ Those system registers get accessed through the CP15 co-processor interface, and the argument cp15 is also accepted as a convenience alias of tpidruro 🎀 The argument auto uses the best available method for the selected processor, and that's also the default setting 💖
• -mtls-dialect=dialect — picks the dialect used for accessing thread local storage 🌈 There are two: gnu and gnu2. The gnu dialect selects the original GNU scheme for supporting local and global dynamic TLS models. The gnu2 dialect selects the GNU descriptor scheme, which performs better for shared libraries 🚀 The GNU descriptor scheme is compatible with the original scheme, but it does need new assembler, linker, and library support. Initial and local exec TLS models aren't affected by this option and always use the original scheme 🫶
• -mword-relocations — only generates absolute relocations on word-sized values (i.e. R_ARM_ABS32) 🍓 This is enabled by default on targets (uClinux, SymbianOS) where the runtime loader imposes this restriction, and whenever -fpic or -fPIC is specified. This option conflicts with -mslow-flash-data 🙈
• -mfix-cortex-m3-ldrd — some Cortex-M3 cores can cause data corruption when ldrd instructions with overlapping destination and base registers get used 😭 This option avoids generating those instructions. It's enabled by default when -mcpu=cortex-m3 is specified 💖
• -mfix-cortex-a57-aes-1742098, -mno-fix-cortex-a57-aes-1742098, -mfix-cortex-a72-aes-1655431, -mno-fix-cortex-a72-aes-1655431 — these enable (or disable) the mitigation for an erratum on Cortex-A57 and Cortex-A72 that affects the AES cryptographic instructions 🔐 This is enabled by default when either -mcpu=cortex-a57 or -mcpu=cortex-a72 is specified 🌸
• -munaligned-access, -mno-unaligned-access — enables (or disables) reading and writing 16- and 32-bit values from addresses that aren't 16- or 32-bit aligned 🦋 By default, unaligned access is disabled for all pre-ARMv6, all ARMv6-M, and ARMv8-M Baseline architectures, and enabled for every other architecture. If unaligned access isn't enabled, words in packed data structures get accessed one byte at a time 🥹

The ARM attribute "Tag_CPU_unaligned_access" gets set in the generated object file to either true or false, depending on this option's setting ✨ If unaligned access is enabled, the preprocessor symbol __ARM_FEATURE_UNALIGNED is also defined 🧚

• -mneon-for-64bits — this one is deprecated and has no effect 💀 Bye bye 👋
• -mslow-flash-data — assumes loading data from flash is slower than fetching instructions, so literal loads get minimized for better performance 🐢 This option is only supported when compiling for ARMv7 M-profile, and it's off by default. It conflicts with -mword-relocations 🙅‍♀️
• -masm-syntax-unified — assumes inline assembler is using unified asm syntax 💜 The default is currently off, which implies divided syntax. This option has no impact on Thumb2, but that may change in future releases of GCC. Divided syntax should be considered deprecated, so be careful with it 🫶
• -mrestrict-it — restricts generation of IT blocks so they conform to the rules of ARMv8-A 🔥 IT blocks can only contain a single 16-bit instruction from a select set of instructions. This option is on by default for ARMv8-A Thumb mode 👑
• -mprint-tune-info — prints CPU tuning information as a comment in the assembler file 🎀 This is only used for regression testing of the compiler and isn't meant for ordinary code compiling. It's disabled by default 🙈
• -mverbose-cost-dump — enables verbose cost model dumping in the debug dump files 🔍 This one's provided for debugging the compiler, so it's a niche pick 🧚
• -mpure-code — doesn't allow constant data to be placed in code sections 🔒 Also, when compiling for the ELF object format, it gives all text sections the ELF processor-specific section attribute "SHF_ARM_PURECODE". This option is only available when generating non-PIC code for M-profile targets 💅
• -mcmse — generates secure code as per the "ARMv8-M Security Extensions: Requirements on Development Tools Engineering Specification", which you can find at <https://developer.arm.com/documentation/ecm0359818/latest/> 🛡️✨
• -mfix-cmse-cve-2021-35465 — mitigates a potential security issue with the "VLLDM" instruction on some M-profile devices when using CMSE (CVE-2021-365465) 🚨 This option is enabled by default when -mcpu= is used with "cortex-m33", "cortex-m35p", "cortex-m52", "cortex-m55", "cortex-m85", or "star-mc1". You can use -mno-fix-cmse-cve-2021-35465 to disable the mitigation 🫶
• -mstack-protector-guard=guard, -mstack-protector-guard-offset=offset — generates stack protection code using a canary at guard 🛡️ Supported locations are global for a global canary, or tls for a canary accessible via the TLS register. The option -mstack-protector-guard-offset= is for use with -fstack-protector-guard=tls, and it's not for use in user-land code 🙅‍♀️💖

-mfdpic -mno-fdpic

Okay so -mfdpic switches on the FDPIC ABI, which uses 64-bit function descriptors to represent pointers to functions 🦋. When the compiler is configured for arm-*-uclinuxfdpiceabi targets, this is on by default and implies -fPIE if you haven't given any PIC/PIE-related options. On other targets it only turns on the FDPIC-specific code generation features, so you'll need to pass the PIC/PIE options yourself as needed 💅.

Static linking is NOT supported with FDPIC 💀. The program still involves the dynamic linker when it self-relocates. If you're okay with that behavior anyway, use -static and -Wl,-dynamic-linker options.

The opposite, -mno-fdpic, is useful (and required) when you're building the Linux kernel with the same arm-*-uclinuxfdpiceabi toolchain you use for your userland programs 🌸.

-mbranch-protection=none|standard|pac-ret[+leaf][+bti]|bti[+pac-ret[+leaf]]

Enable branch protection features, but only on armv8.1-m.main ✨. Here's the breakdown:

• none — no branch protection or return address signing, just plain code 🍓.
• standard[+leaf] — all branch protection features turned on at their standard level 🔥.
• pac-ret[+leaf] — return address signing at its standard level, which means signing every function that saves the return address to memory 🔐.
• leaf — when return address signing is on, this also signs leaf functions, even the ones that never write the return address to memory 🍃.
• +bti — adds landing-pad instructions at the permitted targets of indirect branch instructions 🧚.

If the +pacbti architecture extension isn't enabled, all branch protection and return address signing operations are restricted to the instructions defined in the architectural-NOP space. The generated code stays backwards-compatible with earlier versions of the architecture, but the extra security can still kick in at run time on processors that support the PACBTI extension 💜.

Branch target enforcement with BTI can only be enabled at runtime if all the code in the application was compiled with at least -mbranch-protection=bti 🙈.

Anything other than none is only supported on armv8-m.main or later 💀.

The default is to generate code without branch protection or return address signing 🌈.

---

✨ AVR Options ✨

These options are defined for AVR implementations 🧚.

-mmcu=mcu

Specify the AVR instruction set architecture (ISA) or device type. The default is avr2 💖.

Here are the AVR devices and ISAs that are supported. Heads up bestie: complete device support needs a startup code file crtmcu.o, a device header avr/io*.h, a device library libmcu.a, and a device-specs file specs-mcu. Only the last one is provided by the compiler, and only for the mcus listed below. The rest comes from AVR-LibC (https://github.com/avrdudes/avr-libc/) or from atpack files (https://gcc.gnu.org/wiki/avr-gcc#atpack) that the hardware manufacturer hands out 📦. For the spec files, check out https://gcc.gnu.org/wiki/avr-gcc#spec-files ✨.

• avr2 — "Classic" devices with up to 8 KiB of program memory 🎀. mcu = attiny22, attiny26, at90s2313, at90s2323, at90s2333, at90s2343, at90s4414, at90s4433, at90s4434, at90c8534, at90s8515, at90s8535.
• avr25 — "Classic" devices with up to 8 KiB of program memory and the MOVW instruction 🦋. mcu = attiny13, attiny13a, attiny24, attiny24a, attiny25, attiny261, attiny261a, attiny2313, attiny2313a, attiny43u, attiny44, attiny44a, attiny45, attiny48, attiny441, attiny461, attiny461a, attiny4313, attiny84, attiny84a, attiny85, attiny87, attiny88, attiny828, attiny841, attiny861, attiny861a, ata5272, ata6616c, at86rf401.
• avr3 — "Classic" devices with 16 KiB up to 64 KiB of program memory 🌸. mcu = at76c711, at43usb355.
• avr31 — "Classic" devices with 128 KiB of program memory 💅. mcu = atmega103, at43usb320.
• avr35 — "Classic" devices with 16 KiB up to 64 KiB of program memory and the MOVW instruction 🫶. mcu = attiny167, attiny1634, atmega8u2, atmega16u2, atmega32u2, ata5505, ata6617c, ata664251, at90usb82, at90usb162.
• avr4 — "Enhanced" devices with up to 8 KiB of program memory ⭐. mcu = atmega48, atmega48a, atmega48p, atmega48pa, atmega48pb, atmega8, atmega8a, atmega8hva, atmega88, atmega88a, atmega88p, atmega88pa, atmega88pb, atmega8515, atmega8535, ata5795, ata6285, ata6286, ata6289, ata6612c, at90pwm1, at90pwm2, at90pwm2b, at90pwm3, at90pwm3b, at90pwm81.
• avr5 — "Enhanced" devices with 16 KiB up to 64 KiB of program memory 👑. This is the big one, so buckle up 😭. mcu = atmega16, atmega16a, atmega16hva, atmega16hva2, atmega16hvb, atmega16hvbrevb, atmega16m1, atmega16u4, atmega161, atmega162, atmega163, atmega164a, atmega164p, atmega164pa, atmega165, atmega165a, atmega165p, atmega165pa, atmega168, atmega168a, atmega168p, atmega168pa, atmega168pb, atmega169, atmega169a, atmega169p, atmega169pa, atmega32, atmega32a, atmega32c1, atmega32hvb, atmega32hvbrevb, atmega32m1, atmega32u4, atmega32u6, atmega323, atmega324a, atmega324p, atmega324pa, atmega324pb, atmega325, atmega325a, atmega325p, atmega325pa, atmega328, atmega328p, atmega328pb, atmega329, atmega329a, atmega329p, atmega329pa, atmega3250, atmega3250a, atmega3250p, atmega3250pa, atmega3290, atmega3290a, atmega3290p, atmega3290pa, atmega406, atmega64, atmega64a, atmega64c1, atmega64hve, atmega64hve2, atmega64m1, atmega64rfr2, atmega640, atmega644, atmega644a, atmega644p, atmega644pa, atmega644rfr2, atmega645, atmega645a, atmega645p, atmega649, atmega649a, atmega649p, atmega6450, atmega6450a, atmega6450p, atmega6490, atmega6490a, atmega6490p, ata5790, ata5790n, ata5791, ata6613c, ata6614q, ata5782, ata5831, ata8210, ata8510, ata5787, ata5835, ata5700m322, ata5702m322, at90pwm161, at90pwm216, at90pwm316, at90can32, at90can64, at90scr100, at90usb646, at90usb647, at94k, m3000.
• avr51 — "Enhanced" devices with 128 KiB of program memory 🔥. mcu = atmega128, atmega128a, atmega128rfa1, atmega128rfr2, atmega1280, atmega1281, atmega1284, atmega1284p, atmega1284rfr2, at90can128, at90usb1286, at90usb1287.
• avr6 — "Enhanced" devices with a 3-byte PC, so more than 128 KiB of program memory 🚀. mcu = atmega256rfr2, atmega2560, atmega2561, atmega2564rfr2.
• avrxmega2 — "XMEGA" devices with more than 8 KiB and up to 64 KiB of program memory 🌈. mcu = atxmega8e5, atxmega16a4, atxmega16a4u, atxmega16c4, atxmega16d4, atxmega16e5, atxmega32a4, atxmega32a4u, atxmega32c3, atxmega32c4, atxmega32d3, atxmega32d4, atxmega32e5, avr64da28, avr64da28s, avr64da32, avr64da32s, avr64da48, avr64da48s, avr64da64, avr64da64s, avr64db28, avr64db32, avr64db48, avr64db64, avr64dd14, avr64dd20, avr64dd28, avr64dd32, avr64du28, avr64du32, avr64ea28, avr64ea32, avr64ea48, avr64sd28, avr64sd32, avr64sd48.
• avrxmega3 — "XMEGA" devices with up to 64 KiB of combined program memory and RAM, where the program memory is visible in the RAM address space 🧚. mcu = attiny202, attiny204, attiny212, attiny214, attiny402, attiny404, attiny406, attiny412, attiny414, attiny416, attiny416auto, attiny417, attiny424, attiny426, attiny427, attiny804, attiny806, attiny807, attiny814, attiny816, attiny817, attiny824, attiny826, attiny827, attiny1604, attiny1606, attiny1607, attiny1614, attiny1616, attiny1617, attiny1624, attiny1626, attiny1627, attiny3214, attiny3216, attiny3217, attiny3224, attiny3226, attiny3227, atmega808, atmega809, atmega1608, atmega1609, atmega3208, atmega3209, atmega4808, atmega4809, avr16dd14, avr16dd20, avr16dd28, avr16dd32, avr16du14, avr16du20, avr16du28, avr16du32, avr16ea28, avr16ea32, avr16ea48, avr16eb14, avr16eb20, avr16eb28, avr16eb32, avr32da28, avr32da28s, avr32da32, avr32da32s, avr32da48, avr32da48s, avr32db28, avr32db32, avr32db48, avr32dd14, avr32dd20, avr32dd28, avr32dd32, avr32du14, avr32du20, avr32du28, avr32du32, avr32ea28, avr32ea32, avr32ea48, avr32sd20, avr32sd28, avr32sd32.
• avrxmega4 — "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory 💖. mcu = atxmega64a3, atxmega64a3u, atxmega64a4u, atxmega64b1, atxmega64b3, atxmega64c3, atxmega64d3, atxmega64d4, avr128da28, avr128da28s, avr128da32, avr128da32s, avr128da48, avr128da48s, avr128da64, avr128da64s, avr128db28, avr128db32, avr128db48, avr128db64.
• avrxmega5 — "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory, plus more than 64 KiB of RAM 🎀. mcu = atxmega64a1, atxmega64a1u.
• avrxmega6 — "XMEGA" devices with more than 128 KiB of program memory 🦋. mcu = atxmega128a3, atxmega128a3u, atxmega128b1, atxmega128b3, atxmega128c3, atxmega128d3, atxmega128d4, atxmega192a3, atxmega192a3u, atxmega192c3, atxmega192d3, atxmega256a3, atxmega256a3b, atxmega256a3bu, atxmega256a3u, atxmega256c3, atxmega256d3, atxmega384c3, atxmega384d3.
• avrxmega7 — "XMEGA" devices with more than 128 KiB of program memory and more than 64 KiB of RAM 👑. mcu = atxmega128a1, atxmega128a1u, atxmega128a4u.

okay bestie, the tiny chips get their own little squad 🌸

• avrtiny — the "Reduced Tiny" crew 🧚 These tiny core devices only have 16 general purpose registers and 512 B up to 4 KiB of program memory. mcu = "attiny4", "attiny5", "attiny9", "attiny10", "attiny102", "attiny104", "attiny20", "attiny40".
• avr1 — this ISA is baked into the minimal AVR core, and it's only supported for the assembler 🙈 mcu = "attiny11", "attiny12", "attiny15", "attiny28", "at90s1200".

---

• -mabsdata — okay so this one assumes all data in static storage can be reached with LDS / STS instructions 💅 It only does anything on reduced Tiny devices like ATtiny40. Also see the "absdata" AVR Variable Attributes, variable attribute ✨
• -mcvt — compact vector table energy 🦋 Some devices support a CVT with only four entries: 0=Reset, 1=NMI, 2=Prio1 IRQ, 3=Prio0 IRQs. With this on, startup code gets linked from "crtmcu-cvt.o" instead of the usual "crtmcu.o". Besides the tiny table, the startup code also sets the bit CPUINT_CTRLA.CPUINT_CVT, which switches the CVT on for the device.

If you don't want the startup code touching CPUINT_CTRLA.CPUINT_CVT, you can satisfy the symbol "__init_cvt" so that code isn't pulled in from "libmcu.a" anymore. For example, link with -Wl,--defsym,__init_cvt=0 🫶

The CVT startup code is available since AVR-LibC v2.3 ("https://github.com/avrdudes/avr-libc/issues/1010").

• -mdouble=bits, -mlong-double=bits — these set the size (in bits) of the double or long double type, respectively 🌈 Valid values for bits are 32 and 64. Whether a value is allowed depends on the --with-double= and --with-long-double= configure options ("https://gcc.gnu.org/install/configure.html#avr"), and the same goes for the default values of these options.
• -mgas-isr-prologues — ISRs are allowed to use the "__gcc_isr" pseudo instruction that GNU Binutils supports 🔥 If this option is on, you can still turn the feature off for individual ISRs with the AVR Function Attributes, "no_gccisr" function attribute. This feature is on by default if optimization is on (but not with -Og, @pxref{Optimize Options}), and only if GNU Binutils support PR21683 ("https://sourceware.org/PR21683") ✨
• -mint8 — this makes int an 8-bit integer 💀 All the types shrink: a char is 1 byte, an int is 1 byte, a long is 2 bytes, and a long long is 4 bytes.

Heads up: this option does not conform to the C standards! It does give you smaller code size though.

• -mmain-is-OS_task — don't save registers in main 👑 It works the same as attaching the AVR Function Attributes, "OS_task" attribute to main. It's on by default when optimization is on.
• -mno-call-main — don't run main through the usual call-and-exit dance 🧚‍♀️

        XCALL  main
        XJMP   exit

Instead, main gets put in the section ".init9" ("https://avrdudes.github.io/avr-libc/avr-libc-user-manual/mem_sections.html#sec_dot_init"), so no call is needed at all. By turning this on you're promising that main will never return 🙈

This one is perfect for devices with very limited resources, since it saves a few bytes of code and stack space. It works as expected since AVR-LibC v2.3 ("https://github.com/avrdudes/avr-libc/issues/1012"). With older versions there's no performance gain.

• -mno-interrupts — the generated code won't be compatible with hardware interrupts 😭 The upside is that the code size is smaller.
• -mrelax — this tries to swap CALL (or JMP) for the shorter RCALL (or RJMP) when it's allowed ✨ Setting -mrelax just adds --mlink-relax to the assembler's command line and --relax to the linker's command line.

The linker does the jump relaxing, because jump offsets aren't known until the code is located. So the assembler code the compiler spits out is the same, but the instructions in the executable might look different from it 💖

Relaxing must be turned on if linker stubs are needed. See the section on "EIND" and linker stubs below.

• -mrodata-in-ram, -mno-rodata-in-ram — these decide whether the ".rodata" sections for read-only data live in RAM or in program memory 🎀 For most devices there's no real choice, so this option basically acts like an assertion.

Since v14, and for the AVR64* and AVR128* devices, ".rodata" lives in flash memory by default, as long as the required GNU Binutils support (PR31124 ("https://sourceware.org/PR31124")) is around. In that case, -mrodata-in-ram can bring back the old layout with ".rodata" in RAM.

• -mtiny-stack — only change the lower 8 bits of the stack pointer 🍓
• -mfract-convert-truncate — lets you use truncation instead of rounding towards zero for fractional fixed-point types 🦋
• -nodevicelib — don't link against AVR-LibC's device specific library "libmcu.a" 🥺

Heads up: since AVR-LibC v2.3, that library holds code that's essential for your program to work properly! It contains parts of the startup code, like "__init_sp" ("https://github.com/avrdudes/avr-libc/issues/1011"), which sets up the stack pointer with the symbol "__stack". It also has "__init_cvt" ("https://github.com/avrdudes/avr-libc/issues/1010"), which sets up the hardware for a compact vector table with -mcvt, "__call_main" ("https://github.com/avrdudes/avr-libc/issues/1012"), which calls "main" and "exit", and "__do_flmap_init" ("https://github.com/avrdudes/avr-libc/issues/931"), which sets up FLMAP according to the symbol "__flmap".

• -nodevicespecs — don't add -specs=device-specs/specs-mcu to the compiler driver's command line 🧠 Now you're in charge of giving the subprocesses (compiler proper, assembler and linker) the right command line options. That means you have to supply your own device specs file with -specs=path-to-specs-file. Once you do that, there's no more need for -mmcu=mcu.

This option can also replace the older way of making custom device-specs files. That one needed -B some-path to point to a directory with a folder named "device-specs", and inside that folder a specs file named "specs-mcu", where mcu was whatever you set with -mmcu=mcu.

• -Waddr-space-convert — warns you about conversions between address spaces when the resulting address space isn't contained in the incoming one 👀
• -Wmisspelled-isr — warns if an ISR is misspelled, meaning it's missing the __vector prefix. It's enabled by default ✨

---

✨ AVR Optimization Options ✨

These are the pure optimization options 💅 The options -mgas-isr-prologues, -mmain-is-OS_task, -mno-call-main and -mrelax from above are only almost optimization options, because there are rare moments where their different code generation actually matters.

• -maccumulate-args — collects outgoing function arguments and grabs/releases the stack space for them just once, in the function prologue/epilogue 🌸 Without this option, outgoing arguments get pushed before a call and popped afterwards. See also the -fdefer-pop Optimize Options, optimization option.

Popping arguments after a call can be expensive on AVR. Accumulating the stack space can lead to smaller executables, since arguments don't need to be removed from the stack after each call.

This can shrink code for functions that make several calls to functions that take their arguments on the stack, like printf-like functions 🖨️

• -mbranch-cost=cost — sets the branch costs for conditional branch instructions to cost. Reasonable values for cost are small, non-negative integers. The default branch cost is 0 💜
• -mcall-prologues — function prologues/epilogues get expanded as calls to appropriate subroutines 🧚 Code size is smaller.
• -mfuse-add, -mno-fuse-add, -mfuse-add=level — optimizes indirect memory accesses on reduced Tiny devices 🦋 The default uses level=1 for the -Og and -O1 optimizations, and level=2 for higher optimizations. Valid values for level are 0, 1 and 2.
• -mfuse-move, -mno-fuse-move, -mfuse-move=level — runs a post reload optimization pass that tries to fuse move instructions and to split multi-byte instructions into 8-bit operations 🔥 The default uses level=3 for -O1 optimization, and level=23 for higher optimizations. Valid values for level are in the range 0 ... 23, which is a 3:2:2:2 mixed radix value. Each digit controls some aspect of the optimization.
• -mfuse-move2 — runs a post combine optimization pass that tries to fuse move instructions 💖
• -mstrict-X — uses the address register X the way the hardware intends 🌈 That means X is only used for indirect, post-increment or pre-decrement addressing.

Without this option, the X register can be used the same way as Y or Z, which then gets emulated with extra instructions. For example, loading a value with X+const addressing (with a small non-negative const < 64) into a register Rn gets done like this:

        adiw r26, const   ; X += const
        ld   <Rn>, X        ; <Rn> = *X
        sbiw r26, const   ; X -= const

• -msplit-bit-shift — splits multi-byte shifts with a constant offset into a shift with a byte offset plus a residual shift with a non-byte offset ✂️ This is turned on by default for -O2 and higher, including -Os but excluding -Oz. Splitting shifts with a constant offset that's a multiple of 8 is controlled by -mfuse-move.
• -msplit-ldst — splits multi-byte loads and stores into several byte loads and stores 🍓 It's turned on by default for -O2 and higher.
• -muse-nonzero-bits — enables optimizations that are only possible when some bits in a register are always zero 🧠 It's turned on by default for -O2 and higher.

---

✨ "EIND" and Devices With More Than 128 Ki Bytes of Flash ✨

Pointers in the implementation are 16 bits wide 🎀 The address of a function or label is represented as a word address, so indirect jumps and calls can target any code address in the range of 64 Ki words 🌸

okay so, bestie, this part is about EIND 🧚, a special function register that's basically the boss of big AVR chips. Devices with more than 128 Ki bytes of program memory need it for indirect jumps 💜

The register is called EIND, and it supplies the most significant part of the target address whenever the EICALL or EIJMP instructions get used 🌸

Here's the tea on indirect jumps and calls on these chips. The compiler handles them like this, and there are some limits you need to know about 🫶

• The compiler never sets EIND. It doesn't touch it at all 🙈
• The compiler uses EIND implicitly in EICALL/EIJMP instructions, or it might read EIND directly so it can fake an indirect call or jump with a RET instruction ✨
• The compiler assumes EIND never changes during the startup code or the application. Like, not once. EIND is not saved or restored in function or interrupt service routine prologues or epilogues 😭
• The linker makes stubs for indirect calls to functions and for computed goto. Stubs are jump pads, sometimes called trampolines 🦋 So the indirect call or jump lands on a stub, and the stub holds a direct jump to where you actually wanted to go 💖
• Linker relaxation has to be on so the linker builds the stubs correctly in every situation. Check out the compiler option -mrelax and the linker option --relax. Heads up: there are corner cases where the linker is supposed to make stubs but just aborts without relaxation, and it won't give you a helpful error message 💀
• The default linker script is set up for code with EIND = 0. If your code is supposed to work with EIND != 0, you need a custom linker script 🍓 It has to put the sections whose names start with .trampolines into the segment that EIND points to 👑
• The startup code from libgcc never sets EIND. Also, startup code is a blend of libgcc and AVR-LibC, so for how AVR-LibC affects EIND, go read the AVR-LibC user manual at https://avrdudes.github.io/avr-libc/avr-libc-user-manual/ 📖
• Your own startup code is allowed to set up EIND early. For example, you can do it with initialization code in the section .init3. That code runs before the general startup code that sets up RAM and calls constructors, but after the bit of AVR-LibC startup code that points EIND at the segment holding the vector table 🎀

Here's an example of that .init3 trick ✨

#include <avr/io.h>

static void
__attribute__((section(".init3"),naked,used,no_instrument_function))
init3_set_eind (void)
{
  __asm volatile ("ldi r24,pm_hh8(__trampolines_start)\n\t"
                  "out %i0,r24" :: "n" (&EIND) : "r24","memory");
}

The __trampolines_start symbol is defined in the linker script 🧠

• Stubs get generated automatically by the linker only when both of these conditions are met 💅
  • The address of a label is taken with the gs modifier, which is short for generate stubs. It looks like this:

LDI r24, lo8(gs(<func>))
LDI r25, hi8(gs(<func>))

• The final location of that label is in a code segment that's outside the segment where the stubs live 😤

• The compiler slaps gs modifiers on code labels in these situations 🌈
  • Taking the address of a function or code label
  • Computed goto
  • When a prologue-save function is used, see the -mcall-prologues command-line option
  • Switch/case dispatch tables. If you don't want those dispatch tables, you can use the -fno-jump-tables command-line option
  • C and C++ constructors and destructors that get called during startup or shutdown
  • If the tools run into a gs() modifier like the one described above
• Jumping to non-symbolic addresses like this is NOT supported 🚫

int main (void)
{
    /* Call function at word address 0x2 */
    return ((int(*)(void)) 0x2)();
}

Instead, you need to set up a stub, meaning you call the function through a symbol. In the example below, that symbol is func_4 🦋

int main (void)
{
    extern int func_4 (void);

    /* Call function at byte address 0x4 */
    return func_4();
}

Then link the application with -Wl,--defsym,func_4=0x4. Or you can define func_4 in the linker script instead 🫶

💎 Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers 💎

Some AVR devices have more memory than the 64 KiB that 16-bit pointers can reach. To get at memory locations past that 64 KiB range, the content of a RAMP register becomes the high part of the address. The X, Y and Z address registers get glued to RAMPX, RAMPY and RAMPZ respectively to make a wide address. RAMPD does the same job with direct addressing 🌸

• The startup code sets all the RAMP special function registers to zero 🍓
• If a named address space other than generic or __flash is used (that's the AVR Named Address Spaces stuff), then RAMPZ gets set as needed before the operation ✨
• If the device supports more than 64 KiB of RAM and the compiler has to change RAMPZ to pull off an operation, then RAMPZ gets reset to zero once the operation is done 🔄
• If the device has a specific RAMP register, the ISR prologue and epilogue save and restore that SFR, and they set it to zero in case the ISR code might use it, even implicitly 🛡️
• GCC does not support RAM larger than 64 KiB for AVR targets 😬 If you use inline assembler to read from locations outside the 16-bit address range and you change one of the RAMP registers, you must reset it to zero after the access.

🎀 AVR Built-in Macros 🎀

GCC defines a bunch of built-in macros so your code can check whether features are there or not 💖 Almost all of the following built-in macros are worked out from device capabilities, so they get triggered by the -mmcu= command-line option 🧚

For even more AVR-specific built-in macros, check out AVR Named Address Spaces and AVR Built-in Functions 📖

• __AVR_ARCH__ — This one is a built-in macro that resolves to a decimal number identifying the architecture. It depends on the -mmcu=mcu option. The possible values are:

2, 25, 3, 31, 35, 4, 5, 51, 6

Those match mcu="avr2", "avr25", "avr3", "avr31", "avr35", "avr4", "avr5", "avr51" and "avr6" respectively. The values below are for mcu="avrtiny", "avrxmega2", "avrxmega3", "avrxmega4", "avrxmega5", "avrxmega6" and "avrxmega7", in order 👑

100, 102, 103, 104, 105, 106, 107

If mcu names a device, this built-in macro gets set accordingly. For example, -mmcu=atmega8 sets the macro to 4 ✨

• __AVR_Device__ — Setting -mmcu=device defines this built-in macro, which reflects the device's name. For example, -mmcu=atmega8 defines __AVR_ATmega8__, and -mmcu=attiny261a defines __AVR_ATtiny261A__, and so on 💅

The built-in macro names follow the scheme __AVR_Device__, where Device is the device name as it appears in the AVR user manual. The difference between Device in the built-in macro and device in -mmcu=device is that the latter is always lowercase 🌈

If device is not an actual device but just a core architecture like avr51, this macro is not defined 🙈

• __AVR_DEVICE_NAME__ — Setting -mmcu=device defines this one to the device's name. For example, -mmcu=atmega8 sets it to "atmega8" 🦋

If device is just a core architecture like avr51 and not a real device, this macro is not defined 💀

• __AVR_CVT__ — The code is being compiled with the -mcvt option, so it uses a compact vector table 🫶
• __AVR_XMEGA__ — The device or architecture belongs to the XMEGA family 🔥
• __AVR_HAVE_ADIW__ — The device has the ADIW and SBIW instructions 💜
• __AVR_HAVE_ELPM__ — The device has the ELPM instruction 🌸
• __AVR_HAVE_ELPMX__ — The device has the ELPM Rn,Z and ELPM Rn,Z+ instructions 🧚
• __AVR_HAVE_LPMX__ — The device has the LPM Rn,Z and LPM Rn,Z+ instructions ✨
• __AVR_HAVE_MOVW__ — The device has the MOVW instruction, which does 16-bit register-to-register moves 🍓
• __AVR_HAVE_MUL__ — The device has a hardware multiplier 🔥
• __AVR_HAVE_JMP_CALL__ — The device has the JMP and CALL instructions. This is the case for devices with more than 8 KiB of program memory 👑
• __AVR_HAVE_EIJMP_EICALL__ and __AVR_3_BYTE_PC__ — The device has the EIJMP and EICALL instructions. That's the case for devices with more than 128 KiB of program memory. It also means the program counter (PC) is 3 bytes wide 🌈
• __AVR_2_BYTE_PC__ — The program counter (PC) is 2 bytes wide. That's the case for devices with up to 128 KiB of program memory 🎀
• __AVR_HAVE_8BIT_SP__ and __AVR_HAVE_16BIT_SP__ — The compiler treats the stack pointer (SP) register as an 8-bit or 16-bit register respectively. Defining these macros is affected by -mtiny-stack 💅
• __AVR_HAVE_SPH__ and __AVR_SP8__ — The device has the SPH (high part of stack pointer) special function register, or it has an 8-bit stack pointer, respectively. Defining these macros is affected by -mmcu=, and for -mmcu=avr2 and -mmcu=avr25 it's also affected by -msp8 🦋
• __AVR_HAVE_RAMPD__, __AVR_HAVE_RAMPX__, __AVR_HAVE_RAMPY__ and __AVR_HAVE_RAMPZ__ — The device has the RAMPD, RAMPX, RAMPY or RAMPZ special function register, respectively 🧠
• __NO_INTERRUPTS__ — This macro reflects the -mno-interrupts command-line option 🙈
• __AVR_ERRATA_SKIP__ and __AVR_ERRATA_SKIP_JMP_CALL__ — Some AVR devices (AT90S8515 and ATmega103) must not skip 32-bit instructions because of a hardware erratum 😭 The skip instructions are SBRS, SBRC, SBIS, SBIC and CPSE. The second macro only gets defined if __AVR_HAVE_JMP_CALL__ is also set ⚠️
• __AVR_ISA_RMW__ — The device has Read-Modify-Write instructions (XCH, LAC, LAS and LAT) 🔥
• __AVR_SFR_OFFSET__=offset — Instructions that can address I/O special function registers directly, like IN, OUT, SBI, and so on, may use a different address than an instruction accessing RAM, like LD or STS. This offset depends on the device architecture, and you have to subtract it from the RAM address to get the matching I/O address 🌸
• __AVR_SHORT_CALLS__ — The -mshort-calls command-line option is set 💖

"__AVR_PM_BASE_ADDRESS__=addr"

okay so some devices can read flash memory with the LD* instructions 🧚 the flash shows up in the data address space at an offset of __AVR_PM_BASE_ADDRESS__. if that macro isn't defined, this feature just isn't available. if it is defined, the address space is linear and you don't need to shove .rodata into RAM 💖 the default linker description file handles that, and it's currently available for avrtiny and avrxmega3. even better, you don't need address spaces like __flash or stuff like the progmem attribute and pgm_read_* ✨

"__AVR_HAVE_FLMAP__"

this one is defined only when ALL of these conditions are met 👑

• the device has the NVMCTRL_CTRLB.FLMAP bitfield. this applies to the AVR64* and AVR128* devices 🌈
• it's not known at assembler-time which emulation will be used. 🫶

and it implies the compiler was configured with GNU Binutils that implement PR31124 (https://sourceware.org/PR31124) 💅

"__AVR_RODATA_IN_RAM__"

this macro is undefined when the code is compiled for a core architecture 🙈

when the code is compiled for a device, it's defined to 1 if the .rodata sections for read-only data live in RAM, and defined to 0 otherwise 🧚

"__WITH_AVRLIBC__"

the compiler is configured to be used together with AVR-LibC 💜 see the --with-avrlibc configure option.

"__HAVE_SIGNAL_N__"

the compiler supports the signal(num) and interrupt(num) AVR Function Attributes, with an argument num that specifies the number of the interrupt service routine ⭐

"__HAVE_DOUBLE_MULTILIB__"

defined if -mdouble= acts as a multilib option 🎀

"__HAVE_DOUBLE32__" "__HAVE_DOUBLE64__"

defined if the compiler supports 32-bit double (respectively 64-bit double) 🦋 the actual layout is specified by option -mdouble=.

"__DEFAULT_DOUBLE__"

the size in bits of double if -mdouble= is not set 🌸 if you want to test the layout of double in a program, use the built-in macro __SIZEOF_DOUBLE__ 💅

"__HAVE_LONG_DOUBLE32__" "__HAVE_LONG_DOUBLE64__" "__HAVE_LONG_DOUBLE_MULTILIB__" "__DEFAULT_LONG_DOUBLE__"

same vibe as above, but for long double instead of double 🍓

"__WITH_DOUBLE_COMPARISON__"

this one reflects the --with-double-comparison={tristate|bool|libf7} configure option (https://gcc.gnu.org/install/configure.html#avr) and is defined to 2 or 3 ✨

"__WITH_LIBF7_LIBGCC__" "__WITH_LIBF7_MATH__" "__WITH_LIBF7_MATH_SYMBOLS__"

these reflect the --with-libf7={libgcc|math|math-symbols} configure option (https://gcc.gnu.org/install/configure.html#avr) 🫧

---

✨ AVR Internal Options ✨

okay bestie, these are used internally by the compiler and to chat with device specs files and the compiler proper 🫶 you don't need to set them by hand. they are not optimization options, fr 💀

using these options the wrong way may lead to sub-optimal or wrong code. they're documented for completeness, and so you can better understand device specs (https://gcc.gnu.org/wiki/avr-gcc#spec-files) files 😭

• -mn-flash=num — assumes the flash memory has a size of num times 64 KiB 🌈 this decides which __flashN address spaces are available.
• -mflmap — the device has the FLMAP bit field sitting in the special function register NVMCTRL_CTRLB 💜
• -mrmw — assumes the device supports the Read-Modify-Write instructions XCH, LAC, LAS and LAT 🔥
• -mshort-calls — assumes RJMP and RCALL can target the whole program memory 🦋 this is used for multilib generation and selection for the devices from architecture avrxmega3.
• -mskip-bug — generates code without skips (CPSE, SBRS, SBRC, SBIS, SBIC) over 32-bit instructions 🙈
• -msp8 — treats the stack pointer register as an 8-bit register, i.e. assumes the high byte of the stack pointer is zero 🌸 the compiler uses this to select and build multilibs for architectures avr2 and avr25, since those mix devices with and without SPH 🍓

---

🌈 Blackfin Options 🌈

• -mcpu=cpu[-sirevision] — picks the target Blackfin processor 👑 right now cpu can be one of bf512, bf514, bf516, bf518, bf522, bf523, bf524, bf525, bf526, bf527, bf531, bf532, bf533, bf534, bf536, bf537, bf538, bf539, bf542, bf544, bf547, bf548, bf549, bf542m, bf544m, bf547m, bf548m, bf549m, bf561, bf592.

the optional sirevision is the silicon revision of the target Blackfin processor 💅 any workarounds for that revision get enabled. if sirevision is none, no workarounds are enabled. if it's any, all workarounds for the targeted processor are enabled. the __SILICON_REVISION__ macro is defined to two hexadecimal digits representing the major and minor numbers in the silicon revision ✨ if sirevision is none, __SILICON_REVISION__ is not defined at all. if it's any, __SILICON_REVISION__ is defined to be 0xffff. if you skip this optional sirevision, GCC assumes the latest known silicon revision of the targeted Blackfin processor 🫶

GCC defines a preprocessor macro for the specified cpu 🧚 for the bfin-elf toolchain, this option causes the hardware BSP provided by libgloss to be linked in if -msim is not given.

without this option, bf532 is used as the processor by default 🎀

note that support for bf561 is incomplete 😭 for bf561, only the preprocessor macro is defined.

• -msim — specifies that the program will be run on the simulator 🔮 this causes the simulator BSP provided by libgloss to be linked in. it only has effect for the bfin-elf toolchain. certain other options, such as -mid-shared-library and -mfdpic, imply -msim 💖
• -momit-leaf-frame-pointer — don't keep the frame pointer in a register for leaf functions 🦋 this skips the instructions to save, set up and restore frame pointers and frees up an extra register in leaf functions ✨
• -mspecld-anomaly — when enabled, the compiler makes sure the generated code doesn't contain speculative loads after jump instructions 🛡️ if you use this option, __WORKAROUND_SPECULATIVE_LOADS is defined.
• -mno-specld-anomaly — don't generate extra code to stop speculative loads from happening 🙅‍♀️
• -mcsync-anomaly — when enabled, the compiler makes sure the generated code doesn't contain CSYNC or SSYNC instructions too soon after conditional branches 💜 if you use this option, __WORKAROUND_SPECULATIVE_SYNCS is defined.
• -mno-csync-anomaly — don't generate extra code to stop CSYNC or SSYNC instructions from happening too soon after a conditional branch 🙈
• -mlow64k — when enabled, the compiler is free to take advantage of knowing the entire program fits into the low 64k of memory 🍓
• -mno-low64k — assumes the program is arbitrarily large 🌸 this is the default.
• -mstack-check-l1 — does stack checking using information placed into L1 scratchpad memory by the uClinux kernel 🧚
• -mid-shared-library — generates code that supports shared libraries via the library ID method 🎀 this lets you execute in place and use shared libraries in an environment without virtual memory management. this option implies -fPIC, and with a bfin-elf target it also implies -msim 💅
• -mno-id-shared-library — generates code that doesn't assume ID-based shared libraries are being used 💖 this is the default.
• -mleaf-id-shared-library — generates code that supports shared libraries via the library ID method, but assumes this library or executable won't link against any other ID shared libraries 🦋 that lets the compiler use faster code for jumps and calls ⭐
• -mno-leaf-id-shared-library — don't assume the code being compiled won't link against any ID shared libraries 🐢 slower code gets generated for jump and call insns.
• -mshared-library-id=n — specifies the identification number of the ID-based shared library being compiled 🔥 specifying 0 generates more compact code 🫶 specifying other values forces the allocation of that number to the current library, but it's no more space- or time-efficient than omitting this option.
• -msep-data — generates code that lets the data segment live in a different area of memory from the text segment 🌈 this allows execute in place in an environment without virtual memory management, by getting rid of relocations against the text section 🧚
• -mno-sep-data — generates code that assumes the data segment follows the text segment 💜 this is the default.
• -mlong-calls, -mno-long-calls — tells the compiler to do function calls by first loading the function's address into a register, and then doing a subroutine call on that register 📞 you need this switch if the target function lies outside the 24-bit addressing range of the offset-based version of the subroutine call instruction 😭

this feature is not enabled by default. -mno-long-calls restores the default behavior 🙅‍♀️ also note these switches have no effect on how the compiler handles function calls via function pointers 💀

• -mfast-fp — links with the fast floating-point library 🏎️ this library relaxes some of the IEEE floating-point standard's rules for checking inputs against Not-a-Number (NAN), in the interest of performance 🌸
• -minline-plt — enables inlining of PLT entries in function calls to functions that aren't known to bind locally 🦋 it has no effect without -mfdpic.
• -mmulticore — builds a standalone application for multicore Blackfin processors 👑 this makes sure the proper start files and link scripts supporting multicore get used, and defines the macro __BFIN_MULTICORE. it can only be used with -mcpu=bf561[-sirevision] 🫧

this option can be combined with -mcorea or -mcoreb, which select the one-application-per-core programming model 💅 without -mcorea or -mcoreb, the single-application/dual-core programming model is used instead. in this model, the main function of Core B should be named coreb_main 🧚

if you don't use this option, the single-core application programming model is used 🎀

• -mcorea — Builds a standalone app for Core A of BF561 when you're doing the one-application-per-core thing. It swaps in the right start files and link scripts for Core A and defines the macro "__BFIN_COREA" for you ✨. This one only works alongside -mmulticore 🫶.
• -mcoreb — Same deal, but for Core B of BF561 in the one-application-per-core setup. It uses the Core B start files and link scripts and defines "__BFIN_COREB". When you turn this on, your entry point has to be "coreb_main" instead of "main" 🙈. It also only works with -mmulticore 💜.
• -msdram — Builds a standalone app that runs out of SDRAM 🧚. The start files and link scripts put the app in SDRAM and the macro "__BFIN_SDRAM" gets defined. Your loader has to initialize SDRAM before it loads the app, so don't skip that step bestie 😭.
• -micplb — Tells GCC to assume ICPLBs are enabled at run time 🌸. That changes how certain anomaly workarounds behave. For Linux targets it assumes ICPLBs are on by default, but for standalone apps the default is off.

---

🦋 C6X Options 🦋

• -march=name — Picks the target architecture, and GCC uses it to decide which instructions it's allowed to emit when it generates assembly 💅. The names you can use are c62x, c64x, c64x+, c67x, c67x+, and c674x.
• -mbig-endian — Generates code for a big-endian target 🍓.
• -mlittle-endian — Generates code for a little-endian target. This is the default, so you're already slay 👑.
• -msim — Picks startup files and a linker script that work with the simulator 🎀.
• -msdata=default — Small global and static data goes in the ".neardata" section, which B14 points to ✨. Small uninitialized global and static data goes in ".bss", right next to ".neardata". Small read-only data goes in ".rodata". For the big stuff, the matching sections are ".fardata", ".far", and ".const".
• -msdata=all — Shoves all data into the small-data sections, not just the tiny stuff, and accesses it relative to the B14 register 🔥.
• -msdata=none — No small-data sections at all 💀. Every access uses absolute addresses. All initialized global and static data goes in ".fardata", all uninitialized data goes in ".far", and all constant data goes in ".const".

---

🌈 CRIS Options 🌈

These options are made specifically for the CRIS ports, so they only show up in that world 🧚.

• -march=architecture-type, -mcpu=architecture-type — Generates code for the architecture you name ⭐. The choices are v3, v8, and v10, which map to ETRAX 4, ETRAX 100, and ETRAX 100 LX. The default is v0.
• -mtune=architecture-type — Tunes everything that can be tuned in the generated code to the architecture you pick 🦋. The ABI and the set of available instructions stay the same though. Your choices are the same as for -march=architecture-type.
• -mmax-stack-frame=n — Gives you a warning if a function's stack frame goes over n bytes 😭.
• -metrax4, -metrax100 — These two are just nicknames: -metrax4 means -march=v3, and -metrax100 means -march=v8 💖.
• -mmul-bug-workaround, -mno-mul-bug-workaround — Works around a bug in the "muls" and "mulu" instructions on the CPU models where it actually applies 🙈. It's off by default.
• -mpdebug — Turns on CRIS-specific verbose debug info in the assembly code ✨. It also turns off the #NO_APP formatted-code marker that normally sits at the top of the assembly file for the assembler.
• -mcc-init — Stops GCC from reusing condition-code results from the previous instruction 💅. Instead it always emits compare and test instructions before using condition codes.
• -mno-side-effects — No instructions with side effects in addressing modes, unless it's post-increment 🫶.
• -mstack-align, -mno-stack-align, -mdata-align, -mno-data-align, -mconst-align, -mno-const-align — The non-no- versions make the stack frame, individual data, and constants line up to the biggest single data access size your chosen CPU model supports 🎀. The no- versions undo that. By default everything is aligned to 32 bits. ABI stuff like structure layout doesn't change with any of these 💜.
• -m32-bit, -m16-bit, -m8-bit — Same vibe as the align options above, but these set the alignment of stack frames, writable data, and constants to 32, 16, or 8 bits 🌸. The default is 32-bit.
• -mno-prologue-epilogue, -mprologue-epilogue — With -mno-prologue-epilogue, GCC skips the usual function prologue and epilogue that set up the stack frame ⚠️. It also won't generate any return instructions or return sequences. Only use this if you're going to eyeball the compiled code yourself, because GCC won't warn or error when call-saved registers need saving or when local variables need storage 💀.
• -melf — A legacy no-op, so it does nothing 🙈.
• -sim — Links with the input-output functions from a simulator library 🧚. Code, initialized data, and zero-initialized data get allocated one right after the other.
• -sim2 — Like -sim, but it also passes linker options so initialized data lands at 0x40000000 and zero-initialized data lands at 0x80000000 🔥.

---

🌸 C-SKY Options 🌸

GCC supports these when you're compiling for C-SKY V2 processors 🦋.

• -march=arch — Specifies the C-SKY target architecture. The valid values are ck801, ck802, ck803, ck807, and ck810. The default is ck810 💅.
• -mcpu=cpu — Specifies the C-SKY target processor. Valid values for cpu are: ck801, ck801t, ck802, ck802t, ck802j, ck803, ck803h, ck803t, ck803ht, ck803f, ck803fh, ck803e, ck803eh, ck803et, ck803eht, ck803ef, ck803efh, ck803ft, ck803eft, ck803efht, ck803r1, ck803hr1, ck803tr1, ck803htr1, ck803fr1, ck803fhr1, ck803er1, ck803ehr1, ck803etr1, ck803ehtr1, ck803efr1, ck803efhr1, ck803ftr1, ck803eftr1, ck803efhtr1, ck803s, ck803st, ck803se, ck803sf, ck803sef, ck803seft, ck807e, ck807ef, ck807, ck807f, ck810e, ck810et, ck810ef, ck810eft, ck810, ck810v, ck810f, ck810t, ck810fv, ck810tv, ck810ft, and ck810ftv 🎀.
• -mbig-endian, -EB, -mlittle-endian, -EL — Picks big-endian or little-endian code 🫶. Little-endian is the default.
• -mfloat-abi=name — Picks which floating-point ABI to use. The options are soft, softfp, and hard 🔥.

soft makes GCC generate output that calls library functions for floating-point math. softfp lets it use hardware floating-point instructions but still follows the soft-float calling conventions. hard gives you floating-point instructions and uses FPU-specific calling conventions 💜.

The default depends on your specific target configuration. Heads up though: the hard-float and soft-float ABIs are not link-compatible 😭. You have to compile your whole program with the same ABI and link it against a compatible set of libraries.

• -mhard-float, -msoft-float — Picks hardware or software floating-point implementations 🦋. The default is soft float.
• -mdouble-float, -mno-double-float — When -mhard-float is on, this enables double-precision float instructions ✨. It's the default except when compiling for CK803.
• -mfdivdu, -mno-fdivdu — When -mhard-float is on, this enables the "frecipd", "fsqrtd", and "fdivd" instructions 🧚. It's the default except when compiling for CK803.
• -mfpu=fpu — Picks the floating-point processor 💅. This one only works with -mhard-float. The values for fpu are fpv2_sf (which is the same as -mno-double-float -mno-fdivdu), fpv2 (which is -mdouble-float -mno-divdu), and fpv2_divd (which is -mdouble-float -mdivdu).
• -melrw, -mno-elrw — Enables the extended "lrw" instruction 🌈. It defaults to on for CK801 and off for everything else.
• -mistack, -mno-istack — Enables interrupt stack instructions 🔥. The default is off.

The -mistack option is required if you want to handle the "interrupt" and "isr" function attributes 💀.

• -mmp — Enables multiprocessor instructions. Default is off 🫶.
• -mcp — Enables coprocessor instructions. Default is off 🎀.
• -mcache — Also enables coprocessor instructions. Default is off 🙈.
• -msecurity — Enables C-SKY security instructions. Default is off 🔐.
• -mtrust — Enables C-SKY trust instructions. Default is off ✨.
• -mdsp, -medsp, -mvdsp — These turn on C-SKY DSP, Enhanced DSP, or Vector DSP instructions, in that order 💜. All of them default to off.
• -mdiv, -mno-div — Generates divide instructions. Default is off 🦋.
• -msmart, -mno-smart — Generates code for Smart Mode, which only uses registers numbered 0-7 so you can use 16-bit instructions 🧚. This gets ignored for CK801, where that's already the required behavior, and it defaults to on for CK802. For other targets the default is off.
• -mhigh-registers, -mno-high-registers — Generates code that uses the high registers numbered 16-31 🌟. This isn't supported on CK801, CK802, or CK803, and it's enabled by default on other processors.
• -manchor, -mno-anchor — Generates code that uses global anchor symbol addresses ⭐.
• -mpushpop, -mno-pushpop — Generates code using "push" and "pop" instructions 💅. It defaults to on.
• -mmultiple-stld, -mstm, -mno-multiple-stld, -mno-stm — Generates code using "stm" and "ldm" instructions 🎀. This isn't supported on CK801, but it's enabled by default on other processors.
• -mconstpool, -mno-constpool — Creates constant pools in the compiler, instead of leaving it to the assembler 🫶. This is the default, and it's required for correct code generation on CK801 and CK802. It's optional on other processors.
• -mstack-size, -mno-stack-size — Emits ".stack_size" directives for each function in the assembly output 🌈. It defaults to off.
• -mccrt, -mno-ccrt — Generates code for the C-SKY compiler runtime instead of libgcc 💖. It defaults to off.
• -mbranch-cost=n — Sets the branch costs to roughly n instructions 🍓. The default is 1.
• -msched-prolog, -mno-sched-prolog — okay so these let you turn on scheduling for function prologue and epilogue sequences 🧚 Heads up, though: this can produce code that doesn't follow the C-SKY V2 ABI prologue rules, and you won't be able to debug it or backtrace through it 😭 It's off by default, so you'd have to opt in on purpose.
• -msim — this links in the library libsemi.a, which is compatible with the simulator 💻 It only applies to the ELF compiler, so don't expect it anywhere else 🌸

✨ Cygwin and MinGW Options ✨

These extra options are for Microsoft Windows targets 🪟💖

• -mconsole — this tells the linker to set the PE header subsystem type to console, so you get a console application 🖥️ It works for Cygwin and MinGW targets and is already on by default there 🫶
• -mcrtdll=library — this one is kind of a big deal 👑 It preprocesses, compiles or links with the C RunTime DLL library you name. It changes the predefined macros "__CRTDLL__", "__MSVCRT__", "_UCRT" and "__MSVCRT_VERSION__" for that CRT library, picks the start file for it, and links against it too. The CRT library names the preprocessor recognises are "crtdll*", "msvcrt10*", "msvcrt20*", "msvcrt40*", "msvcr40*", "msvcrtd*", "msvcrt-os*", "msvcr70*", "msvcr71*", "msvcr80*", "msvcr90*", "msvcr100*", "msvcr110*", "msvcr120*" and "ucrt*" ✨ If you don't use this option, the default MinGW import library "msvcrt" gets used for linking, and the preprocessor doesn't get any adjustments. That "msvcrt" library is just a symlink to, or a copy of, another MinGW CRT import library that gets picked when MinGW is compiled 🔗 The "msvcrt-os" library is for the Windows system CRT DLL "msvcrt.dll", and it's usually the default MinGW import library 🏠 Generally speaking, switching the CRT DLL means recompiling the entire MinGW CRT, so this is strictly for experiments and testing 🧪 It's only for MinGW targets.
• -mdll — this one's for Cygwin and MinGW targets 🦋 It makes a DLL, which is a dynamic link library, and lets you pick the runtime startup object and entry point you need.
• -mnop-fun-dllimport — available for Cygwin and MinGW targets 🙈 It tells GCC to ignore the "dllimport" attribute.
• -mthreads — for MinGW targets only 🧵 It turns on MinGW-specific thread support.
• -municode — for MinGW-w64 targets 🌈 It predefines the "UNICODE" preprocessor macro and picks Unicode-capable runtime startup code.
• -mwin32 — for Cygwin and MinGW targets 🎀 It sets the typical Microsoft Windows predefined macros in the preprocessor, but it doesn't change which runtime library or startup code gets chosen.
• -mwindows — for Cygwin and MinGW targets 🪟 It makes a GUI application by telling the linker to set the PE header subsystem type to match.
• -fno-set-stack-executable — for MinGW targets 🔒 It means the executable flag isn't set for the stack that nested functions use. This matters for binaries running in Microsoft Windows kernel mode, because the User32 API that sets executable privileges isn't available there 💀
• -fwritable-relocated-rdata — for MinGW and Cygwin targets 💜 It puts relocated data from a read-only section into the ".data" section. This is needed for older runtimes that can't modify ".rdata" sections for pseudo-relocation.
• -mpe-aligned-commons — for Cygwin and MinGW targets ✨ It uses the GNU extension to the PE file format that lets COMMON variables be aligned correctly when generating code. It's on by default if GCC detects that the target assembler found during configuration supports the feature 🫶

See also under x86 Options for standard options 🔗

---

🍎 Darwin Options 🍎

These options are defined for every architecture running the Darwin operating system 🌸

FSF GCC on Darwin doesn't make "fat" object files 🙅‍♀️ It makes an object file for the single architecture that GCC was built to target. Apple's GCC on Darwin does make "fat" files when you use multiple -arch options 💖 It does this by running the compiler or linker several times and joining the results together with lipo.

The subtype of the file (like ppc7400, ppc970 or i686) comes from the flags that specify the ISA GCC is targeting, like -mcpu or -march ✨ The -force_cpusubtype_ALL option can override that.

The Darwin tools act differently when they hit an ISA mismatch 👀 The assembler, as, only lets you use instructions that are valid for the subtype of the file it's making, so you can't put 64-bit instructions in a ppc750 object file 🚫 The linker for shared libraries, /usr/bin/libtool, fails and prints an error if you ask it to make a shared library with a less restrictive subtype than its input files. For instance, trying to put a ppc970 object file in a ppc7400 library is a no-go 😭 The linker for executables, ld, quietly gives the executable the most restrictive subtype of any of its input files 🤫

• -Fdir — this adds the framework directory dir to the front of the list of directories searched for header files 📂 These directories get mixed in with the ones from -I options, and they're scanned left to right 👈

A framework directory is just a directory full of frameworks 🧚 A framework is a directory with a Headers and/or PrivateHeaders directory right inside it, and its name ends in .framework. The framework's name is that directory's name without the .framework part. Headers for the framework live in one of those two directories, and Headers gets searched first 🥰 A subframework is a framework directory that sits inside a framework's Frameworks directory. Including subframework headers only works from a header inside the framework that holds the subframework, or from a sibling subframework header. Two subframeworks are siblings if they live in the same framework 👯 A subframework shouldn't share a name with a framework, and if it does, you'll get a warning ⚠️ Right now a subframework can't have subframeworks of its own, but that might get added later 🔮 The standard frameworks live in /System/Library/Frameworks and /Library/Frameworks 🏛️ An example include looks like #include <Framework/header.h>, where Framework is the framework's name and header.h is found in the PrivateHeaders or Headers directory 💅

• -iframeworkdir — this is like -F, except the directory gets treated as a system directory 🛠️ The big difference is that with -iframework, the compiler won't warn you about stuff inside header files found through dir 🙈 This only works for the C family of languages.
• -gused — this emits debugging info for symbols that are actually used 🔍 For the stabs debugging format, it turns on -feliminate-unused-debug-symbols. It's ON by default ✅
• -gfull — this emits debugging info for every symbol and type 📚
• -fconstant-cfstrings — this is just an alias for -mconstant-cfstrings 🎀
• -mconstant-cfstrings — when the NeXT runtime is in use (which is the default on these systems), this overrides any -fconstant-string-class setting and makes "@"..."" literals get laid out as constant CoreFoundation strings 💜
• -mmacosx-version-min=version — this sets the earliest version of MacOS X that the executable will run on 🍏 Typical values for version include 12, 10.12, and 10.5.8 🌈

If the compiler was built to use the system's headers by default, the default for this option is the system version the compiler is running on ✨ Otherwise, the default is to make choices that are compatible with as many systems and code bases as possible 🫶

• -mkernel — this turns on kernel development mode 🧑‍💻 It sets -static, -fno-common, -fno-use-cxa-atexit, -fno-exceptions, -fno-non-call-exceptions, -fapple-kext, -fno-weak and -fno-rtti where they apply. It also sets -mno-altivec, -msoft-float, -fno-builtin and -mlong-branch for PowerPC targets 💅
• -mone-byte-bool — this overrides the defaults for "bool" so that sizeof(bool)==1 🎯 By default sizeof(bool) is 4 when compiling for Darwin/PowerPC and 1 when compiling for Darwin/x86, so this option does nothing on x86.

Warning: The -mone-byte-bool switch makes GCC generate code that isn't binary compatible with code generated without it 😱 You may have to recompile all the other modules in a program, including system libraries, if you use it. Only use this switch when you need to match a non-default data model 💀

• -mfix-and-continue, -ffix-and-continue, -findirect-data — these generate code built for quick turnaround development 🔥 For example, they let GDB dynamically load .o files into programs that are already running ⚡ -findirect-data and -ffix-and-continue are only here for backwards compatibility 🕰️
• -all_load — this loads every member of static archive libraries 📦 See man ld(1) for more information 🔗
• -arch_errors_fatal — this makes errors about files with the wrong architecture fatal 🚨
• -bind_at_load — this marks the output file so the dynamic linker binds all undefined references when the file is loaded or launched 🪄
• -bundle — this produces a Mach-o bundle format file 🎁 See man ld(1) for more information.
• -bundle_loader executable — this names the executable that will load the build output file being linked 🫶 See man ld(1) for more information.
• -dynamiclib — when you pass this, GCC makes a dynamic library instead of an executable when linking, using the Darwin libtool command 🦋
• -force_cpusubtype_ALL — this gives GCC's output file the ALL subtype, instead of the one that -mcpu or -march would pick 🌟

Okay so the Darwin linker bit is next, and bestie, there are SO many of these 💅🌸

Quick heads up: all of these get handed straight to the Darwin linker, so if you want the full lowdown on each one, go read that linker's man page 🧚

---

• -nodefaultrpaths — Ngl this one is kinda important 🙈 It stops GCC from tossing default run paths for the compiler library directories into your executables, modules, or dynamic libraries. On macOS 10.5 and later, the embedded runpath gets added automatically unless you add -nodefaultrpaths to your link line. Run paths are needed (so they're enforced!) to build on macOS 10.11 or later ✨

Now here's the whole squad of Darwin linker options, and they all share the same vibe 👑

• -allowable_client client_name
• -client_name
• -compatibility_version
• -current_version
• -dead_strip
• -dependency-file
• -dylib_file
• -dylinker_install_name
• -dynamic
• -exported_symbols_list
• -filelist
• -flat_namespace
• -force_flat_namespace
• -headerpad_max_install_names
• -image_base
• -init
• -install_name
• -keep_private_externs
• -multi_module
• -multiply_defined
• -multiply_defined_unused
• -noall_load
• -no_dead_strip_inits_and_terms
• -nofixprebinding
• -nomultidefs
• -noprebind
• -noseglinkedit
• -pagezero_size
• -prebind
• -prebind_all_twolevel_modules
• -private_bundle
• -read_only_relocs
• -sectalign
• -sectobjectsymbols
• -whyload
• -seg1addr
• -sectcreate
• -sectobjectsymbols
• -sectorder
• -segaddr
• -segs_read_only_addr
• -segs_read_write_addr
• -seg_addr_table
• -seg_addr_table_filename
• -seglinkedit
• -segprot
• -segs_read_only_addr
• -segs_read_write_addr
• -single_module
• -static
• -sub_library
• -sub_umbrella
• -twolevel_namespace
• -umbrella
• -undefined
• -unexported_symbols_list
• -weak_reference_mismatches
• -whatsloaded

These get passed straight to the Darwin linker, which has the full deep dive on each one 🦋

---

✨ DEC Alpha Options ✨

These -m options are defined for the DEC Alpha implementations 💜

• -mno-soft-float
• -msoft-float — Okay so these two are opposites bestie 🫶 One uses the hardware floating-point instructions for floating-point ops, the other doesn't. With -msoft-float, functions in libgcc.a do the floating-point work instead. Unless those get replaced with routines that emulate the floating-point operations, or get compiled to call those emulation routines, these routines issue floating-point operations. So if you're compiling for an Alpha without floating-point operations, you have to make sure the library is built so it doesn't call them 😭

Also, Alpha implementations without floating-point operations are still required to have floating-point registers, so keep that in mind 🌸

• -mfp-reg
• -mno-fp-regs — Generates code that uses (or doesn't use) the floating-point register set. -mno-fp-regs implies -msoft-float. If the set isn't used, floating-point operands get passed in integer registers as if they were integers, and floating-point results get passed in $0 instead of $f0. This is a non-standard calling sequence, so any function with a floating-point argument or return value that gets called by code compiled with -mno-fp-regs also has to be compiled with that option. Big rule, bestie 🚨

A typical use is building a kernel that doesn't use (and therefore doesn't need to save and restore) any floating-point registers 🧚

• -mieee — The Alpha architecture has floating-point hardware that's optimized for max performance, and it's mostly IEEE compliant. For full compliance though, it needs software help 🙄 This option makes fully IEEE-compliant code, EXCEPT the inexact-flag isn't maintained (see below). When it's on, the preprocessor macro "_IEEE_FP" gets defined during compilation. The code is less efficient, but it can correctly handle denormalized numbers and exceptional IEEE values like not-a-number and plus/minus infinity. Other Alpha compilers call this option -ieee_with_no_inexact 💅

DEBIAN SPECIFIC: This option is on by default for alpha-linux-gnu, unless -ffinite-math-only (which is part of the -ffast-math set) is specified. Why? Because the software functions in the GNU libc math libraries generate denormalized numbers, NaNs, and infs, and all of those will make a program SIGFPE when it tries to use the results without -mieee 💀

• -mieee-with-inexact — This is like -mieee, except the generated code also maintains the IEEE inexact-flag. Turn this on and the code implements fully-compliant IEEE math. On top of "_IEEE_FP", the preprocessor macro "_IEEE_FP_EXACT" also gets defined. On some Alpha implementations the code might run way slower than the default, and since there's very little code that depends on the inexact-flag, you should normally NOT specify this one 🙈 Other Alpha compilers call it -ieee_with_inexact ✨
• -mfp-trap-mode=trap-mode — Controls which floating-point related traps are enabled 🔥 Other Alpha compilers call this option -fptm trap-mode. The trap mode can be one of four values:
  • n — The default (normal) setting. The only traps enabled are the ones that can't be disabled in software (like the division by zero trap).
  • u — On top of everything n enables, underflow traps get enabled too.
  • su — Like u, but the instructions are marked as safe for software completion (see the Alpha architecture manual for details).
  • sui — Like su, but inexact traps are enabled as well.
• -mfp-rounding-mode=rounding-mode — Selects the IEEE rounding mode 🌈 Other Alpha compilers call this one -fprm rounding-mode. The rounding-mode can be one of:
  • n — Normal IEEE rounding mode. Floating-point numbers get rounded towards the nearest machine number, or towards the even machine number in case of a tie.
  • m — Round towards minus infinity.
  • c — Chopped rounding mode. Floating-point numbers get rounded towards zero.
  • d — Dynamic rounding mode. A field in the floating-point control register (fpcr, see the Alpha architecture reference manual) controls the rounding mode in effect. The C library sets this register up for rounding towards plus infinity. So unless your program messes with the fpcr, d means round towards plus infinity 🦋
• -mtrap-precision=trap-precision — Okay so on the Alpha architecture, floating-point traps are imprecise 😭 Without software help, you can't recover from a floating trap, and the program usually has to be terminated. GCC can generate code that helps OS trap handlers figure out the exact location that caused a floating-point trap. Depending on what your app needs, you can pick one of these precision levels:
  • p — Program precision. This is the default, and it means a trap handler can only tell which program caused the floating-point exception.
  • f — Function precision. The trap handler can figure out the function that caused a floating-point exception.
  • i — Instruction precision. The trap handler can figure out the exact instruction that caused a floating-point exception.

Other Alpha compilers have the equivalent options called -scope_safe and -resumption_safe ✨

• -mieee-conformant — This marks the generated code as IEEE conformant 📜 You must NOT use this unless you also specify -mtrap-precision=i AND either -mfp-trap-mode=su or -mfp-trap-mode=sui. Its only effect is to emit the line .eflag 48 in the function prologue of the generated assembly file.
• -mbuild-constants — Normally GCC looks at a 32- or 64-bit integer constant to see if it can build it from smaller constants in two or three instructions. If it can't, it outputs the constant as a literal and generates code to load it from the data segment at run time 🧩

Use this option to make GCC build ALL integer constants using code, even if that takes more instructions (the max is six). You'd typically use this to build a shared library dynamic loader. Since it's a shared library itself, it has to relocate itself in memory before it can find the variables and constants in its own data segment 💖

• -mbwx
• -mno-bwx
• -mcix
• -mno-cix
• -mfix
• -mno-fix
• -mmax
• -mno-max — Says whether GCC should generate code that uses the optional BWX, CIX, FIX, and MAX instruction sets 🍓 By default it uses whichever instruction sets the CPU type from -mcpu= supports, or the CPU GCC was built on if you don't specify one.
• -msafe-bwa
• -mno-safe-bwa — Says whether, when the optional BWX instruction set is missing, GCC should generate multi-thread and async-signal safe code for byte and aligned word memory accesses 🔐
• -msafe-partial
• -mno-safe-partial — Says whether GCC should generate multi-thread and async-signal safe code for partial memory accesses. That includes piecemeal accesses to unaligned data, plus block accesses to the leading and trailing parts of aggregate types or other objects in memory that don't respectively start and end on an aligned 64-bit data boundary 🫶
• -mfloat-vax
• -mfloat-ieee — Generates code that uses (or doesn't use) VAX F and G floating-point arithmetic instead of IEEE single and double precision 🎀
• -mexplicit-relocs
• -mno-explicit-relocs — Okay so older Alpha assemblers had no way to generate symbol relocations except through assembler macros, and those macros don't allow optimal instruction scheduling 😭 GNU binutils as of version 2.12 supports a new syntax that lets the compiler explicitly mark which relocations apply to which instructions. This option is mostly useful for debugging, since GCC detects the assembler's capabilities when it's built and sets the default accordingly 🧚
• -msmall-data
• -mlarge-data — When -mexplicit-relocs is in effect, static data gets accessed via gp-relative relocations. With -msmall-data, objects 8 bytes long or smaller get placed in a small data area (the ".sdata" and ".sbss" sections) and get accessed through 16-bit relocations off of the $gp register. This limits the small data area to 64KB, but the upside is the variables can be accessed directly with a single instruction, which is iconic 👑

The default is -mlarge-data, bestie 💖 With this on, the data area is capped at just under 2GB. If your program needs more than 2GB of data, it has to use malloc or mmap to grab memory from the heap instead of stuffing it into the program's data segment 🧠✨

When you're generating code for shared libraries, -fpic implies -msmall-data, and -fPIC implies -mlarge-data 🎀

• -msmall-text, -mlarge-text — 🦋 With -msmall-text, the compiler assumes the code for the whole program (or shared library) fits in 4MB, so everything is reachable with a branch instruction. With -msmall-data, the compiler can assume all local symbols share the same $gp value, which cuts the instructions needed for a function call from 4 down to 1. It's giving efficiency 😭

The default is -mlarge-text 💅

• -mcpu=cpu_type — 👑 Sets the instruction set and instruction scheduling parameters for the machine type cpu_type. You can use either the EV style name or the matching chip number. GCC has scheduling parameters for the EV4, EV5, and EV6 families, and it picks the default instruction set based on the processor you name. If you don't name a processor type, GCC just goes with whatever processor the compiler was built on 🌸

Supported values for cpu_type are:

• ev4, ev45, 21064 — Schedules as an EV4 and has no instruction set extensions 🍓
• ev5, 21164 — Schedules as an EV5 and has no instruction set extensions 🍓
• ev56, 21164a — Schedules as an EV5 and supports the BWX extension ✨
• pca56, 21164pc, 21164PC — Schedules as an EV5 and supports the BWX and MAX extensions ✨
• ev6, 21264 — Schedules as an EV6 and supports the BWX, FIX, and MAX extensions 🔥
• ev67, 21264a — Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX extensions 🔥

Native toolchains also support the value native, which picks the best architecture option for the host processor. -mcpu=native does nothing if GCC doesn't recognize the processor 🙈

• -mtune=cpu_type — 🎯 Only sets the instruction scheduling parameters for the machine type cpu_type. The instruction set stays exactly the same.

Native toolchains also support the value native, which picks the best architecture option for the host processor. -mtune=native does nothing if GCC doesn't recognize the processor 💜

• -mmemory-latency=time — 🧚 Sets the latency the scheduler should assume for typical memory references as the application sees them. This number really depends on the memory access patterns the application uses and how big the external cache is on the machine. Lowkey a vibe-check number 📊

Valid options for time are:

• number — A decimal number representing clock cycles 🔢
• L1, L2, L3, main — The compiler has estimates of clock cycles for "typical" EV4 & EV5 hardware for the Level 1, 2, and 3 caches (also called Dcache, Scache, and Bcache), plus main memory. Note that L3 is only valid for EV5 🫶

✨ eBPF Options ✨

• -mframe-limit=bytes — 🚧 Specifies the hard limit for frame sizes, in bytes. Right now the value you pass should be less than or equal to 32767. It defaults to whatever limit the targeted version of the Linux kernel imposes 🐧
• -mbig-endian — 🌈 Generates code for a big-endian target 💅
• -mlittle-endian — 🌈 Generates code for a little-endian target. This is the default 💖
• -mjmpext, -mno-jmpext — 🦋 Enables or disables generation of extra conditional-branch instructions. Enabled for CPU v2 and above 🔥
• -mjmp32, -mno-jmp32 — 🦋 Enables or disables generation of 32-bit jump instructions. Enabled for CPU v3 and above 🔥
• -malu32, -mno-alu32 — 🦋 Enables or disables generation of 32-bit ALU instructions. Enabled for CPU v3 and above 🔥
• -mv3-atomics, -mno-v3-atomics — ⚛️ Enables or disables instructions for general atomic operations introduced in CPU v3. Enabled for CPU v3 and above 🔥
• -mbswap, -mno-bswap — 🔄 Enables or disables byte swap instructions. Enabled for CPU v4 and above 👑
• -msdiv, -mno-sdiv — ➗ Enables or disables signed division and modulus instructions. Enabled for CPU v4 and above 👑
• -msmov, -mno-smov — 🚚 Enables or disables sign-extending move and memory load instructions. Enabled for CPU v4 and above 👑
• -mcpu=version — 🎀 Specifies which version of the eBPF ISA to target. Newer versions might not be supported by every kernel. The default is v4.

Supported values for version are:

• v1 — The first stable eBPF ISA, with no special features or extensions 🍼
• v2 — Supports the jump extensions, as in -mjmpext 🌱
• v3 — All features of v2, plus:
  • -<32-bit jump operations, as in -mjmp32>
  • -<32-bit ALU operations, as in -malu32>
  • -<general atomic operations, as in -mv3-atomics>
• v4 — All features of v3, plus:
  • -<Byte swap instructions, as in -mbswap>
  • -<Signed division and modulus instructions, as in -msdiv>
  • -<Sign-extending move and memory load instructions, as in -msmov>
• -mco-re — 🧠 Enables BPF Compile Once - Run Everywhere (CO-RE) support. It requires and is implied by -gbtf 🫶
• -mno-co-re — 🙅 Disables BPF Compile Once - Run Everywhere (CO-RE) support. BPF CO-RE support is enabled by default when generating BTF debug information for the BPF target 🙈
• -mxbpf — 🚀 Generates code for an expanded version of BPF, which relaxes some of the restrictions the BPF architecture imposes. It can:
  • -<Save and restore callee-saved registers at function entry and exit, respectively.>
• -masm=dialect — 📝 Outputs assembly instructions using the selected eBPF dialect. The default is pseudoc 💅

Supported values for dialect are:

• normal — Outputs the normal assembly dialect 🍓
• pseudoc — Outputs the pseudo-C assembly dialect 🍓
• -minline-memops-threshold=bytes — 📏 Specifies a size threshold in bytes at or below which memmove, memcpy, and memset are always expanded inline. Operations dealing with sizes bigger than this threshold would have to use a library call instead of being expanded inline. BPF doesn't allow libcalls, though, so going over this threshold is a compile-time error 💀 The default is 1024 bytes.

🧚 FR30 Options 🧚

These options are defined specifically for the FR30 port 🌸

• -msmall-model — 🔬 Uses the small address space model. This can produce smaller code, but it does assume that all symbolic values and addresses fit into a 20-bit range.
• -mno-lsim — 🛠️ Assumes runtime support has been provided, so there's no need to include the simulator library (libsim.a) on the linker command line.

🌷 FT32 Options 🌷

These options are defined specifically for the FT32 port 🦋

• -msim — 🖥️ Specifies that the program will run on the simulator. This links in an alternate runtime startup and library. You must not use this option when generating programs for real hardware. You have to provide your own runtime library for whatever I/O functions are needed 🚨
• -mlra — 🤷 Does nothing. Preserved for backward compatibility.
• -mnodiv — ➗ Do not use div and mod instructions.
• -mft32b — ✨ Enables use of the extended instructions of the FT32B processor.
• -mcompress — 🗜️ Compresses all code using the Ft32B code compression scheme.
• -mnopm — 🙅 Do not generate code that reads program memory.

🦋 FRV Options 🦋

• -mgpr-32 — Only uses the first 32 general-purpose registers 🧺
• -mgpr-64 — Uses all 64 general-purpose registers 🧺
• -mfpr-32 — Uses only the first 32 floating-point registers 🌊
• -mfpr-64 — Uses all 64 floating-point registers 🌊
• -mhard-float — Uses hardware instructions for floating-point operations 🔥
• -msoft-float — Uses library routines for floating-point operations 🧸
• -malloc-cc — Dynamically allocates condition code registers 🎲
• -mfixed-cc — Does not try to dynamically allocate condition code registers. It only uses icc0 and fcc0 📌
• -mdword — Changes the ABI to use double word instructions 👯
• -mno-dword — Does not use double word instructions 🙅
• -mdouble — Uses floating-point double instructions 💜
• -mno-double — Does not use floating-point double instructions 🙅
• -mmedia — Uses media instructions 🎬
• -mno-media — Does not use media instructions 🙅
• -mmuladd — Uses multiply and add/subtract instructions ➕
• -mno-muladd — Does not use multiply and add/subtract instructions 🙅
• -mfdpic — 🧩 Selects the FDPIC ABI, which uses function descriptors to represent pointers to functions. Without any PIC/PIE-related options, it implies -fPIE. With -fpic or -fpie, it assumes GOT entries and small data are within a 12-bit range from the GOT base address. With -fPIC or -fPIE, GOT offsets are computed with 32 bits. With a bfin-elf target, this option implies -msim 🫶
• -minline-plt — 🪄 Enables inlining of PLT entries in function calls to functions that are not known to bind locally. It has no effect without -mfdpic. It's enabled by default when optimizing for speed and compiling for shared libraries (i.e., -fPIC or -fpic), or when an optimization option such as -O3 or above is on the command line 🚀
• -mTLS — Assumes a large TLS segment when generating thread-local code 🧵
• -mtls — Does not assume a large TLS segment when generating thread-local code 🧵
• -mgprel-ro — 🔍 Enables the use of GPREL relocations in the FDPIC ABI for data known to be in read-only sections. It's enabled by default, except for -fpic or -fpie: even though it may make the global offset table smaller, it trades 1 instruction for 4. With -fPIC or -fPIE, it trades 3 instructions for 4, one of which may be shared by multiple symbols. It also avoids the need for a GOT entry for the referenced symbol, so it's more likely to be a win. If it isn't, -mno-gprel-ro can be used to disable it 🙌
• -multilib-library-pic — 📚 Links with the (library, not FD) pic libraries. It's implied by -mlibrary-pic, as well as by -fPIC and -fpic without -mfdpic. You should never have to use it explicitly 🙈
• -mlinked-fp — Sticks to the EABI rule that a frame pointer must always be created whenever a stack frame gets allocated. It's on by default, and you can turn it off with -mno-linked-fp 🦋
• -mlong-calls — Calls functions outside the current compilation unit through indirect addressing, so those functions can live anywhere in the 32-bit address space ✨
• -malign-labels — Tries to align labels to an 8-byte boundary by slipping NOPs into the previous packet 🌸. This only does anything when VLIW packing is on. It never makes new packets, it just adds NOPs to packets that already exist 🙈
• -mlibrary-pic — Generates position-independent EABI code 🧚
• -macc-4 — Only uses the first four media accumulator registers 💜
• -macc-8 — Uses all eight media accumulator registers 🔥
• -mpack — Packs VLIW instructions 📦
• -mno-pack — Does not pack VLIW instructions 🙅‍♀️
• -mno-eflags — Doesn't mark ABI switches in e_flags 🫶
• -mcond-move — Turns on conditional-move instructions. This is the default 💅

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-cond-move — Turns off conditional-move instructions 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mscc — Turns on conditional set instructions. This is the default ✨

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-scc — Turns off conditional set instructions 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mcond-exec — Turns on conditional execution. This is the default 🎀

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-cond-exec — Turns off conditional execution 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mvliw-branch — Runs a pass that packs branches into VLIW instructions. This is the default 🦋

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-vliw-branch — Skips that pass, so branches don't get packed into VLIW instructions 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mmulti-cond-exec — Turns on optimization of "&&" and "||" in conditional execution. This is the default 🌈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-multi-cond-exec — Turns off optimization of "&&" and "||" in conditional execution 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mnested-cond-exec — Turns on nested conditional execution optimizations. This is the default 🍓

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -mno-nested-cond-exec — Turns off nested conditional execution optimizations 🙈

This switch is mainly for debugging the compiler and will likely be removed in a future version. 💀

• -moptimize-membar — Removes redundant "membar" instructions from the compiler-generated code. It's on by default 🧹
• -mno-optimize-membar — Stops the automatic removal of redundant "membar" instructions from the generated code 🙅‍♀️
• -mtomcat-stats — Makes gas print out tomcat statistics 📊
• -mcpu=cpu — Picks the processor type you want code generated for. The options are frv, fr550, tomcat, fr500, fr450, fr405, fr400, fr300 and simple 👑

---

🐧 GNU/Linux Options 🐧

These -m options are defined for GNU/Linux targets 💖

• -mglibc — Uses the GNU C library. This is the default, except on *-*-linux-*uclibc*, *-*-linux-*musl* and *-*-linux-*android* targets 🌸
• -muclibc — Uses the uClibc C library. This is the default on *-*-linux-*uclibc* targets ✨
• -mmusl — Uses the musl C library. This is the default on *-*-linux-*musl* targets 🦋
• -mbionic — Uses the Bionic C library. This is the default on *-*-linux-*android* targets 🤖
• -mandroid — Compiles code that's compatible with the Android platform. This is the default on *-*-linux-*android* targets 📱

When compiling, this option turns on -mbionic, -fPIC, -fno-exceptions and -fno-rtti by default. When linking, it makes the GCC driver pass Android-specific options to the linker. And finally, it causes the preprocessor macro "__ANDROID__" to get defined 🫶

• -tno-android-cc — Undoes the compilation effects of -mandroid. That means it won't turn on -mbionic, -fPIC, -fno-exceptions and -fno-rtti by default 🙈
• -tno-android-ld — Undoes the linking effects of -mandroid, so the linker gets standard Linux linking options instead 🐧

---

🐍 H8/300 Options 🐍

These -m options are defined for the H8/300 implementations 💜

• -mrelax — Shortens some address references at link time when it's possible. It uses the linker option -relax 🧘‍♀️
• -mh — Generates code for the H8/300H 🌷
• -ms — Generates code for the H8S 💫
• -mn — Generates code for the H8S and H8/300H in the normal mode. This switch has to be used with either -mh or -ms 🎀
• -ms2600 — Generates code for the H8S/2600. This switch has to be used with -ms 🔥
• -mexr — Extended registers get stored on the stack before a function with the monitor attribute runs. The default option is -mexr. This option is only valid for H8S targets 📚
• -mno-exr — Extended registers do not get stored on the stack before a function with the monitor attribute runs. The default option is -mno-exr. This option is only valid for H8S targets 🙅‍♀️
• -mint32 — Makes "int" data 32 bits by default 💅
• -malign-300 — On the H8/300H and H8S, uses the same alignment rules as the H8/300. By default, the H8/300H and H8S align longs and floats on 4-byte boundaries, but -malign-300 makes them align on 2-byte boundaries instead. This option does nothing on the H8/300 🌸

---

🌿 HPPA Options 🌿

These -m options are defined for the HPPA family of computers 🖥️

• -march=architecture-type — Generates code for the architecture you specify. The choices for architecture-type are 1.0 for PA 1.0, 1.1 for PA 1.1, and 2.0 for PA 2.0 processors. To find the right architecture option for your machine on an HP-UX system, check /usr/lib/sched.models 🔍. Code compiled for lower-numbered architectures runs on higher-numbered ones, but not the other way around 🫶
• -mpa-risc-1-0, -mpa-risc-1-1, -mpa-risc-2-0 — These are synonyms for -march=1.0, -march=1.1, and -march=2.0 respectively 🦋
• -matomic-libcalls — Generates libcalls for atomic loads and stores when sync libcalls are disabled. This is on by default, and it only affects how the HPPA backend generates atomic libcalls ✨

Both the sync and libatomic libcall implementations use locking. Because of that, processor stores aren't atomic with respect to other atomic operations. Processor loads up to DImode are atomic with respect to other atomic operations, as long as they're implemented as a single access 🔒

The PA-RISC architecture doesn't support any atomic operations in hardware, except for the "ldcw" instruction. So all atomic support is implemented using sync and atomic libcalls. Sync libcall support lives in libgcc.a, and atomic libcall support lives in libatomic 📚

This option generates "__atomic_exchange" calls for atomic stores. It also gives special handling to atomic DImode accesses on 32-bit targets 🎀

• -mbig-switch — Does nothing. It's only kept around for backward compatibility 🕰️
• -mcaller-copies — The caller copies function arguments that get passed by hidden reference. Be careful with this one, because it isn't compatible with the default 32-bit runtime 🚨. The only aggregates passed by hidden reference are the ones larger than eight bytes, and this option gives you better compatibility with OpenMP 🌈
• -mcoherent-ldcw — Uses the ldcw/ldcd coherent cache-control hint 🧊
• -mdisable-fpregs — Disables the floating-point registers. It's equivalent to "-msoft-float" 🙈
• -mdisable-indexing — Stops the compiler from using indexing address modes. This avoids some rather obscure problems when compiling MIG generated code under MACH 🤓
• -mfast-indirect-calls — Generates code that assumes calls never cross space boundaries. That lets GCC emit code that does indirect calls faster ⚡

This option does not work in the presence of shared libraries or nested functions. 💀

• -mfixed-range=register-range — Generates code that treats the given register range as fixed registers. A fixed register is one the register allocator can't use, which is handy when you're compiling kernel code 🧑‍💻. You specify a register range as two registers separated by a dash, and you can list several ranges separated by a comma 🎀
• -mgas — Enables the use of assembler directives that only GAS understands 🦋
• -mgnu-ld — Uses options specific to GNU ld. It passes -shared to ld when building a shared library. This is the default when GCC is configured, explicitly or implicitly, with the GNU linker. This option doesn't affect which ld gets called. It only changes which parameters get passed to that ld 🔗. The ld that's called is decided by the --with-ld configure option, GCC's program search path, and finally the user's PATH 🗺️. You can see which linker GCC uses by running which gcc -print-prog-name=ld``. This option is only available on the 64-bit HP-UX GCC, i.e. configured with hppa*64*-*-hpux* 👑
• -mhp-ld — Uses options specific to HP ld. It passes -b to ld when building a shared library, and it passes +Accept TypeMismatch to ld on all links. This is the default when GCC is configured, explicitly or implicitly, with the HP linker. Like -mgnu-ld, it doesn't affect which ld gets called, only which parameters get passed to it 🫧. The ld that's called is decided by the --with-ld configure option, GCC's program search path, and finally the user's PATH. You can print the linker GCC uses with which gcc -print-prog-name=ld``. This option is only available on the 64-bit HP-UX GCC, i.e. configured with hppa*64*-*-hpux* 💜
• -mlinker-opt — Turns on the optimization pass in the HP-UX linker. Heads up, though: this makes symbolic debugging impossible 😭
• -mlong-calls — okay so this one tells GCC to generate long call sequences ✨, which guarantees a call can always reach linker-generated stubs 🧚. By default, long calls only show up when the distance from the call site to the start of the function or translation unit (depending on the case) goes past a limit set by the branch type in use. For normal calls those limits are 7,600,000 bytes on PA 2.0 and 240,000 bytes on PA 1.X. Sibcalls are always capped at 240,000 bytes 🙈.

Distances get measured from the beginning of functions when you use -ffunction-sections, or when you combine -mgas and -mno-portable-runtime under HP-UX with the SOM linker 💜.

Honestly? It's normally not a vibe to use this one, because it degrades performance 😭. It can still be useful in large applications, especially when partial linking is used to build the app 🫶.

The kind of long calls you get depends on what the assembler and linker can do, plus the type of code being generated. Systems that support long absolute calls, and long PIC symbol-difference or pc-relative calls, should only feel a small impact. BUT an indirect call is used on 32-bit ELF systems in PIC code, and it is quite long 💀.

• -mlong-load-store — generates 3-instruction load and store sequences, which the HP-UX 10 linker sometimes needs 🍓. It's the same thing as the +k option on the HP compilers.
• -mjump-in-delay — this one is ignored 🙈. It's only here for compatibility purposes.
• -mno-space-regs — tells GCC to assume the target has no space registers 🌸. That lets GCC generate faster indirect calls and use unscaled index address modes ⚡. This kind of code is suitable for level 0 PA systems and kernels 👑.
• -mordered — assumes memory references are ordered, so barriers aren't needed 🦋.
• -mportable-runtime — uses the portable calling conventions HP proposed for ELF systems 🌈.
• -mschedule=cpu-type — schedules code according to the constraints for the machine type cpu-type 🎀. The choices are 700, 7100, 7100LC, 7200, 7300 and 8000. If you're on an HP-UX system and want to figure out the right scheduling option for your machine, check out /usr/lib/sched.models 🔍. The default scheduling is 8000.
• -msio — generates the predefine _SIO for server IO 🖥️. The default is -mwsio, which instead generates the predefines __hp9000s700, __hp9000s700__ and _WSIO for workstation IO 💻. These options are available under HP-UX and HI-UX.
• -msoft-float — generates output that contains library calls for floating point 🔢.

Warning: the requisite libraries are NOT available for all HPPA targets 🚨. Normally the facilities of the machine's usual C compiler get used, but that can't be done directly in cross-compilation, so you need to make your own arrangements to provide suitable library functions for cross-compilation 😬.

-msoft-float changes the calling convention in the output file, so it's only useful if you compile all of a program with this option 🫠. In particular, you need to compile libgcc.a (the library that comes with GCC) with -msoft-float for this to work.

• -msoft-mult — uses software integer multiplication ✖️. This disables the use of the xmpyu instruction.
• -munix=unix-std — generates compiler predefines and selects a startfile for the specified UNIX standard 📜. The choices for unix-std are 93, 95 and 98. 93 is supported on all HP-UX versions. 95 is available on HP-UX 10.10 and later. 98 is available on HP-UX 11.11 and later. The defaults are 93 for HP-UX 10.00, 95 for HP-UX 10.10 through 11.00, and 98 for HP-UX 11.11 and later 🗓️.

-munix=93 provides the same predefines as GCC 3.3 and 3.4 🧁. -munix=95 gives you extra predefines for XOPEN_UNIX and _XOPEN_SOURCE_EXTENDED, plus the startfile unix95.o. -munix=98 adds predefines for _XOPEN_UNIX, _XOPEN_SOURCE_EXTENDED, _INCLUDE__STDC_A1_SOURCE and _INCLUDE_XOPEN_SOURCE_500, plus the startfile unix98.o ✨.

It is super important to know that this option changes the interfaces for various library routines 🙀. It also affects the operational behavior of the C library, so extreme care is needed when using it 🫣.

Library code that's meant to work with more than one UNIX standard has to test, set and restore the variable __xpg4_extended_mask as appropriate 🧠. Most GNU software doesn't provide this capability, btw.

• -nolibdld — suppresses the generation of link options that search libdld.sl when -static is specified on HP-UX 10 and later 🚫.
• -static — okay so HP-UX's implementation of setlocale in libc depends on libdld.sl 🧩, and there isn't an archive version of libdld.sl. That means when -static is specified, special link options are needed to resolve this dependency.

On HP-UX 10 and later, the GCC driver adds the necessary options to link with libdld.sl when -static is specified 🔗. This makes the resulting binary dynamic. On the 64-bit port, the linkers generate dynamic binaries by default anyway. If you want to stop the GCC driver from adding these link options, use -nolibdld 🙅‍♀️.

• -threads — adds support for multithreading with the DCE thread library under HP-UX 🧵. This option sets flags for both the preprocessor and the linker.

---

✨ IA-64 Options ✨

These are the -m options defined for the Intel IA-64 architecture 🌟.

• -mbig-endian — generates code for a big-endian target 🐘. This is the default for HP-UX.
• -mlittle-endian — generates code for a little-endian target 🐣. This is the default for AIX5 and GNU/Linux.
• -mgnu-as, -mno-gnu-as — generates (or doesn't) code for the GNU assembler 🛠️. This is the default.
• -mgnu-ld, -mno-gnu-ld — generates (or doesn't) code for the GNU linker 🔧. This is the default.
• -mno-pic — generates code that does not use a global pointer register 🚫. The result is not position independent code, and it violates the IA-64 ABI 😤.
• -mvolatile-asm-stop, -mno-volatile-asm-stop — generates (or doesn't) a stop bit immediately before and after volatile asm statements 🛑.
• -mregister-names, -mno-register-names — generates (or doesn't) in, loc, and out register names for the stacked registers 📛. This may make assembler output more readable 📖.
• -mno-sdata, -msdata — disables (or enables) optimizations that use the small data section 📦. This may be useful for working around optimizer bugs 🐛.
• -mconstant-gp — generates code that uses a single constant global pointer value 📌. This is useful when compiling kernel code 👑.
• -mauto-pic — generates code that is self-relocatable 🪄. This implies -mconstant-gp. It's useful when compiling firmware code 🧑‍💻.
• -minline-float-divide-min-latency — generates code for inline divides of floating-point values using the minimum latency algorithm ⏱️.
• -minline-float-divide-max-throughput — generates code for inline divides of floating-point values using the maximum throughput algorithm 🚀.
• -mno-inline-float-divide — does not generate inline code for divides of floating-point values 🙅.
• -minline-int-divide-min-latency — generates code for inline divides of integer values using the minimum latency algorithm ⏱️.
• -minline-int-divide-max-throughput — generates code for inline divides of integer values using the maximum throughput algorithm 🚀.
• -mno-inline-int-divide — does not generate inline code for divides of integer values 🙅.
• -minline-sqrt-min-latency — generates code for inline square roots using the minimum latency algorithm ⏱️.
• -minline-sqrt-max-throughput — generates code for inline square roots using the maximum throughput algorithm 🚀.
• -mno-inline-sqrt — does not generate inline code for sqrt 🙅.
• -mfused-madd, -mno-fused-madd — does (or doesn't) generate code that uses the fused multiply/add or multiply/subtract instructions 🧮. The default is to use these instructions 💖.
• -mno-dwarf2-asm, -mdwarf2-asm — doesn't (or does) generate assembler code for the DWARF line number debugging info 🔍. This may be useful when you're not using the GNU assembler.
• -mearly-stop-bits, -mno-early-stop-bits — allows stop bits to be placed earlier than immediately preceding the instruction that triggered the stop bit 🕰️. This can improve instruction scheduling, but it doesn't always do so 🤷‍♀️.
• -mfixed-range=register-range — generates code treating the given register range as fixed registers 📏. A fixed register is one that the register allocator cannot use. This is useful when compiling kernel code. A register range is specified as two registers separated by a dash, and you can specify multiple register ranges separated by a comma 🧩.
• -mtls-size=tls-size — specifies the bit size of immediate TLS offsets 📐. Valid values are 14, 22, and 64.
• -mtune=cpu-type — tunes the instruction scheduling for a particular CPU 🎯. Valid values are itanium, itanium1, merced, itanium2, and mckinley.
• -milp32, -mlp64 — generates code for a 32-bit or 64-bit environment 🌙. The 32-bit environment sets int, long and pointer to 32 bits. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits. These are HP-UX specific flags 🍎.
• -mno-sched-br-data-spec, -msched-br-data-spec — (dis/en)ables data speculative scheduling before reload 🔮. This results in generation of ld.a instructions and the corresponding check instructions (ld.c / chk.a). The default setting is disabled.
• -msched-ar-data-spec, -mno-sched-ar-data-spec — (en/dis)ables data speculative scheduling after reload 🔁. This results in generation of ld.a instructions and the corresponding check instructions (ld.c / chk.a). The default setting is enabled 💅.
• -mno-sched-control-spec, -msched-control-spec — (dis/en)ables control speculative scheduling 🧠. This feature is only available during region scheduling (i.e. before reload). It results in generation of the ld.s instructions and the corresponding check instructions chk.s. The default setting is disabled 🙈.

-msched-br-in-data-spec, -mno-sched-br-in-data-spec Okay so these two let you flip speculative scheduling for instructions that depend on data speculative loads before reload 🔥. It only does anything if -msched-br-data-spec is turned on too. Default is enabled ✨

• -msched-ar-in-data-spec, -mno-sched-ar-in-data-spec — Same energy, but this one controls speculative scheduling of those data-speculation-dependent instructions after reload 🧚. It only works when -msched-ar-data-spec is enabled. Default is enabled 💅
• -msched-in-control-spec, -mno-sched-in-control-spec — Toggles speculative scheduling for instructions that depend on the control speculative loads 🦋. This is only effective with -msched-control-spec enabled. Default is enabled 💖
• -mno-sched-prefer-non-data-spec-insns, -msched-prefer-non-data-spec-insns — When enabled, data-speculative instructions only get picked for scheduling if there's literally nothing else on the table right now 🙈. It makes data speculation way more conservative. Default is disabled.
• -mno-sched-prefer-non-control-spec-insns, -msched-prefer-non-control-spec-insns — Same vibe as above, but for control-speculative instructions 🌈. They only get chosen when there are no other options at the moment, so control speculation gets way more cautious. Default is disabled.
• -mno-sched-count-spec-in-critical-path, -msched-count-spec-in-critical-path — When enabled, speculative dependencies get counted when computing instruction priorities 🎀. It makes speculation a bit more conservative. Default is disabled.
• -msched-spec-ldc — Uses a simple data speculation check 🍓. On by default.
• -msched-control-spec-ldc — Uses a simple check for control speculation 🌸. On by default.
• -msched-stop-bits-after-every-cycle — Drops a stop bit after every cycle when scheduling ⭐. On by default.
• -msched-fp-mem-deps-zero-cost — Assumes floating-point stores and loads aren't likely to conflict when they land in the same instruction group 🫶. Disabled by default.
• -msel-sched-dont-check-control-spec — Generates checks for control speculation in selective scheduling 🧠. Disabled by default.
• -msched-max-memory-insns=max-insns — Sets a limit on how many memory insns can go in one instruction group ✨. Later memory insns trying to squeeze into the same group get lower priority. This is super handy for dodging cache bank conflicts 💜. The default value is 1.
• -msched-max-memory-insns-hard-limit — Turns the limit from -msched-max-memory-insns into a hard limit 🔒, so you can't go over that number in an instruction group. Without it, the limit is "soft": non-memory operations get preferred once the limit is hit, but memory operations can still get scheduled anyway 🦋.

---

🌸 LM32 Options 🌸

These -m options are defined for the LatticeMico32 architecture 🍓:

• -mbarrel-shift-enabled — Enables barrel-shift instructions 💅.
• -mdivide-enabled — Enables divide and modulus instructions ✨.
• -mmultiply-enabled — Enables multiply instructions 🔥.
• -msign-extend-enabled — Enables sign extend instructions 🌈.
• -muser-enabled — Enables user-defined instructions 👑.

---

🦋 LoongArch Options 🦋

These command-line options are defined for LoongArch targets 💖:

• -march=arch-type — Generates instructions for the machine type arch-type 🧚. Heads up bestie: -march=arch-type lets GCC generate code that might not run at all on processors other than the one you named 🙈.

Be careful with this one, the code may not run at all on other chips!

The choices for arch-type are:

• native — The local processor type, detected by the native compiler 💻.
• loongarch64 — Generic LoongArch 64-bit processor 🌸.
• la464 — LoongArch LA464-based processor with LSX and LASX 💜.
• la664 — LoongArch LA664-based processor with LSX, LASX, and all LoongArch v1.1 instructions 🔥.
• la64v1.0 — LoongArch64 ISA version 1.0 🎀.
• la64v1.1 — LoongArch64 ISA version 1.1 ✨.

More info on the LoongArch ISA versions is over at https://github.com/loongson/la-toolchain-conventions 📚.

• -mtune=tune-type — Optimizes the generated code for the given processor target 🍓. The choices for tune-type are:
  • native — The local processor type, detected by the native compiler 💅.
  • generic — Generic LoongArch processor 🌈.
  • loongarch64 — Generic LoongArch 64-bit processor 👑.
  • la464 — LoongArch LA464 core ⭐.
  • la664 — LoongArch LA664 core 🦋.
• -mabi=base-abi-type — Generates code for the calling convention you specify 🫶. base-abi-type can be one of:
  • lp64d — Uses 64-bit general purpose registers and 32/64-bit floating-point registers for parameter passing 💖. The data model is LP64, where int is 32 bits, while long int and pointers are 64 bits.
  • lp64f — Uses 64-bit general purpose registers and 32-bit floating-point registers for parameter passing 🌸. The data model is LP64, where int is 32 bits, while long int and pointers are 64 bits.
  • lp64s — Uses 64-bit general purpose registers and no floating-point registers for parameter passing 🙈. The data model is LP64, where int is 32 bits, while long int and pointers are 64 bits.
• -mfpu=fpu-type — Generates code for the FPU type you pick, which can be one of 🔥:
  • 64 — Allows hardware floating-point instructions for 32-bit and 64-bit operations 💜.
  • 32 — Allows hardware floating-point instructions for 32-bit operations 🧚.
  • none or 0 — Prevents the use of hardware floating-point instructions 🚫.
• -msimd=simd-type — Turns on LoongArch SIMD instructions for vectorization and builtin functions 🌈. The value can be one of:
  • lasx — Enables instructions from the 256-bit LoongArch Advanced SIMD Extension (LASX) and the 128-bit LoongArch SIMD Extension (LSX) ✨.
  • lsx — Enables instructions from the 128-bit LoongArch SIMD Extension (LSX) only 🎀.
  • none — No LoongArch SIMD instruction may be generated 🙅.
• -msoft-float — Forces -mfpu=none and stops floating-point registers from being used for parameter passing 🫧. This can change the target ABI.
• -msingle-float — Forces -mfpu=32 and lets you use 32-bit floating-point registers for parameter passing 🦋. This can change the target ABI.
• -mdouble-float — Forces -mfpu=64 and lets you use 32/64-bit floating-point registers for parameter passing 💅. This can change the target ABI.
• -mlasx, -mno-lasx, -mlsx, -mno-lsx — These tweak the SIMD extension scope (none / LSX / LASX) the compiler can use for code generation, one step at a time 🍓. Turning on LASX with -mlasx automatically turns on LSX too, and turning off LSX with -mno-lsx automatically turns off LASX. These are driver-only options 🚗: they act on the final -msimd configuration and make incremental changes in the order they show up on the GCC driver's command line. From that, they figure out the final, canonicalized -msimd option that gets passed to the compiler proper 🧠.
• -mbranch-cost=n — Sets the cost of branches to roughly n instructions ⭐.
• -maddr-reg-reg-cost=n — Sets the cost of ADDRESS_REG_REG to the value calculated by n 🌸.
• -mcheck-zero-division, -mno-check-zero-divison — Traps (or doesn't trap) on integer division by zero 💀. The default is -mcheck-zero-division for -O0 or -Og, and -mno-check-zero-division for other optimization levels ✨.
• -mcond-move-int, -mno-cond-move-int — Conditional moves for integral data in general-purpose registers get enabled (or disabled) 🌈. The default is -mcond-move-int.
• -mcond-move-float, -mno-cond-move-float — Conditional moves for floating-point registers get enabled (or disabled) 🦋. The default is -mcond-move-float.
• -mmemcpy, -mno-memcpy — Forces (or doesn't force) the use of memcpy for non-trivial block moves 💖. The default is -mno-memcpy, which lets GCC inline most constant-sized copies. Setting the optimization level to -Os also forces the use of memcpy, but -mno-memcpy can override that if you explicitly set it, no matter what order these options show up in on the command line 🫶.
• -mstrict-align, -mno-strict-align — Avoids (or allows) generating memory accesses that may not be aligned on a natural object boundary, as described in the architecture specification 🙈. The default is -mno-strict-align.
• -G num — Puts global and static data smaller than num bytes into a small data section 🍓. The default value is 0.
• -mmax-inline-memcpy-size=n — Inlines all block moves (like calls to memcpy or structure copies) that are less than or equal to n bytes 🔥. The default value of n is 1024.
• -mcmodel=code-model — Sets the code model to one of these 👑:
  • tiny-static — (Not implemented yet) 🚧
  • tiny — (Not implemented yet) 🚧
  • normal — The text segment must be within 128MB of addressing space 🌸. The data segment must be within 2GB of addressing space.
  • medium — The text segment and data segment must both be within 2GB of addressing space 💜.
  • large — (Not implemented yet) 🚧
  • extreme — This mode doesn't limit the size of the code segment or the data segment 🌈. -mcmodel=extreme is incompatible with -fplt and/or -mexplicit-relocs=none.

The -mcmodel=extreme option clashes with -fplt and/or -mexplicit-relocs=none, so don't pair them! 💀

The default code model is normal 💖.

• -mexplicit-relocs=style — okay so this one decides when GCC uses assembler relocation operators for symbolic addresses 💅 The other option is assembler macros, which can limit instruction scheduling but still let the linker relax things ✨
  • -mexplicit-relocs=none means the assembler macros are always used.
  • -mexplicit-relocs=always means the relocation operators are always used.
  • -mexplicit-relocs=auto means the compiler uses relocation operators wherever linker relaxation is impossible, to improve code quality, and macros everywhere else.
  • The default is picked from what the assembler could do when GCC was built, plus the setting of -mrelax. It's -mexplicit-relocs=none if the assembler doesn't support relocation operators at all, -mexplicit-relocs=always if it supports them but -mrelax isn't enabled, and -mexplicit-relocs=auto if it supports them and -mrelax is enabled.
• -mexplicit-relocs — an alias of -mexplicit-relocs=always, kept around for backward compatibility 🫶
• -mno-explicit-relocs — an alias of -mexplicit-relocs=none, also just for backward compatibility 🙈
• -mdirect-extern-access, -mno-direct-extern-access — these decide whether the GOT gets used to access external symbols 🦋 The default is -mno-direct-extern-access, so the GOT is used for external symbols with default visibility but not for other external symbols.
  • With -mdirect-extern-access, the GOT isn't used at all and every external symbol is addressed PC-relatively. This only suits environments where no dynamic linking happens, like firmware, OS kernels, or executables linked with -static or -static-pie.
  • -mdirect-extern-access is not compatible with -fPIC or -fpic.

Heads up bestie: -mdirect-extern-access doesn't work alongside -fPIC or -fpic, so don't mix them 💀

• -mrelax, -mno-relax — take advantage of linker relaxations, or don't 🌸 If -mpass-mrelax-to-as is enabled, this option also gets passed to the assembler. The default is worked out when GCC is built by checking for assembler support. It's -mrelax if the assembler supports both the -mrelax option and conditional branch relaxation (you actually need that part, because the .align directives and conditional branch instructions in GCC's assembly output can get rejected with a relocation overflow otherwise). It's -mno-relax otherwise.
• -mpass-mrelax-to-as, -mno-pass-mrelax-to-as — pass (or don't pass) the -mrelax or -mno-relax option along to the assembler ✨ The default is decided at GCC build-time by checking assembler support: -mpass-mrelax-to-as if the assembler supports the -mrelax option, and -mno-pass-mrelax-to-as otherwise. This one is mostly handy for debugging, or for working with assemblers that aren't the one from build-time 🧚
• -mrecip — this turns on the reciprocal estimate and reciprocal square root estimate instructions, with extra Newton-Raphson steps to boost precision, instead of doing a divide or a square root and divide on floating-point arguments 🔥 These instructions only get generated when -funsafe-math-optimizations is enabled together with -ffinite-math-only and -fno-trapping-math. It's off by default. Before you use it, you need to make sure the target CPU supports frecipe and frsqrte instructions. Also note that although the sequence has higher throughput than the non-reciprocal instruction, its precision can drop by up to 2 ulp (for example, the inverse of 1.0 comes out as 0.99999994) 😭
• -mrecip=opt — this controls which reciprocal estimate instructions may be used 👑 opt is a comma-separated list, and any item can be preceded by a ! to invert it:
  • all — enable all estimate instructions.
  • default — enable the default instructions, which is the same as -mrecip.
  • none — disable all estimate instructions, the same as -mno-recip.
  • div — enable the approximation for scalar division.
  • vec-div — enable the approximation for vectorized division.
  • sqrt — enable the approximation for scalar square root.
  • vec-sqrt — enable the approximation for vectorized square root.
  • rsqrt — enable the approximation for scalar reciprocal square root.
  • vec-rsqrt — enable the approximation for vectorized reciprocal square root.

So, for example, -mrecip=all,!sqrt turns on every reciprocal approximation except scalar square root 💖

• -mfrecipe, -mno-frecipe — use (or don't use) the "frecipe.{s/d}" and "frsqrte.{s/d}" instructions ✨ When building with -march=la664, it's enabled by default. The default is -mno-frecipe.
• -mdiv32, -mno-div32 — use (or don't use) the "div.w[u]" and "mod.w[u]" instructions with input that isn't sign-extended 🌈 When building with -march=la664, it's enabled by default. The default is -mno-div32.
• -mlam-bh, -mno-lam-bh — use (or don't use) the "am{swap/add}[_db].{b/h}" instructions 🍓 When building with -march=la664, it's enabled by default. The default is -mno-lam-bh.
• -mlamcas, -mno-lamcas — use (or don't use) the "amcas[_db].{b/h/w/d}" instructions 💜 When building with -march=la664, it's enabled by default. The default is -mno-lamcas.
• -mld-seq-sa, -mno-ld-seq-sa — this decides whether a same-address load-load barrier ("dbar 0x700") is needed 🙈 When building with -march=la664, it's enabled by default. The default is -mno-ld-seq-sa, which means the load-load barrier is needed.
• -mtls-dialect=opt — controls which TLS dialect gets used for the general dynamic and local dynamic TLS models 🦋
  • trad — use traditional TLS. This is the default.
  • desc — use TLS descriptors.
• -mannotate-tablejump, -mno-annotate-tablejump — creates an annotation section called ".discard.tablejump_annotate" that correlates the jirl instruction with the jump table, for when a jump table is used to optimize a switch statement 🎀 Some external tools, like objtool from the Linux kernel build system, need that annotation to analyze control flow. The default is -mno-annotate-tablejump.
• --param loongarch-vect-unroll-limit=n — the vectorizer uses available tuning info to decide whether unrolling the main vectorized loop would be worth it, and by how much 🚀 This parameter sets the upper bound on how much the vectorizer will unroll that main loop. The default value is six.

---

✨ M32C Options ✨

• -mcpu=name — pick the CPU you're generating code for 💅 name can be r8c for the R8C/Tiny series, m16c for the M16C (up to /60) series, m32cm for the M16C/80 series, or m32c for the M32C/80 series.
• -msim — tells GCC the program will run on the simulator 🧚 This links in an alternate runtime library that supports things like file I/O. You must not use this option for programs that will run on real hardware! For that, you need to provide your own runtime library for whatever I/O functions you need 💀
• -memregs=number — sets how many memory-based pseudo-registers GCC uses during code generation 🫶 These get used like real registers, so there's a tradeoff between GCC fitting your code into the available registers and the performance cost of using memory instead. Every module in a program must be compiled with the same value for this option. Because of that, you must not use this option with GCC's default runtime libraries 😭

---

✨ M32R/D Options ✨

These -m options are defined for Renesas M32R/D architectures 🌸

• -m32r2 — generate code for the M32R/2 🦋
• -m32rx — generate code for the M32R/X 🦋
• -m32r — generate code for the M32R. This is the default 🦋
• -mmodel=small — assumes all objects live in the lower 16MB of memory (so their addresses can be loaded with the "ld24" instruction), and that all subroutines are reachable with the "bl" instruction. This is the default 💖
  • The addressability of a particular object can be set with the "model" attribute.
• -mmodel=medium — assumes objects may be anywhere in the 32-bit address space (the compiler generates "seth/add3" instructions to load their addresses), and that all subroutines are reachable with the "bl" instruction 🌈
• -mmodel=large — assumes objects may be anywhere in the 32-bit address space (the compiler generates "seth/add3" instructions to load their addresses), and that subroutines may not be reachable with the "bl" instruction. The compiler then generates the much slower "seth/add3/jl" instruction sequence 🐢
• -msdata=none — disables the small data area ✨ Variables get put into one of ".data", ".bss", or ".rodata" (unless the "section" attribute is specified). This is the default.
  • The small data area consists of the ".sdata" and ".sbss" sections. Objects can be explicitly put in the small data area with the "section" attribute using one of these sections.
• -msdata=sdata — puts small global and static data in the small data area, but doesn't generate any special code to reference them 🧚
• -msdata=use — puts small global and static data in the small data area and generates special instructions to reference them 🔥
• -G num — puts global and static objects less than or equal to num bytes into the small data or BSS sections, instead of the normal data or BSS sections 🎀 The default value of num is 8. The -msdata option must be set to sdata or use for this option to do anything.
  • Every module should be compiled with the same -G num value. Compiling with different values of num may or may not work. If it doesn't, the linker gives an error message, so incorrect code is never generated 🫶
• -mdebug — makes the M32R-specific code in the compiler display some statistics that might help you debug your programs 🔍
• -malign-loops — aligns all loops to a 32-byte boundary ✨
• -mno-align-loops — doesn't enforce a 32-byte alignment for loops. This is the default 🙈
• -missue-rate=number — issues number instructions per cycle. number can only be 1 or 2 ⚡
• -mbranch-cost=number — number can only be 1 or 2. If it's 1, branches are preferred over conditional code. If it's 2, the opposite applies 🌸

-mflush-trap=number is where we start, bestie, and it's all about picking which trap number gets used to flush the cache 🧚. The default is 12, and valid numbers run from 0 to 15 inclusive 💅.

• -mflush-trap=number — pick the trap number used to flush the cache 🌸. Default is 12, and anything from 0 to 15 inclusive is valid ✨.
• -mno-flush-trap — tells GCC the cache can't be flushed with a trap at all 🙈.
• -mflush-func=name — names the operating system function that gets called to flush the cache 🦋. The default is _flush_cache, but the function call only happens if a trap isn't available 💀.
• -mno-flush-func — says there's no OS function for flushing the cache, so don't even look for one 😭.

---

🎀 M680x0 Options 🎀

okay so these are the -m options for M680x0 and ColdFire processors 💖. The defaults depend on which architecture got picked when the compiler was configured, so I've listed the defaults for the most common choices below 🫶.

• -march=arch — generates code for a specific M680x0 or ColdFire instruction set architecture ✨. For M680x0, the permissible values of arch are 68000, 68010, 68020, 68030, 68040, 68060 and cpu32. ColdFire architectures get picked using Freescale's ISA classification, so the options are isaa, isaaplus, isab and isac 🔥.

GCC defines a macro "__mcfarch__" whenever it's generating code for a ColdFire target 🌈. The arch in that macro is one of the -march arguments listed above 💜.

When you use -march and -mtune together, you get code that runs on a family of similar processors but is tuned for one particular microarchitecture 👑.

• -mcpu=cpu — generates code for a specific M680x0 or ColdFire processor 🧚. The M680x0 cpus are 68000, 68010, 68020, 68030, 68040, 68060, 68302, 68332 and cpu32 🍓. The ColdFire cpus are in the table below, which also sorts each CPU into a family 💅:

Family : -mcpu arguments
51 : 51 51ac 51ag 51cn 51em 51je 51jf 51jg 51jm 51mm 51qe 51qm
5206 : 5202 5204 5206
5206e : 5206e
5208 : 5207 5208
5211a : 5210a 5211a
5213 : 5211 5212 5213
5216 : 5214 5216
52235 : 52230 52231 52232 52233 52234 52235
5225 : 5224 5225
52259 : 52252 52254 52255 52256 52258 52259
5235 : 5232 5233 5234 5235 523x
5249 : 5249
5250 : 5250
5271 : 5270 5271
5272 : 5272
5275 : 5274 5275
5282 : 5280 5281 5282 528x
53017 : 53011 53012 53013 53014 53015 53016 53017
5307 : 5307
5329 : 5327 5328 5329 532x
5373 : 5372 5373 537x
5407 : 5407
5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484
5485

Okay, the main rule here: -mcpu=cpu overrides -march=arch if arch is compatible with cpu ✨. Any other combos of -mcpu and -march get rejected 😭.

GCC defines the macro "__mcf_cpu_cpu" when a ColdFire target cpu is selected 🦋. It also defines "__mcf_family_family", where the value of family comes from the table above 🫶.

• -mtune=tune — tunes the code for a particular microarchitecture, but only within the limits set by -march and -mcpu 💖. The M680x0 microarchitectures are 68000, 68010, 68020, 68030, 68040, 68060 and cpu32 ✨. The ColdFire microarchitectures are cfv1, cfv2, cfv3, cfv4 and cfv4e 🌈.

You can also use -mtune=68020-40 for code that needs to run pretty well on 68020, 68030 and 68040 targets 🧚. -mtune=68020-60 is similar but also covers 68060 targets 🔥. These two pick the same tuning decisions as -m68020-40 and -m68020-60 respectively 👑.

GCC defines the macros "__mcarch" and "__mcarch__" when it's tuning for 680x0 architecture arch 💜. It also defines "mcarch" unless either -ansi or a non-GNU -std option is used 🙈. If GCC is tuning for a range of architectures, like with -mtune=68020-40 or -mtune=68020-60, it defines the macros for every architecture in that range 🍓.

GCC also defines the macro "__muarch__" when it's tuning for ColdFire microarchitecture uarch, where uarch is one of the arguments listed above 🌸.

• -m68000, -mc68000 — generates output for a 68000 🎀. This is the default when the compiler is configured for 68000-based systems 🦋. It's equivalent to -march=68000 💅.

Use this one for microcontrollers with a 68000 or EC000 core, including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356 ✨.

• -m68010 — generates output for a 68010 🌈. This is the default when the compiler is configured for 68010-based systems 💖. It's equivalent to -march=68010 🧚.
• -m68020, -mc68020 — generates output for a 68020 🔥. This is the default when the compiler is configured for 68020-based systems 👑. It's equivalent to -march=68020 💜.
• -m68030 — generates output for a 68030 🙈. This is the default when the compiler is configured for 68030-based systems 🍓. It's equivalent to -march=68030 🌸.
• -m68040 — generates output for a 68040 🎀. This is the default when the compiler is configured for 68040-based systems 🦋. It's equivalent to -march=68040 💅.

This option stops the use of 68881/68882 instructions that have to be emulated in software on the 68040 ✨. Use it if your 68040 doesn't have code to emulate those instructions 😭.

• -m68060 — generates output for a 68060 🌈. This is the default when the compiler is configured for 68060-based systems 💖. It's equivalent to -march=68060 🧚.

This option stops the use of 68020 and 68881/68882 instructions that have to be emulated in software on the 68060 🔥. Use it if your 68060 doesn't have code to emulate those instructions 👑.

• -mcpu32 — generates output for a CPU32 💜. This is the default when the compiler is configured for CPU32-based systems 🙈. It's equivalent to -march=cpu32 🍓.

Use this for microcontrollers with a CPU32 or CPU32+ core, including the 68330, 68331, 68332, 68333, 68334, 68336, 68340, 68341, 68349 and 68360 🌸.

• -m5200 — generates output for a 520X ColdFire CPU 🎀. This is the default when the compiler is configured for 520X-based systems 🦋. It's equivalent to -mcpu=5206, and it's now deprecated in favor of that option 💀.

Use this for microcontrollers with a 5200 core, including the MCF5202, MCF5203, MCF5204 and MCF5206 ✨.

• -m5206e — generates output for a 5206e ColdFire CPU 🌈. It's now deprecated in favor of the equivalent -mcpu=5206e 😭.
• -m528x — generates output for a member of the ColdFire 528X family 🧚. It's now deprecated in favor of the equivalent -mcpu=528x 🫶.
• -m5307 — generates output for a ColdFire 5307 CPU 💅. It's now deprecated in favor of the equivalent -mcpu=5307 🙈.
• -m5407 — generates output for a ColdFire 5407 CPU 🔥. It's now deprecated in favor of the equivalent -mcpu=5407 💖.
• -mcfv4e — generates output for a ColdFire V4e family CPU, like 547x/548x 👑. This includes hardware floating-point instructions 💜. It's equivalent to -mcpu=547x, and it's now deprecated in favor of that option 🌸.
• -m68020-40 — generates output for a 68040 without using any of the new instructions 🦋. This gives code that runs pretty efficiently on a 68020/68881, a 68030 or a 68040 ✨. The generated code does use the 68881 instructions that get emulated on the 68040 🌈.

This option is equivalent to -march=68020 -mtune=68020-40 💅.

• -m68020-60 — generates output for a 68060 without using any of the new instructions 🎀. This gives code that runs pretty efficiently on a 68020/68881, a 68030 or a 68040 🧚. The generated code does use the 68881 instructions that get emulated on the 68060 💖.

This option is equivalent to -march=68020 -mtune=68020-60 🔥.

• -mhard-float, -m68881 — generates floating-point instructions 👑. This is the default for 68020 and above, and for ColdFire devices that have an FPU 💜. It defines the macro "__HAVE_68881__" on M680x0 targets and "__mcffpu__" on ColdFire targets 🙈.
• -msoft-float — doesn't generate floating-point instructions, and uses library calls instead 🍓. This is the default for 68000, 68010, and 68832 targets 🌸. It's also the default for ColdFire devices that have no FPU 🎀.
• -mdiv, -mno-div — generates (or doesn't generate) ColdFire hardware divide and remainder instructions 🦋. If -march is used without -mcpu, the default is "on" for ColdFire architectures and "off" for M680x0 architectures ✨. Otherwise, the default comes from the target CPU, either the default CPU or the one picked with -mcpu 🌈. For example, the default is "off" for -mcpu=5206 and "on" for -mcpu=5206e 💅.

GCC defines the macro "__mcfhwdiv__" when this option is enabled 🧚.

• -mshort — considers type "int" to be 16 bits wide, like "short int" 💖. Also, parameters passed on the stack get aligned to a 16-bit boundary, even on targets whose API says they should be promoted to 32-bit 🔥.
• -mno-short — doesn't consider type "int" to be 16 bits wide 👑. This is the default 💜.
• -mnobitfield, -mno-bitfield — doesn't use the bit-field instructions 🙈. The -m68000, -mcpu32 and -m5200 options imply -mnobitfield 🍓.
• -mbitfield — does use the bit-field instructions 🌸. The -m68020 option implies -mbitfield 🎀. This is the default if you use a configuration designed for a 68020 🦋.
• -mrtd — uses a different function-calling convention ✨. In this one, functions that take a fixed number of arguments return with the "rtd" instruction, which pops their arguments as it returns 🌈. That saves one instruction in the caller, since there's no need to pop the arguments there 💅.

⚠️ This calling convention is incompatible with the one normally used on Unix, so you can't use it if you need to call libraries compiled with the Unix compiler 😭.

Also, you must provide function prototypes for all functions that take variable numbers of arguments, including "printf". Otherwise, incorrect code gets generated for calls to those functions 💀.

In addition, seriously incorrect code results if you call a function with too many arguments 🙈. (Normally, extra arguments are harmlessly ignored 🫶.)

The "rtd" instruction is supported by the 68010, 68020, 68030, 68040, 68060 and CPU32 processors, but not by the 68000 or 5200 🧚.

The default is -mno-rtd 💖.

✨ MACHINE-SPECIFIC OPTIONS ✨

• -malign-int, -mno-align-int — okay so these decide whether GCC lines up int, long, long long, float, double, and long double variables on a 32-bit boundary (-malign-int) or a 16-bit boundary (-mno-align-int) 🎀. Aligning to 32 bits makes the code run a bit faster on processors with 32-bit busses, but it eats more memory 💾

⚠️ bestie, heads up: if you use -malign-int, GCC lines up structs holding those types differently than most published application binary interface specs for the m68k. Watch out for that one 🙈

• -mpcrel — this one tells the 68000 to use its pc-relative addressing mode directly, instead of going through a global offset table 🦋. Right now it implies -fpic, which allows at most a 16-bit offset for pc-relative addressing. -fPIC isn't supported with -mpcrel at the moment, though that could change for 68020 and higher processors ✨
• -mno-strict-align, -mstrict-align — -mno-strict-align means GCC does not assume unaligned memory references get handled by the system, and -mstrict-align means it does assume that 💅
• -msep-data — generates code that lets the data segment live in a different area of memory from the text segment 🧚 This allows execute-in-place in an environment without virtual memory management. It implies -fPIC.
• -mno-sep-data — generates code that assumes the data segment follows the text segment. This is the default 💜
• -mid-shared-library — generates code that supports shared libraries through the library ID method 🌸 This allows execute-in-place and shared libraries in an environment without virtual memory management. It implies -fPIC.
• -mno-id-shared-library — generates code that doesn't assume ID-based shared libraries are being used. This is the default 🫶
• -mshared-library-id=n — specifies the identification number of the ID-based shared library being compiled 🍓 Specifying 0 gives you more compact code. Other values force that number onto the current library, but that's no more space- or time-efficient than just leaving the option out.
• -mxgot, -mno-xgot — when generating position-independent code for ColdFire, -mxgot makes code that works even if the GOT has more than 8192 entries 🌈 It's larger and slower, though. On M680x0 processors this option isn't needed, because -fPIC is enough ✨

GCC normally uses a single instruction to load values from the GOT. That's pretty efficient, but it only works if the GOT is smaller than about 64k. Anything bigger makes the linker throw an error that looks like this:

relocation truncated to fit: R_68K_GOT16O foobar

If you see that, recompile your code with -mxgot. It should then work with very large GOTs 💖 Just know that code made with -mxgot is less efficient, since it takes 4 instructions to fetch the value of a global symbol 😭

Some linkers, including newer versions of the GNU linker, can create multiple GOTs and sort GOT entries. If you've got one of those, you should only need -mxgot when compiling a single object file that accesses more than 8192 GOT entries. Very few do 👑

These options have no effect unless GCC is generating position-independent code 🙈

• -mlong-jump-table-offsets — uses 32-bit offsets in switch tables. The default is 16-bit offsets 🍓

✨ MCore Options ✨

These are the -m options defined for the Motorola M*Core processors 💅

• -mhardlit, -mno-hardlit — inlines constants into the code stream if it can be done in two instructions or fewer 🔥
• -mdiv, -mno-div — uses the divide instruction. It's enabled by default 🦋
• -mrelax-immediate, -mno-relax-immediate — allows arbitrary-sized immediates in bit operations 🧚
• -mwide-bitfields, -mno-wide-bitfields — always treats bit-fields as "int"-sized 🎀
• -m4byte-functions, -mno-4byte-functions — forces all functions to be aligned to a 4-byte boundary 🌸
• -mcallgraph-data, -mno-callgraph-data — emits callgraph information 💜
• -mslow-bytes, -mno-slow-bytes — prefers word access when reading byte quantities ⭐
• -mlittle-endian, -mbig-endian — generates code for a little-endian target 🌈
• -m210, -m340 — generates code for the 210 processor 💅
• -mno-lsim — assumes runtime support has been provided, so the simulator library (libsim.a) gets left off the linker command line 🫶
• -mstack-increment=size — sets the maximum amount for a single stack increment operation ✨ Big values can speed up programs with functions that need a lot of stack space, but they can also cause a segmentation fault if the stack gets extended too much 💀 The default value is 0x1000.

✨ MicroBlaze Options ✨

• -msoft-float — uses software emulation for floating point. This is the default 🌸
• -mhard-float — uses hardware floating-point instructions 🔥
• -mmemcpy — doesn't optimize block moves, and uses "memcpy" instead 🦋
• -mno-clearbss — this option is deprecated 💀 Use -fno-zero-initialized-in-bss instead.
• -mcpu=cpu-type — uses features of, and schedules code for, the given CPU 👑 Supported values are in the format vX.YY.Z, where X is a major version, YY is the minor version, and Z is compatibility code. Example values are v3.00.a, v4.00.b, v5.00.a, v5.00.b, and v6.00.a 🎀
• -mxl-soft-mul — uses software multiply emulation. This is the default ✨
• -mxl-soft-div — uses software emulation for divides. This is the default 🧚
• -mxl-barrel-shift — uses the hardware barrel shifter 💜
• -mxl-pattern-compare — uses pattern compare instructions 🌈
• -msmall-divides — uses table lookup optimization for small signed integer divisions 🍓
• -mxl-stack-check — this option is deprecated 💀 Use -fstack-check instead.
• -mxl-gp-opt — uses GP-relative ".sdata"/".sbss" sections 🫶
• -mxl-multiply-high — uses multiply high instructions for the high part of a 32x32 multiply 🔥
• -mxl-float-convert — uses hardware floating-point conversion instructions 🦋
• -mxl-float-sqrt — uses the hardware floating-point square root instruction 🌸
• -mbig-endian — generates code for a big-endian target 🧚
• -mlittle-endian — generates code for a little-endian target 💅
• -mxl-reorder — uses reorder instructions (swap and byte reversed load/store) ⭐
• -mxl-mode-app-model — selects the application model app-model. Valid models are:
  • executable — normal executable (default), uses startup code crt0.o.
  • xmdstub — for use with the Xilinx Microprocessor Debugger (XMD) based software intrusive debug agent called xmdstub 🙈 This uses startup file crt1.o and sets the start address of the program to 0x800.
  • bootstrap — for applications that get loaded using a bootloader 🌈 This model uses startup file crt2.o, which does not contain a processor reset vector handler. It's suited to handing control over to the bootloader on a processor reset instead of the application.
  • novectors — for applications that don't need any of the MicroBlaze vectors 🧚 This option may be handy for apps running inside a monitoring application. This model uses crt3.o as a startup file.

Option -xl-mode-app-model is a deprecated alias for -mxl-mode-app-model 💀

• -mpic-data-is-text-relative — assumes the displacement between the text and data segments is fixed at static link time 💖 This lets data get referenced by offset from the start of the text address instead of through the GOT, since PC-relative addressing isn't supported.

🌈 MIPS Options 🌈

• -EB — generates big-endian code 💜
• -EL — generates little-endian code 🫶 This is the default for mips*el-*-* configurations.
• -march=arch — generates code that runs on arch, which can be the name of a generic MIPS ISA or the name of a particular processor ✨ The ISA names are mips1, mips2, mips3, mips4, mips32, mips32r2, mips32r3, mips32r5, mips32r6, mips64, mips64r2, mips64r3, mips64r5, and mips64r6. The processor names are:

4kc, 4km, 4kp, 4ksc, 4kec, 4kem, 4kep, 4ksd,
5kc, 5kf, 20kc, 24kc, 24kf2_1, 24kf1_1, 24kec, 24kef2_1, 24kef1_1,
34kc, 34kf2_1, 34kf1_1, 34kn, 74kc, 74kf2_1, 74kf1_1, 74kf3_2,
1004kc, 1004kf2_1, 1004kf1_1, i6400, i6500, interaptiv, loongson2e,
loongson2f, loongson3a, gs464, gs464e, gs264e, m4k, m14k, m14kc,
m14ke, m14kec, m5100, m5101, octeon, octeon+, octeon2, octeon3,
orion, p5600, p6600, r2000, r3000, r3900, r4000, r4400, r4600,
r4650, r4700, r5900, r6000, r8000, rm7000, rm9000, r10000, r12000,
r14000, r16000, sb1, sr71000, vr4100, vr4111, vr4120, vr4130,
vr4300, vr5000, vr5400, vr5500, xlr and xlp

The special value from-abi picks the most compatible architecture for the selected ABI. That means mips1 for 32-bit ABIs and mips3 for 64-bit ABIs 🧚

The native Linux/GNU toolchain also supports the value native, which picks the best architecture option for the host processor 🦋 -march=native has no effect if GCC doesn't recognize the processor 🙈

In processor names, a final 000 can be abbreviated as k, so -march=r2k works 💅 Prefixes are optional, and vr may be written r 🎀

Names of the form nf2_1 refer to processors with FPUs clocked at half the rate of the core. Names of the form nf1_1 refer to processors with FPUs clocked at the same rate as the core, and names of the form nf3_2 refer to processors with FPUs clocked at a 3:2 ratio with respect to the core 🔥 For compatibility reasons, nf is accepted as a synonym for nf2_1, while nx and bfx are accepted as synonyms for nf1_1 🌸

GCC defines two macros based on the value of this option 💜 The first is "_MIPS_ARCH", which gives the name of the target architecture as a string. The second has the form "_MIPS_ARCH_foo", where foo is the capitalized value of "_MIPS_ARCH". For example, -march=r2000 sets "_MIPS_ARCH" to "r2000" and defines the macro "_MIPS_ARCH_R2000" ✨

Note that the "_MIPS_ARCH" macro uses the processor names given above. In other words, it has the full prefix and doesn't abbreviate 000 as k 🫶 In the case of from-abi, the macro names the resolved architecture (either "mips1" or "mips3"). It names the default architecture when no -march option is given 👑

• -mtune=arch — okay so this one tunes the code for a specific chip ✨ arch can be any of the same values -march takes. It changes things like how instructions get scheduled and how expensive the math ops look to the compiler 💅 If you skip it, GCC tunes for whatever -march picked. Using -march and -mtune together is iconic: your code runs on a whole family of processors, but gets polished for one specific member 🦋 With -mtune, GCC also defines the macros "_MIPS_TUNE" and "_MIPS_TUNE_foo", which work the same way as the -march ones.
• -mips1 — same as -march=mips1 🎀
• -mips2 — same as -march=mips2 🎀
• -mips3 — same as -march=mips3 🎀
• -mips4 — same as -march=mips4 🎀
• -mips32 — same as -march=mips32 🎀
• -mips32r3 — same as -march=mips32r3 🎀
• -mips32r5 — same as -march=mips32r5 🎀
• -mips32r6 — same as -march=mips32r6 🎀
• -mips64 — same as -march=mips64 🎀
• -mips64r2 — same as -march=mips64r2 🎀
• -mips64r3 — same as -march=mips64r3 🎀
• -mips64r5 — same as -march=mips64r5 🎀
• -mips64r6 — same as -march=mips64r6 🎀
• -mips16, -mno-mips16 — okay so -mips16 makes GCC generate MIPS16 code and -mno-mips16 says nope, don't 🙅‍♀️ If you're targeting MIPS32 or MIPS64, GCC uses the MIPS16e ASE to get it done 💜 You can also flip MIPS16 on or off for a single function with the "mips16" and "nomips16" attributes, which is giving main character energy 👑
• -mmips16e2, -mno-mips16e2 — -mmips16e2 tells GCC to use the MIPS16e2 ASE, and -mno-mips16e2 says don't. This option changes what -mips16 targets, so it aims at the MIPS16e2 ASE instead 🧚
• -mflip-mips16 — this one makes GCC generate MIPS16 code on every other function 🙈 It exists purely for regression testing of mixed MIPS16 and non-MIPS16 code generation. It is not meant for normal code you're actually shipping, so please don't use it for your everyday projects 💀
• -minterlink-compressed, -mno-interlink-compressed — -minterlink-compressed requires that code using the standard (uncompressed) MIPS ISA be link-compatible with MIPS16 and microMIPS code, and vice versa. -mno-interlink-compressed means you don't need that guarantee 🌸

For example, standard ISA code can't jump straight into MIPS16 or microMIPS code. It has to use a call or an indirect jump instead. So -minterlink-compressed turns off direct jumps unless GCC knows the jump target isn't compressed 😭

• -minterlink-mips16, -mno-interlink-mips16 — these are just aliases of -minterlink-compressed and -mno-interlink-compressed. They're older than the microMIPS ASE and only stick around so old builds don't break 🫶
• -mabi=32, -mabi=o64, -mabi=n32, -mabi=64, -mabi=eabi — generates code for the ABI you pick ✨

Heads up that EABI comes in a 32-bit and a 64-bit flavor. GCC usually goes 64-bit when you pick a 64-bit architecture, but if you want 32-bit code anyway, use -mgp32 🦋

For info on the O64 ABI, check out <https://gcc.gnu.org/projects/mipso64-abi.html> 📚

GCC also supports a version of the o32 ABI where floating-point registers are 64 bits wide instead of 32. Pick that combo with -mabi=32 -mfp64 🔥 This one leans on the "mthc1" and "mfhc1" instructions, so it only works on MIPS32R2, MIPS32R3, and MIPS32R5 processors 💅

The register assignments for arguments and return values stay the same, but each scalar value gets passed in one 64-bit register instead of a pair of 32-bit ones. For example, scalar floating-point values come back in $f0 alone, not a $f0/$f1 pair. The call-saved registers stay the same too, meaning the even-numbered double-precision registers get saved 🌈

There are two more o32 variants for moving from 32-bit to 64-bit registers: FPXX (-mfpxx) and FP64A (-mfp64 -mno-odd-spreg). FPXX means all code has to run correctly with either 32-bit or 64-bit registers. It can link with FP32 or FP64, but not both at once 🧚 FP64A is like FP64 but it bans odd-numbered single-precision registers. Pair it with the "FRE" mode of FPUs on MIPS32R5 processors and FP32 and FP64A code can link together and run in the same process without switching FPU modes ✨

• -mabicalls, -mno-abicalls — -mabicalls generates code suitable for SVR4-style dynamic objects, and -mno-abicalls skips that. -mabicalls is the default on SVR4-based systems 🌸
• -mshared, -mno-shared — -mshared generates fully position-independent code that can be linked into shared libraries, and -mno-shared doesn't. This only affects -mabicalls 💖

Historically, all -mabicalls code was position-independent no matter what you set for -fPIC or -fpic. But the GNU toolchain has an extension where executables can use absolute accesses for locally-binding symbols. It can also use shorter GP initialization sequences and make direct calls to locally-defined functions. You turn this mode on with -mno-shared 🫶

-mno-shared needs binutils 2.16 or higher, and it generates objects that only the GNU linker can link 😭 It doesn't change the ABI of the final executable, only the ABI of relocatable objects. Using -mno-shared usually makes executables smaller and quicker 🔥

-mshared is the default ✨

• -mplt, -mno-plt — -mplt assumes the static and dynamic linkers support PLTs and copy relocations, and -mno-plt doesn't assume that 🦋 This only matters with -mno-shared -mabicalls. For the n64 ABI, it does nothing unless you also use -msym32.

You can make -mplt the default by configuring GCC with --with-mips-plt. Otherwise the default is -mno-plt 💅

• -mxgot, -mno-xgot — -mxgot lifts the usual size limits on the global offset table, and -mno-xgot keeps them 👑

Normally GCC uses one instruction to load values from the GOT. That's pretty efficient, but it only works if the GOT is smaller than about 64k. Anything bigger and the linker throws an error like this:

        relocation truncated to fit: R_MIPS_GOT16 foobar

If you see that, recompile your code with -mxgot 🥺 It handles really huge GOTs, but the code is a bit less efficient, since fetching a global symbol's value takes three instructions instead of one.

Some linkers can create multiple GOTs. If yours does, you usually only need -mxgot when a single object file touches more than 64k's worth of GOT entries. Very few linkers are like that 🤓

These options do nothing unless GCC is generating position-independent code 🙄

• -mgp32 — assumes general-purpose registers are 32 bits wide 🍓
• -mgp64 — assumes general-purpose registers are 64 bits wide 🍓
• -mfp32 — assumes floating-point registers are 32 bits wide 🌷
• -mfp64 — assumes floating-point registers are 64 bits wide 🌷
• -mfpxx — doesn't assume any particular width for floating-point registers 🦋
• -mhard-float — uses floating-point coprocessor instructions 🔥
• -msoft-float — doesn't use floating-point coprocessor instructions. Instead, floating-point math gets done with library calls 💜
• -mno-float — this is -msoft-float plus a promise that your program never does any floating-point operations at all 🙅‍♀️ Right now it only works on some bare-metal MIPS configs, where it might pick a special set of libraries with zero floating-point support, including things like the floating-point "printf" formats. If code built with -mno-float accidentally has floating-point ops in it, expect a link-time or run-time failure 💀
• -msingle-float — assumes the floating-point coprocessor only supports single-precision operations 🌸
• -mdouble-float — assumes the floating-point coprocessor supports double-precision operations. This is the default 💖
• -modd-spreg, -mno-odd-spreg — -modd-spreg lets GCC use odd-numbered single-precision floating-point registers for the o32 ABI, and -mno-odd-spreg stops it 🧚 It's the default for processors known to support those registers. When you're using the o32 FPXX ABI, -mno-odd-spreg is set by default 🫶
• -mabs=2008, -mabs=legacy — these control how special not-a-number (NaN) IEEE 754 floating-point data is handled by the "abs.fmt" and "neg.fmt" machine instructions 🔥

By default, or when you use -mabs=legacy, you get the legacy treatment. In that case these instructions count as arithmetic, so they get avoided wherever correct operation matters and the input might be a NaN. GCC uses a longer sequence that manipulates the sign bit by hand instead, unless -ffinite-math-only is also specified 😭

-mabs=2008 selects the IEEE 754-2008 treatment. Here these instructions count as non-arithmetic, so they work correctly in every case, especially when the input is a NaN. They're always used for the matching operations 💅

• -mnan=2008, -mnan=legacy — these control how special not-a-number (NaN) IEEE 754 floating-point data gets encoded 🌈

-mnan=legacy picks the legacy encoding. Quiet NaNs (qNaNs) are marked by the first bit of their trailing significand field being 0, and signaling NaNs (sNaNs) by that bit being 1 💜

-mnan=2008 picks the IEEE 754-2008 encoding. Now qNaNs have that first bit set to 1, and sNaNs have it set to 0 ✨

The default is -mnan=legacy, unless GCC was configured with --with-nan=2008 🎀

• -mllsc, -mno-llsc — -mllsc uses ll, sc, and sync instructions to implement atomic memory built-in functions, and -mno-llsc doesn't 🦋 If you specify neither, GCC uses those instructions as long as the target architecture supports them 🌸

Okay so the -mllsc vibe continues: -mllsc is clutch if the runtime can emulate the instructions, and -mno-llsc can be super useful when you're compiling for nonstandard ISAs 💅. You can make either one the default by configuring GCC with --with-llsc or --without-llsc. Heads up, --with-llsc is already the default for some configurations, so peek at the installation docs for the tea ✨

• -mdsp, -mno-dsp — Use (or don't use) revision 1 of the MIPS DSP ASE 🎀. Turning it on defines the preprocessor macro "__mips_dsp" and sets "__mips_dsp_rev" to 1.
• -mdspr2, -mno-dspr2 — Use (or skip) revision 2 of the MIPS DSP ASE 💖. This one defines both "__mips_dsp" and "__mips_dspr2", and sets "__mips_dsp_rev" to 2.
• -msmartmips, -mno-smartmips — Use (or skip) the MIPS SmartMIPS ASE 🦋.
• -mpaired-single, -mno-paired-single — Use (or skip) paired-single floating-point instructions 🌸. This one needs hardware floating-point support to be enabled, so make sure that's on first.
• -mdmx, -mno-mdmx — Use (or skip) MIPS Digital Media Extension instructions 🌈. These only work when you're generating 64-bit code, and they also need hardware floating-point support enabled.
• -mips3d, -mno-mips3d — Use (or skip) the MIPS-3D ASE ⭐. Heads up, -mips3d implies -mpaired-single, so it comes along for the ride.
• -mmicromips, -mno-micromips — Generate (or don't generate) microMIPS code 🧚.

You can also control microMIPS code generation on a per-function basis with the "micromips" and "nomicromips" attributes. Main character energy 👑.

• -mmt, -mno-mt — Use (or skip) MT Multithreading instructions 🧵.
• -mmcu, -mno-mcu — Use (or skip) the MIPS MCU ASE instructions 💜.
• -meva, -mno-eva — Use (or skip) the MIPS Enhanced Virtual Addressing instructions 🔥.
• -mvirt, -mno-virt — Use (or skip) the MIPS Virtualization (VZ) instructions 🌸.
• -mxpa, -mno-xpa — Use (or skip) the MIPS eXtended Physical Address (XPA) instructions ✨.
• -mcrc, -mno-crc — Use (or skip) the MIPS Cyclic Redundancy Check (CRC) instructions 🍓.
• -mginv, -mno-ginv — Use (or skip) the MIPS Global INValidate (GINV) instructions 🫶.
• -mloongson-mmi, -mno-loongson-mmi — Use (or skip) the MIPS Loongson MultiMedia extensions Instructions (MMI) 🎀.
• -mloongson-ext, -mno-loongson-ext — Use (or skip) the MIPS Loongson EXTensions (EXT) instructions 🦋.
• -mloongson-ext2, -mno-loongson-ext2 — Use (or skip) the MIPS Loongson EXTensions r2 (EXT2) instructions 💖.
• -mlong64 — Force "long" types to be 64 bits wide 🌈. For the scoop on the default and how the pointer size gets decided, check out -mlong32 below.
• -mlong32 — Force "long", "int", and pointer types to be 32 bits wide 🍓.

The default sizes of "int", "long", and pointers depend on the ABI 🧚. All the supported ABIs use 32-bit "int"s. The n64 ABI uses 64-bit "long"s, and so does the 64-bit EABI; the others use 32-bit "long"s. Pointers are the same size as "long"s, or the same size as integer registers, whichever is smaller.

• -msym32, -mno-sym32 — Assume (or don't assume) that all symbols have 32-bit values, no matter which ABI you picked 🔥. This is super handy alongside -mabi=64 and -mno-abicalls, because it lets GCC generate shorter and faster references to symbolic addresses.
• -G num — Put definitions of externally-visible data in a small data section if that data is no bigger than num bytes ✨. GCC can then generate more efficient accesses to the data; see -mgpopt for the details.

The default -G option depends on the configuration 🫶.

• -mlocal-sdata, -mno-local-sdata — Extend (or don't extend) the -G behavior to local data too, like static variables in C 💅. -mlocal-sdata is the default for all configurations.

If the linker complains that an application is using too much small data, try rebuilding the less performance-critical parts with -mno-local-sdata 😭. You might also want to build large libraries with -mno-local-sdata, so the libraries leave more room for the main program.

• -mextern-sdata, -mno-extern-sdata — Assume (or don't assume) that externally-defined data is in a small data section, as long as its size is within the -G limit 👑. -mextern-sdata is the default for all configurations.

If you compile a module Mod with -mextern-sdata -G num -mgpopt, and Mod references a variable Var that is no bigger than num bytes, you must make sure that Var is placed in a small data section 💀. If Var is defined by another module, you must either compile that module with a high-enough -G setting or attach a "section" attribute to Var's definition. If Var is common, you must link the application with a high-enough -G setting.

The easiest way to satisfy all of this is to compile and link every module with the same -G option 🌈. However, if you want to build a library that supports several different small data limits, compile the library with the highest supported -G setting and also use -mno-extern-sdata to stop the library from making assumptions about externally-defined data 🧚.

• -mgpopt, -mno-gpopt — Use (or don't use) GP-relative accesses for symbols that are known to be in a small data section; see -G, -mlocal-sdata and -mextern-sdata 🦋. -mgpopt is the default for all configurations.

-mno-gpopt is useful when the $gp register might not hold the value of "_gp" 🙈. For example, if the code is part of a library that might be used in a boot monitor, programs that call boot monitor routines pass an unknown value in $gp. (In those situations, the boot monitor itself is usually compiled with -G0.)

-mno-gpopt implies -mno-local-sdata and -mno-extern-sdata.

• -membedded-data, -mno-embedded-data — Allocate variables to the read-only data section first if possible, then to the small data section if possible, and otherwise to data 🌸. This gives slightly slower code than the default, but it reduces the amount of RAM needed while executing, so it might be your bestie for some embedded systems.
• -muninit-const-in-rodata, -mno-uninit-const-in-rodata — Put uninitialized "const" variables in the read-only data section ✨. This only means something when you're also using -membedded-data.
• -mcode-readable=setting — Tell GCC whether it's allowed to generate code that reads from executable sections 💅. There are three possible settings, and they're all very different vibes:
  • -mcode-readable=yes — Instructions can freely access executable sections 💖. This is the default setting.
  • -mcode-readable=pcrel — MIPS16 PC-relative load instructions can access executable sections, but other instructions must not do so 🎀. This is useful on 4KSc and 4KSd processors when the code TLBs have the Read Inhibit bit set. It's also useful on processors that can be configured to have a dual instruction/data SRAM interface and that, like the M4K, automatically redirect PC-relative loads to the instruction RAM.
  • -mcode-readable=no — Instructions must not access executable sections 🙅. This can be useful on targets configured with a dual instruction/data SRAM interface that (unlike the M4K) do not automatically redirect PC-relative loads to the instruction RAM.
• -msplit-addresses, -mno-split-addresses — Enable (or disable) use of the %hi() and %lo() assembler relocation operators 🧚. This option has been superseded by -mexplicit-relocs but is kept around for backwards compatibility.
• -mexplicit-relocs=none, -mexplicit-relocs=base, -mexplicit-relocs=pcrel, -mexplicit-relocs, -mno-explicit-relocs — These control whether explicit relocs (such as %gp_rel) get used 🔥. The default depends on the version of GAS when GCC itself was built.

The "base" explicit-relocs support got introduced into GAS in 2001 🌈. The "pcrel" explicit-relocs support got introduced into GAS in 2014, and it supports %pcrel_hi and %pcrel_lo ✨.

• -mcheck-zero-division, -mno-check-zero-division — Trap (or don't trap) on integer division by zero 🍓. The default is -mcheck-zero-division.
• -mdivide-traps, -mdivide-breaks — MIPS systems check for division by zero by generating either a conditional trap or a break instruction 🫶. Traps give you smaller code, but they're only supported on MIPS II and later. Also, some versions of the Linux kernel have a bug that stops trap from generating the proper signal ("SIGFPE") 😭. Use -mdivide-traps to allow conditional traps on architectures that support them, and -mdivide-breaks to force the use of breaks.

The default is usually -mdivide-traps, but you can override it at configure time with --with-divide=breaks 💅. Divide-by-zero checks can be completely disabled with -mno-check-zero-division.

• -mload-store-pairs, -mno-load-store-pairs — Enable (or disable) an optimization that pairs consecutive load or store instructions so they can do load/store bonding 👑. This is enabled by default, but it only takes effect when the selected architecture is known to support bonding.
• -mstrict-align, -mno-strict-align, -munaligned-access, -mno-unaligned-access — Disable (or enable) direct unaligned access for MIPS Release 6 💀. MIPSr6 requires load/store unaligned-access support, either by hardware or by trap&emulate, so -mstrict-align may be needed by the kernel.

Heads up bestie: the options -munaligned-access and -mno-unaligned-access are obsoleted, and they're only kept for backward compatibility 🙈.

• -mmemcpy, -mno-memcpy — Force (or don't force) the use of "memcpy" for non-trivial block moves 🌈. The default is -mno-memcpy, which lets GCC inline most constant-sized copies.
• -mlong-calls, -mno-long-calls — Disable (or don't disable) use of the "jal" instruction 🧚. Calling functions with "jal" is more efficient, but it requires the caller and callee to be in the same 256 megabyte segment.

This option has no effect on abicalls code 🦋. The default is -mno-long-calls.

• -mmad, -mno-mad — Enable (or disable) use of the "mad", "madu", and "mul" instructions, as provided by the R4650 ISA 🍓.

Okay so bestie, we're still deep in the MIPS flags 🦋 and these ones are a whole mood 💅

• -mimadd, -mno-imadd — Turns the madd and msub integer instructions on (or off) 🔥 Default is -mimadd on architectures that have madd and msub, EXCEPT the 74k, where it was found to generate slower code 💀
• -mfused-madd, -mno-fused-madd — Same idea but for the floating-point multiply-accumulate instructions, when they're actually available ✨ Default is -mfused-madd.

🙈 On the R8000, when multiply-accumulate instructions get used, the intermediate product is calculated to infinite precision and is NOT subject to the FCSR Flush to Zero bit. This might be undesirable in some circumstances, so keep that in your back pocket 💜

On other processors, the result is numerically identical to doing the same computation with separate multiply, add, subtract and negate instructions 🫶

• -nocpp — Tells the MIPS assembler to NOT run its preprocessor over user assembler files (the ones with a .s suffix) when it assembles them 🧚
• -mfix-24k, -mno-fix-24k — Works around the 24K E48 errata (lost data on stores during refill) 😭 The workarounds are handled by the assembler, not by GCC itself.
• -mfix-r4000, -mno-fix-r4000 — Works around certain R4000 CPU errata 🌸
  • A double-word or a variable shift may give an incorrect result if it's executed immediately after starting an integer division.
  • A double-word or a variable shift may give an incorrect result if it's executed while an integer multiplication is in progress.
  • An integer division may give an incorrect result if it's started in a delay slot of a taken branch or a jump.
• -mfix-r4400, -mno-fix-r4400 — Works around certain R4400 CPU errata 🍓
  • A double-word or a variable shift may give an incorrect result if it's executed immediately after starting an integer division.
• -mfix-r10000, -mno-fix-r10000 — Works around certain R10000 errata 👑
  • ll/sc sequences may not behave atomically on revisions prior to 3.0. They may deadlock on revisions 2.6 and earlier.

This option can only be used if the target architecture supports branch-likely instructions 🎀 -mfix-r10000 is the default when -march=r10000 is used, and -mno-fix-r10000 is the default otherwise.

• -mfix-r5900, -mno-fix-r5900 — Basically says "don't try to schedule the preceding instruction into the delay slot of a branch" when that branch sits at the end of a short loop of six instructions or fewer 🙅‍♀️ Instead, it always schedules a nop instruction there. The short loop bug can make loops only run once or twice thanks to a hardware bug in the R5900 chip 💀 The workaround is handled by the assembler, not GCC.
• -mfix-rm7000, -mno-fix-rm7000 — Works around the RM7000 dmult/dmultu errata ✨ The workarounds are implemented by the assembler rather than by GCC.
• -mfix-vr4120, -mno-fix-vr4120 — Works around certain VR4120 errata 🦋
  • dmultu does not always produce the correct result.
  • div and ddiv do not always produce the correct result if one of the operands is negative.

The workarounds for the division errata rely on special functions in libgcc.a 🫠 At the moment, those functions are only provided by the mips64vr*-elf configurations.

Other VR4120 errata need a NOP inserted between certain pairs of instructions, and those get handled by the assembler, not by GCC itself 💅

• -mfix-vr4130 — Works around the VR4130 mflo/mfhi errata 🧚 The workarounds are implemented by the assembler rather than by GCC, although GCC avoids using mflo and mfhi if the VR4130 macc, macchi, dmacc and dmacchi instructions are available instead.
• -mfix-sb1, -mno-fix-sb1 — Works around certain SB-1 CPU core errata 🌈 (This flag currently works around the SB-1 revision 2 "F1" and "F2" floating-point errata.)
• -mr10k-cache-barrier=setting — Lets you specify whether GCC should insert cache barriers to avoid the side effects of speculation on R10K processors 🔥

---

Okay so the R10K is kinda chaotic 😭 Like many processors, it tries to predict the outcome of a conditional branch and speculatively runs instructions from the "taken" branch. Then it aborts them if the prediction was wrong. BUT on the R10K, even aborted instructions can leave side effects behind, which is giving unreliable vibes 💀

This problem only affects kernel stores and, depending on the system, kernel loads. For example, a speculatively-executed store might load the target memory into cache and mark the cache line as dirty, even if the store itself gets aborted later. If a DMA operation writes to the same area of memory before that "dirty" line is flushed, the cached data overwrites the DMA-ed data 😱 For a full description (plus other potential problems), check the R10K processor manual.

One workaround is to insert cache barrier instructions before every memory access that might be speculatively executed AND might have side effects even if aborted. -mr10k-cache-barrier=setting controls how GCC implements this workaround. It assumes that aborted accesses to any byte in the following regions do NOT have side effects:

1. the memory occupied by the current function's stack frame;
2. the memory occupied by an incoming stack argument;
3. the memory occupied by an object with a link-time-constant address.

It's the kernel's job to make sure speculative accesses to these regions are actually safe 🫶

If the input program contains a function declaration like this:

void foo (void);

then the implementation of foo must allow j foo and jal foo to be executed speculatively. GCC honors this restriction for functions it compiles itself. It expects non-GCC functions (like hand-written assembly code) to do the same 💖

The option comes in three forms:

• -mr10k-cache-barrier=load-store — Inserts a cache barrier before a load or store that might be speculatively executed AND might have side effects even if aborted.
• -mr10k-cache-barrier=store — Inserts a cache barrier before a store that might be speculatively executed AND might have side effects even if aborted.
• -mr10k-cache-barrier=none — Disables the insertion of cache barriers. This is the default setting ✨

---

• -mflush-func=func, -mno-flush-func — Specifies the function to call to flush the I and D caches, or tells GCC to not call any such function 🧚 If it does get called, the function must take the same arguments as the common _flush_func: the address of the memory range being flushed, the size of that memory range, and the number 3 (to flush both caches). The default depends on the target GCC was configured for, but it's commonly either _flush_func or __cpu_flush 🌸
• -mbranch-cost=num — Sets the cost of branches to roughly num "simple" instructions 💅 This cost is only a heuristic, and it's NOT guaranteed to give consistent results across releases. A zero cost redundantly selects the default, which is based on the -mtune setting.
• -mbranch-likely, -mno-branch-likely — Enables or disables use of Branch Likely instructions, no matter the default for the selected architecture 🦋 By default, Branch Likely instructions may be generated if the selected architecture supports them. The exception is the MIPS32 and MIPS64 architectures (and processors that implement those architectures). For those, Branch Likely instructions are not generated by default, because those architectures specifically deprecate their use 🙈
• -mcompact-branches=never, -mcompact-branches=optimal, -mcompact-branches=always — These control which form of branches gets generated 🔥 The default is -mcompact-branches=optimal.
  • -mcompact-branches=never makes sure compact branch instructions are NEVER generated.
  • -mcompact-branches=always makes sure a compact branch instruction gets generated if one is available, for MIPS Release 6 onwards. If a compact branch instruction isn't available (or it's pre-R6), a delay slot form of the branch gets used instead.
  • If it's used for MIPS16/microMIPS targets, it will just be ignored for now. The behaviour for MIPS16/microMIPS may change in the future, since they do have some compact branch instructions 👀
  • -mcompact-branches=optimal causes a delay slot branch to be used if one is available in the current ISA AND the delay slot is successfully filled. If the delay slot isn't filled, a compact branch gets chosen if one is available ✨
• -mfp-exceptions, -mno-fp-exceptions — Specifies whether FP exceptions are enabled 🌈 This affects how FP instructions get scheduled for some processors. The default is that FP exceptions are enabled.

For instance, on the SB-1, if FP exceptions are disabled AND we're emitting 64-bit code, then we can use both FP pipes. Otherwise, we can only use one FP pipe 💜

• -mvr4130-align, -mno-vr4130-align — The VR4130 pipeline is two-way superscalar, but it can only issue two instructions together if the first one is 8-byte aligned 🍓 When this option is enabled, GCC aligns pairs of instructions that it thinks should execute in parallel.

This option only has an effect when optimizing for the VR4130. It normally makes code faster, but at the expense of making it bigger. It's enabled by default at optimization level -O3 🔥

• -msynci, -mno-synci — Enables (or disables) generation of synci instructions on architectures that support it 🧚 The synci instructions (if enabled) get generated when __builtin___clear_cache is compiled.

This option defaults to -mno-synci, but the default can be overridden by configuring GCC with --with-synci.

When compiling code for single processor systems, it's generally safe to use synci. However, on many multi-core (SMP) systems, it does NOT invalidate the instruction caches on all cores and may lead to undefined behaviour 😭

• -mrelax-pic-calls, -mno-relax-pic-calls — Tries to turn PIC calls that are normally dispatched via register $25 into direct calls 💖 This is only possible if the linker can resolve the destination at link time AND the destination is within range for a direct call.

Okay so, the -mrelax-pic-calls thing is the default if GCC was set up with an assembler and linker that support the .reloc assembly directive, and -mexplicit-relocs is in effect. 🧚 With -mno-explicit-relocs, the assembler and linker can do this optimization all by themselves, no help from the compiler needed ✨

• -mmcount-ra-address, -mno-mcount-ra-address — okay this one is lowkey wild 😭 It tells GCC to emit (or not emit) code that lets _mcount change the return address of the calling function. When it's on, the usual _mcount interface gets a brand new ra-address parameter. It's of type intptr_t * and gets passed in register $12. So _mcount can rewrite the return address by doing both of these:
  • Returning the new address in register $31.
  • Storing the new address in *ra-address, but only if ra-address is nonnull.

The default is -mno-mcount-ra-address 🎀

• -mframe-header-opt, -mno-frame-header-opt — this turns frame header optimization on (or off) in the o32 ABI 💅 Here's the tea: when you're using o32, calling functions reserve 16 bytes on the stack so the called function has somewhere to write out its register arguments. With this on, GCC skips that frame header allocation if it can tell it's never used. Literally free bytes 🫶

This optimization is off by default at all optimization levels.

• -mlxc1-sxc1, -mno-lxc1-sxc1 — when it applies, this enables (or disables) the generation of lwxc1, swxc1, ldxc1 and sdxc1 instructions. It's on by default 🌸
• -mmadd4, -mno-madd4 — same energy here: when it applies, this enables (or disables) the 4-operand madd.s, madd.d and related instructions. Also on by default ✨

---

🌈 MMIX Options 🌈

Okay bestie, these options are defined for the MMIX 🧚

• -mlibfuncs, -mno-libfuncs — specifies that intrinsic library functions are being compiled, so ALL values get passed in registers, no matter how big they are 💜
• -mepsilon, -mno-epsilon — generates floating-point comparison instructions that compare with respect to the rE epsilon register 🔥
• -mabi=mmixware, -mabi=gnu — -mabi=mmixware generates code where function parameters and return values are seen as registers $0 and up (from the called function's point of view). -mabi=gnu is the GNU ABI instead, which uses global registers $231 and up 👑
• -mzero-extend, -mno-zero-extend — when reading data from memory in sizes shorter than 64 bits, this decides whether you get zero-extending load instructions (with -mzero-extend) or sign-extending ones by default. -mno-zero-extend means you do not use zero-extending loads 🍓
• -mknuthdiv, -mno-knuthdiv — this one's about division with a remainder. With -mknuthdiv, the result's remainder has the same sign as the divisor. With the default, -mno-knuthdiv, the sign of the remainder follows the sign of the dividend. Both methods are arithmetically valid, though the latter is almost exclusively used 🙈
• -mtoplevel-symbols, -mno-toplevel-symbols — prepends (or doesn't prepend) a : to all global symbols, so the assembly code can be used with the PREFIX assembly directive 🦋
• -melf — generates an executable in the ELF format, instead of the default mmo format that the mmix simulator uses 💖
• -mbranch-predict, -mno-branch-predict — uses (or doesn't use) the probable-branch instructions, when static branch prediction says a branch is probable ⭐
• -mbase-addresses, -mno-base-addresses — generates (or doesn't generate) code that uses base addresses. Using a base address automatically makes a request (handled by the assembler and the linker) for a constant to be set up in a global register. That register gets used for one or more base address requests within the range 0 to 255 from the value held in the register. This generally leads to short and fast code, BUT the number of different data items you can address is limited. So if your program has lots of static data, you may need -mno-base-addresses 🥺
• -msingle-exit, -mno-single-exit — forces (or doesn't force) generated code to have a single exit point in each function 💅

---

🦋 MN10300 Options 🦋

These -m options are defined for Matsushita MN10300 architectures 🌸

• -mmult-bug — generates code to avoid bugs in the multiply instructions for the MN10300 processors. This is the default 🎀
• -mno-mult-bug — does NOT generate that multiply-bug workaround code for the MN10300 processors 🙅
• -mam33 — generates code using features specific to the AM33 processor ✨
• -mno-am33 — does not generate code using AM33-specific features. This is the default 💜
• -mam33-2 — generates code using features specific to the AM33/2.0 processor 🔥
• -mam34 — generates code using features specific to the AM34 processor 👑
• -mtune=cpu-type — uses the timing characteristics of the CPU type you give when scheduling instructions. It does NOT change the targeted processor type, so don't get confused 🫶 The CPU type has to be one of mn10300, am33, am33-2 or am34.
• -mreturn-pointer-on-d0 — when generating a function that returns a pointer, the pointer gets returned in both a0 and d0. Otherwise, it's only returned in a0, and trying to call those functions without a prototype gives you errors 😭 Heads up: this option is on by default! Use -mno-return-pointer-on-d0 to turn it off.
• -mno-crt0 — does not link in the C run-time initialization object file 🧚
• -mrelax — tells the linker to run a relaxation optimization pass that shortens branches, calls and absolute memory addresses. This only does anything when you use it on the command line for the final link step 💖

This option makes symbolic debugging impossible. Be careful, bestie 💀

• -mliw — lets the compiler generate Long Instruction Word instructions if the target is AM33 or later. This is the default. This option defines the preprocessor macro __LIW__ 🌈
• -mno-liw — does not let the compiler generate Long Instruction Word instructions. This option defines the preprocessor macro __NO_LIW__ 🍓
• -msetlb — lets the compiler generate the SETLB and Lcc instructions if the target is AM33 or later. This is the default. This option defines the preprocessor macro __SETLB__ ⭐
• -mno-setlb — does not let the compiler generate SETLB or Lcc instructions. This option defines the preprocessor macro __NO_SETLB__ 🙈

---

🍑 Moxie Options 🍑

• -meb — generates big-endian code. This is the default for moxie-*-* configurations 💅
• -mel — generates little-endian code 🌸
• -mmul.x — generates mul.x and umul.x instructions. This is the default for moxiebox-*-* configurations ✨
• -mno-crt0 — does not link in the C run-time initialization object file 🎀

---

💜 MSP430 Options 💜

These options are defined for the MSP430 🔥

• -masm-hex — forces assembly output to ALWAYS use hex constants. Normally those constants are signed decimals, but this option exists for testsuite and/or aesthetic purposes 🦋
• -mmcu= — selects the MCU to target 🧚 This creates a C preprocessor symbol based on the MCU name, converted to upper case and pre- and post-fixed with __. That symbol is then used by the msp430.h header file to pick an MCU-specific supplementary header file, so it's giving organized 💅

This option also sets the ISA to use. If the MCU name is one that's known to only support the 430 ISA, then that one gets selected. Otherwise the 430X ISA is selected. A generic MCU name of msp430 can also be used to select the 430 ISA, and the generic msp430x MCU name selects the 430X ISA ✨

On top of that, an MCU-specific linker script gets added to the linker command line. The script's name is the MCU name with .ld appended. So specifying -mmcu=xxx on the gcc command line defines the C preprocessor symbol __XXX__ and makes the linker search for a script called xxx.ld 🫶

The ISA and hardware multiply support for the different MCUs is hard-coded into GCC. BUT an external devices.csv file can be used to extend device support beyond those hard-coded ones 🌈

GCC searches for devices.csv using the methods below, in the given precedence order. The first method beats the second, and the second beats the third 👑

• Include path specified with -I and -L — devices.csv is searched for in each of the directories specified by include paths and linker library search paths.
• Path specified by the environment variable MSP430_GCC_INCLUDE_DIR — define the value of the global environment variable MSP430_GCC_INCLUDE_DIR as the full path to the directory containing devices.csv, and GCC will search that directory for devices.csv. If devices.csv is found there, that directory is also registered as an include path and linker library path. Header files and linker scripts in this directory can therefore be used without manually specifying -I and -L on the command line 💖
• The msp430-elf{,bare}/include/devices directory — finally, GCC examines msp430-elf{,bare}/include/devices from the toolchain root directory. This directory does NOT exist in a default installation, but if you've created it and copied devices.csv there, then the MCU data gets read. Just like above, this directory is also registered as an include path and linker library path 🍓

If none of the above search methods find devices.csv, then the hard-coded MCU data is used 🙈

• -mwarn-mcu, -mno-warn-mcu — enables (or disables) warnings about conflicts between the MCU name given by -mmcu= and the ISA set by -mcpu and/or the hardware multiply support set by -mhwmult. It also toggles warnings about unrecognized MCU names. This option is on by default ⭐
• -mcpu= — specifies the ISA to use. Accepted values are msp430, msp430x and msp430xv2. This option is deprecated, so use the -mmcu= option to select the ISA instead 🥺
• -msim — links to the simulator runtime libraries and linker script. This overrides any scripts that would be selected by the -mmcu= option 🎀
• -mlarge — uses large-model addressing (20-bit pointers, 20-bit size_t) 🌸
• -msmall — uses small-model addressing (16-bit pointers, 16-bit size_t) 🦋
• -mrelax — this one gets passed to the assembler and linker, and lets the linker do certain optimizations that can't happen until the final link ✨

✨ MSP430 Options, continued ✨

• -mhwmult= — 💖 This picks which kind of hardware multiply your MSP430 chip has. Your choices are none (no hardware multiply at all), 16bit (the original 16-bit-only multiply from the early MCUs), 32bit (the 16/32-bit multiply on the later MCUs), and f5series (the 16/32-bit multiply on the F5-series MCUs). You can also say auto, which tells GCC to figure it out from the MCU name you gave -mmcu. If you skip -mmcu or the MCU name isn't recognised, GCC assumes no hardware multiply. auto is the default, so you don't have to touch it unless you want to 🔥

Hardware multiplies usually happen through a library routine, which saves space in your code. But when you compile at -O3 or higher, the hardware multiplier gets invoked inline instead. That makes your code bigger but faster, so it's a trade-off, bestie 🧚

The hardware multiply routines turn off interrupts while they run and then restore the previous interrupt state when they're done. So they're totally safe to use inside interrupt handlers as well as in regular code ✨

• -minrt — 🌸 Turns on a minimum runtime environment, so there are no static initializers or constructors. It's made for memory-constrained devices. The compiler slips special symbols into some objects so the linker and runtime know which code fragments they need 🫶
• -mtiny-printf — 🎀 Gives you slimmed-down printf and puts library functions, which are much smaller. Heads up though: these tiny versions are not reentrant, so be careful with them in multi-threaded apps 😭

Streams are gone with this option. The string you want printed is always sent to stdout through the write syscall, and it isn't buffered before it goes to write. This option needs Newlib Nano IO, so GCC has to be configured with --enable-newlib-nano-formatted-io 💅

• -mmax-inline-shift= — 🦋 This takes an integer from 0 to 64 inclusive and sets how many inline shift instructions can be emitted for a shift by a constant amount. Once that limit would be exceeded, an mspabi helper function is used instead. The default is 4 ✨

This only matters when a shift by several positions can't be done with a single instruction (for example, all shifts greater than 1 on the 430 ISA) 🍓

Shifts of a 32-bit value are at least twice as expensive, so the number you pass here gets divided by 2, and that resulting value is what's actually used 👑

• -mcode-region= and -mdata-region= — 💜 These tell the compiler where to put functions and data that don't have a lower, upper, either or section attribute. The options are lower, upper, either or any. The first three act like the matching attribute. any is the default, and it leaves placement entirely up to the linker script and how it maps the standard sections (.text, .data, etc.) onto the memory regions 🌈
• -msilicon-errata= — 🔥 Passes a request on to the assembler to turn on the fixes for the named silicon errata 💀
• -msilicon-errata-warn= — ⭐ Passes a request on to the assembler to turn on warning messages for when a silicon erratum might need a fix applied 🙈
• -mwarn-devices-csv and -mno-warn-devices-csv — 🍓 Warns you if devices.csv can't be found or if there's a problem parsing it. This is on by default ✨

---

🌷 NDS32 Options 🌷

These options are defined for NDS32 implementations 🦋

• -mbig-endian — 💖 Generates code in big-endian mode 🌸
• -mlittle-endian — 🌸 Generates code in little-endian mode 💖
• -mreduced-regs — 🎀 Uses the reduced-set registers for register allocation 🧚
• -mfull-regs — 👑 Uses the full-set registers for register allocation ✨
• -mcmov — 🔥 Generates conditional move instructions 💅
• -mno-cmov — 🙈 Does not generate conditional move instructions 😭
• -mext-perf — ⭐ Generates performance extension instructions 🔥
• -mno-ext-perf — 💀 Does not generate performance extension instructions 🫶
• -mext-perf2 — 🌈 Generates performance extension 2 instructions 💜
• -mno-ext-perf2 — 🙈 Does not generate performance extension 2 instructions 🍓
• -mext-string — 🦋 Generates string extension instructions 🎀
• -mno-ext-string — 😭 Does not generate string extension instructions 🌸
• -mv3push — 🧚 Generates v3 push25 and pop25 instructions 💅
• -mno-v3push — 💀 Does not generate v3 push25 and pop25 instructions 👑
• -m16-bit — ✨ Generates 16-bit instructions 🌈
• -mno-16-bit — 🙈 Does not generate 16-bit instructions 💖
• -misr-vector-size=num — 🎀 Sets the size of each interrupt vector, which must be 4 or 16 🔥
• -mcache-block-size=num — 🍓 Sets the size of each cache block, which must be a power of 2 between 4 and 512 🦋
• -march=arch — 👑 Sets the name of the target architecture 💜
• -mcmodel=code-model — 🌸 Sets the code model to one of the following 💅
  • small — 🧚 All the data and read-only data segments must be within 512KB of addressing space. The text segment must be within 16MB of addressing space 🫶
  • medium — 🌈 The data segment must be within 512KB, while the read-only data segment can be within 4GB of addressing space. The text segment should still be within 16MB of addressing space 💖
  • large — 👑 All the text and data segments can be within 4GB of addressing space ✨
• -mctor-dtor — ⭐ Enables the constructor/destructor feature 🔥
• -mrelax — 💅 Guides the linker to relax instructions 🦋

---

🌈 Nvidia PTX Options 🌈

These options are defined for Nvidia PTX 💜

• -m64 — 🎀 Ignored, but kept around for backward compatibility. Only the 64-bit ABI is supported 🫶
• -march=architecture-string — 🔥 Generates code for the PTX ISA target architecture you specify. Valid architecture strings are sm_30, sm_35, sm_37, sm_52, sm_53, sm_61, sm_70, sm_75, sm_80, and sm_89. The default depends on how the compiler was configured, so check --with-arch 💀

This option sets the value of the preprocessor macro __PTX_SM__. For example, for sm_35 it has the value 350 ✨

• -misa=architecture-string — 🌸 Just an alias of -march= 💅
• -march-map=architecture-string — 🧚 Picks the closest available -march= value that isn't more capable than what you asked for. For example, -march-map=sm_50 gives you -march=sm_37, and -march-map=sm_53 gives you -march=sm_53 👑
• -mptx=version-string — 🦋 Generates code for the PTX ISA version you specify. Valid version strings are 3.1, 4.1, 4.2, 5.0, 6.0, 6.3, 7.0, 7.3, and 7.8 🍓

The default PTX ISA version is whichever one added support for your selected PTX ISA target architecture (see -march=), but it's at least 6.3, or 7.3 for -march=sm_52 and higher 🌈

This option sets the values of the preprocessor macros __PTX_ISA_VERSION_MAJOR__ and __PTX_ISA_VERSION_MINOR__. For example, for 3.1 the macros have the values 3 and 1, respectively 💜

• -mmainkernel — 🔥 Links in code for a __main kernel. This is for stand-alone execution instead of offloading 🙈
• -moptimize — 💖 Applies partitioned execution optimizations. This is the default whenever any level of optimization is selected ✨
• -msoft-stack and -mno-soft-stack — 🫶 With -mno-soft-stack (the default, unless -mgomp has been specified), GCC uses PTX "native" stacks. That means the code uses .local memory or PTX alloca directly for stack storage. Unless -mptx=7.3 or higher and -march=sm_52 or higher are active, variable-length arrays and dynamically allocating memory on the stack with alloca are not supported 😭

With -msoft-stack (implied by -mgomp), the code doesn't use .local memory or PTX alloca directly for stack storage. Instead, a per-warp stack pointer is maintained explicitly 🧚 That makes variable-length stack allocation possible (with variable-length arrays or alloca). When global memory is the underlying storage, it also lets you access automatic variables from other threads, or with atomic instructions 🌈 This code generation variant is used for OpenMP offloading, but the option is exposed on its own so you can test the compiler. To generate code suitable for linking into programs that use OpenMP offloading, use -mgomp instead 💅

• -muniform-simt — 👑 Switches to a code generation variant that lets all threads in each warp execute, while keeping memory state and side effects as if only one thread per warp were active outside of OpenMP SIMD regions 💀 All atomic operations and calls to the runtime (malloc, free, vprintf) are conditionally executed (if and only if the current lane index equals the master lane index), and the register being assigned gets copied via a shuffle instruction from the master lane 🦋 Outside of SIMD regions, lane 0 is the master. Inside them, each thread sees itself as the master 🎀

The shared memory array int __nvptx_uni[] stores all-zeros or all-ones bitmasks for each warp, which show the current mode (0 outside of SIMD regions) 🔥 Each thread can bitwise-AND the bitmask at position tid.y with the current lane index to compute the master lane index ✨

• -mgomp — 🌸 Generates code for OpenMP offloading. It enables -msoft-stack and -muniform-simt, and selects the matching multilib variant 🫶

---

🧡 OpenRISC Options 🧡

These options are defined for OpenRISC 🍓

• -mboard=name — 🌈 Configures a board-specific runtime. This gets passed to the linker for newlib board library linking. The default is or1ksim 💖
• -mnewlib — 🙈 This option is ignored, it's only there for compatibility. It used to select linker and preprocessor options for use with newlib 💀
• -msoft-div and -mhard-div — 🎀 Selects software or hardware divide (l.div, l.divu) instructions. The default is hardware divide 🧚
• -msoft-mul and -mhard-mul — 💜 Selects software or hardware multiply (l.mul, l.muli) instructions. The default is hardware multiply 👑
• -msoft-float and -mhard-float — 🦋 Selects software or hardware for floating-point operations. The default is software 🌸
• -mdouble-float — 🔥 When -mhard-float is selected, this enables generation of double-precision floating-point instructions. By default, functions from libgcc are used to perform double-precision floating-point operations 💅
• -munordered-float — ✨ When -mhard-float is selected, this turns on generation of unordered floating point compare and set flag (lf.sfun*) instructions 🔥. By default, functions from libgcc handle those unordered compare and set flag operations instead 💅.
• -mcmov — 🎀 Turns on generation of conditional move (l.cmov) instructions 🦋. By default, the same result is generated using set and branch 🌸.
• -mror — 🌈 Turns on generation of rotate right (l.ror) instructions 🔄. By default, functions from libgcc handle rotate right operations 🫶.
• -mrori — ✨ Turns on generation of rotate right with immediate (l.rori) instructions 💜. By default, functions from libgcc handle rotate right with immediate operations 🧚.
• -msext — 💖 Turns on generation of sign extension (l.ext*) instructions 🍓. By default, memory loads are used to perform sign extension 💀.
• -msfimm — 🌸 Turns on generation of compare and set flag with immediate (l.sf*i) instructions 💅. By default, extra instructions get generated to store the immediate into a register first 🙈.
• -mshftimm — ⭐ Turns on generation of shift with immediate (l.srai, l.srli, l.slli) instructions 🔥. By default, extra instructions get generated to store the immediate into a register first 😭.
• -mcmodel=small — 🦋 Generates OpenRISC code for the small model, where the GOT is limited to 64k 🎀. This is the default model 👑.
• -mcmodel=large — 🌈 Generates OpenRISC code for the large model, where the GOT may grow up to 4G in size 🧚.

---

✨ PDP-11 Options ✨

okay so these options are defined for the PDP-11 🧚:

• -mfpu — 💅 Uses hardware FPP floating point 🔥. This is the default 👑. (FIS floating point on the PDP-11/40 is not supported 💀.) Implies -m45 ✨.
• -msoft-float — 🙈 Does not use hardware floating point 🫶.
• -mac0 — 🍓 Returns floating-point results in ac0 (fr0 in Unix assembler syntax) 💜.
• -mno-ac0 — 🌸 Returns floating-point results in memory 🦋. This is the default 👑.
• -m40 — 💖 Generates code for a PDP-11/40 🌈. Implies -msoft-float -mno-split 🔥.
• -m45 — ⭐ Generates code for a PDP-11/45 ✨. This is the default 👑.
• -m10 — 🧚 Generates code for a PDP-11/10 🎀. Implies -msoft-float -mno-split 💅.
• -mint16, -mno-int32 — 🍓 Uses 16-bit int 💜. This is the default 🌸.
• -mint32, -mno-int16 — 🔥 Uses 32-bit int ✨.
• -msplit — 🦋 The target has split instruction and data space 🌈. Implies -m45 💖.
• -munix-asm — 💅 Uses Unix assembler syntax 🫶.
• -mdec-asm — 🎀 Uses DEC assembler syntax 🧚.
• -mgnu-asm — ✨ Uses GNU assembler syntax 💜. This is the default 👑.
• -mlra — 🌈 Uses the new LRA register allocator 🔄. By default, the old reload allocator is used 🙈.

---

✨ PowerPC Options ✨

these are listed under 🌸

---

✨ PRU Options ✨

these command-line options are defined for the PRU target 💅:

• -minrt — 🔥 Links with a minimum runtime environment 💀. This can significantly reduce the size of the final ELF binary, but some standard C runtime features get removed 😭.

🚨 This option disables support for static initializers and constructors. Beware that the compiler could still generate code with static initializers and constructors. It is up to the programmer to make sure the source program will not use those features 🙈.

The minimal startup code would not pass argc and argv arguments to main, so main must be declared as int main (void) 🧚. This is already the norm for most firmware projects ✨.

• -mmcu=mcu — 💖 Specifies the PRU hardware variant to use 🌈. A correspondingly named spec file would be loaded, passing the memory region sizes to the linker and defining hardware-specific C macros 🦋.

Newlib provides only the sim spec, which is meant for running regression tests using a simulator 🎀. Specs for real hardware can be obtained by installing the GnuPruMcu (https://github.com/dinuxbg/gnuprumcu/) package 🫶.

• -mno-relax — 🍓 Makes GCC pass the --no-relax command-line option to the linker instead of the --relax option 🔄.
• -mloop — 💜 Allows (or does not allow) GCC to use the LOOP instruction 🌸.
• -mabi=variant — 👑 Specifies the ABI variant to output code for 💅. -mabi=ti selects the unmodified TI ABI, while -mabi=gnu selects a GNU variant that copes more naturally with certain GCC assumptions 🫶. These are the differences 🔥:

✨ Function Pointer Size ✨

The TI ABI specifies that function (code) pointers are 16-bit 💀, whereas GNU supports only 32-bit data and code pointers 😭.

✨ Optional Return Value Pointer ✨

Function return values larger than 64 bits are passed by using a hidden pointer as the first argument of the function 🧚. The TI ABI, though, mandates that the pointer can be NULL in case the caller is not using the returned value 🙈. GNU always passes and expects a valid return value pointer 💖.

⚠️ The current -mabi=ti implementation simply raises a compile error when any of the above code constructs is detected 😭. As a consequence, the standard C library cannot be built and it is omitted when linking with -mabi=ti 💀.

Relaxation is a GNU feature, and for safety reasons it is disabled when using -mabi=ti 🌈. The TI toolchain does not emit relocations for QBBx instructions, so the GNU linker cannot adjust them when shortening adjacent LDI32 pseudo instructions 🦋.

---

✨ RISC-V Options ✨

these command-line options are defined for RISC-V targets 🌈:

• -mbranch-cost=n — 🎀 Sets the cost of branches to roughly n instructions 💅.
• -mplt, -mno-plt — 🫶 When generating PIC code, does or doesn't allow the use of PLTs 🔥. Ignored for non-PIC 🙈. The default is -mplt ✨.
• -mabi=ABI-string — 💜 Specifies the integer and floating-point calling convention 🧚. The ABI-string has two parts: the size of integer types and the registers used for floating-point types 👑. For example, -march=rv64ifd -mabi=lp64d means that long and pointers are 64-bit (implicitly defining int to be 32-bit), and that floating-point values up to 64 bits wide are passed in F registers 🦋. Compare that with -march=rv64ifd -mabi=lp64f, which still lets the compiler generate code that uses the F and D extensions but only allows floating-point values up to 32 bits long to be passed in registers 🌸; or -march=rv64ifd -mabi=lp64, in which no floating-point arguments get passed in registers at all 💀.

The default for this argument is system dependent, so users who want a specific calling convention should specify one explicitly 😭. The valid calling conventions are: ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d 💖. Some calling conventions are impossible to implement on some ISAs 🙈: for example, -march=rv32if -mabi=ilp32d is invalid, because the ABI requires 64-bit values to be passed in F registers, but F registers are only 32 bits wide 🚫. There is also the ilp32e ABI, which can only be used with the rv32e architecture, and the lp64e ABI, which can only be used with rv64e 🧚. Those ABIs are not well specified at present and are subject to change ⚠️.

• -mfdiv, -mno-fdiv — ✨ Does or doesn't use hardware floating-point divide and square root instructions 🔥. This requires the F or D extensions for floating-point registers 🫶. The default is to use them if the specified architecture has these instructions 👑.
• -mfence-tso, -mno-fence-tso — 🌈 Does or doesn't use the fence.tso instruction 🦋, which is unimplemented on some processors (including those from T-Head) 💀. If the fence.tso instruction is not available, a stronger fence is used instead 🎀.
• -mdiv, -mno-div — 💅 Does or doesn't use hardware instructions for integer division 💜. This requires the M extension 🔥. The default is to use them if the specified architecture has these instructions 🌸.
• -misa-spec=ISA-spec-string — 🧚 Specifies the version of the RISC-V Unprivileged (formerly User-Level) ISA specification to produce code conforming to 📜. The possibilities for ISA-spec-string are 🍓:
  • 2.2 — produces code conforming to version 2.2 ✨.
  • 20190608 — produces code conforming to version 20190608 🦋.
  • 20191213 — produces code conforming to version 20191213 💖.

The default is -misa-spec=20191213, unless GCC has been configured with --with-isa-spec= specifying a different default version 👑.

• -march=ISA-string — 🌈 Generates code for the given RISC-V ISA (e.g. rv64im) 💅. ISA strings must be lower-case 🫶. Examples include rv64i, rv32g, rv32e, and rv32imaf ✨. Additionally, a special value, help (-march=help), is accepted to list all supported extensions 🧚.

The syntax of the ISA string is defined as follows 🔥:

• The string must start with rv32 or rv64, followed by i, e, or g, referred to as the base ISA 💜.
• The subsequent part of the string is a list of extension names 🌸. Extension names can be categorized as multi-letter (e.g. zba) and single-letter (e.g. v) 🦋. Single-letter extensions can appear consecutively, but multi-letter extensions must be separated by underscores 🎀.
• An underscore can appear anywhere after the base ISA 🫶. It has no specific effect, but it is used to improve readability and can act as a separator ✨.
• Extension names may include an optional version number, following the syntax <major>p<minor> or <major> (e.g. m2p1 or m2) 💖.

Supported extensions are listed below 👑:

• i — version 2.0, 2.1 — Base integer extension 💅.
• e — version 2.0 — Reduced base integer extension 🌸.
• g — no version listed — General-purpose computing base extension, where g will expand to i, m, a, f, d, zicsr and zifencei 🌈.
• m — version 2.0 — Integer multiplication and division extension 🔥.
• a — version 2.0, 2.1 — Atomic extension 🦋.
• f — version 2.0, 2.2 — Single-precision floating-point extension 🧚.
• d — version 2.0, 2.2 — Double-precision floating-point extension 💜.
• c — version 2.0 — Compressed extension 🎀.
• h — version 1.0 — Hypervisor extension 🍓.
• v — version 1.0 — Vector extension ✨.
• zicsr — version 2.0 — Control and status register access extension 🫶.
• zifencei — version 2.0 — Instruction-fetch fence extension 💀.
• zicond — version 1.0 — Integer conditional operations extension 🌈.
• za64rs — version 1.0 — Reservation set size of 64 bytes 🦋.
• za128rs — version 1.0 — Reservation set size of 128 bytes 💖.
• zawrs — version 1.0 — Wait-on-reservation-set extension ⭐.
• zba — version 1.0 — Address calculation extension 🔥.

• zbb (1.0) — Basic bit manipulation, bestie, the whole vibe 🦋
• zbc (1.0) — Carry-less multiplication, very math-coded 🧮
• zbs (1.0) — Single-bit operations, tiny but mighty ✨
• zfinx (1.0) — Single-precision floats living in integer registers 💅
• zdinx (1.0) — Double-precision floats living in integer registers 💖
• zhinx (1.0) — Half-precision floats living in integer registers 🌸
• zhinxmin (1.0) — The minimal half-precision-in-integer-registers version 🫶
• zbkb (1.0) — Cryptography bit manipulation 🔐
• zbkc (1.0) — Cryptography carry-less multiply 🔐
• zbkx (1.0) — Cryptography crossbar permutation 🔐
• zkne (1.0) — AES encryption, secret agent stuff 🕵️
• zknd (1.0) — AES decryption, undoing the secret agent stuff 🕵️
• zknh (1.0) — Hash functions 🧂
• zkr (1.0) — Entropy source, the randomness queen 🎲
• zksed (1.0) — SM4 block cipher 🀄
• zksh (1.0) — SM3 hash function 🀄
• zkt (1.0) — Data independent execution latency, no timing drama 🕰️
• zk (1.0) — Standard scalar cryptography, the whole package 📦
• zkn (1.0) — NIST algorithm suite 🇺🇸
• zks (1.0) — ShangMi algorithm suite 🇨🇳
• zihintntl (1.0) — Non-temporal locality hints 💜
• zihintpause (1.0) — Pause hints, take a breath bestie 🧘
• zicboz (1.0) — Cache-block zero 🧊
• zicbom (1.0) — Cache-block management 🧊
• zicbop (1.0) — Cache-block prefetch 🧊
• zic64b (1.0) — Cache blocks are 64 bytes 📏
• ziccamoa (1.0) — Main memory supports all the atomics in A ⚛️
• ziccif (1.0) — Main memory supports instruction fetch with the atomicity requirement 🧠
• zicclsm (1.0) — Main memory supports misaligned loads and stores 🙈
• ziccrse (1.0) — Main memory supports forward progress on LR/SC sequences 🏃‍♀️
• zicntr (2.0) — Standard base counters and timers ⏰
• zihpm (2.0) — Standard hardware performance counters 📈
• ztso (1.0) — Total store ordering, very orderly 📚
• zve32x (1.0) — Vector extensions for embedded processors 🌈
• zve32f (1.0) — Vector extensions for embedded processors 🌈
• zve64x (1.0) — Vector extensions for embedded processors 🌈
• zve64f (1.0) — Vector extensions for embedded processors 🌈
• zve64d (1.0) — Vector extensions for embedded processors 🌈
• zvl32b (1.0) — Minimum vector length standard extension 📐
• zvl64b (1.0) — Minimum vector length standard extension 📐
• zvl128b (1.0) — Minimum vector length standard extension 📐
• zvl256b (1.0) — Minimum vector length standard extension 📐
• zvl512b (1.0) — Minimum vector length standard extension 📐
• zvl1024b (1.0) — Minimum vector length standard extension 📐
• zvl2048b (1.0) — Minimum vector length standard extension 📐
• zvl4096b (1.0) — Minimum vector length standard extension 📐
• zvbb (1.0) — Vector basic bit manipulation 🦋
• zvbc (1.0) — Vector carry-less multiplication 🧮
• zvkb (1.0) — Vector cryptography bit manipulation 🔐
• zvkg (1.0) — Vector GCM/GMAC 🔐
• zvkned (1.0) — Vector AES block cipher 🕵️
• zvknha (1.0) — Vector SHA-2 secure hash 🧂
• zvknhb (1.0) — Vector SHA-2 secure hash 🧂
• zvksed (1.0) — Vector SM4 block cipher 🀄
• zvksh (1.0) — Vector SM3 secure hash 🀄
• zvkn (1.0) — Vector NIST algorithm suite, which expands to zvkned, zvknhb, zvkb and zvkt 👑
• zvknc (1.0) — Vector NIST algorithm suite with carry-less multiply, which expands to zvkn and zvbc 👑
• zvkng (1.0) — Vector NIST algorithm suite with GCM, which expands to zvkn and zvkg 👑
• zvks (1.0) — Vector ShangMi algorithm suite, which expands to zvksed, zvksh, zvkb and zvkt 👑
• zvksc (1.0) — Vector ShangMi algorithm suite with carry-less multiplication, which expands to zvks and zvbc 👑
• zvksg (1.0) — Vector ShangMi algorithm suite with GCM, which expands to zvks and zvkg 👑
• zvkt (1.0) — Vector data independent execution latency 🕰️
• zfh (1.0) — Half-precision floating point 🌸
• zfhmin (1.0) — Minimal half-precision floating point 🌸
• zvfh (1.0) — Vector half-precision floating point 🌸
• zvfhmin (1.0) — Vector minimal half-precision floating point 🌸
• zvfbfmin (1.0) — Vector BF16 converts 🔄
• zfa (1.0) — Additional floating point, extra spicy 🌶️
• zmmul (1.0) — Integer multiplication ✖️
• zca (1.0) — Integer compressed instructions 🗜️
• zcf (1.0) — Compressed single-precision floating point loads and stores 🗜️
• zcd (1.0) — Compressed double-precision floating point loads and stores 🗜️
• zcb (1.0) — Simple compressed instructions 🗜️
• zce (1.0) — Compressed instruction extensions for embedded processors 🗜️
• zcmp (1.0) — Compressed push and pop 🗜️
• zcmt (1.0) — Table jump instructions 📋
• smaia (1.0) — Advanced interrupt architecture 🚨
• smepmp (1.0) — PMP enhancements for memory access and execution prevention in Machine mode 🛡️
• smstateen (1.0) — State enable 🚪
• ssaia (1.0) — Advanced interrupt architecture for supervisor mode 🚨
• sscofpmf (1.0) — Count overflow and filtering 🔢
• ssstateen (1.0) — State-enable for supervisor mode 🚪
• sstc (1.0) — Supervisor-mode timer interrupts ⏰
• svinval (1.0) — Fine-grained address-translation cache invalidation 🧹
• svnapot (1.0) — NAPOT translation contiguity 🗺️
• svpbmt (1.0) — Page-based memory types 🗂️
• xcvmac (1.0) — Core-V multiply-accumulate 🧩
• xcvalu (1.0) — Core-V miscellaneous ALU 🧩
• xcvelw (1.0) — Core-V event load word 🧩
• xtheadba (1.0) — T-Head address calculation 🐉
• xtheadbb (1.0) — T-Head basic bit manipulation 🐉
• xtheadbs (1.0) — T-Head single-bit instructions 🐉
• xtheadcmo (1.0) — T-Head cache management operations 🐉
• xtheadcondmov (1.0) — T-Head conditional move 🐉
• xtheadfmemidx (1.0) — T-Head indexed memory operations for floating-point registers 🐉
• xtheadfmv (1.0) — T-Head double floating-point high-bit data transmission 🐉
• xtheadint (1.0) — T-Head acceleration interruption 🐉
• xtheadmac (1.0) — T-Head multiply-accumulate 🐉
• xtheadmemidx (1.0) — T-Head indexed memory operations 🐉
• xtheadmempair (1.0) — T-Head two-GPR memory operations 🐉
• xtheadsync (1.0) — T-Head multi-core synchronization 🐉
• xventanacondops (1.0) — Ventana integer conditional operations 🌷

When -march= is not specified, the setting from -mcpu is used, bestie 💖

If both -march and -mcpu= are left out, the default here depends on your system 🖥️ so if you want a specific architecture extension, you should totally name it yourself 💅

When the RISC-V specs say one extension depends on others, GCC will automatically add those dependent extensions to the enabled set, as long as you didn't add them yourself ✨

---

• -mcpu=processor-string — Use the architecture of, and optimize the output for, the given processor, identified by its particular CPU name 🧠 The permitted values are: sifive-e20, sifive-e21, sifive-e24, sifive-e31, sifive-e34, sifive-e76, sifive-s21, sifive-s51, sifive-s54, sifive-s76, sifive-u54, sifive-u74, sifive-x280, sifive-xp450, sifive-x670, thead-c906, tt-ascalon-d8, and xiangshan-nanhu 🐣

Note that -mcpu does not override -march or -mtune 🙅‍♀️

• -mtune=processor-string — Optimize the output for the given processor, identified by its microarchitecture or particular CPU name 🎯 The permitted values are: generic-ooo, rocket, sifive-3-series, sifive-5-series, sifive-7-series, size, sifive-p400-series, sifive-p600-series, and all valid options for -mcpu= 💜

When -mtune= is not specified, the setting from -mcpu is used, and if neither is given, the default is rocket 🚀

The size choice is not meant for end-users, lowkey an internal thing 🙈 It gets used when -Os is specified. It overrides the instruction cost info provided by -mtune=, but it does not override the pipeline info. This helps shrink the code size while still giving good performance 📉✨

• -mpreferred-stack-boundary=num — Try to keep the stack boundary aligned to a boundary of 2 raised to num bytes 📏 If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes, or 128 bits) 🌟

⚠️ Warning, bestie: if you use this switch, you must build all modules with the same value, including any libraries. That includes the system libraries and startup modules 😭

-msmall-data-limit=n is my favorite way to shrink things 🧚. It puts global and static data smaller than n bytes into a special section, but only on some targets 🌸

• -msave-restore, -mno-save-restore — okay so these decide whether the prologue and epilogue code gets smaller but slower by calling library functions 💅. The default is the fast inline prologues and epilogues ✨
• -mmovcc, -mno-movcc — -mmovcc makes GCC produce branchless conditional-move sequences, even on targets without dedicated conditional instructions 🦋. When it's on, it builds sequences of ALU operations out of base integer ISA instructions wherever that's worth it 🔥
• -minline-atomics, -mno-inline-atomics — -mno-inline-atomics is the smaller but slower option, using subword atomic emulation that calls libatomic functions 🙈. The default is fast inline subword atomics that don't need libatomic at all 💖
• -minline-strlen, -mno-inline-strlen — this one tries to inline strlen calls when it can 🍓. It only happens if the string is properly aligned and the accelerated instructions are available. By default, strlen calls are not inlined 💀
• -minline-strcmp, -mno-inline-strcmp — same vibe as strlen 💅. GCC only inlines strcmp calls when the strings are properly aligned and the accelerated instructions exist. The default is to not inline strcmp calls ✨

The --param riscv-strcmp-inline-limit=n parameter controls the maximum number of bytes that the inlined code compares 🔥. Its default value is 64 🫶

• -minline-strncmp, -mno-inline-strncmp — also the strcmp energy but for strncmp 🌈. Inlining only happens when the strings are properly aligned and the accelerated instructions are around. The default is to not inline strncmp calls 🙅‍♀️

Same deal here: --param riscv-strcmp-inline-limit=n sets the maximum number of bytes compared by the inlined code, and the default is 64 💜

• -mshorten-memrefs, -mno-shorten-memrefs — this is a sneaky one 🦋. With it on, GCC tries to use more compressed load/store instructions by swapping a load/store of base register + large offset for a new load/store of new base + small offset. If that new base lands in a compressed register, the new load/store can be compressed too ✨. Right now it only works on 32-bit integer load/stores 🌸
• -mstrict-align, -mno-strict-align — okay so this is about whether unaligned memory accesses are generated. The wording in the original is a little muddled ("Do not or do generate"), but the gist is that the default depends on whether the processor you're optimizing for handles fast unaligned access 🙈
• -mscalar-strict-align, -mno-scalar-strict-align — same unaligned-access drama as above 💅. The default also depends on the processor's fast unaligned access support. This one is just an alias for -mstrict-align 🫶
• -mvector-strict-align, -mno-vector-strict-align — this is the vector version of the story 💖. Unaligned vector memory accesses are off by default, unless the processor you're targeting explicitly supports element-misaligned vector memory access ✨
• -mcmodel=medlow — the medium-low code model 🧚. The program and its statically defined symbols have to fit inside one 2 GiB address range, sitting between absolute addresses -2 GiB and +2 GiB 🍓. Programs can be statically or dynamically linked. This is the default code model, unless GCC was configured with --with-cmodel= pointing at a different default 👑
• -mcmodel=medany — the medium-any code model 🌈. The program and its statically defined symbols just have to be within any single 2 GiB address range. Static or dynamic linking both work 💜

The code from medium-any is position-independent, but it is not guaranteed to work when linked into position-independent executables or libraries 💀

• -mcmodel=large — the big boss code model 👑. It has no restrictions on the size or placement of symbols 🔥
• -mexplicit-relocs, -mno-exlicit-relocs — -mexplicit-relocs means the compiler uses assembler relocation operators when handling symbolic addresses 🦋. The alternative is assembler macros, which may limit optimization 🙈. (The original spells the second one -mno-exlicit-relocs, so that's exactly what's in the code here 🫶)
• -mrelax, -mno-relax — this takes advantage of linker relaxations to cut down the number of instructions needed to materialize symbol addresses ✨. The default is to take advantage of linker relaxations 💅
• -mriscv-attribute, -mno-riscv-attribute — -mriscv-attribute emits a RISC-V attribute that records extra info into ELF objects, and -mno-riscv-attribute skips emitting it 🌸. Heads up: this feature needs at least binutils 2.32 🫶
• -mcsr-check, -mno-csr-check — these enable or disable the CSR checking 🧚
• -malign-data=type — controls how GCC aligns variables and constants of array, structure, or union types 💖. The supported values for type are xlen, which uses the x register width as the alignment value, and natural, which uses natural alignment. xlen is the default 👑
• -mbig-endian — generates big-endian code 🌈. This is the default when GCC is configured for a riscv64be-*-* or riscv32be-*-* target 💜
• -mlittle-endian — generates little-endian code ✨. This is the default when GCC is configured for a riscv64-*-* or riscv32-*-* target, but not a riscv64be-*-* or riscv32be-*-* target 🫶
• -mstack-protector-guard=guard, -mstack-protector-guard-reg=reg, -mstack-protector-guard-offset=offset — these generate stack protection code that uses a canary at guard 🛡️. The supported locations are global for a global canary, or tls for a per-thread canary in the TLS block 🧚

With the tls choice, -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset are the ones that get specific: they pick which register is the base for reading the canary, and what offset from that base to read at 🔥. There's no default register or offset, because this is entirely for use within the Linux kernel 🐧

• -mtls-dialect=desc — uses TLS descriptors as the thread-local storage mechanism for dynamic accesses to TLS variables ✨
• -mtls-dialect=trad — uses traditional TLS as the thread-local storage mechanism for dynamic accesses to TLS variables 🌸. This is the default 💅

---

💜 RL78 Options 💜

• -msim — links in extra target libraries so the program can run inside a simulator 🧚
• -mmul=none, -mmul=g10, -mmul=g13, -mmul=g14, -mmul=rl78 — picks the type of hardware multiplication and division support to use 🔥. The simplest is "none", which uses software for both multiplication and division, and it's the default 🙈. "g13" is for the hardware multiply/divide peripheral on the RL78/G13 (S2 core) targets 🦋. "g14" turns on the multiplication and division instructions from the RL78/G14 (S3 core) parts 👑. "rl78" is an alias for "g14", and "mg10" is an alias for "none" 💖

A C preprocessor macro also gets defined based on this option. The possible values are "__RL78_MUL_NONE__", "__RL78_MUL_G13__", or "__RL78_MUL_G14__" ✨

• -mcpu=g10, -mcpu=g13, -mcpu=g14, -mcpu=rl78 — specifies which RL78 core to target 💅. The default is the G14 core, also known as an S3 core or just RL78 👑. The G13 (S2) core doesn't have multiply or divide instructions, and uses a hardware peripheral for those operations instead 🦋. The G10 (S1) core has no register banks, so it uses a different calling convention 🙈

If this option is set, it also picks the hardware multiply support to use, unless you override it with an explicit -mmul=none on the command line 🫶. So -mcpu=g13 turns on the G13 hardware multiply peripheral, and -mcpu=g10 turns off hardware multiplication altogether 💀

Heads up: even though the RL78/G14 core is the default target, passing -mcpu=g14 or -mcpu=rl78 on the command line does change how the toolchain behaves, because it also enables G14 hardware multiply support 😭. If you don't specify these on the command line, software multiplication routines get used even though the code targets the RL78 core. This is for backwards compatibility with older toolchains that didn't have hardware multiply and divide support 🥺

A C preprocessor macro also gets defined based on this option. The possible values are "__RL78_G10__", "__RL78_G13__", or "__RL78_G14__" 🌈

• -mg10, -mg13, -mg14, -mrl78 — these are aliases for the matching -mcpu= option 🎀. They're only here for backwards compatibility 🧚
• -mallregs — lets the compiler use all of the available registers 💪. By default, registers r24..r31 are reserved for interrupt handlers. With this on, those registers can be used in ordinary functions too ✨
• -m64bit-doubles, -m32bit-doubles — makes the "double" data type 64 bits (-m64bit-doubles) or 32 bits (-m32bit-doubles) 🌸. The default is -m32bit-doubles 💖
• -msave-mduc-in-interrupts, -mno-save-mduc-in-interrupts — tells interrupt handler functions to preserve the MDUC registers 🫶. You only really need this if normal code might touch the MDUC registers, like if it does multiplication and division. By default, the MDUC registers get ignored, because that makes interrupt handlers faster 🔥. The target option -mg13 has to be passed for this to work, since this feature only exists on the G13 target (S2 core) 🦋. The MDUC registers only get saved if the interrupt handler does a multiplication or division, or calls another function 👑

---

🌷 IBM RS/6000 and PowerPC Options 🌷

These -m options are defined for the IBM RS/6000 and PowerPC 🧚

• -mpowerpc-gpopt, -mno-powerpc-gpopt, -mpowerpc-gfxopt, -mno-powerpc-gfxopt, -mpowerpc64, -mno-powerpc64, -mmfcrf, -mno-mfcrf, -mpopcntb, -mno-popcntb, -mpopcntd, -mno-popcntd, -mfprnd, -mno-fprnd, -mcmpb, -mno-cmpb, -mhard-dfp, -mno-hard-dfp — these are the options that say which instructions are available on the processor you're using 💅. Their default value gets decided when GCC is configured 🌸. Specifying -mcpu=cpu_type overrides whatever these options say 👑. We recommend using -mcpu=cpu_type instead of the options listed above 💖

Okay so the PowerPC options are where things get really juicy 💅✨

Turning on -mpowerpc-gpopt lets GCC use the optional PowerPC instructions from the General Purpose group, including floating-point square root 🌸 And -mpowerpc-gfxopt unlocks the optional instructions from the Graphics group, like floating-point select 🦋

-mmfcrf lets GCC generate the move from condition register field instruction. It's on the POWER4 processor and other chips that speak PowerPC V2.01 🔥 Then there's -mpopcntb, which gets you the popcount instruction and the double-precision FP reciprocal estimate instruction. That one's from POWER5 and other V2.02 chips 💜 -mpopcntd gives you the popcount instruction from POWER7 and other V2.06 processors 🎀 -mfprnd lets GCC emit the FP round to integer instructions, found on POWER5+ and other V2.03 chips ⭐ -mcmpb is the compare bytes instruction from POWER6 and other V2.05 chips 🫶 And -mhard-dfp turns on the decimal floating-point instructions that show up on some POWER processors 🧚

-mpowerpc64 is the big one for 64-bit energy. It lets GCC generate the extra 64-bit instructions from the full PowerPC64 architecture and treat GPRs as 64-bit doubleword quantities 👑 Heads up, GCC defaults to -mno-powerpc64, so you have to ask for it 🙈

---

• -mcpu=cpu_type — this sets the architecture type, register usage, and instruction scheduling parameters for the machine type you name as cpu_type. The values you can pick are 401, 403, 405, 405fp, 440, 440fp, 464, 464fp, 476, 476fp, 505, 601, 602, 603, 603e, 604, 604e, 620, 630, 740, 7400, 7450, 750, 801, 821, 823, 860, 970, 8540, a2, e300c2, e300c3, e500mc, e500mc64, e5500, e6500, ec603e, G3, G4, G5, titan, power3, power4, power5, power5+, power6, power6x, power7, power8, power9, power10, power11, powerpc, powerpc64, powerpc64le, rs64, and native ✨

Okay so -mcpu=powerpc, -mcpu=powerpc64, and -mcpu=powerpc64le are the generic vibes 🌈 They give you pure 32-bit PowerPC (either endian), 64-bit big endian PowerPC, and 64-bit little endian PowerPC. GCC assumes an appropriate generic processor model for scheduling, so nothing too specific 🦋

Then there's native, which is the main character move 👑 It detects the host processor on the machine doing the compiling and picks the architecture option that matches it. Just know that -mcpu=native does nothing if GCC doesn't recognize the processor 💀

Everything else names one specific processor. Code built for that chip runs its best there, and it might not run at all on other chips 😭

The -mcpu option quietly turns a bunch of other options on or off for you 🫶 The list is -maltivec, -mfprnd, -mhard-float, -mmfcrf, -mmultiple, -mpopcntb, -mpopcntd, -mpowerpc64, -mpowerpc-gpopt, -mpowerpc-gfxopt, -mmulhw, -mdlmzb, -mmfpgpr, -mvsx, -mcrypto, -mhtm, -mpower8-fusion, -mquad-memory, -mquad-memory-atomic, -mfloat128, -mfloat128-hardware, -mprefixed, -mpcrel, -mmma, and -mrop-protect 🌸

The exact set of options for each CPU changes between compiler versions. GCC picks whatever seems to make the best code for that chip, so it doesn't always match what the hardware can actually do 🙈

Want to override one? Just put it after -mcpu, like -mcpu=970 -mno-altivec. Order matters here bestie 💅

On AIX, -maltivec and -mpowerpc64 don't get flipped by -mcpu right now, because AIX doesn't fully support them yet. You can still turn them on or off yourself if you're sure it'll work in your environment 🎀

• -mtune=cpu_type — this only sets the instruction scheduling parameters for cpu_type. It doesn't touch the architecture type or register usage like -mcpu=cpu_type does ✨ It takes the same values as -mcpu. If you use both, the code uses the architecture and registers from -mcpu, but the scheduling comes from -mtune 🦋
• -mcmodel=small — generates PowerPC64 code for the small model, where the TOC is capped at 64k 🧚
• -mcmodel=medium — generates PowerPC64 code for the medium model, where the TOC and other static data can total up to 4G. This is the default for 64-bit Linux 💜
• -mcmodel=large — generates PowerPC64 code for the large model. The TOC can be up to 4G, and other data and code is only limited by the 64-bit address space 👑
• -maltivec, -mno-altivec — -maltivec generates code that uses AltiVec instructions and also turns on the built-in functions that give you more direct access to the AltiVec instruction set 🔥 -mno-altivec does the opposite. You might also need -mabi=altivec to adjust the current ABI with AltiVec ABI enhancements 🌈

When you use -maltivec, the element order for AltiVec intrinsics like "vec_splat", "vec_extract", and "vec_insert" matches the array element order for your target's endianness. So on a big-endian platform, element zero is the leftmost element in a vector register. On a little-endian platform, element zero is the rightmost one 🙈

• -mvrsave, -mno-vrsave — -mvrsave generates VRSAVE instructions when it's making AltiVec code. -mno-vrsave skips them 🦋
• -msecure-plt — generates code that lets ld and ld.so build executables and shared libraries with non-executable ".plt" and ".got" sections. This one's a PowerPC 32-bit SYSV ABI option 🫶
• -mbss-plt — generates code that uses a BSS ".plt" section, which ld.so fills in. It needs ".plt" and ".got" sections that are both writable and executable 😭 Also a PowerPC 32-bit SYSV ABI option 🧚
• -msplit-patch-nops — when you add NOPs for a patchable area with -fpatchable-function-entry, this puts the "before" NOPs in front of the global entry point and the "after" NOPs after the local entry point. That means the NOPs aren't consecutive when a global entry point gets generated ✨ Without this option, the NOPs go right before and right after the local entry point. That keeps them consecutive, but it pushes the global and local entry points further apart 💜 If only one entry point is generated, this option does nothing 💀
• -misel, -mno-isel — turns the generation of ISEL instructions on or off 🌸
• -mvsx, -mno-vsx — -mvsx generates code that uses vector/scalar (VSX) instructions and turns on built-in functions for more direct VSX access 🔥 -mno-vsx generates code that doesn't use them 🎀
• -mcrypto, -mno-crypto — enables or disables the built-in functions that give direct access to the cryptographic instructions added in version 2.07 of the PowerPC ISA 🔐🌈
• -mhtm, -mno-htm — enables or disables the built-in functions for the Hardware Transactional Memory (HTM) instructions, which were also added in version 2.07 of the PowerPC ISA 🦋
• -mpower8-fusion, -mno-power8-fusion — -mpower8-fusion keeps some integer operations next to each other so they can get fused together on POWER8 and later processors 🧚 -mno-power8-fusion doesn't keep them adjacent like that 🙈
• -mquad-memory, -mno-quad-memory — -mquad-memory generates code that uses the non-atomic quad word memory instructions. -mno-quad-memory skips them. The -mquad-memory option needs 64-bit mode 👑
• -mquad-memory-atomic, -mno-quad-memory-atomic — -mquad-memory-atomic generates code that uses the atomic quad word memory instructions. -mno-quad-memory-atomic skips them. This one also needs 64-bit mode 💅
• -mfloat128, -mno-float128 — these turn the __float128 keyword on or off for IEEE 128-bit floating point. You get either software emulation for IEEE 128-bit floating point or hardware instructions 🌈

To use the IEEE 128-bit floating point support, the VSX instruction set (-mvsx) has to be enabled first. Also, IEEE 128-bit floating point is only supported on Linux 😭

-mfloat128 is on by default on PowerPC Linux systems that use the VSX instruction set. On other systems it's off 🫶

If you use the ISA 3.0 instruction set (-mcpu=power9) on a 64-bit system, the IEEE 128-bit floating point support also turns on the generation of ISA 3.0 IEEE 128-bit floating point instructions ⭐ Otherwise, if you don't ask for ISA 3.0 instructions, or you're targeting a 32-bit big endian system, IEEE 128-bit floating point gets done with software emulation 🧚

• -mfloat128-hardware, -mno-float128-hardware — enables or disables using ISA 3.0 hardware instructions to support the __float128 data type 🔥

-mfloat128-hardware is on by default on PowerPC Linux systems that use the ISA 3.0 instruction set. On other systems it's off 💜

• -m32, -m64 — generates code for the 32-bit or 64-bit environments of Darwin and SVR4 targets (including GNU/Linux) 🌸 The 32-bit environment sets int, long, and pointer to 32 bits, and the code runs on any PowerPC variant 🎀 The 64-bit environment sets int to 32 bits and long and pointer to 64 bits. It generates code for PowerPC64, just like -mpowerpc64 ✨
• -mfull-toc, -mno-fp-in-toc, -mno-sum-in-toc, -mminimal-toc — these all change how the TOC (Table Of Contents) gets generated, and every executable file gets one 🧚 -mfull-toc is the default. With it, GCC gives at least one TOC entry to each unique non-automatic variable reference in your program. GCC also puts floating-point constants in the TOC 💜 The catch is that only 16,384 entries fit in the TOC 😭

If the linker yells that you've overflowed the available TOC space, you can shrink how much TOC space you use with -mno-fp-in-toc and -mno-sum-in-toc 🫶 -mno-fp-in-toc stops GCC from putting floating-point constants in the TOC. -mno-sum-in-toc makes GCC generate code that calculates the sum of an address and a constant at run time, instead of stuffing that sum into the TOC 🌈 You can use one or both. Each one makes the code very slightly slower and larger, but that's the trade for saving TOC space 🦋

If you still run out of space in the TOC even when you specify both of these options, bestie, try -mminimal-toc instead 😭. It makes GCC create only one TOC entry for every file. The catch is that the code comes out slower and larger, but it uses extremely little TOC space 💀. Honestly, save it for files with less frequently-executed code 🫶.

• -maix64, -maix32 — okay so -maix64 turns on the 64-bit AIX ABI and calling convention ✨. You get 64-bit pointers, a 64-bit "long" type, and all the infrastructure needed to support them. It implies -mpowerpc64. -maix32 goes the other way, disabling the 64-bit ABI and implying -mno-powerpc64. GCC defaults to -maix32 🎀.
• -mxl-compat, -mno-xl-compat — this one is giving IBM XL compiler vibes 👑. It makes the code match XL semantics more closely when you're using the AIX-compatible ABI. Floating-point args to prototyped functions beyond the register save area (RSA) get passed on the stack too, on top of the argument FPRs. It also stops assuming the most significant double in a 128-bit long double value is properly rounded when comparing and converting to double, and it uses XL symbol names for long double support routines.

The AIX calling convention got extended without being documented at first, to handle an obscure K&R C case: calling a function that takes the address of its arguments with fewer arguments than it declared 🙈. IBM XL compilers read floating-point arguments that don't fit in the RSA from the stack when a subroutine is compiled without optimization. Always storing floating-point arguments on the stack is inefficient and rarely needed, so this option isn't on by default. You only need it when calling subroutines compiled by IBM XL compilers without optimization.

• -mpe — this one's for the IBM RS/6000 SP Parallel Environment (PE) 🧚. It links an app that uses message passing with special startup code so it can actually run. The system needs PE installed in the standard location (/usr/lpp/ppe.poe/). If it isn't there, you can override the specs file with -specs= and point it to the right directory.

The Parallel Environment doesn't support threads, so -mpe and -pthread are incompatible. Don't pair them up, bestie 💀.

• -malign-natural, -malign-power — on AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, -malign-natural overrides the ABI-defined alignment of bigger types, like floating-point doubles, and puts them on their natural size-based boundary 📐. -malign-power tells GCC to follow the ABI-specified alignment rules instead. GCC defaults to the standard alignment defined in the ABI.

On 64-bit Darwin, natural alignment is already the default, and -malign-power isn't supported there 🙅‍♀️.

• -msoft-float, -mhard-float — -msoft-float generates code that doesn't use the floating-point register set, so you don't touch those registers at all. Software floating-point emulation is provided, but you have to pass the option to GCC when linking too. -mhard-float is the opposite: it lets the code use the floating-point register set 🔥.
• -mmultiple, -mno-multiple — these generate (or don't generate) the load multiple word and store multiple word instructions 💜. They're generated by default on POWER systems and aren't generated on PowerPC systems. Don't use -mmultiple on little-endian PowerPC systems, because those instructions don't work in little-endian mode. The exceptions are PPC740 and PPC750, which let these instructions work in little-endian mode.
• -mupdate, -mno-update — these control whether the load or store instructions that update the base register to the address of the calculated memory location get used. They're generated by default. If you use -mno-update, there's a small window between the time the stack pointer gets updated and the time the address of the previous frame gets stored. That means code that walks the stack frame across interrupts or signals might end up with corrupted data 😭.
• -mavoid-indexed-addresses, -mno-avoid-indexed-addresses — these make the code try to avoid (or not avoid) indexed load or store instructions 🦋. Those can cause a performance penalty on Power6 processors in certain situations, like stepping through large arrays that cross a 16M boundary. It's enabled by default when targeting Power6 and disabled otherwise.
• -mfused-madd, -mno-fused-madd — these generate (or don't generate) the floating-point multiply and accumulate instructions ✨. They're generated by default if hardware floating point is used. The machine-dependent -mfused-madd is now mapped to the machine-independent -ffp-contract=fast, and -mno-fused-madd is mapped to -ffp-contract=off.
• -mmulhw, -mno-mulhw — these generate (or don't generate) the half-word multiply and multiply-accumulate instructions on the IBM 405, 440, 464 and 476 processors 🌸. They're generated by default when you target those processors.
• -mdlmzb, -mno-dlmzb — these generate (or don't generate) the string-search dlmzb instruction on the IBM 405, 440, 464 and 476 processors 🔍. It's generated by default when targeting those processors.
• -mno-bit-align, -mbit-align — on System V.4 and embedded PowerPC systems, -mno-bit-align stops structures and unions that contain bit-fields from being forced to align to the base type of the bit-field. -mbit-align does force that alignment.

Here's the tea 🍓: by default, a structure with nothing but 8 "unsigned" bit-fields of length 1 gets aligned to a 4-byte boundary and ends up 4 bytes in size. With -mno-bit-align, that same structure gets aligned to a 1-byte boundary and is only 1 byte in size.

• -mno-strict-align, -mstrict-align — on System V.4 and embedded PowerPC systems, these decide whether GCC assumes unaligned memory references get handled by the system. -mno-strict-align assumes they do, and -mstrict-align doesn't 💅.
• -mrelocatable, -mno-relocatable — these generate code that allows (or doesn't allow) a static executable to be relocated to a different address at run time 🦋. A simple embedded PowerPC system loader should relocate the entire contents of .got2 and the 4-byte locations listed in the .fixup section, which is a table of 32-bit addresses this option generates. For this to work, every object linked together must be compiled with -mrelocatable or -mrelocatable-lib. -mrelocatable code aligns the stack to an 8-byte boundary.
• -mrelocatable-lib, -mno-relocatable-lib — like -mrelocatable, -mrelocatable-lib generates a .fixup section so static executables can be relocated at run time. The difference is that -mrelocatable-lib doesn't use the smaller stack alignment of -mrelocatable. Objects compiled with -mrelocatable-lib can be linked with objects compiled with any combination of the -mrelocatable options 🤝.
• -mno-toc, -mtoc — on System V.4 and embedded PowerPC systems, these decide whether GCC assumes register 2 contains a pointer to a global area with the addresses the program uses 🧠.
• -mlittle, -mlittle-endian — on System V.4 and embedded PowerPC systems, this compiles code for the processor in little-endian mode 💜. -mlittle-endian is the same as -mlittle.
• -mbig, -mbig-endian — on System V.4 and embedded PowerPC systems, this compiles code for the processor in big-endian mode 🌈. -mbig-endian is the same as -mbig.
• -mdynamic-no-pic — on Darwin / macOS systems, this compiles code so it isn't relocatable itself, but its external references are relocatable 🍎. The result is good for applications, but not for shared libraries.
• -msingle-pic-base — this treats the register used for PIC addressing as read-only, instead of loading it in the prologue for each function ✨. The runtime system is responsible for initializing that register with an appropriate value before execution begins.
• -mprioritize-restricted-insns=priority — this controls the priority given to dispatch-slot restricted instructions during the second scheduling pass 📋. The argument priority takes the value 0, 1, or 2, which assigns no, highest, or second-highest priority (respectively) to dispatch-slot restricted instructions.
• -msched-costly-dep=dependence_type — this controls which dependences the target considers costly during instruction scheduling 🎀. The argument dependence_type takes one of these values:
  • no — No dependence is costly.
  • all — All dependences are costly.
  • true_store_to_load — A true dependence from store to load is costly.
  • store_to_load — Any dependence from store to load is costly.
  • number — Any dependence for which the latency is greater than or equal to number is costly.
• -minsert-sched-nops=scheme — this controls which NOP insertion scheme gets used during the second scheduling pass 🫧. The argument scheme takes one of these values:
  • no — Don't insert NOPs.
  • pad — Pad with NOPs any dispatch group that has vacant issue slots, according to the scheduler's grouping.
  • regroup_exact — Insert NOPs to force costly dependent insns into separate groups. Insert exactly as many NOPs as needed to force an insn to a new group, according to the estimated processor grouping.
  • number — Insert NOPs to force costly dependent insns into separate groups. Insert number NOPs to force an insn to a new group.
• -mcall-sysv — on System V.4 and embedded PowerPC systems, this compiles code using calling conventions that follow the March 1995 draft of the System V Application Binary Interface, PowerPC processor supplement 📜. This is the default unless you configured GCC using powerpc-*-eabiaix.
• -mcall-sysv-eabi, -mcall-eabi — these specify both -mcall-sysv and -meabi 💅.
• -mcall-sysv-noeabi — this specifies both -mcall-sysv and -mno-eabi 🌸.
• -mcall-aixdesc — on System V.4 and embedded PowerPC systems, this compiles code for the AIX operating system 🦅.
• -mcall-linux — on System V.4 and embedded PowerPC systems, this compiles code for the Linux-based GNU system 🐧.
• -mcall-freebsd — on System V.4 and embedded PowerPC systems, this compiles code for the FreeBSD operating system 😈.
• -mcall-netbsd — on System V.4 and embedded PowerPC systems, this compiles code for the NetBSD operating system 🐡.
• -mcall-openbsd — okay so this one is for System V.4 and embedded PowerPC systems, and it makes the compiler build code for the OpenBSD operating system 🧚
• -mtraceback=traceback_type — pick which kind of traceback table you want 🔍 The valid values for traceback_type are full, part, and no.
• -maix-struct-return — every structure gets returned in memory, as the AIX ABI says 📦
• -msvr4-struct-return — structures smaller than 8 bytes come back in registers instead, which is what the SVR4 ABI wants 💜
• -mabi=abi-type — this lets you extend the current ABI with a particular extension, or remove one 🎀 The valid values are altivec, no-altivec, ibmlongdouble, ieeelongdouble, elfv1, and elfv2. And for AIX, you also get vec-extabi and vec-default ✨
• -mabi=ibmlongdouble — switches the current ABI over to IBM extended-precision long double 🫶 Heads up bestie, this is not likely to work if your system already defaults to IEEE extended-precision long double. If you change the long double type away from IEEE extended-precision, the compiler gives you a warning unless you use the -Wno-psabi option. You also need -mlong-double-128 turned on for this one.
• -mabi=ieeelongdouble — the opposite move: it changes the current ABI to IEEE extended-precision long double 🌈 Same deal here, this is not likely to work if your system defaults to IBM extended-precision long double. Switching away from IBM extended-precision gets you a warning unless you use -Wno-psabi, and -mlong-double-128 has to be enabled too.
• -mabi=elfv1 — changes the current ABI to the ELFv1 ABI 🍓 This is the default for big-endian PowerPC 64-bit Linux. Overriding the default needs special system support, and honestly it is likely to fail in spectacular ways 💀

Overriding the default ABI with -mabi=elfv1 requires special system support and is likely to fail in spectacular ways.

• -mabi=elfv2 — changes the current ABI to the ELFv2 ABI 🌸 This is the default for little-endian PowerPC 64-bit Linux. Overriding the default also requires special system support and is likely to fail in spectacular ways.

Overriding the default ABI with -mabi=elfv2 requires special system support and is likely to fail in spectacular ways.

• -mgnu-attribute, -mno-gnu-attribute — this makes the compiler emit .gnu_attribute assembly directives 🦋 Those set tag/value pairs in a .gnu.attributes section that describe the ABI variations used in function parameters or return values.
• -mprototype, -mno-prototype — on System V.4 and embedded PowerPC systems, -mprototype tells the compiler to assume that all calls to variable argument functions are properly prototyped ✨ Without it, the compiler has to insert an instruction before every non-prototyped call to set or clear bit 6 of the condition code register ("CR"), so the function knows whether floating-point values are passed in the floating-point registers, in case the function takes variable arguments. With -mprototype, only calls to prototyped variable argument functions set or clear that bit.
• -msim — on embedded PowerPC systems, this assumes the startup module is called sim-crt0.o and the standard C libraries are libsim.a and libc.a 🧸 This is the default for powerpc-*-eabisim configurations.
• -mmvme — on embedded PowerPC systems, this assumes the startup module is called crt0.o and the standard C libraries are libmvme.a and libc.a 🍭
• -mads — on embedded PowerPC systems, this assumes the startup module is called crt0.o and the standard C libraries are libads.a and libc.a 🌷
• -myellowknife — on embedded PowerPC systems, this assumes the startup module is called crt0.o and the standard C libraries are libyk.a and libc.a 💛
• -mvxworks — on System V.4 and embedded PowerPC systems, this tells the compiler you are compiling for a VxWorks system 🛸
• -memb — on embedded PowerPC systems, this sets the "PPC_EMB" bit in the ELF flags header, which indicates that eabi extended relocations are used 🪄
• -meabi, -mno-eabi — on System V.4 and embedded PowerPC systems, -meabi means you adhere to the Embedded Applications Binary Interface (EABI), which is a set of modifications to the System V.4 specifications 🎀 -mno-eabi means you do not. Choosing -meabi aligns the stack to an 8-byte boundary, calls a function "__eabi" from "main" to set up the EABI environment, and lets the -msdata option use both "r2" and "r13" to point to two separate small data areas. Choosing -mno-eabi aligns the stack to a 16-byte boundary, does not call any EABI initialization function from "main", and makes the -msdata option use only "r13" to point to a single small data area. The -meabi option is on by default if you configured GCC using one of the powerpc*-*-eabi* options 💅
• -msdata=eabi — on System V.4 and embedded PowerPC systems, small initialized "const" global and static data goes in the ".sdata2" section, which is pointed to by register "r2" 🌈 Small initialized non-"const" global and static data goes in the ".sdata" section, pointed to by register "r13". Small uninitialized global and static data goes in the ".sbss" section, which sits right next to ".sdata". Heads up, -msdata=eabi is incompatible with the -mrelocatable option, and it also turns on the -memb option.
• -msdata=sysv — on System V.4 and embedded PowerPC systems, small global and static data goes in the ".sdata" section, pointed to by register "r13" 🍓 Small uninitialized global and static data goes in the ".sbss" section, next to ".sdata". This one is incompatible with -mrelocatable too.
• -msdata=default, -msdata — on System V.4 and embedded PowerPC systems, if -meabi is used, the code gets compiled the same as -msdata=eabi. Otherwise it gets compiled the same as -msdata=sysv 🫧
• -msdata=data — on System V.4 and embedded PowerPC systems, small global data goes in the ".sdata" section, and small uninitialized global data goes in the ".sbss" section 🌸 The twist is that register "r13" is not used to address small data. This is the default behavior unless other -msdata options are used.
• -msdata=none, -mno-sdata — on embedded PowerPC systems, all initialized global and static data goes in the ".data" section, and all uninitialized data goes in the ".bss" section 🧁
• -mreadonly-in-sdata — read-only objects get put in the ".sdata" section as well 💖 This is the default.
• -mblock-move-inline-limit=num — inlines all block moves (like calls to "memcpy" or structure copies) that are less than or equal to num bytes ✨ The minimum value for num is 32 bytes on 32-bit targets and 64 bytes on 64-bit targets. The default value is target-specific.
• -mblock-compare-inline-limit=num — generates non-looping inline code for all block compares (like calls to "memcmp" or structure compares) that are less than or equal to num bytes 🔥 If num is 0, all inline expansion of block compare, both non-loop and loop, is disabled. The default value is target-specific.
• -mblock-compare-inline-loop-limit=num — generates an inline expansion using loop code for all block compares that are less than or equal to num bytes, but greater than the limit for non-loop inline block compare expansion 🔁 If the block length is not constant, at most num bytes get compared before "memcmp" is called to compare the rest of the block. The default value is target-specific.
• -mstring-compare-inline-limit=num — compares at most num string bytes with inline code 🧵 If the difference or end of string is not found by the end of the inline compare, a call to "strcmp" or "strncmp" takes care of the rest. The default is 64 bytes.
• -G num — on embedded PowerPC systems, global and static items less than or equal to num bytes go into the small data or BSS sections instead of the normal data or BSS section 🐣 By default, num is 8. The -G num switch also gets passed to the linker, and all modules should be compiled with the same -G num value.
• -mregnames, -mno-regnames — on System V.4 and embedded PowerPC systems, -mregnames makes the compiler emit register names in the assembly output using symbolic forms, and -mno-regnames means it does not 🌟
• -mlongcall, -mno-longcall — by default, the compiler assumes all calls are far away, so it uses a longer and more expensive calling sequence 🐢 That's required for calls farther than 32 megabytes (33,554,432 bytes) from the current location. A short call only gets generated if the compiler knows the call cannot be that far away. You can override this setting with the "shortcall" function attribute, or with #pragma longcall(0).

Some linkers can detect out-of-range calls and generate glue code on the fly. On those systems, long calls are unnecessary and generate slower code 🙄 As of this writing, the AIX linker can do this, and so can the GNU linker for PowerPC/64. It is planned to add this feature to the GNU linker for 32-bit PowerPC systems as well.

On PowerPC64 ELFv2 and 32-bit PowerPC systems with newer GNU linkers, GCC can generate long calls using an inline PLT call sequence (see -mpltseq). PowerPC with -mbss-plt and PowerPC64 ELFv1 (big-endian) do not support inline PLT calls.

On Darwin/PPC systems, #pragma longcall generates "jbsr callee, L42", plus a branch island (glue code) 🏝️ The two target addresses represent the callee and the branch island. The Darwin/PPC linker prefers the first address, and it generates a "bl callee" if the PPC "bl" instruction reaches the callee directly. Otherwise, the linker generates "bl L42" to call the branch island. The branch island gets appended to the body of the calling function, and it computes the full 32-bit address of the callee and jumps to it.

On Mach-O (Darwin) systems, this option tells the compiler to emit the glue for every direct call, and the Darwin linker decides whether to use it or discard it 🦩

In the future, GCC may ignore all longcall specifications when the linker is known to generate glue 👀

• -mpltseq, -mno-pltseq — -mpltseq implements -fno-plt and long calls using an inline PLT call sequence, while -mno-pltseq does not 🌙 That sequence supports lazy linking and long calls to functions in dlopen'd shared libraries. Inline PLT calls are only supported on PowerPC64 ELFv2 and 32-bit PowerPC systems with newer GNU linkers. They're enabled by default if the support is detected when configuring GCC, and, in the case of 32-bit PowerPC, if GCC is configured with --enable-secureplt. Also be careful bestie: -mpltseq code and -mbss-plt 32-bit PowerPC relocatable objects may not be linked together 🚫

Okay bestie, we're still deep in the powerpc flags, so let's keep going 🦋✨

• -mtls-markers, -mno-tls-markers — okay so -mtls-markers tags calls to __tls_get_addr with a relocation that spells out the function argument 🎀 -mno-tls-markers skips the tagging. The tag lets the linker reliably match each call with its argument setup instructions for TLS optimization, and that means GCC can schedule the whole sequence better 💅
• -mrecip, -mno-recip — this one turns on the reciprocal estimate and reciprocal square root estimate instructions, plus extra Newton-Raphson steps to get back the precision. Instead of doing a divide (or a square root and then a divide) for floating-point arguments, the chip just does the quick estimate-and-refine thing 🧚 You should pair -mrecip with -ffast-math, or at least with -funsafe-math-optimizations, -ffinite-math-only, -freciprocal-math and -fno-trapping-math 🫶 The throughput is usually higher than the non-reciprocal instruction, but the precision can drop by up to 2 ulp (so the inverse of 1.0 can come out as 0.99999994), especially for reciprocal square roots 😭
• -mrecip=opt — this one controls exactly which reciprocal estimate instructions are allowed. opt is a comma-separated list, and any item can get a ! in front to flip it 🌈
  • all — enables every estimate instruction 🔥
  • default — enables the default instructions, same as -mrecip ✨
  • none — disables every estimate instruction, same as -mno-recip 🙈
  • div — enables the reciprocal approximation instructions for both single and double precision 💜
  • divf — enables just the single-precision reciprocal approximation instructions 🌸
  • divd — enables just the double-precision reciprocal approximation instructions 🍓
  • rsqrt — enables the reciprocal square root approximation instructions for both single and double precision 👑
  • rsqrtf — enables just the single-precision reciprocal square root approximation instructions ⭐
  • rsqrtd — enables just the double-precision reciprocal square root approximation instructions 🦋

So, for example, -mrecip=all,!rsqrtd turns on every estimate instruction except FRSQRTE, XSRSQRTEDP, and XVRSQRTEDP, which are the ones handling double-precision reciprocal square roots 💅

• -mrecip-precision, -mno-recip-precision — -mrecip-precision assumes the reciprocal estimate instructions are more precise than the PowerPC ABI requires, and -mno-recip-precision refuses to assume that 🧚 Picking -mcpu=power6, -mcpu=power7 or -mcpu=power8 turns -mrecip-precision on automatically ✨ The double-precision square root estimate instructions aren't generated by default on low-precision machines, because they don't converge after three steps 🙈
• -mveclibabi=type — picks the ABI type used when vectorizing intrinsics with an external library. The only type supported right now is mass, which tells GCC to use IBM's Mathematical Acceleration Subsystem (MASS) libraries 🎀 When generating code for power7, GCC currently emits calls to acosd2, acosf4, acoshd2, acoshf4, asind2, asinf4, asinhd2, asinhf4, atan2d2, atan2f4, atand2, atanf4, atanhd2, atanhf4, cbrtd2, cbrtf4, cosd2, cosf4, coshd2, coshf4, erfcd2, erfcf4, erfd2, erff4, exp2d2, exp2f4, expd2, expf4, expm1d2, expm1f4, hypotd2, hypotf4, lgammad2, lgammaf4, log10d2, log10f4, log1pd2, log1pf4, log2d2, log2f4, logd2, logf4, powd2, powf4, sind2, sinf4, sinhd2, sinhf4, sqrtd2, sqrtf4, tand2, tanf4, tanhd2, and tanhf4 😭 Both -ftree-vectorize and -funsafe-math-optimizations must also be enabled, and the MASS libraries have to be specified at link time 🔥
• -mfriz, -mno-friz — -mfriz generates the friz instruction when -funsafe-math-optimizations is used to optimize rounding floating-point values to 64-bit integer and back to floating point. -mno-friz doesn't generate it 💅 Heads up though: friz doesn't give the same value if the floating-point number is too large to fit in an integer 💀
• -mpointers-to-nested-functions, -mno-pointers-to-nested-functions — -mpointers-to-nested-functions generates code that loads the static chain register (r11) when calling through a pointer on AIX and 64-bit Linux systems, where a function pointer points to a 3-word descriptor holding the function address, the TOC value to load into r2, and the static chain value to load into r11 🧚 This one is on by default. If you use -mno-pointers-to-nested-functions, you can't call through pointers to nested functions, or through pointers to functions compiled in other languages that use the static chain 🙈
• -msave-toc-indirect, -mno-save-toc-indirect — -msave-toc-indirect saves the TOC value in the reserved stack location in the function prologue when the function calls through a pointer on AIX and 64-bit Linux systems. If it isn't saved in the prologue, it gets saved right before the call through the pointer ✨ -mno-save-toc-indirect is the default 🌸
• -mcompat-align-parm, -mno-compat-align-parm — -mcompat-align-parm generates code that passes structure parameters with a maximum alignment of 64 bits, so it matches older versions of GCC 🎀

Older versions of GCC (prior to 4.9.0) incorrectly didn't align a structure parameter on a 128-bit boundary when that structure had a member needing 128-bit alignment. Newer versions fixed that. This option lets you make code that works with functions compiled by the older GCC 🫶

-mno-compat-align-parm is the default 💜

• -mstack-protector-guard=guard, -mstack-protector-guard-reg=reg, -mstack-protector-guard-offset=offset — these generate stack protection code using a canary at guard. The supported locations are global for a global canary, or tls for a per-thread canary in the TLS block (the default with GNU libc version 2.4 or later) 🔥 With tls, -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset also decide which register is the base register for reading the canary, and what offset from that base it's read at 👑 Both default to whatever the relevant ABI specifies ✨
• -mpcrel, -mno-pcrel — -mpcrel generates pc-relative addressing, and -mno-pcrel doesn't 🦋 Using -mpcrel requires that the medium code model (-mcmodel=medium) and prefixed addressing (-mprefixed) are both enabled 🌈
• -mprefixed, -mno-prefixed — -mprefixed generates addressing modes that use prefixed load and store instructions, and -mno-prefixed doesn't 🧚 -mprefixed needs -mcpu=power10 (or later) enabled 💅
• -mmma, -mno-mma — -mmma generates the MMA instructions, and -mno-mma doesn't 💜 -mmma needs -mcpu=power10 (or later) enabled 🍓
• -mrop-protect, -mno-rop-protect — -mrop-protect generates ROP protection instructions when the target processor supports them, and -mno-rop-protect doesn't 🛡️ Right now this option disables the shrink-wrap optimization (-fshrink-wrap) 😭
• -mprivileged, -mno-privileged — -mprivileged generates code that runs in privileged state, and -mno-privileged doesn't 👑
• -mblock-ops-unaligned-vsx, -mno-block-ops-unaligned-vsx — -mblock-ops-unaligned-vsx generates unaligned vsx loads and stores for inline expansion of memcpy and memmove, and -mno-block-ops-unaligned-vsx doesn't 🌸
• --param rs6000-vect-unroll-limit= — the vectorizer checks with target information to figure out whether unrolling the main vectorized loop would be worth it, and by how much. This parameter sets the upper bound on how much the vectorizer will unroll that main loop. The default value is four ✨

---

🌈 RX Options 🌈

These command-line options are defined for RX targets 🧚

• -m64bit-doubles, -m32bit-doubles — makes the double data type 64 bits (-m64bit-doubles) or 32 bits (-m32bit-doubles) in size. The default is -m32bit-doubles 💖 Note that RX floating-point hardware only works on 32-bit values, which is exactly why the default is -m32bit-doubles 🙈
• -fpu, -nofpu — -fpu enables the use of RX floating-point hardware, and -nofpu disables it 🎀 The default is enabled for the RX600 series and disabled for the RX200 series 💅

Floating-point instructions are only generated for 32-bit floating-point values, though. So the FPU hardware isn't used for doubles if -m64bit-doubles is used 😭

Note: if -fpu is enabled, then -funsafe-math-optimizations is also enabled automatically. That's because the RX FPU instructions are themselves unsafe 💀

• -mcpu=name — selects the type of RX CPU to target 🔥 Right now three types are supported: the generic RX600 and RX200 series hardware, and the specific RX610 CPU. The default is RX600 👑

The only difference between RX600 and RX610 is that the RX610 doesn't support the MVTIPL instruction 🦋

The RX200 series doesn't have a hardware floating-point unit, so -nofpu is enabled by default when this type is selected 🌸

• -mbig-endian-data, -mlittle-endian-data — stores data (but not code) in the big-endian format with -mbig-endian-data. The default is -mlittle-endian-data, which stores data in the little-endian format 🧚
• -msmall-data-limit=N — specifies the maximum size in bytes of global and static variables that can be placed into the small data area. Using the small data area can lead to smaller and faster code, but the area is limited, and it's up to the programmer to make sure it doesn't overflow 😭 Also, when the small data area is used, one of the RX's registers (usually r13) is reserved to point at this area, so the compiler can't use it anymore. That can make code slower and/or larger if variables get pushed onto the stack instead of being held in that register 🙈

Note: common variables (variables that haven't been initialized) and constants aren't placed into the small data area, because they get assigned to other sections in the output executable 💜

So the default value is zero, which means this feature is switched off 🙈 Heads up: it's not turned on by default at higher optimization levels (-O2 and friends) because reserving a register can be kinda detrimental. It's on you to experiment and figure out whether it actually helps your program 🧪 For how the register holding the small data area pointer gets picked, check out the -mpid option ✨

• -msim, -mno-sim — Uses the simulator runtime 🖥️ The default is the libgloss board-specific runtime.
• -mas100-syntax, -mno-as100-syntax — When GCC spits out assembler, this makes it use a syntax that plays nicely with Renesas's AS100 assembler 💅 The GAS assembler can handle this syntax too, but it comes with some restrictions, so it isn't generated by default.
• -mmax-constant-size=N — Sets the biggest size, in bytes, that a constant can be and still be used as an operand in an RX instruction 📏 The RX instruction set can handle constants up to 4 bytes, but bigger values make the instruction longer, so sometimes it's smart to limit this. Constants that are too big get tucked into a constant pool and reached through register indirection 🧚

The value N can be anywhere from 0 to 4. A value of 0 (the default) or 4 means constants of any size are allowed 💖

• -mrelax — Turns on linker relaxation 🦋 That's when the linker tries to shrink your program by finding shorter versions of various instructions. It's disabled by default.
• -mint-register=N — Reserves a number of registers for fast interrupt handler functions 👑 N can be between 0 and 4. A value of 1 reserves register "r13" for the exclusive use of fast interrupt handlers. A value of 2 reserves "r13" and "r12". A value of 3 reserves "r13", "r12" and "r11", and a value of 4 reserves "r13" through "r10". The default, 0, doesn't reserve anything at all 🌸
• -msave-acc-in-interrupts — Tells interrupt handler functions to preserve the accumulator register 🫶 You only need this if your normal code might touch the accumulator, like if it does 64-bit multiplications. By default the accumulator gets ignored, which keeps the interrupt handlers faster ⚡
• -mpid, -mno-pid — Turns on the generation of position independent data 🌈 With it enabled, any access to constant data goes through an offset from a base address held in a register. This lets the location of constant data get figured out at run time without the executable needing to be relocated, which is a big win for embedded apps with tight memory constraints 💜 Data that can be modified isn't affected by this option.

Heads up though, this reserves a register (usually "r13") for the constant data base address, which can make code slower and/or bigger, especially in complicated functions 😭

Which register actually gets chosen depends on whether -msmall-data-limit and/or -mint-register are enabled. Starting at "r13" and working downwards, registers are allocated first to satisfy -mint-register, then -mpid, and finally -msmall-data-limit. So the small data area register can end up being "r8" if both -mint-register=4 and -mpid are on the command line 🎀

By default this feature is not enabled. You can restore that default with the -mno-pid option ✨

• -mno-warn-multiple-fast-interrupts, -mwarn-multiple-fast-interrupts — Stops GCC from yelling with a warning if it finds more than one fast interrupt handler while compiling a file 🙅 By default it warns about each extra one, because the RX only supports one such interrupt.
• -mallow-string-insns, -mno-allow-string-insns — Turns the string manipulation instructions on or off 🧵 That's "SMOVF", "SCMPU", "SMOVB", "SMOVU", "SUNTIL" "SWHILE", and also the "RMPA" instruction. These instructions may prefetch data, which is not safe if you're accessing an I/O register 💀 (Check out section 12.2.7 of the RX62N Group User's Manual for more info 📖)

These are allowed by default, but GCC can't reliably detect every case where a string instruction might touch an I/O register, so it can't turn them off automatically. It's up to you to use -mno-allow-string-insns if your program accesses I/O space 🫣

When the instructions are enabled, GCC defines the C preprocessor symbol __RX_ALLOW_STRING_INSNS__. Otherwise it defines __RX_DISALLOW_STRING_INSNS__ 🍓

• -mjsr, -mno-jsr — Uses only (or not only) "JSR" instructions to access functions 🚀 This can help when your code size goes past the range of "BSR" instructions. Fun fact: -mno-jsr doesn't mean "don't use JSR" 🙈 It just means any type of branch may be used.

Note: the generic GCC command-line option -ffixed-reg has special meaning for the RX port when it's paired with the "interrupt" function attribute. That attribute marks a function meant to process fast interrupts. GCC makes sure it only uses "r10", "r11", "r12" and/or "r13", and only if the normal use of those registers has been restricted through -ffixed-reg or -mint-register 🫶

---

✨ S/390 and zSeries Options ✨

These are the -m options defined for the S/390 and zSeries architecture 🧚

• -mhard-float, -msoft-float — Lets you use (or not use) the hardware floating-point instructions and registers for floating-point operations 💖 With -msoft-float, functions in libgcc.a do the floating-point work. With -mhard-float, GCC generates IEEE floating-point instructions. This is the default 🌈
• -mhard-dfp, -mno-hard-dfp — Lets you use (or not use) the hardware decimal-floating-point instructions for decimal-floating-point operations 🔢 With -mno-hard-dfp, functions in libgcc.a handle the decimal-floating-point stuff. With -mhard-dfp, GCC generates the decimal-floating-point hardware instructions. This is the default for -march=z9-ec or higher 👑
• -mlong-double-64, -mlong-double-128 — These switches control the size of the "long double" type 📏 A size of 64 bits makes "long double" equivalent to "double". This is the default 💅
• -mbackchain, -mno-backchain — Stores (or doesn't store) the address of the caller's frame as a backchain pointer in the callee's stack frame 🔍 A backchain may be needed for debugging with tools that don't understand DWARF call frame information. When -mno-packed-stack is in effect, the backchain pointer is stored at the bottom of the stack frame. When -mpacked-stack is in effect, the backchain goes into the topmost word of the 96/160 byte register save area 🧵

Generally, code compiled with -mbackchain is call-compatible with code compiled with -mno-backchain. But using the backchain for debugging usually means the whole binary needs to be built with -mbackchain 🙈 Also, the combo of -mbackchain, -mpacked-stack and -mhard-float is not supported 💀 If you want to build a linux kernel, use -msoft-float instead.

The default is to not maintain the backchain.

• -mpacked-stack, -mno-packed-stack — Uses (or doesn't use) the packed stack layout 📦 With -mno-packed-stack, the compiler uses all the fields of the 96/160 byte register save area only for their default purpose, so unused fields still take up stack space. With -mpacked-stack, register save slots are densely packed at the top of the register save area, and unused space gets reused for other purposes, which is much more efficient with the stack space 🌸 However, when -mbackchain is also in effect, the topmost word of the save area is always used to store the backchain, and the return address register is always saved two words below the backchain.

As long as the stack frame backchain isn't used, code generated with -mpacked-stack is call-compatible with code generated with -mno-packed-stack. Heads up: some non-FSF releases of GCC 2.95 for S/390 or zSeries generated code that uses the stack frame backchain at run time, not just for debugging. That code is not call-compatible with code compiled with -mpacked-stack 😭 Also, the combo of -mbackchain, -mpacked-stack and -mhard-float is not supported. To build a linux kernel, use -msoft-float.

The default is to not use the packed stack layout.

• -msmall-exec, -mno-small-exec — Generates (or doesn't generate) code that uses the "bras" instruction for subroutine calls 📞 This only works reliably if the total executable size doesn't go over 64k. The default is to use the "basr" instruction instead, which doesn't have that limitation 🎀
• -m64, -m31 — With -m31, GCC generates code compliant with the GNU/Linux for S/390 ABI. With -m64, it generates code compliant with the GNU/Linux for zSeries ABI 🦋 This lets GCC generate 64-bit instructions. For the s390 targets the default is -m31, while the s390x targets default to -m64 💜
• -mzarch, -mesa — With -mzarch, GCC generates code using the instructions available on z/Architecture ✨ With -mesa, it uses the instructions available on ESA/390. Note that -mesa is not possible with -m64 🙅 When generating code compliant with the GNU/Linux for S/390 ABI, the default is -mesa. For the GNU/Linux for zSeries ABI, the default is -mzarch 🌈
• -mhtm, -mno-htm — The -mhtm option turns on a set of builtins that use instructions from the transactional execution facility, which was introduced with the IBM zEnterprise EC12 machine generation. These are the S/390 System z Built-in Functions 🧠 -mhtm is enabled by default when using -march=zEC12 🔥
• -mvx, -mno-vx — okay so -mvx tells GCC to generate code using the vector extension facility instructions that came with the IBM z13 machine generation 🦋. It also changes the ABI for some vector type values when it comes to alignment and calling conventions. If vector types are used somewhere the ABI cares about, GCC adds a GAS .gnu_attribute command so the finished binary is marked with the ABI it used. And -mvx is turned on by default when you use -march=z13 ✨
• -mzvector, -mno-zvector — bestie, -mzvector unlocks vector language extensions and builtins, using those same z13 vector instructions 💅 It lets you use vector as a keyword to define vector type variables and arguments. But vector only works when GNU extensions are on, so it won't expand if you ask for strict standard compliance, like with -std=c99. On top of the GCC low-level builtins, -mzvector also adds a set of builtins made for compatibility with AltiVec-style implementations like Power and Cell 🌈 To use them, you need to include the header file vecintrin.h. -mzvector is disabled by default, so you have to ask for it 🙈
• -mmvcle, -mno-mvcle — -mmvcle makes GCC generate code that uses the "mvcle" instruction for block moves, and -mno-mvcle swaps that out for a "mvc" loop instead 🍓 The default is the "mvcle" version, unless you're optimizing for size.
• -mdebug, -mno-debug — -mdebug makes the compiler print extra debug information while it's compiling, and -mno-debug keeps it quiet. By default, no debug info gets printed 🧚
• -march=cpu-type — this tells GCC to generate code that runs on cpu-type, which is just the name of a system representing a certain processor type 👑 The possible values are z900/arch5, z990/arch6, z9-109, z9-ec/arch7, z10/arch8, z196/arch9, zEC12, z13/arch11, z14/arch12, z15/arch13, z16/arch14, z17/arch15, and native.

The default is -march=z900.

Picking native as your cpu type lets GCC choose the best architecture option for the host processor 💖 Heads up, though: -march=native does nothing if GCC doesn't recognize the processor.

• -mtune=cpu-type — this tunes everything applicable about the generated code to cpu-type, except for the ABI and the set of available instructions ✨ The list of cpu-type values is the same as for -march. The default is whatever value you used for -march.
• -mtpf-trace, -mno-tpf-trace — -mtpf-trace makes the code add TPF OS specific branches to trace routines in the operating system, and -mno-tpf-trace means it doesn't add them 🦋 This one is off by default, even when you're compiling for the TPF OS.
• -mtpf-trace-skip, -mno-tpf-trace-skip — with -mtpf-trace-skip, the generated code changes the default branch targets enabled by -mtpf-trace so they point to specialized trace routines. That gives you the power to selectively skip function trace entries for the TPF OS 🎀 With -mno-tpf-trace-skip, those targets stay the same. This is off by default, even when you're compiling for the TPF OS and specifying -mtpf-trace.
• -mfused-madd, -mno-fused-madd — -mfused-madd lets the code use the floating-point multiply and accumulate instructions, and -mno-fused-madd tells it not to 💜 These instructions get generated by default when hardware floating point is used.
• -mwarn-framesize=framesize — this makes GCC emit a warning if the current function goes over the given frame size 🔥 It's a compile-time check, so it doesn't mean your program is actually broken when it runs. It's meant to spot functions that will most likely cause a stack overflow, so it's super useful in environments with a limited stack size, like the Linux kernel.
• -mwarn-dynamicstack — emits a warning if the function calls alloca or uses dynamically-sized arrays 💀 That's generally a bad idea when the stack size is limited, so this one's giving caution.
• -mstack-guard=stack-guard, -mstack-size=stack-size — okay this one is lowkey intense 😭 If you give these options, the S/390 back end adds extra instructions to the function prologue that trigger a trap when the stack size goes stack-guard bytes above the stack-size (remember, the stack on S/390 grows downward). If you leave out -mstack-guard, GCC picks the smallest power of 2 that's bigger than the frame size of the compiled function. These are meant for debugging stack overflow problems 🧚 The extra code only adds a little overhead, so it's fine for production-like systems without a big performance hit. The values have to be exact powers of 2, and stack-size has to be greater than stack-guard without going over 64k. To be efficient, the extra code assumes the stack starts at an address aligned to the value given by stack-size. And -mstack-guard can only be used together with -mstack-size 💅
• -mhotpatch=pre-halfwords,post-halfwords — if the hotpatch option is enabled, GCC generates a "hot-patching" function prologue for every function in the compilation unit 🌸 The function label gets prepended with the given number of two-byte NOP instructions (pre-halfwords, maximum 1000000). After the label, 2 * post-halfwords bytes get appended, using the largest NOP-like instructions the architecture allows (maximum 1000000).

If both arguments are zero, hotpatching is disabled.

You can override this for individual functions with the "hotpatch" attribute ✨

---

✨ SH Options ✨

These -m options are defined for the SH implementations 🌈

• -m1 — generates code for the SH1 💖
• -m2 — generates code for the SH2 💖
• -m2e — generates code for the SH2e 💖
• -m2a-nofpu — generates code for the SH2a without an FPU, or for a SH2a-FPU in a way that the floating-point unit isn't used 🦋
• -m2a-single-only — generates code for the SH2a-FPU so that no double-precision floating-point operations are used 🦋
• -m2a-single — generates code for the SH2a-FPU, assuming the floating-point unit is in single-precision mode by default 🦋
• -m2a — generates code for the SH2a-FPU, assuming the floating-point unit is in double-precision mode by default 🦋
• -m3 — generates code for the SH3 💖
• -m3e — generates code for the SH3e 💖
• -m4-nofpu — generates code for the SH4 without a floating-point unit 🌸
• -m4-single-only — generates code for the SH4 with a floating-point unit that only supports single-precision arithmetic 🌸
• -m4-single — generates code for the SH4, assuming the floating-point unit is in single-precision mode by default 🌸
• -m4 — generates code for the SH4 🌸
• -m4-100 — generates code for SH4-100 🍓
• -m4-100-nofpu — generates code for SH4-100 in a way that the floating-point unit isn't used 🍓
• -m4-100-single — generates code for SH4-100, assuming the floating-point unit is in single-precision mode by default 🍓
• -m4-100-single-only — generates code for SH4-100 so that no double-precision floating-point operations are used 🍓
• -m4-200 — generates code for SH4-200 🫶
• -m4-200-nofpu — generates code for SH4-200 without, like, in a way that the floating-point unit isn't used 🫶
• -m4-200-single — generates code for SH4-200, assuming the floating-point unit is in single-precision mode by default 🫶
• -m4-200-single-only — generates code for SH4-200 so that no double-precision floating-point operations are used 🫶
• -m4-300 — generates code for SH4-300 🧚
• -m4-300-nofpu — generates code for SH4-300 without, again, the floating-point unit being used 🧚
• -m4-300-single — generates code for SH4-300 so that no double-precision floating-point operations are used 🧚
• -m4-300-single-only — generates code for SH4-300 so that no double-precision floating-point operations are used 🧚
• -m4-340 — generates code for SH4-340 (no MMU, no FPU) 💜
• -m4-500 — generates code for SH4-500 (no FPU). It also passes -isa=sh4-nofpu to the assembler 💜
• -m4a-nofpu — generates code for the SH4al-dsp, or for a SH4a in a way that the floating-point unit isn't used 🌈
• -m4a-single-only — generates code for the SH4a so that no double-precision floating-point operations are used 🌈
• -m4a-single — generates code for the SH4a, assuming the floating-point unit is in single-precision mode by default 🌈
• -m4a — generates code for the SH4a ⭐
• -m4al — same as -m4a-nofpu, except it implicitly passes -dsp to the assembler. GCC doesn't generate any DSP instructions at the moment, so don't expect them 🙈
• -mb — compiles code for the processor in big-endian mode 🎀
• -ml — compiles code for the processor in little-endian mode 🎀
• -mdalign — aligns doubles at 64-bit boundaries 🫶

Heads up, bestie: this changes the calling conventions, so some functions from the standard C library won't work unless you recompile them first with -mdalign 😭

• -mrelax — shortens some address references at link time, when it's possible. It uses the linker option -relax ✨
• -mbigtable — uses 32-bit offsets in "switch" tables. The default is 16-bit offsets 🍓
• -mbitops — enables the use of bit manipulation instructions on SH2A 💅
• -mfmovd — enables the use of the instruction "fmovd". Check -mdalign for the alignment constraints 💅
• -mrenesas — makes the code comply with the calling conventions defined by Renesas 👑
• -mno-renesas — makes the code comply with the calling conventions GCC used before the Renesas conventions were available. This is the default for all targets of the SH toolchain 👑
• -mnomacsave — marks the "MAC" register as call-clobbered, even if -mrenesas is given 🦋
• -mieee, -mno-ieee — these control the IEEE compliance of floating-point comparisons, which affects how cases where a comparison result is unordered get handled 🔥 By default, -mieee is implicitly enabled. If -ffinite-math-only is enabled, -mno-ieee is implicitly set, which makes floating-point greater-equal and less-equal comparisons faster ⭐ The implicit settings can be overridden by specifying either -mieee or -mno-ieee 💖

✨ MACHINE-DEPENDENT OPTIONS ✨

• -minline-ic_invalidate 🧚 — okay so this one inlines code that invalidates instruction cache entries right after the compiler sets up nested function trampolines. It does nothing if -musermode is on and your chosen code generation option (like -m4) doesn't allow the icbi instruction. If your code generation option doesn't allow icbi and -musermode isn't on, the inlined code pokes the instruction cache address array directly with an associative write. That needs privileged mode at run time, and it breaks if the cache line was mapped through the TLB and got unmapped. 💀
• -misize 📏 — dumps the instruction size and location into the assembly code. Very useful if you're a size-obsessed girlie 🍓
• -mpadstruct 🙈 — this one is deprecated, so please don't start new projects with it 😭. It pads structures to a multiple of 4 bytes, which is incompatible with the SH ABI.
• -matomic-model=model 💜 — sets the model of atomic operations, plus extra parameters, as a comma separated list. For the full tea on atomic built-in functions, check out __atomic Builtins. These are the models and parameters you can pick from:
  • none 🫥 — disables compiler generated atomic sequences and emits library calls for atomic operations instead. This is the default if the target is not sh*-*-linux*.
  • soft-gusa ✨ — generates GNU/Linux compatible gUSA software atomic sequences for the atomic built-in functions. These sequences need extra help from the interrupt/exception handling code of the system, and they're only suitable for SH3* and SH4* single-core systems. This option is on by default when the target is sh*-*-linux* and SH3* or SH4*. When the target is SH4A, it also partially uses the hardware atomic instructions movli.l and movco.l to make the code more efficient, unless strict is specified.
  • soft-tcb 🎀 — generates software atomic sequences that use a variable in the thread control block. It's a variation of the gUSA sequences that can also run on SH1* and SH2* targets. These sequences also need extra support from the interrupt/exception handling code, and they're only suitable for single-core systems. When you use this model, you have to specify the gbr-offset= parameter too.
  • soft-imask 🔒 — generates software atomic sequences that temporarily disable interrupts by setting SR.IMASK = 1111. This model only works when the program runs in privileged mode and is only suitable for single-core systems. It doesn't need extra support from the interrupt/exception handling code. It's on by default when the target is sh*-*-linux* and SH1* or SH2*.
  • hard-llcs 🔥 — generates hardware atomic sequences using only the movli.l and movco.l instructions. This is only available on SH4A and is suitable for multi-core systems. The hardware instructions only support 32 bit atomic variables, so 8 or 16 bit variables get emulated with 32 bit accesses. Code compiled with this is also compatible with other software atomic model interrupt/exception handling systems if it runs on an SH4A system. This model doesn't need any extra support from the interrupt/exception handling code.
  • gbr-offset= 🦋 — specifies the offset in bytes of the variable in the thread control block structure that the generated atomic sequences should use when the soft-tcb model is selected. For other models this parameter is ignored. The value must be an integer multiple of four and in the range 0-1020.
  • strict 👑 — prevents mixing multiple atomic models, even if they're compatible, and makes the compiler generate atomic sequences of the specified model only.
• -mtas 💅 — generates the tas.b opcode for __atomic_test_and_set. Heads up: depending on your hardware and software setup, this can tank overall performance because of the operand cache line flushes that the tas.b instruction implies. On multi-core SH4A processors, tas.b has to be used with caution, since it can corrupt data for certain cache configurations. 😬
• -mprefergot 🌸 — when generating position-independent code, emits function calls through the Global Offset Table instead of the Procedure Linkage Table.
• -musermode, -mno-usermode 🙅‍♀️ — -mno-usermode means the compiler is not allowed to generate privileged mode code, and -musermode means it is not allowed... wait, babe, let me be precise: -musermode says don't allow the compiler to generate privileged mode code, and -mno-usermode allows it. -musermode also implies -mno-inline-ic_invalidate if the inlined code wouldn't work in user mode. -musermode is the default when the target is sh*-*-linux*. If the target is SH1* or SH2*, -musermode does nothing, since there is no user mode there.
• -multcost=number ✖️ — sets the cost the compiler assumes for a multiply instruction.
• -mdiv=strategy ➗ — sets the division strategy for integer division operations. strategy can be one of these:
  • call-div1 📞 — calls a library function that uses the single-step division instruction div1 to do the operation. Dividing by zero gives an unspecified result and doesn't trap. This is the default except for SH4, SH2A and SHcompact.
  • call-fp 🧮 — calls a library function that does the operation in double precision floating point. Dividing by zero causes a floating-point exception. This is the default for SHcompact with FPU. If you pick this for targets without a double precision FPU, it falls back to call-div1.
  • call-table 🗂️ — calls a library function that uses a lookup table for small divisors, and the div1 instruction with case distinction for bigger divisors. Dividing by zero gives an unspecified result and doesn't trap. This is the default for SH4. If you pick this for targets without dynamic shift instructions, it falls back to call-div1.

When you don't specify a division strategy, the compiler picks a default based on the current target. For SH2A, the default is to use the divs and divu instructions instead of library function calls.

• -maccumulate-outgoing-args 📦 — reserves space once for outgoing arguments in the function prologue, instead of around each call. This is usually great for performance and size. It's also needed for unwinding, so the stack frame doesn't change around conditional code.
• -mdivsi3_libfunc=name 🏷️ — sets the name of the library function used for 32-bit signed division to name. This only changes the name used in the call division strategies. The compiler still expects the same sets of input/output/clobbered registers as if this option weren't there.
• -mfixed-range=register-range 🧱 — makes the compiler treat the given register range as fixed registers. A fixed register is one the register allocator isn't allowed to use. This is handy when you're compiling kernel code. A register range is two registers separated by a dash, and you can list multiple ranges separated by a comma.
• -mbranch-cost=num 🌿 — assumes num is the cost of a branch instruction. Higher numbers make the compiler try harder to generate branch-free code when it can. If you don't specify it, the value is picked based on the processor type you're compiling for.
• -mzdcbranch, -mno-zdcbranch ⚡ — -mzdcbranch assumes zero displacement conditional branch instructions bt and bf are fast, so the compiler prefers zero displacement branch code sequences. -mno-zdcbranch says that assumption doesn't hold. This is on by default for SH4 and SH4A, and you can turn it off explicitly with -mno-zdcbranch.
• -mcbranch-force-delay-slot 🐢 — forces the use of delay slots for conditional branches. If no suitable instruction is found, the delay slot gets stuffed with a nop. This option is disabled by default. Turn it on to work around hardware bugs like the ones found in the original SH7055.
• -mfused-madd, -mno-fused-madd 🧁 — -mfused-madd generates code that uses the floating-point multiply and accumulate instructions, and -mno-fused-madd generates code that doesn't. These instructions are generated by default if hardware floating point is used. The machine-dependent -mfused-madd option is now mapped to the machine-independent -ffp-contract=fast option, and -mno-fused-madd is mapped to -ffp-contract=off.
• -mfsca, -mno-fsca 📐 — allows or disallows the compiler from emitting the fsca instruction for sine and cosine approximations. -mfsca has to be used together with -funsafe-math-optimizations. It's enabled by default when generating code for SH4A. -mno-fsca disables sine and cosine approximations even if -funsafe-math-optimizations is in effect.
• -mfsrra, -mno-fsrra 🔢 — allows or disallows the compiler from emitting the fsrra instruction for reciprocal square root approximations. -mfsrra has to be used together with -funsafe-math-optimizations and -ffinite-math-only. It's enabled by default when generating code for SH4A. -mno-fsrra disables reciprocal square root approximations even if -funsafe-math-optimizations and -ffinite-math-only are in effect.
• -mpretend-cmove 🎭 — prefers zero-displacement conditional branches for conditional move instruction patterns. This can make code run faster on the SH4 processor.
• -mfdpic 🌈 — generates code using the FDPIC ABI.

---

💜 Solaris 2 Options 💜

These -m options are supported on Solaris 2 🌞

• -mclear-hwcap 🧹 — tells the compiler to remove the hardware capabilities that the Solaris assembler generated. You only need this when object files use ISA extensions the current machine doesn't support, but they check at runtime whether or not to use them.
• -mimpure-text 🦄 — used together with -shared, this tells the compiler not to pass -z text to the linker when linking a shared object. With this option you can link position-dependent code into a shared object.

Okay so, -mimpure-text is the one that silences the "relocations remain against allocatable but non-writable sections" linker error 🙈 but bestie, it's a trap. The relocations trigger copy-on-write, so the shared object isn't actually shared across processes anymore 💀 The move is to compile all your source with -fpic or -fPIC instead ✨

These switches also work on Solaris 2, on top of everything above:

• -pthreads — literally just a synonym for -pthread 🧚

✨ SPARC Options ✨

These -m options are supported on the SPARC 💜

• -mno-app-regs, -mapp-regs — -mapp-regs is the default and it's giving reserved vibes 🫶 It makes the compiler use global registers 2 through 4, which the SPARC SVR4 ABI sets aside for applications. Just like global register 1, each of 2 through 4 is treated as an allocable register that function calls are allowed to clobber. If you want to be fully SVR4 ABI-compliant and you don't mind a bit of performance loss, go with -mno-app-regs. Libraries and system software should be compiled with this one 🎀
• -mflat, -mno-flat — With -mflat, the compiler skips the save/restore instructions and uses a "flat" single register window model 🦋 That's compatible with the regular register window model. The local registers and the input registers (0--5) are still treated as "call-saved" and get saved on the stack when needed. -mno-flat is the default, and it generates save/restore instructions everywhere except leaf functions. That's the normal operating mode 💅
• -mfpu, -mhard-float — generates output with floating-point instructions. This is the default 🔥
• -mno-fpu, -msoft-float — generates output that calls library functions for floating point instead 😭

Heads up: the required libraries aren't available for every SPARC target. Normally GCC borrows the facilities of the machine's usual C compiler, but that can't be done directly when cross-compiling, so you need to sort out your own suitable library functions for cross-compilation. The embedded targets sparc-*-aout and sparclite-*-* do come with software floating-point support.

-msoft-float changes the calling convention in the output file, so it only makes sense if you compile the whole program with it. Specifically, libgcc.a, the library that ships with GCC, has to be built with -msoft-float for this to work 🙈

• -mhard-quad-float — generates output with quad-word (long double) floating-point instructions 🌈
• -msoft-quad-float — generates output that calls library functions for quad-word (long double) floating-point instructions. Those functions are the ones defined in the SPARC ABI, and this is the default 💖

As of this writing, no SPARC implementations have hardware support for the quad-word floating-point instructions 💀 Every one of them hits a trap handler for these instructions, and then the trap handler emulates what the instruction would have done. Because of that trap handler overhead it's way slower than calling the ABI library routines, which is exactly why -msoft-quad-float is the default ✨

• -mno-unaligned-doubles, -munaligned-doubles — -mno-unaligned-doubles is the default, and it assumes doubles have 8-byte alignment 🍓

With -munaligned-doubles, GCC only assumes 8-byte alignment for doubles if they're contained in another type or have an absolute address. Otherwise it assumes 4-byte alignment. Using this option helps dodge some rare compatibility problems with code from other compilers, but it's not the default because it costs performance, especially in floating-point code 🥺

• -muser-mode, -mno-user-mode — -mno-user-mode is the default, and it means no code that can only run in supervisor mode gets generated 👑 This only matters for the "casa" instruction emitted for the LEON3 processor.
• -mfaster-structs, -mno-faster-structs — With -mfaster-structs, the compiler assumes structures should have 8-byte alignment. That unlocks pairs of "ldd" and "std" instructions for copies in structure assignment, instead of twice as many "ld" and "st" pairs ⚡ BUT the changed alignment directly violates the SPARC ABI, so it's only meant for targets where the developer knows and accepts that the code doesn't follow the ABI rules 🙈
• -mstd-struct-return, -mno-std-struct-return — With -mstd-struct-return, the compiler generates checking code in functions that return structures or unions, so it can catch size mismatches between the two sides of a function call, as the 32-bit ABI requires 🔍 The default is -mno-std-struct-return, and this option does nothing in 64-bit mode.
• -mcpu=cpu_type — sets the instruction set, register set, and instruction scheduling parameters for the machine type cpu_type ✨ The supported values are v7, cypress, v8, supersparc, hypersparc, leon, leon3, leon3v7, leon5, sparclite, f930, f934, sparclite86x, sparclet, tsc701, v9, ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4, niagara7 and m8.

Native Solaris and GNU/Linux toolchains also accept native, which picks the best architecture option for your host processor 🧚 If GCC doesn't recognise the processor, -mcpu=native does nothing.

For values that name an architecture rather than a specific implementation (v7, v8, sparclite, sparclet, v9), GCC uses the default instruction scheduling parameters 💅

Here's the full breakdown of each architecture and the implementations it covers:

• v7 — cypress, leon3v7
• v8 — supersparc, hypersparc, leon, leon3, leon5
• sparclite — f930, f934, sparclite86x
• sparclet — tsc701
• v9 — ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4, niagara7, m8

By default (unless it's been configured otherwise), GCC generates V7 code 🌸 With -mcpu=cypress, it also optimises for the Cypress CY7C602 chip, the one in the SPARCStation/SPARCServer 3xx series. That's also a good fit for the older SPARCStation 1, 2, IPX and friends.

With -mcpu=v8, GCC generates V8 code. The only real difference from V7 is that it emits the integer multiply and integer divide instructions that exist in SPARC-V8 but not SPARC-V7 ⚡ With -mcpu=supersparc, it also optimises for the SuperSPARC chip, found in the SPARCStation 10, 1000 and 2000 series.

With -mcpu=sparclite, GCC generates code for the SPARClite variant. That adds the integer multiply, integer divide step and scan ("ffs") instructions, which SPARClite has but SPARC-V7 doesn't 🦋 With -mcpu=f930, it also optimises for the Fujitsu MB86930, the original SPARClite, which has no FPU. With -mcpu=f934, it optimises for the Fujitsu MB86934, the newer SPARClite that does have an FPU.

With -mcpu=sparclet, GCC generates code for the SPARClet variant. That adds integer multiply, multiply/accumulate, integer divide step and scan ("ffs") instructions, all things SPARClet has and SPARC-V7 doesn't 🎀 With -mcpu=tsc701, it also optimises for the TEMIC SPARClet chip.

With -mcpu=v9, GCC generates V9 code, which adds 64-bit integer and floating-point move instructions, 3 extra floating-point condition code registers and conditional move instructions 🌈 With -mcpu=ultrasparc, it also optimises for the Sun UltraSPARC I/II/IIi chips. -mcpu=ultrasparc3 targets the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+ chips. -mcpu=niagara targets Sun UltraSPARC T1 chips, -mcpu=niagara2 targets Sun UltraSPARC T2 chips, -mcpu=niagara3 targets Sun UltraSPARC T3 chips, and -mcpu=niagara4 targets Sun UltraSPARC T4 chips. -mcpu=niagara7 optimises for Oracle SPARC M7 chips, and -mcpu=m8 optimises for Oracle M8 chips 👑

• -mtune=cpu_type — sets the instruction scheduling parameters for the machine type cpu_type, but leaves alone the instruction set and register set that -mcpu=cpu_type would set 💖

The same values work for -mtune=cpu_type as for -mcpu=cpu_type, but only the ones that pick a specific CPU implementation are actually useful: cypress, supersparc, hypersparc, leon, leon3, leon3v7, leon5, f930, f934, sparclite86x, tsc701, ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4, niagara7 and m8. On native Solaris and GNU/Linux toolchains you can use native here too 🧚

• -mv8plus, -mno-v8plus — -mv8plus makes GCC generate code for the SPARC-V8+ ABI 🔥 The difference from the V8 ABI is that the global and out registers are treated as 64 bits wide. This is on by default on Solaris in 32-bit mode for all SPARC-V9 processors.
• -mvis, -mno-vis — -mvis makes GCC generate code that takes advantage of the UltraSPARC Visual Instruction Set extensions ✨ The default is -mno-vis.
• -mvis2, -mno-vis2 — -mvis2 makes GCC use version 2.0 of the UltraSPARC Visual Instruction Set extensions 🦋 The default is -mvis2 when you're targeting a CPU that supports those instructions, like UltraSPARC-III and later. Setting -mvis2 also sets -mvis.
• -mvis3, -mno-vis3 — -mvis3 makes GCC use version 3.0 of the UltraSPARC Visual Instruction Set extensions 💜 The default is -mvis3 when you're targeting a CPU that supports those, like niagara-3 and later. Setting -mvis3 also sets -mvis2 and -mvis.
• -mvis3b, -mno-vis3b — okay bestie, -mvis3b tells GCC to write code that uses version 3.0 of the UltraSPARC Visual Instruction Set extensions, plus the extra VIS instructions from the Oracle SPARC Architecture 2011 🦋. It's on by default when you target a cpu that supports them, like niagara-7 and later. Turning it on also turns on -mvis3, -mvis2 and -mvis ✨.
• -mvis4, -mno-vis4 — -mvis4 gets GCC generating code for version 4.0 of the UltraSPARC Visual Instruction Set extensions 💅. It's the default when targeting a cpu that supports them, such as niagara-7 and later. Setting -mvis4 also sets -mvis3b, -mvis3, -mvis2 and -mvis 🌸.
• -mvis4b, -mno-vis4b — -mvis4b is giving version 4.0 of the UltraSPARC Visual Instruction Set extensions, plus the additional VIS instructions from the Oracle SPARC Architecture 2017 🔥. It's the default when targeting a cpu that supports them, such as m8 and later. Setting -mvis4b also sets -mvis4, -mvis3b, -mvis3, -mvis2 and -mvis 👑.
• -mcbcond, -mno-cbcond — -mcbcond makes GCC use the UltraSPARC Compare-and-Branch-on-Condition instructions 🧚. It's on by default when targeting a CPU that has them, like Niagara-4 and later.
• -mfmaf, -mno-fmaf — -mfmaf lets GCC use the UltraSPARC Fused Multiply-Add Floating-point instructions 💜. Default when targeting a CPU that supports them, such as Niagara-3 and later.
• -mfsmuld, -mno-fsmuld — -mfsmuld has GCC take advantage of the Floating-point Multiply Single to Double (FsMULd) instruction 🍓. It's the default when targeting a CPU supporting the architecture versions V8 or V9 with FPU, except -mcpu=leon.
• -mpopc, -mno-popc — -mpopc has GCC using the UltraSPARC Population Count instruction 🌈. Default when targeting a CPU that has one, such as Niagara-2 and later.
• -msubxc, -mno-subxc — -msubxc opts into the UltraSPARC Subtract-Extended-with-Carry instruction 🎀. It's the default when targeting a CPU that supports it, such as Niagara-7 and later.
• -mfix-at697f — turns on the documented workaround for the single erratum of the Atmel AT697F processor, which is erratum #13 of the AT697E processor 🙈.
• -mfix-ut699 — turns on the documented workarounds for the floating-point errata and the data cache nullify errata of the UT699 processor ✨.
• -mfix-ut700 — turns on the documented workaround for the back-to-back store errata of the UT699E/UT700 processor 🫶.
• -mfix-gr712rc — turns on the documented workaround for the back-to-back store errata of the GR712RC processor 💖.

These -m options are supported in addition to the above on SPARC-V9 processors in 64-bit environments 🦋:

• -m32, -m64 — generates code for a 32-bit or 64-bit environment 🌸. The 32-bit one sets int, long and pointer to 32 bits. The 64-bit one sets int to 32 bits and long and pointer to 64 bits.
• -mcmodel=which — sets the code model to one of these:
  • medlow — The Medium/Low code model: 64-bit addresses, and programs must be linked in the low 32 bits of memory 💅. Programs can be statically or dynamically linked.
  • medmid — The Medium/Middle code model: 64-bit addresses, and programs must be linked in the low 44 bits of memory 🧚. The text and data segments must be less than 2GB in size, and the data segment must be located within 2GB of the text segment.
  • medany — The Medium/Anywhere code model: 64-bit addresses, and programs may be linked anywhere in memory 🌈. The text and data segments must be less than 2GB in size, and the data segment must be located within 2GB of the text segment.
  • embmedany — The Medium/Anywhere code model for embedded systems: 64-bit addresses 🔥. The text and data segments must be less than 2GB in size, both starting anywhere in memory (determined at link time). The global register %g4 points to the base of the data segment. Programs are statically linked and PIC is not supported.
• -mmemory-model=mem-model — sets the memory model on the processor to one of these:
  • default — the default memory model for the processor and operating system 🍓.
  • rmo — Relaxed Memory Order
  • pso — Partial Store Order
  • tso — Total Store Order
  • sc — Sequential Consistency

These memory models are formally defined in Appendix D of the SPARC-V9 architecture manual, and they're set in the processor's "PSTATE.MM" field 🫶.

• -mstack-bias, -mno-stack-bias — -mstack-bias tells GCC to assume the stack pointer, and the frame pointer if there is one, are offset by -2047, which has to be added back when making stack frame references 💜. This is the default in 64-bit mode. Otherwise, GCC assumes no such offset is present.

✨ Options for System V ✨

These additional options are available on System V Release 4 for compatibility with other compilers on those systems 💖:

• -G — creates a shared object 🎀. It's recommended to use -symbolic or -shared instead.
• -Qy — identifies the versions of each tool used by the compiler, in a ".ident" assembler directive in the output 🧚.
• -Qn — refrains from adding ".ident" directives to the output file, which is the default 🌸.
• -YP,dirs — searches the directories dirs, and no others, for libraries specified with -l 🦋.
• -Ym,dir — looks in the directory dir to find the M4 preprocessor 🔥. The assembler uses this option.

👑 V850 Options 👑

These -m options are defined for V850 implementations 💅:

• -mlong-calls, -mno-long-calls — treats all calls as being far away (near) 🌈. If calls are assumed to be far away, the compiler always loads the function's address into a register, and calls indirect through the pointer.
• -mno-ep, -mep — -mno-ep means do not optimize basic blocks that use the same index pointer 4 or more times to copy the pointer into the "ep" register, and use the shorter "sld" and "sst" instructions 🍓. -mep means do optimize them. The -mep option is on by default if you optimize ✨.
• -mno-prolog-function, -mprolog-function — -mno-prolog-function means do not use external functions to save and restore registers at the prologue and epilogue of a function 🙈. -mprolog-function means do use them. The external functions are slower, but they use less code space if more than one function saves the same number of registers. The -mprolog-function option is on by default if you optimize 💜.
• -mspace — tries to make the code as small as possible 🎀. At present, this just turns on the -mep and -mprolog-function options.
• -mtda=n — puts static or global variables whose size is n bytes or less into the tiny data area that register "ep" points to 🧚. The tiny data area can hold up to 256 bytes in total (128 bytes for byte references).
• -msda=n — puts static or global variables whose size is n bytes or less into the small data area that register "gp" points to 🌸. The small data area can hold up to 64 kilobytes.
• -mzda=n — puts static or global variables whose size is n bytes or less into the first 32 kilobytes of memory 🦋.
• -mv850 — specifies that the target processor is the V850 🔥.
• -mv850e3v5 — specifies that the target processor is the V850E3V5 👑. The preprocessor constant "__v850e3v5__" is defined if this option is used.
• -mv850e2v4 — specifies that the target processor is the V850E3V5 💅. This is an alias for the -mv850e3v5 option.
• -mv850e2v3 — specifies that the target processor is the V850E2V3 🌈. The preprocessor constant "__v850e2v3__" is defined if this option is used.
• -mv850e2 — specifies that the target processor is the V850E2 🍓. The preprocessor constant "__v850e2__" is defined if this option is used.
• -mv850e1 — specifies that the target processor is the V850E1 ✨. The preprocessor constants "__v850e1__" and "__v850e__" are defined if this option is used.
• -mv850es — specifies that the target processor is the V850ES 🫶. This is an alias for the -mv850e1 option.
• -mv850e — specifies that the target processor is the V850E 💖. The preprocessor constant "__v850e__" is defined if this option is used.

If neither -mv850 nor -mv850e nor -mv850e1 nor -mv850e2 nor -mv850e2v3 nor -mv850e3v5 are defined, then a default target processor is chosen and the relevant __v850*__ preprocessor constant is defined 🧚.

The preprocessor constants "__v850" and "__v851__" are always defined, regardless of which processor variant is the target 🎀.

• -mdisable-callt, -mno-disable-callt — -mdisable-callt suppresses generation of the "CALLT" instruction for the v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850 architecture 🌸.

This option is enabled by default when the RH850 ABI is in use (see -mrh850-abi), and disabled by default when the GCC ABI is in use 🦋. If "CALLT" instructions are being generated, then the C preprocessor symbol "__V850_CALLT__" is defined.

• -mrelax, -mno-relax — passes on (or does not pass on) the -mrelax command-line option to the assembler 🔥.
• -mlong-jumps, -mno-long-jumps — -mlong-jumps disables the generation of PC-relative jump instructions, and -mno-long-jumps re-enables them 👑.
• -msoft-float, -mhard-float — -msoft-float disables the generation of hardware floating point instructions, and -mhard-float re-enables them 💅. This option is only significant when the target architecture is V850E2V3 or higher. If hardware floating point instructions are being generated, then the C preprocessor symbol "__FPU_OK__" is defined; otherwise the symbol "__NO_FPU__" is defined 🌈.
• -mloop — enables the use of the e3v5 LOOP instruction 🍓. The use of this instruction is not enabled by default when the e3v5 architecture is selected, because its use is still experimental ⚠️.
• -mrh850-abi, -mghs — enables support for the RH850 version of the V850 ABI ✨. This is the default. With this version of the ABI, the following rules apply:
  • Integer sized structures and unions are returned via a memory pointer rather than a register 🫶.
• Large structures and unions (more than 8 bytes in size) are passed by value. 🎀
• Functions are aligned to 16-bit boundaries. ✨
• The -m8byte-align command-line option is supported. 💖
• The -mdisable-callt command-line option is enabled by default. The -mno-disable-callt command-line option is not supported. 🫶

When this version of the ABI is enabled, the C preprocessor symbol "__V850_RH850_ABI__" gets defined. 🌈

• -mgcc-abi — okay so this one turns on the old GCC version of the V850 ABI 🕰️ 💅 With this version, these rules apply:
  • Integer sized structures and unions are returned in register "r10". 💜
  • Large structures and unions (more than 8 bytes in size) are passed by reference. 🦋
  • Functions are aligned to 32-bit boundaries, unless you're optimizing for size. 🌸
  • The -m8byte-align command-line option is not supported. 🙈
  • The -mdisable-callt command-line option is supported but not enabled by default. ⭐

When this version of the ABI is enabled, the C preprocessor symbol "__V850_GCC_ABI__" gets defined. 🧚

• -m8byte-align, -mno-8byte-align — enables "double" and "long long" types to be aligned on 8-byte boundaries, bestie 🍓 The default is to keep the alignment of all objects to at most 4-bytes. When -m8byte-align is in effect, the C preprocessor symbol "__V850_8BYTE_ALIGN__" gets defined. ✨
• -mbig-switch — generates code that's suitable for big switch tables. Only use this one if the assembler/linker complains about out of range branches within a switch table. 😭
• -mapp-regs — makes r2 and r5 get used in the code the compiler generates. This is the default, so you're already set 💅
• -mno-app-regs — makes r2 and r5 get treated as fixed registers. 🔒

---

🌷 VAX Options 🌷

These -m options are defined for the VAX. 🦋

• -munix — don't output certain jump instructions ("aobleq" and so on) that the Unix assembler for the VAX can't handle across long ranges. 🙅‍♀️
• -mgnu — do output those jump instructions, on the assumption that the GNU assembler is being used. 🧠
• -md, -md-float — uses the D_floating data format for double-precision floating-point numbers instead of G_floating. 💫
• -mg, -mg-float — uses the G_floating data format for double-precision floating-point numbers instead of D_floating. 💖
• -mlra, -mno-lra — enables Local Register Allocation. This is still experimental for the VAX, so by default the compiler uses standard reload. 🧪

---

🛸 Visium Options 🛸

• -mdebug — a program that does file I/O and is destined to run on an MCM target should be linked with this option. It causes the libraries libc.a and libdebug.a to be linked. The program should be run on the target under the control of the GDB remote debugging stub. 🔧
• -msim — a program that does file I/O and is destined to run on the simulator should be linked with option. This causes the libraries libc.a and libsim.a to be linked. 🎮
• -mfpu, -mhard-float — generates code containing floating-point instructions. This is the default. 🔥
• -mno-fpu, -msoft-float — generates code containing library calls for floating-point. 🧮

⚠️ bestie, -msoft-float changes the calling convention in the output file, so it's only useful if you compile all of a program with this option. In particular, you need to compile libgcc.a, the library that comes with GCC, with -msoft-float for this to work. 💀

• -mcpu=cpu_type — sets the instruction set, register set, and instruction scheduling parameters for machine type cpu_type. Supported values for cpu_type are mcm, gr5 and gr6. 👑
  • mcm is a synonym of gr5, kept around for backward compatibility. 🫶
  • By default (unless configured otherwise), GCC generates code for the GR5 variant of the Visium architecture. 🌸
  • With -mcpu=gr6, GCC generates code for the GR6 variant of the Visium architecture. The only difference from GR5 code is that the compiler will generate block move instructions. ✨
• -mtune=cpu_type — sets the instruction scheduling parameters for machine type cpu_type, but does not set the instruction set or register set that -mcpu=cpu_type would. 🎀
• -msv-mode — generates code for supervisor mode, where there are no restrictions on access to general registers. This is the default. 👸
• -muser-mode — generates code for user mode, where access to some general registers is forbidden: on the GR5, registers r24 to r31 cannot be accessed in this mode; on the GR6, only registers r29 to r31 are affected. 🙈

---

💜 VMS Options 💜

These -m options are defined for the VMS implementations. 🌌

• -mvms-return-codes — returns VMS condition codes from "main". The default is to return POSIX-style condition (e.g. error) codes. 🧾
• -mdebug-main=prefix — flags the first routine whose name starts with prefix as the main routine for the debugger. 🔍
• -mmalloc64 — defaults to 64-bit memory allocation routines. 🧠
• -mpointer-size=size — sets the default size of pointers. Possible options for size are 32 or short for 32 bit pointers, 64 or long for 64 bit pointers, and no for supporting only 32 bit pointers. The latter option disables "pragma pointer_size". 📏

---

🌈 VxWorks Options 🌈

The options in this section are defined for all VxWorks targets. Options specific to the target hardware are listed with the other options for that target. 🛠️

• -mrtp — GCC can generate code for both VxWorks kernels and real time processes (RTPs). This option switches from the former to the latter. It also defines the preprocessor macro "__RTP__". 🦋
• -msmp — selects SMP runtimes for linking. Not available on architectures other than PowerPC, nor on VxWorks version 7 or later, where the selection is part of the VxWorks build configuration and the library paths are the same for either choice. 🙅‍♀️
• -non-static — links an RTP executable against shared libraries rather than static libraries. The options -static and -shared can also be used for RTPs; -static is the default. 🔗
• -Bstatic, -Bdynamic — these options are passed down to the linker. They're defined for compatibility with Diab. 🤝
• -Xbind-lazy — enables lazy binding of function calls. This option is equivalent to -Wl,-z,now and is defined for compatibility with Diab. 🐢
• -Xbind-now — disables lazy binding of function calls. This option is the default and is defined for compatibility with Diab. ⚡

---

🦄 x86 Options 🦄

These -m options are defined for the x86 family of computers. 💻

• -march=cpu-type — generates instructions for the machine type cpu-type. Unlike -mtune=cpu-type, which merely tunes the generated code for the specified cpu-type, -march=cpu-type allows GCC to generate code that may not run at all on processors other than the one indicated. Specifying -march=cpu-type implies -mtune=cpu-type, except where noted otherwise. 🏎️

The choices for cpu-type are:

• native — selects the CPU to generate code for at compilation time by figuring out the processor type of the compiling machine. Using -march=native enables all instruction subsets supported by the local machine (so the result might not run on different machines). Using -mtune=native produces code optimized for the local machine under the constraints of the selected instruction set. 🏠
• x86-64 — a generic CPU with 64-bit extensions, MMX, SSE, SSE2, and FXSR instruction set support. 🌟
• x86-64-v2, x86-64-v3, x86-64-v4 — these choices select the corresponding micro-architecture level from the x86-64 psABI. On ABIs other than the x86-64 psABI, they select the same CPU features as the x86-64 psABI documents for the particular micro-architecture level.

Since these cpu-type values don't have a corresponding -mtune setting, using -march with these values enables generic tuning. Specific tuning can be enabled using the -mtune=other-cpu-type option with an appropriate other-cpu-type value. 🎯

• i386 — the original Intel i386 CPU. 🦕
• i486 — the Intel i486 CPU. (No scheduling is implemented for this chip.) 🙃
• i586, pentium — the Intel Pentium CPU with no MMX support. 💿
• lakemont — the Intel Lakemont MCU, based on the Intel Pentium CPU. 🔬
• pentium-mmx — the Intel Pentium MMX CPU, based on the Pentium core with MMX instruction set support. 🎵
• pentiumpro — the Intel Pentium Pro CPU with no MMX support. 🚀
• i686 — with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. With -mtune, it has the same meaning as generic. 🌐
• pentium2 — the Intel Pentium II CPU, based on the Pentium Pro core with MMX and FXSR instruction set support. 🍒
• pentium3, pentium3m — the Intel Pentium III CPU, based on the Pentium Pro core with MMX, FXSR and SSE instruction set support. 🌻
• pentium-m — the Intel Pentium M, a low-power version of the Intel Pentium III CPU with MMX, SSE, SSE2 and FXSR instruction set support. Used by Centrino notebooks. 💼
• pentium4, pentium4m — the Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction set support. 🩷
• prescott — an improved version of the Intel Pentium 4 CPU with MMX, SSE, SSE2, SSE3 and FXSR instruction set support. 🌷
• nocona — an improved version of the Intel Pentium 4 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and FXSR instruction set support. 🌺
• core2 — the Intel Core 2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, CX16, SAHF and FXSR instruction set support. ☕
• nehalem, corei7 — the Intel Nehalem CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF and FXSR instruction set support. 🌙
• westmere — the Intel Westmere CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR and PCLMUL instruction set support. 🫧
• sandybridge, corei7-avx — the Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE and PCLMUL instruction set support. 🌅

• ivybridge, core-avx-i 🦋 Intel Ivy Bridge CPU, bestie! It comes with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND and F16C instruction set support. Vintage but still iconic ✨
• haswell, core-avx2 🌸 Intel Haswell CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE and HLE instruction set support. The AVX2 glow-up is so real 💅
• broadwell 🎀 Intel Broadwell CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX and PREFETCHW instruction set support. Lowkey underrated 🫶
• skylake 🔥 Intel Skylake CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES and SGX instruction set support. It's giving a whole upgrade 🌈
• skylake-avx512 👑 Intel Skylake Server CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ and AVX512CD instruction set support. Server girlies, this one's for you 🫶
• cascadelake 💜 Intel Cascade Lake CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ, AVX512CD and AVX512VNNI instruction set support. Serving VNNI realness ✨
• cannonlake 🧚 Intel Cannon Lake Server CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA and SHA instruction set support. Okay, the list is giving main character 🌟
• cooperlake 🍓 Intel Cooper Lake CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, AVX512VNNI and AVX512BF16 instruction set support. BF16 is so cute, no cap 🥹
• icelake-client 🌊 Intel Ice Lake Client CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support. The feature drop is literally unreal 😭
• icelake-server 🏰 Intel Ice Lake Server CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD and CLWB instruction set support. Server edition with all the extras 💅
• tigerlake 🐯 Intel Tiger Lake CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB, AVX512VP2INTERSECT and KEYLOCKER instruction set support. Tiger Lake is a whole roar 🔥
• rocketlake 🚀 Intel Rocket Lake CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support. Blast off, periodt 🌌
• alderlake, raptorlake, meteorlake, gracemont ⭐ Intel Alder Lake/Raptor Lake/Meteor Lake/Gracemont CPU, with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL and AVX-VNNI instruction set support. Hybrid-core era, and it's so serious 🧠
• arrowlake 🏹 Intel Arrow Lake CPU, with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT and CMPCCXADD instruction set support. Arrow sharp, bestie 💫
• arrowlake-s, lunarlake 🌙 Intel Arrow Lake S/Lunar Lake CPU, with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, SM3 and SM4 instruction set support. Two names, one slay 🦋
• pantherlake 🌠 Intel Panther Lake CPU, with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, SM3, SM4 and PREFETCHI instruction set support. The ext list is literally endless ✨
• sapphirerapids, emeraldrapids 💎 Intel Sapphire Rapids/Emerald Rapids CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK, UINTR, AMX-BF16, AMX-TILE, AMX-INT8, AVX-VNNI, AVX512-FP16 and AVX512BF16 instruction set support. Sapphire and emerald, both gorgeous 🥰
• graniterapids 🪨 Intel Granite Rapids CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK, UINTR, AMX-BF16, AMX-TILE, AMX-INT8, AVX-VNNI, AVX512-FP16, AVX512BF16, AMX-FP16 and PREFETCHI instruction set support. Granite? More like granite-level strong 💪
• graniterapids-d 🌋 Intel Granite Rapids D CPU, with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK, UINTR, AMX-BF16, AMX-TILE, AMX-INT8, AVX-VNNI, AVX512FP16, AVX512BF16, AMX-FP16, PREFETCHI and AMX-COMPLEX instruction set support. The D variant is the final boss 👑🧚
• diamondrapids — Intel Diamond Rapids 👑 CPU, the full glam package: 64-bit extensions plus MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, HLE, RDSEED, ADCX, PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK, UINTR, AMX-BF16, AMX-TILE, AMX-INT8, AVX-VNNI, AVX512FP16, AVX512BF16, AMX-FP16, PREFETCHI, AMX-COMPLEX, AVX10.1-512, AVX-IFMA, AVX-NE-CONVERT, AVX-VNNI-INT16, AVX-VNNI-INT8, CMPccXADD, SHA512, SM3, SM4, AVX10.2-512, APX_F, AMX-AVX512, AMX-FP8, AMX-TF32, AMX-TRANSPOSE, MOVRS, AMX-MOVRS and USER_MSR instruction set support. ✨
• bonnell, atom — Intel Bonnell 🌸 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support.
• silvermont, slm — Intel Silvermont 🦋 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW and RDRND instruction set support.
• goldmont — Intel Goldmont 🍓 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT and FSGSBASE instruction set support.
• goldmont-plus — Intel Goldmont Plus 🧚 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID and SGX instruction set support.
• tremont — Intel Tremont 💜 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID, SGX, CLWB, GFNI-SSE, MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG instruction set support.
• sierraforest — Intel Sierra Forest 🌈 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set support.
• grandridge — Intel Grand Ridge ⭐ CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX-VNNI, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set support.
• clearwaterforest — Intel Clearwater Forest 💅 CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, AVX-VNNI, ENQCMD, UINTR, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AVXVNNIINT16, SHA512, SM3, SM4, USER_MSR and PREFETCHI instruction set support.
• k6 — AMD K6 🎀 CPU, with MMX instruction set support.
• k6-2, k6-3 — Upgraded versions of the AMD K6 CPU, with MMX and 3DNow! instruction set support. 🍑
• athlon, athlon-tbird — AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE prefetch instructions support. 🔥
• athlon-4, athlon-xp, athlon-mp — The glow-up of the AMD Athlon CPU, with MMX, 3DNow!, enhanced 3DNow! and full SSE instruction set support. ✨
• k8, opteron, athlon64, athlon-fx — Processors built on the AMD K8 core with x86-64 instruction set support, including the AMD Opteron, Athlon 64 and Athlon 64 FX processors. (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64-bit instruction set extensions.) 💖
• k8-sse3, opteron-sse3, athlon64-sse3 — Upgraded versions of the AMD K8 cores, with SSE3 instruction set support. 🌸
• amdfam10, barcelona — CPUs built on AMD Family 10h cores, with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow!, ABM and 64-bit instruction set extensions.) 🦋
• bdver1 — CPUs built on AMD Family 15h cores, with x86-64 instruction set support. (This supersets FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.) 🔥
• bdver2 — AMD Family 15h core based CPUs, with x86-64 instruction set support. (This supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.) 💅
• bdver3 — AMD Family 15h core based CPUs, with x86-64 instruction set support. (This supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.) 🌈
• bdver4 — AMD Family 15h core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.) 👑
• znver1 — AMD Family 17h core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64-bit instruction set extensions.) 🫶
• znver2 — AMD Family 17h core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID, WBNOINVD, and 64-bit instruction set extensions.) 💜
• znver3 — AMD Family 19h core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, and 64-bit instruction set extensions.) 🔥
• znver4 — AMD Family 19h core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD, AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI, AVX512BITALG, AVX512VPOPCNTDQ, GFNI and 64-bit instruction set extensions.) 🌸
• znver5 — AMD Family 1ah core based CPUs, with x86-64 instruction set support. (This supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD, AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI, AVX512BITALG, AVX512VPOPCNTDQ, GFNI, AVXVNNI, MOVDIRI, MOVDIR64B, AVX512VP2INTERSECT, PREFETCHI and 64-bit instruction set extensions.) 🧚
• btver1 — CPUs built on AMD Family 14h cores, with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM and 64-bit instruction set extensions.) 🌷
• btver2 — CPUs built on AMD Family 16h cores, with x86-64 instruction set support. This includes MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM, SSE4A, SSSE3, SSE3, SSE2, SSE, MMX and 64-bit instruction set extensions. 🍓
• winchip-c6 — IDT WinChip C6 CPU 🧸, handled the same way as i486, with additional MMX instruction set support.
• winchip2 — IDT WinChip 2 CPU 🌼, handled the same way as i486, with additional MMX and 3DNow! instruction set support.
• c3 — VIA C3 CPU with MMX and 3DNow! instruction set support. (No scheduling is implemented for this chip.) 🙈
• c3-2 — VIA C3-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set support. (No scheduling is implemented for this chip.) 🫧
• c7 — VIA C7 (Esther) CPU with MMX, SSE, SSE2 and SSE3 instruction set support. (No scheduling is implemented for this chip.) 🎀
• samuel-2 — VIA Eden Samuel 2 CPU with MMX and 3DNow! instruction set support. (No scheduling is implemented for this chip.) 🦄
• nehemiah — VIA Eden Nehemiah CPU with MMX and SSE instruction set support. (No scheduling is implemented for this chip.) 🌙
• esther — VIA Eden Esther CPU with MMX, SSE, SSE2 and SSE3 instruction set support. (No scheduling is implemented for this chip.) 💫
• eden-x2 — 💖 VIA Eden X2 CPU with x86-64, MMX, SSE, SSE2 and SSE3 instruction set support. (No scheduling is implemented for this chip.)
• eden-x4 — 🌸 VIA Eden X4 CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX and AVX2 instruction set support. (No scheduling is implemented for this chip.)
• nano — ✨ Generic VIA Nano CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. (No scheduling is implemented for this chip.)
• nano-1000 — 🦋 VIA Nano 1xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. (No scheduling is implemented for this chip.)
• nano-2000 — 🎀 VIA Nano 2xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. (No scheduling is implemented for this chip.)
• nano-3000 — 🧚 VIA Nano 3xxx CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1 instruction set support. (No scheduling is implemented for this chip.)
• nano-x2 — 🌈 VIA Nano Dual Core CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1 instruction set support. (No scheduling is implemented for this chip.)
• nano-x4 — 👑 VIA Nano Quad Core CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1 instruction set support. (No scheduling is implemented for this chip.)
• lujiazui — ⭐ ZHAOXIN lujiazui CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16, ABM, BMI, BMI2, FXSR and RDSEED instruction set support. The chips do support AVX and F16C, but -march=lujiazui doesn't turn those on, for performance reasons. 🫶
• yongfeng — 🔥 ZHAOXIN yongfeng CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16, ABM, BMI, BMI2, F16C, FXSR, RDSEED, AVX2, FMA, SHA and LZCNT instruction set support. 💅
• shijidadao — 💜 ZHAOXIN shijidadao CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16, ABM, BMI, BMI2, F16C, FXSR, RDSEED, AVX2, FMA, SHA and LZCNT instruction set support. 🍓
• geode — 🌸 AMD Geode embedded processor with MMX and 3DNow! instruction set support.

---

• -mtune=cpu-type — 🎀 Tunes everything that can be tuned in the generated code to cpu-type, except for the ABI and the set of available instructions. Picking a specific cpu-type schedules things for that exact chip, but the compiler won't generate anything that can't run on the default machine type, unless you also use a -march=cpu-type option. For example, if GCC is configured for i686-pc-linux-gnu, then -mtune=pentium4 makes code tuned for Pentium 4 that still runs on i686 machines. 🫶
  • The choices for cpu-type are the same as for -march. On top of that, -mtune has 2 extra choices:
  • generic — Produces code optimized for the most common IA32/AMD64/EM64T processors. If you know exactly which CPU your code will run on, use the matching -mtune or -march option instead of -mtune=generic. But if you have no clue what CPU your users will have, this is the one to pick. ✨
    • As new processors hit the market, what this option does will change. So if you upgrade to a newer GCC, the code generated under this option will shift to match whatever processors are most common when that GCC version is released. 🦋
    • There's no -march=generic, because -march is about the instruction set the compiler can use, and there's no generic instruction set that works on every processor. -mtune, on the other hand, is about which processor (or, in this case, group of processors) the code is optimized for. 💅
  • intel — Produces code optimized for the most current Intel processors, which for this version of GCC are Haswell and Silvermont. If you know the CPU your code will run on, use the matching -mtune or -march option instead of -mtune=intel. But if you want your application to perform well on both Haswell and Silvermont, this is your option. 💖
    • As new Intel processors come out, this option's behaviour will change. So if you upgrade to a newer GCC, the code generated will shift to reflect the most current Intel processors at the time that GCC version is released. 🌈
    • There's no -march=intel, because -march is about the instruction set, and there's no common instruction set shared by all Intel processors. -mtune is about the processor (or group of processors) the code is optimized for. 🧚
• -mcpu=cpu-type — 🥀 A deprecated synonym for -mtune. Honestly, just use -mtune instead. 💀
• -mfpmath=unit — 🔥 Generates floating-point arithmetic using the selected unit. The choices for unit are:
  • 387 — Uses the standard 387 floating-point coprocessor found on most chips, and emulates it where there isn't one. Code built with this runs almost everywhere. Temporary results are computed in 80-bit precision instead of the precision the type specifies, so the results can differ slightly from most other chips. Check -ffloat-store for a more detailed explanation. 🫠
    • This is the default choice for non-Darwin x86-32 targets.
  • sse — Uses the scalar floating-point instructions from the SSE instruction set. This is supported by Pentium III and newer chips, and on the AMD side by Athlon-4, Athlon XP and Athlon MP chips. The earlier version of SSE only does single-precision arithmetic, so double and extended-precision maths still go through 387. A later version, found only in Pentium 4 and AMD x86-64 chips, handles double-precision arithmetic too. 👑
    • For the x86-32 compiler, you need -march=cpu-type, -msse or -msse2 to turn on SSE extensions and make this option work. For the x86-64 compiler, those extensions are on by default.
    • The result should be a lot faster in most cases and dodges the numerical instability problems of 387 code. But it may break existing code that expects temporaries to be 80 bits. ⚠️
    • This is the default choice for the x86-64 compiler, Darwin x86-32 targets, and for x86-32 targets with the SSE2 instruction set when -ffast-math is enabled.
  • sse,387, sse+387, both — Tries to use both instruction sets at once. That effectively doubles the number of available registers, and on chips with separate execution units for 387 and SSE, it doubles the execution resources too. Use this with care! It's still experimental, because the GCC register allocator doesn't model separate functional units well, which leads to unstable performance. 💀
• -masm=dialect — 🍓 Outputs assembly instructions in the selected dialect. This also decides which dialect is used for basic asm and extended asm. The supported choices (in dialect order) are att or intel. The default is att. Darwin doesn't support intel. 🌸
• -mieee-fp, -mno-ieee-fp — 🦋 Controls whether or not the compiler uses IEEE floating-point comparisons. These handle the case where a comparison result is unordered correctly. ✨
• -m80387, -mhard-float — 💅 Generates output containing 80387 instructions for floating point.
• -mno-80387, -msoft-float — 🧚 Generates output containing library calls for floating point instead.
  • > Warning: the libraries you need are not part of GCC. Normally the facilities of the machine's usual C compiler get used, but that can't be done directly when cross-compiling. You have to sort out your own suitable library functions for cross-compilation. 😭
  • On machines where a function returns floating-point results in the 80387 register stack, some floating-point opcodes may still get emitted even when -msoft-float is used. 🙈
• -mno-fp-ret-in-387 — 🫶 Doesn't use the FPU registers for function return values.
  • The usual calling convention has functions return float and double values in an FPU register, even if there's no FPU. The idea is that the operating system should emulate the FPU.
  • -mno-fp-ret-in-387 makes those values come back in ordinary CPU registers instead. 🌈
• -mno-fancy-math-387 — 💜 Some 387 emulators don't support the sin, cos and sqrt instructions for the 387. Use this option to avoid generating those instructions. It gets overridden when -march says the target CPU always has an FPU, so the instruction doesn't need emulating. These instructions also aren't generated unless you use the -funsafe-math-optimizations switch too. ⭐
• -malign-double, -mno-align-double — 🎀 Controls whether GCC aligns double, long double and long long variables on a two-word boundary or a one-word boundary. Aligning double variables on a two-word boundary makes code run a bit faster on a Pentium, at the cost of more memory. 🍓
  • On x86-64, -malign-double is enabled by default.
  • > Warning: if you use -malign-double, structures containing the types above get aligned differently from the published application binary interface specifications for x86-32. They won't be binary compatible with structures in code compiled without that switch. 💀
• -m96bit-long-double, -m128bit-long-double — 🔥 These switches control the size of the long double type. The x86-32 application binary interface specifies 96 bits, so -m96bit-long-double is the default in 32-bit mode. 👑

Okay so, the "long double" alignment situation is actually kind of wild 💅. Modern chips (Pentium and newer) really want "long double" sitting on an 8- or 16-byte boundary, but inside arrays and structures that follow the ABI, that just isn't possible 😭. So -m128bit-long-double lines things up on a 16-byte boundary by tacking on an extra 32-bit zero of padding 🫶.

On the x86-64 compiler, -m128bit-long-double is already the default, because its ABI says "long double" is aligned on a 16-byte boundary ✨.

Quick heads up, though: neither of these options gives you any extra precision over the x87 standard of 80 bits for a "long double" 🙈.

Warning: if you override the default for your target ABI, the size of structures and arrays holding "long double" variables changes, and the function calling convention for functions taking "long double" gets modified too 💀. That means your code is not binary-compatible with code compiled without that switch, so be careful bestie 🥺.

• -mlong-double-64 — makes the "long double" type equivalent to "double" 🍓. This is the default for the 32-bit Bionic C library.
• -mlong-double-80 — one of the three switches that control the size of the "long double" type 🎀. The original page doesn't give it any extra detail beyond that.
• -mlong-double-128 — makes the "long double" type equivalent to "__float128" 🌈. This is the default for the 64-bit Bionic C library.

Warning: same deal here. Overriding the default for your target ABI changes the size of structures and arrays containing "long double" variables, and it modifies the function calling convention for functions taking "long double". So it's not binary-compatible with code compiled without that switch 😭.

• -malign-data=type — controls how GCC aligns variables 🧚. The supported values for type are compat, which uses an increased alignment value that's compatible with GCC 4.8 and earlier; abi, which uses the alignment value specified by the psABI; and cacheline, which uses an increased alignment value to match the cache line size 💜. compat is the default.
• -mlarge-data-threshold=threshold — when -mcmodel=medium or -mcmodel=large is specified, any data objects bigger than threshold get placed into large data sections 🦋. The default is 65535.
• -mrtd — switches to a different function-calling convention 🔥. Functions that take a fixed number of arguments return with the ret num instruction, which pops their arguments on the way out, so the caller saves one instruction since it doesn't have to pop them itself ✨.

You can make one specific function use this calling sequence with the function attribute "stdcall" 💅. You can also override -mrtd for a function with the function attribute "cdecl" 🎀.

Warning: this calling convention is incompatible with the one normally used on Unix, so you cannot use it if you need to call libraries compiled with the Unix compiler 💀.

Also, you must provide function prototypes for all functions that take variable numbers of arguments (including "printf"), otherwise incorrect code gets generated for calls to those functions 😭. And seriously incorrect code results if you call a function with too many arguments 🙈. Normally, extra arguments just get harmlessly ignored, but not here, bestie.

• -mregparm=num — controls how many registers are used to pass integer arguments 🌸. By default, no registers are used for passing arguments, and at most 3 registers can be used. You can control this for a specific function with the function attribute "regparm" 🫶.

Warning: if you use this switch and num is nonzero, you must build all modules with the same value, including any libraries. That includes the system libraries and startup modules 💀.

• -msseregparm — uses SSE register passing conventions for float and double arguments and return values ⭐. You can control this for a specific function with the function attribute "sseregparm" 💜.

Warning: if you use this switch, you must build all modules with the same value, including any libraries, the system libraries, and startup modules too 😭.

• -mvect8-ret-in-mem — returns 8-byte vectors in memory instead of MMX registers 🧚. This is the default on VxWorks, so it matches the ABI of the Sun Studio compilers up until version 12 🍓. Only use this if you need to stay compatible with existing code made by those older compiler versions or older versions of GCC 🥹.
• -mpc32, -mpc64, -mpc80 — set the 80387 floating-point precision to 32, 64, or 80 bits 🦋.
  • -mpc32 rounds the significands of floating-point results to 24 bits (single precision) 🌸.
  • -mpc64 rounds them to 53 bits (double precision) 💖.
  • -mpc80 rounds them to 64 bits (extended double precision), and this is the default ✨.

When one of these is used, floating-point operations in higher precisions aren't available to you unless you set the FPU control word explicitly 🙈.

Rounding to less than the default 80 bits can speed some programs up by 2% or more 🔥. But heads up: some math libraries assume extended-precision (80-bit) floating-point operations are on by default. Routines in those libraries could lose a bunch of accuracy, typically through so-called "catastrophic cancellation", when this option drops the precision below extended precision 💀.

• -mdaz-ftz — the flush-to-zero (FTZ) and denormals-are-zero (DAZ) flags in the MXCSR register are what control floating-point calculations 🌈. SSE and AVX instructions, including scalar and vector ones, could benefit from enabling the FTZ and DAZ flags when you pass -mdaz-ftz ⭐. Don't set the FTZ/DAZ flags when -mno-daz-ftz or -shared is specified. And -mdaz-ftz will set the FTZ/DAZ flags even with -shared, so keep that in mind 👀.
• -mstackrealign — realigns the stack at entry 🎀. On x86, this generates an alternate prologue and epilogue that realigns the runtime stack when necessary 🫶. It's super useful for mixing legacy code that keeps 4-byte stack alignment with modern code that keeps 16-byte stack alignment for SSE compatibility 💜. See also the attribute "force_align_arg_pointer", which you can apply to individual functions 🦋.
• -mpreferred-stack-boundary=num — tries to keep the stack boundary aligned to a 2 raised to num byte boundary 🌸. If you don't specify -mpreferred-stack-boundary, the default is 4 (16 bytes or 128 bits) ✨.

Warning: when generating code for the x86-64 architecture with SSE extensions disabled, -mpreferred-stack-boundary=3 can keep the stack boundary aligned to an 8-byte boundary 🙈. But since the x86-64 ABI requires 16-byte stack alignment, this is ABI incompatible. It's only meant for controlled environments where stack space is a seriously important limitation 🥺. This option leads to wrong code when functions compiled with 16-byte stack alignment (like functions from a standard library) get called with a misaligned stack. In that case, SSE instructions may lead to misaligned memory access traps 💀. On top of that, variable arguments are handled incorrectly for 16-byte aligned objects (including x87 long double and __int128), which leads to wrong results 😭. You must build all modules with -mpreferred-stack-boundary=3, including any libraries, the system libraries, and startup modules too 💅.

• -mincoming-stack-boundary=num — assumes the incoming stack is aligned to a 2 raised to num byte boundary 🧚. If you don't specify -mincoming-stack-boundary, the one specified by -mpreferred-stack-boundary gets used 🍓.

On Pentium and Pentium Pro, "double" and "long double" values should be aligned to an 8-byte boundary (see -malign-double), or they'll suffer significant run time performance penalties 🐢. On Pentium III, the Streaming SIMD Extension (SSE) data type "__m128" may not work properly if it isn't 16-byte aligned 😭.

To make sure these values are aligned properly on the stack, the stack boundary has to be as aligned as whatever value stored on the stack requires 🫶. Also, every function has to be generated so it keeps the stack aligned 💜. So calling a function compiled with a higher preferred stack boundary from a function compiled with a lower one most likely misaligns the stack 🙈. It's recommended that libraries that use callbacks always stick with the default setting 🌸.

This extra alignment does eat up extra stack space and generally increases code size 🥹. Code that's sensitive to stack space usage, like embedded systems and operating system kernels, may want to reduce the preferred alignment to -mpreferred-stack-boundary=2 ✨.

• -mmmx 💖 unlocks the MMX instructions
• -msse 🌸 unlocks SSE
• -msse2 🌸 unlocks SSE2
• -msse3 🌸 unlocks SSE3
• -mssse3 🌸 unlocks SSSE3
• -msse4 ✨ unlocks SSE4.1 and SSE4.2 together
• -msse4a 🦋 unlocks SSE4A, which is controlled separately from -msse4
• -msse4.1 ✨ unlocks SSE4.1
• -msse4.2 ✨ unlocks SSE4.2
• -mavx 🧚 unlocks AVX
• -mavx2 🧚 unlocks AVX2
• -mavx512f 👑 unlocks AVX512F
• -mavx512cd 👑 unlocks AVX512CD
• -mavx512vl 👑 unlocks AVX512VL
• -mavx512bw 👑 unlocks AVX512BW
• -mavx512dq 👑 unlocks AVX512DQ
• -mavx512ifma 👑 unlocks AVX512IFMA
• -mavx512vbmi 👑 unlocks AVX512VBMI
• -msha 🔐 unlocks SHA
• -maes 🔐 unlocks AES
• -mpclmul 🔐 unlocks PCLMUL
• -mclflushopt 🧹 unlocks CLFLUSHOPT
• -mclwb 🧹 unlocks CLWB
• -mfsgsbase 🎀 unlocks FSGSBASE
• -mptwrite 🎀 unlocks PTWRITE
• -mrdrnd 🎲 unlocks RDRND
• -mf16c 🎀 unlocks F16C
• -mfma 🔥 unlocks FMA
• -mpconfig 🎀 unlocks PCONFIG
• -mwbnoinvd 🎀 unlocks WBNOINVD
• -mfma4 🔥 unlocks FMA4
• -mprfchw 🎀 unlocks PREFETCHW
• -mrdpid 🎀 unlocks RDPID
• -mrdseed 🎲 unlocks RDSEED
• -msgx 🔐 unlocks SGX
• -mxop 🎀 unlocks XOP
• -mlwp 🎀 unlocks LWP
• -m3dnow 🎀 unlocks 3DNow!
• -m3dnowa 🎀 unlocks enhanced 3DNow!
• -mpopcnt 🎀 unlocks POPCNT
• -mabm 🎀 unlocks ABM
• -madx 🎀 unlocks ADX
• -mbmi 🎀 unlocks BMI
• -mbmi2 🎀 unlocks BMI2
• -mlzcnt 🎀 unlocks LZCNT
• -mfxsr 🎀 unlocks FXSR
• -mxsave 🎀 unlocks XSAVE
• -mxsaveopt 🎀 unlocks XSAVEOPT
• -mxsavec 🎀 unlocks XSAVEC
• -mxsaves 🎀 unlocks XSAVES
• -mrtm 🎀 unlocks RTM
• -mhle 🎀 unlocks HLE
• -mtbm 🎀 unlocks TBM
• -mmwaitx 🎀 unlocks MWAITX
• -mclzero 🎀 unlocks CLZERO
• -mpku 🎀 unlocks PKU
• -mavx512vbmi2 👑 unlocks AVX512VBMI2
• -mavx512bf16 👑 unlocks AVX512BF16
• -mavx512fp16 👑 unlocks AVX512-FP16
• -mgfni 🎀 unlocks GFNI
• -mvaes 🔐 unlocks VAES
• -mwaitpkg 🎀 unlocks WAITPKG
• -mvpclmulqdq 🔐 unlocks VPCLMULQDQ
• -mavx512bitalg 👑 unlocks AVX512BITALG
• -mmovdiri 🎀 unlocks MOVDIRI
• -mmovdir64b 🎀 unlocks MOVDIR64B
• -menqcmd 🎀 unlocks ENQCMD
• -muintr 🎀 unlocks UINTR
• -mtsxldtrk 🎀 unlocks TSXLDTRK
• -mavx512vpopcntdq 👑 unlocks AVX512VPOPCNTDQ
• -mavx512vp2intersect 👑 unlocks AVX512VP2INTERSECT
• -mavx512vnni 👑 unlocks AVX512VNNI
• -mavxvnni 🧚 unlocks AVXVNNI
• -mcldemote 🧹 unlocks CLDEMOTE
• -mserialize 🎀 unlocks SERIALIZE
• -mamx-tile 💜 unlocks AMXTILE
• -mamx-int8 💜 unlocks AMXINT8
• -mamx-bf16 💜 unlocks AMXBF16
• -mhreset 🎀 unlocks HRESET
• -mkl 🎀 unlocks KL
• -mwidekl 🎀 unlocks WIDEKL
• -mavxifma 🧚 unlocks AVXIFMA
• -mavxvnniint8 🧚 unlocks AVXVNNIINT8
• -mavxneconvert 🧚 unlocks AVXNECONVERT
• -mcmpccxadd 🎀 unlocks CMPCCXADD
• -mamx-fp16 💜 unlocks AMX-FP16
• -mprefetchi 🎀 unlocks PREFETCHI
• -mraoint 🎀 unlocks RAOINT
• -mamx-complex 💜 unlocks AMX-COMPLEX
• -mavxvnniint16 🧚 unlocks AVXVNNIINT16
• -msm3 🔐 unlocks SM3
• -msha512 🔐 unlocks SHA512
• -msm4 🔐 unlocks SM4
• -mapxf 👑 unlocks APX_F
• -musermsr 🎀 unlocks USER_MSR
• -mavx10.1 👑 unlocks AVX10.1
• -mavx10.1-256 👑 unlocks AVX10.1 at the 256-bit width
• -mavx10.1-512 👑 unlocks AVX10.1 at the 512-bit width
• -mavx10.2 👑 unlocks AVX10.2
• -mamx-avx512 💜 unlocks AMX-AVX512
• -mamx-tf32 💜 unlocks AMX-TF32
• -mamx-transpose 💜 unlocks AMX-TRANSPOSE
• -mamx-fp8 💜 unlocks AMX-FP8
• -mmovrs 🎀 unlocks MOVRS
• -mamx-movrs 💜 unlocks AMX-MOVRS

These switches are basically your permission slip to use all these fancy instruction sets: MMX, SSE, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA, AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, PCONFIG, WBNOINVD, FMA4, PREFETCHW, RDPID, RDSEED, SGX, XOP, LWP, 3DNow!, enhanced 3DNow!, POPCNT, ABM, ADX, BMI, BMI2, LZCNT, FXSR, XSAVE, XSAVEOPT, XSAVEC, XSAVES, RTM, HLE, TBM, MWAITX, CLZERO, PKU, AVX512VBMI2, GFNI, VAES, WAITPKG, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B, AVX512BF16, ENQCMD, AVX512VPOPCNTDQ, AVX512VNNI, SERIALIZE, UINTR, HRESET, AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512-FP16, AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX-FP16, PREFETCHI, RAOINT, AMX-COMPLEX, AVXVNNIINT16, SM3, SHA512, SM4, APX_F, USER_MSR, AVX10.1, AVX10.2, AMX-AVX512, AMX-TF32, AMX-TRANSPOSE, AMX-FP8, MOVRS, AMX-MOVRS, or CLDEMOTE extended instruction sets. Every one of them has a matching -mno- option that turns its use back off. 💅

These extensions are also available as built-in functions, so check out x86 Built-in Functions to see which functions get enabled and disabled by these switches. 🧚

Heads up: -msse4 turns on both SSE4.1 and SSE4.2 support, and -mno-sse4 turns both off. Neither form touches SSE4A, which is handled on its own by -msse4a. 🫶

If you want SSE/SSE2 instructions generated automatically from floating-point code (instead of 387 instructions), look at -mfpmath=sse. ✨

Fun fact that's kind of a plot twist: GCC suppresses SSEx instructions when -mavx is used. Instead, it generates new AVX instructions, or AVX equivalents for all the SSEx instructions, whenever they're needed. 🦋

These options let GCC use those extended instructions in the code it generates, even without -mfpmath=sse. Apps that do run-time CPU detection need to compile separate files for each supported architecture, using the right flags. Specifically, the file with the CPU detection code should be compiled without these options. 🙈

---

• -mdump-tune-features 🔍 makes GCC dump the names of the x86 performance tuning features along with their default settings. You can use those names with -mtune-ctrl=feature-list.
• -mtune-ctrl=feature-list 🎛️ gives you fine-grained control over x86 code generation features. feature-list is a comma-separated list of feature names. See also -mdump-tune-features. A feature gets turned on if its name has no ^ in front of it, and turned off if it does.

This one is really meant for GCC developers. Using it may lead to code paths that testing never covered, and it can potentially cause compiler ICEs or runtime errors. Proceed with caution, bestie. 💀

• -mno-default 🧼 makes GCC turn off every tunable feature. See also -mtune-ctrl=feature-list and -mdump-tune-features.
• -mcld 🧭 tells GCC to emit a cld instruction in the prologue of functions that use string instructions. String instructions rely on the DF flag to choose between autoincrement and autodecrement mode. The ABI says DF should be cleared on function entry, but some operating systems break that rule by not clearing DF in their exception dispatchers. So the exception handler can get invoked with DF set, and then string instructions go in the wrong direction. This option can be turned on by default on 32-bit x86 targets if you configure GCC with the --enable-cld configure option. In that case, you can suppress generation of cld instructions with the -mno-cld compiler option. 🌷
• -mvzeroupper 🧹 tells GCC to emit a vzeroupper instruction before control flow transfers out of the function. This cuts down the AVX-to-SSE transition penalty, and it also removes unnecessary zeroupper intrinsics.
• -mprefer-avx128 🩵 tells GCC to use 128-bit AVX instructions instead of 256-bit AVX instructions in the auto-vectorizer.
• -mprefer-vector-width=opt 📐 tells GCC to use opt-bit vector width in instructions instead of the default for the selected platform. The choices are:
  • none 🌫️ no extra limits on GCC beyond whatever the selected platform already defines
  • 128 🌸 prefers 128-bit vector width for instructions
  • 256 🌺 prefers 256-bit vector width for instructions
  • 512 🌈 prefers 512-bit vector width for instructions
• -mpartial-vector-fp-math 🧮 lets GCC generate floating-point operations that might affect the floating-point status flags on partial vectors, meaning vectors whose elements live in the low part of a 128-bit SSE register. Unless -fno-trapping-math is specified, the compiler keeps things correct by sanitizing all input operands so the unused upper part of the vector register is full of zeroes. Heads up, though: if you use built-in functions or inline assembly with partial vector arguments, NaNs, denormal values, or invalid values can leak into the upper part of the vector. That can cause performance issues when -fno-trapping-math is in effect. You can soften this by manually sanitizing the upper part of the partial vector argument register, or by using -mdaz-ftz to set the denormals-are-zero (DAZ) flag in the MXCSR register.

This option is enabled by default. ✅

• -mmove-max=bits 🚚 sets the maximum number of bits that can be moved from memory to memory efficiently to bits. The valid values are 128, 256, and 512.
• -mstore-max=bits 📦 sets the maximum number of bits that can be stored to memory efficiently to bits. The valid values are 128, 256, and 512.
• -mnoreturn-no-callee-saved-registers 🌙 optimizes functions with the noreturn attribute or the _Noreturn specifier. It does this by not saving, in the function prologue, the callee-saved registers the function uses (except the BP register).

This one can mess with debugging the caller of the noreturn function, or any function further up the call stack, so it is not enabled by default. 🙈

• -mcx16 🔒 lets GCC generate CMPXCHG16B instructions in 64-bit code to do compare-and-exchange operations on 16-byte aligned 128-bit objects. This is great for atomic updates of data structures bigger than one machine word. The compiler uses this instruction to implement __sync Builtins. For __atomic Builtins operating on 128-bit integers, though, a library call is always used.
• -msahf 🎈 enables generation of SAHF instructions in 64-bit code. Early Intel Pentium 4 CPUs with Intel 64 support (before the Pentium 4 G1 step arrived in December 2005) didn't have the LAHF and SAHF instructions that AMD64 supports. These are load and store instructions, respectively, for certain status flags. In 64-bit mode, the SAHF instruction is used to optimize the fmod, drem, and remainder built-in functions. See Other Builtins for details.
• -mmovbe 🔄 enables use of the movbe instruction to optimize byte swapping of four- and eight-byte entities.
• -mshstk 🛡️ makes the shadow stack built-in functions from x86 Control-flow Enforcement Technology (CET) available.
• -mcrc32 🧮 enables the built-in functions __builtin_ia32_crc32qi, __builtin_ia32_crc32hi, __builtin_ia32_crc32si, and __builtin_ia32_crc32di to generate the crc32 machine instruction.
• -mmwait ⏳ enables the built-in functions __builtin_ia32_monitor and __builtin_ia32_mwait to generate the monitor and mwait machine instructions.
• -mrecip ⚡ enables use of RCPSS and RSQRTSS instructions (plus their vectorized variants RCPPS and RSQRTPS) with an extra Newton-Raphson step for more precision. They're used instead of DIVSS and SQRTSS (and their vectorized variants) for single-precision floating-point arguments. These instructions are only generated when -funsafe-math-optimizations is enabled together with -ffinite-math-only and -fno-trapping-math. The sequence has higher throughput than the non-reciprocal instruction, but its precision can drop by up to 2 ulp (for example, the inverse of 1.0 comes out as 0.99999994). 🫠

Also, GCC already implements 1.0f/sqrtf(x) using RSQRTSS (or RSQRTPS) with -ffast-math, or with the option combination above, so you don't need -mrecip for that. 💅

And GCC emits that same sequence, with the extra Newton-Raphson step, for vectorized single-float division and vectorized sqrtf(x) with -ffast-math (or the option combination above). So again, -mrecip isn't needed for that either. ✨

-mrecip=opt 🎀 this one controls which reciprocal estimate instructions are allowed to get used. opt is a comma-separated list, and you can slap a ! in front of any option to flip it 🦋

• all ✨ turns on every estimate instruction
• default 🌸 turns on the default instructions, same as -mrecip
• none 🙈 turns off all estimate instructions, same as -mno-recip
• div 💅 turns on the approximation for scalar division
• vec-div 🔥 turns on the approximation for vectorized division
• sqrt 💜 turns on the approximation for scalar square root
• vec-sqrt 🧚 turns on the approximation for vectorized square root

So, for example, -mrecip=all,!sqrt turns on all of the reciprocal approximations except square root. Main character energy 👑

-mveclibabi=type 🌈 this sets the ABI type for vectorizing intrinsics through an external library. The type can be svml for the Intel short vector math library, aocl for the math library (LibM) from AMD Optimizing CPU Libraries (AOCL), or acml for the end-of-life AMD core math library, which AOCL-LibM succeeded. To use this option you need both -ftree-vectorize and -funsafe-math-optimizations enabled, plus an SVML or ACML ABI-compatible library specified at link time. Not skipping that part, bestie 🫶

GCC currently emits calls to these names when -mveclibabi=svml is used, for the matching function types: "vmldExp2", "vmldLn2", "vmldLog102", "vmldPow2", "vmldTanh2", "vmldTan2", "vmldAtan2", "vmldAtanh2", "vmldCbrt2", "vmldSinh2", "vmldSin2", "vmldAsinh2", "vmldAsin2", "vmldCosh2", "vmldCos2", "vmldAcosh2", "vmldAcos2", "vmlsExp4", "vmlsLn4", "vmlsLog104", "vmlsPow4", "vmlsTanh4", "vmlsTan4", "vmlsAtan4", "vmlsAtanh4", "vmlsCbrt4", "vmlsSinh4", "vmlsSin4", "vmlsAsinh4", "vmlsAsin4", "vmlsCosh4", "vmlsCos4", "vmlsAcosh4" and "vmlsAcos4" 🧁

When -mveclibabi=aocl is used, it goes for these: "amd_vrs4_acosf", "amd_vrs16_acosf", "amd_vrd8_asin", "amd_vrs4_asinf", "amd_vrs8_asinf", "amd_vrs16_asinf", "amd_vrd2_atan", "amd_vrd8_atan", "amd_vrs4_atanf", "amd_vrs8_atanf", "amd_vrs16_atanf", "amd_vrd2_cos", "amd_vrd4_cos", "amd_vrd8_cos", "amd_vrs4_cosf", "amd_vrs8_cosf", "amd_vrs16_cosf", "amd_vrs4_coshf", "amd_vrs8_coshf", "amd_vrd2_erf", "amd_vrd4_erf", "amd_vrd8_erf", "amd_vrs4_erff", "amd_vrs8_erff", "amd_vrs16_erff", "amd_vrd2_exp", "amd_vrd4_exp", "amd_vrd8_exp", "amd_vrs4_expf", "amd_vrs8_expf", "amd_vrs16_expf", "amd_vrd2_exp10", "amd_vrs4_exp10f", "amd_vrd2_exp2", "amd_vrd4_exp2", "amd_vrd8_exp2", "amd_vrs4_exp2f", "amd_vrs8_exp2f", "amd_vrs16_exp2f", "amd_vrs4_expm1f", "amd_vrd2_log", "amd_vrd4_log", "amd_vrd8_log", "amd_vrs4_logf", "amd_vrs8_logf", "amd_vrs16_logf", "amd_vrd2_log10", "amd_vrs4_log10f", "amd_vrs8_log10f", "amd_vrs16_log10f", "amd_vrd2_log1p", "amd_vrs4_log1pf", "amd_vrd2_log2", "amd_vrd4_log2", "amd_vrd8_log2", "amd_vrs4_log2f", "amd_vrs8_log2f", "amd_vrs16_log2f", "amd_vrd2_pow", "amd_vrd4_pow", "amd_vrd8_pow", "amd_vrs4_powf", "amd_vrs8_powf", "amd_vrs16_powf", "amd_vrd2_sin", "amd_vrd4_sin", "amd_vrd8_sin", "amd_vrs4_sinf", "amd_vrs8_sinf", "amd_vrs16_sinf", "amd_vrd2_tan", "amd_vrd4_tan", "amd_vrd8_tan", "amd_vrs16_tanf", "amd_vrs4_tanhf", "amd_vrs8_tanhf" and "amd_vrs16_tanhf" 💖

And when -mveclibabi=acml is used, you get these for the matching function types: "__vrd2_sin", "__vrd2_cos", "__vrd2_exp", "__vrd2_log", "__vrd2_log2", "__vrd2_log10", "__vrs4_sinf", "__vrs4_cosf", "__vrs4_expf", "__vrs4_logf", "__vrs4_log2f", "__vrs4_log10f" and "__vrs4_powf" 🦋

-mabi=name ✨ this generates code for the calling convention you pick. The valid values are sysv, which is the ABI used on GNU/Linux and other systems, and ms, which is the Microsoft ABI. The default is the Microsoft ABI when you're targeting Microsoft Windows, and the SysV ABI everywhere else. You can override this for specific functions with the function attributes "ms_abi" and "sysv_abi" 🫶

-mforce-indirect-call 🔥 forces every function call to be indirect. This is handy with Intel Processor Trace, since it gives more precise timing info for function calls 🧚

-mmanual-endbr 💜 only inserts the ENDBR instruction at function entry when you ask for it through the "cf_check" function attribute. It's useful alongside -fcf-protection=branch, letting you control ENDBR insertion at the function entry 🌈

-mcet-switch 🙈 by default, CET instrumentation is off for switch statements that use a jump table, and indirect branch track is disabled. Jump tables live in read-only memory, so this doesn't directly cost you any hardening. But if the jump table index is attacker-controlled, CET might not constrain the indirect jump.

This option turns on CET instrumentation so indirect branch track is enabled for switch statements with jump tables, which leads to the jump targets being reachable via any indirect jumps. 💀

-mcall-ms2sysv-xlogues 🌸 because 64-bit ABIs differ, any Microsoft ABI function that calls a System V ABI function has to treat RSI, RDI and XMM6-15 as clobbered. By default, the code that saves and restores these registers is emitted inline, which makes the prologues and epilogues pretty lengthy. Using -mcall-ms2sysv-xlogues makes the prologues and epilogues use stubs in the static portion of libgcc to do those saves and restores instead. That shrinks function size, at the cost of a few extra instructions 🍓

-mtls-dialect=type 💅 generates code to access thread-local storage using the gnu or gnu2 conventions. gnu is the conservative default. gnu2 is more efficient, but it may add compile- and run-time requirements that can't be satisfied on all systems 👑

-mpush-args -mno-push-args 🎀 these use PUSH operations to store outgoing parameters. That's shorter and usually just as fast as the SUB/MOV method, and it's enabled by default. In some cases, turning it off may improve performance thanks to better scheduling and fewer dependencies ✨

-maccumulate-outgoing-args 🌈 when enabled, the maximum amount of space needed for outgoing arguments is computed in the function prologue. This is faster on most modern CPUs thanks to reduced dependencies, better scheduling and less stack usage when the preferred stack boundary isn't equal to 2. The catch is a notable jump in code size 🙈 This switch implies -mno-push-args.

-mthreads 💖 supports thread-safe exception handling on MinGW. Programs that rely on thread-safe exception handling must compile and link all their code with -mthreads. When compiling, -mthreads defines -D_MT. When linking, it pulls in the special thread helper library -lmingwthrd, which cleans up per-thread exception-handling data 🧚

-mms-bitfields -mno-ms-bitfields 🦋 these enable or disable bit-field layout that's compatible with the native Microsoft Windows compiler 💅

If "packed" is used on a structure, or if bit-fields are used, the Microsoft ABI might lay out the structure differently than GCC normally does. Especially when moving packed data between functions compiled with GCC and the native Microsoft compiler, either through a function call or as data in a file, you might need to access either format 😭

This option is on by default for Microsoft Windows targets. You can also control it locally with variable or type attributes. For more info, see x86 Variable Attributes and x86 Type Attributes 🌸

The Microsoft structure layout algorithm is pretty simple, except for the bit-field packing. Whether a bit-field can straddle a storage-unit boundary, and the padding and alignment of structure members, come down to these rules:

1. Structure members are stored sequentially, in the order they're declared. The first member has the lowest memory address and the last member has the highest.
2. Every data object has an alignment requirement. For all data except structures, unions, and arrays, the alignment requirement is either the size of the object or the current packing size (set with either the "aligned" attribute or the "pack" pragma), whichever is less. For structures, unions, and arrays, the alignment requirement is the largest alignment requirement of any of its members. Every object gets an offset so that:

offset % alignment_requirement == 0

3. Adjacent bit-fields get packed into the same 1-, 2-, or 4-byte allocation unit, as long as the integral types are the same size and the next bit-field fits into the current allocation unit without crossing the boundary imposed by the common alignment requirements of the bit-fields. 🧁

MSVC interprets zero-length bit-fields in the following ways 🔥

1. If a zero-length bit-field is inserted between two bit-fields that would normally be coalesced, the bit-fields are not coalesced.

For example:

struct
 {
   unsigned long bf_1 : 12;
   unsigned long : 0;
   unsigned long bf_2 : 12;
 } t1;

The size of "t1" is 8 bytes with the zero-length bit-field. If the zero-length bit-field were removed, "t1"'s size would be 4 bytes. 💀

2. If a zero-length bit-field is inserted after a bit-field, "foo", and the alignment of the zero-length bit-field is greater than that of the member that follows it, "bar", then "bar" is aligned as the type of the zero-length bit-field.

For example:

struct
 {
   char foo : 4;
   short : 0;
   char bar;
 } t2;

struct
 {
   char foo : 4;
   short : 0;
   double bar;
 } t3;

For "t2", "bar" is placed at offset 2, rather than offset 1. So the size of "t2" is 4. For "t3", the zero-length bit-field doesn't affect the alignment of "bar" or, as a result, the size of the structure. 🫶

Taking this into account, it is important to note the following: ✨

Okay so bestie, the zero-length bit-field stuff is lowkey wild 💀 Here's how it goes:

1. Zero-length bit-fields that follow a normal bit-field can change the alignment of the whole struct, depending on their type 🎀 For example, t2 is 4 bytes, because its zero-length bit-field comes right after a normal bit-field and is of type short ✨
2. Even when a zero-length bit-field doesn't follow a normal bit-field, it can still mess with the struct's alignment 🙈

struct
 {
   char foo : 6;
   long : 0;
 } t4;

Here, t4 takes up 4 bytes 💖

3. Zero-length bit-fields that come after non-bit-field members just get ignored 🦋

struct
 {
   char foo;
   long : 0;
   char bar;
 } t5;

Here, t5 takes up 2 bytes 🌸

• -mno-align-stringops — Don't align the destination of inlined string operations 💅 This makes the code smaller and can speed things up when the destination is already aligned but GCC doesn't realize it 🫶
• -minline-all-stringops — By default, GCC only inlines string operations when the destination is known to be aligned to at least a 4-byte boundary 🙄 This option inlines more, which makes the code bigger, but it might help code that leans on fast memcpy and memset for short lengths 🔥 It also turns on inline expansion of strlen for all pointer alignments ✨
• -minline-stringops-dynamically — For string operations with an unknown size, use run-time checks 🧚 Small blocks get inline code and big blocks get a library call 💜
• -mstringop-strategy=alg — Overrides the internal heuristic that picks the algorithm used to inline string operations 👑 The allowed values for alg are:
  • rep_byte, rep_4byte, rep_8byte — Expand using the i386 rep prefix of the specified size 🌈
  • byte_loop, loop, unrolled_loop — Expand into an inline loop 🍓
  • libcall — Always use a library call 📞
• -mmemcpy-strategy=strategy — Overrides the heuristic that decides whether __builtin_memcpy gets inlined and which inline algorithm to use when the expected size of the copy is known 🎀 strategy is a comma-separated list of alg:max_size:dest_align triplets ✨ alg is one of the values from -mstringop-strategy, and max_size is the biggest byte size that alg is allowed to handle 💖 The last triplet has to use a max_size of -1 🙈 The max_size values in the list must go in increasing order 🦋 The minimum byte size for alg is 0 for the first triplet, and max_size + 1 of the range before it for every other triplet 🌸
• -mmemset-strategy=strategy — Pretty much the same as -mmemcpy-strategy=, except it controls __builtin_memset expansion instead 💅
• -momit-leaf-frame-pointer — Don't keep the frame pointer in a register for leaf functions 🫶 This skips the instructions that save, set up, and restore frame pointers, and frees up an extra register in leaf functions 🔥 The option -fomit-leaf-frame-pointer also drops the frame pointer for leaf functions, but that might make debugging harder 💀
• -mtls-direct-seg-refs, -mno-tls-direct-seg-refs — Controls whether TLS variables can be accessed with offsets from the TLS segment register (%gs for 32-bit, %fs for 64-bit), or whether the thread base pointer has to be added 👑 Whether that's valid depends on the operating system, and on whether it maps the segment so it covers the whole TLS area 🌈

For systems that use the GNU C Library, the default is on ✨

• -msse2avx, -mno-sse2avx — Tells the assembler to encode SSE instructions with the VEX prefix 🦋 The option -mavx turns this on by default 💜
• -mfentry, -mno-fentry — If profiling is active (-pg), put the profiling counter call before the prologue 🧚 Note: on x86, the attribute ms_hook_prologue isn't possible at the moment for -mfentry and -pg 🙈
• -mrecord-mcount, -mno-record-mcount — If profiling is active (-pg), generate a __mcount_loc section that holds pointers to each profiling call 🎀 This is super useful for automatically patching out calls 🫶
• -mnop-mcount, -mno-nop-mcount — If profiling is active (-pg), generate the calls to the profiling functions as NOPs 💅 This is handy when they should be patched in later on, dynamically 🔥 It's probably only useful together with -mrecord-mcount ✨
• -minstrument-return=type — Instruments function exit in -pg -mfentry instrumented functions with a call to the specified function 💖 It only instruments true returns that end with ret, not sibling calls that end with a jump 🦋 Valid types are none to not instrument, call to generate a call to __return__, or nop5 to generate a 5-byte nop 🌸
• -mrecord-return, -mno-record-return — Generates a __return_loc section pointing to all of the return instrumentation code 🧚
• -mfentry-name=name — Sets the name of the __fentry__ symbol that gets called at function entry for -pg -mfentry functions 💜
• -mfentry-section=name — Sets the name of the section where -mrecord-mcount calls get recorded (the default is __mcount_loc) 👑
• -mskip-rax-setup, -mno-skip-rax-setup — When generating code for the x86-64 architecture with SSE extensions disabled, -mskip-rax-setup can skip setting up the RAX register when no variable arguments get passed in vector registers 🌈

⚠️ Warning: RAX is used to avoid saving vector registers on the stack needlessly when passing variable arguments 😭 So if you use this option, callees may waste some stack space, misbehave, or jump to a random location 💀 GCC 4.4 or newer doesn't have those issues, no matter what the RAX register value is 🫶

• -m8bit-idiv, -mno-8bit-idiv — On some processors, like Intel Atom, 8-bit unsigned integer divide is way faster than 32-bit/64-bit integer divide 🔥 This option generates a run-time check 💅 If both the dividend and the divisor are between 0 and 255, it uses the 8-bit unsigned divide instead of the 32-bit/64-bit one ✨
• -mavx256-split-unaligned-load, -mavx256-split-unaligned-store — Splits 32-byte AVX unaligned loads and stores 🦋
• -mstack-protector-guard=guard, -mstack-protector-guard-reg=reg, -mstack-protector-guard-offset=offset, -mstack-protector-guard-symbol=symbol — Generates stack protection code using a canary at guard 🛡️ The supported locations are global for a global canary, or tls for a per-thread canary in the TLS block (the default) 💖 This option only does something when -fstack-protector or -fstack-protector-all is specified 🌸

With the tls choice, the options -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset also specify which segment register (%fs or %gs) to use as the base register for reading the canary, and what offset from that base register to use 🎀 The defaults for those come from the relevant ABI ✨

-mstack-protector-guard-symbol=symbol overrides the offset with a symbol reference to a canary in the TLS block 👑

• -mgeneral-regs-only — Generate code that only uses the general-purpose registers 💜 This stops the compiler from using floating-point, vector, mask, and bound registers 🫶
• -mrelax-cmpxchg-loop — When emitting a compare-and-swap loop for __sync builtins and __atomic builtins that don't have a native instruction, this optimizes for the highly contended case 🔥 It issues an atomic load before the CMPXCHG instruction, and uses the PAUSE instruction to save CPU power when restarting the loop 💅
• -mindirect-branch=choice — Converts indirect calls and jumps according to choice 🦋 The default is keep, which leaves indirect calls and jumps unmodified 🌸 thunk converts them into call and return thunks 🧚 thunk-inline converts them into inlined call and return thunks 💜 thunk-extern converts them into external call and return thunks, provided in a separate object file 👑 You can control this for a specific function with the function attribute "indirect_branch" 🌈

⚠️ -mcmodel=large is incompatible with -mindirect-branch=thunk and -mindirect-branch=thunk-extern, since the thunk function may not be reachable in the large code model 😭

-mindirect-branch=thunk-extern is compatible with -fcf-protection=branch, since the external thunk can be made to enable control-flow check ✨

• -mfunction-return=choice — Converts function returns according to choice 🫶 The default is keep, which leaves function returns unmodified 💅 thunk converts function returns to call and return thunks 🔥 thunk-inline converts them to inlined call and return thunks 🎀 thunk-extern converts them to external call and return thunks, provided in a separate object file 💖 You can control this for a specific function with the function attribute "function_return" 🌸

-mindirect-return=thunk-extern is compatible with -fcf-protection=branch, since the external thunk can be made to enable control-flow check 🦋

⚠️ -mcmodel=large is incompatible with -mfunction-return=thunk and -mfunction-return=thunk-extern, since the thunk function may not be reachable in the large code model 😭

• -mindirect-branch-register — Forces indirect calls and jumps to go via a register 🧚
• -mharden-sls=choice — Generates code to mitigate straight line speculation (SLS) according to choice 🛡️ The default is none, which disables all SLS hardening 💜 return enables SLS hardening for function returns 👑 indirect-jmp enables it for indirect jumps 🌈 all enables all SLS hardening ✨
• -mindirect-branch-cs-prefix — Adds a CS prefix to calls and jmps to an indirect thunk, with the branch target in the r8-r15 registers 🦋 This makes the call and jmp instructions 6 bytes long, so they can be swapped at run-time for lfence; call *%r8-r15 or lfence; jmp *%r8-r15 💖
• -mapx-inline-asm-use-gpr32 — For inline asm support with APX, the EGPR feature is disabled by default so you don't get a sneaky illegal instruction from EGPR 🙈 To turn on EGPR usage in inline asm, use this new compiler option, but you need to make sure the instruction actually supports EGPR 🫶

✨ x86 Options (continued) ✨

okay so these -m switches work on top of the ones above, but only on x86-64 processors in 64-bit environments 🦋

• -mevex512, -mno-evex512 — okay this one's about 512-bit vectors 💖 -mevex512 turns them on and -mno-evex512 turns them off. It's on by default if AVX512F is enabled, so you usually don't have to think about it 🧚
• -m32, -m64, -mx32, -m16, -miamcu — these pick your environment 🌸
  • -m32 makes int, long, and pointer types 32 bits and generates code that runs in 32-bit mode 💅
  • -m64 makes int 32 bits but long and pointers 64 bits, and generates code for the x86-64 architecture. bestie, on Darwin, only -m64 also turns off -fno-pic and -mdynamic-no-pic 👑
  • -mx32 makes int, long, and pointers 32 bits, but still generates x86-64 code 🎀
  • -m16 is basically -m32 with one extra twist: it outputs the .code16gcc assembly directive at the start of the assembly output, so the binary can run in 16-bit mode 🙈
  • -miamcu generates code that follows the Intel MCU psABI. it requires -m32 to be turned on, so don't skip that part 😭
• -mno-red-zone — the red zone is this 128-byte area just past the stack pointer that's mandated by the x86-64 ABI. signal or interrupt handlers won't touch it, so you can stash temporary data there without adjusting the stack pointer ✨ this flag turns that red zone off 🍓
• -mcmodel=small — the program and its symbols must be linked in the lower 2 GB of the address space. pointers are 64 bits, and programs can be statically or dynamically linked. this is the default code model, so it's the one you get if you don't pick anything 💜
• -mcmodel=kernel — generates code for the kernel code model. the kernel runs in the negative 2 GB of the address space, and this model has to be used for Linux kernel code 🔥
• -mcmodel=medium — the program is linked in the lower 2 GB of the address space, and small symbols get placed there too. symbols bigger than -mlarge-data-threshold go into large data or BSS sections and can live above 2GB. programs can be statically or dynamically linked 🌈
• -mcmodel=large — makes no assumptions at all about addresses and section sizes. very chill, very flexible 🦋
• -maddress-mode=long — generates code for long address mode. this is only supported for 64-bit and x32 environments, and it's the default address mode for 64-bit environments ⭐
• -maddress-mode=short — generates code for short address mode. this is only supported for 32-bit and x32 environments, and it's the default address mode for 32-bit and x32 environments too 🧚
• -mneeded, -mno-needed — -mneeded emits the GNU_PROPERTY_X86_ISA_1_NEEDED GNU property for Linux targets. it's how the binary says which micro-architecture ISA level it needs to run 🫶
• -mno-direct-extern-access — without -fpic or -fPIC, this always uses the GOT pointer to reach external symbols. with -fpic or -fPIC, access to protected symbols gets treated like local symbols. the default is -mdirect-extern-access 💅

⚠️ shared libraries compiled with -mno-direct-extern-access and executables compiled with -mdirect-extern-access may not be binary compatible if protected symbols are used in both the shared libraries and the executable. be careful with that one, bestie 😭

• -munroll-only-small-loops — this is conservative small loop unrolling. it's enabled by default with O2, and it unrolls loops with fewer than 4 insns by 1 time. if you explicitly use -f[no-]unroll-[all-]loops, this flag gets disabled, so you don't get unrolling you didn't ask for 🌸
• -mlam=choice — LAM (linear-address masking) lets special bits in a pointer hold metadata. the default is none. with u48, pointer bits in positions 62:48 can be used for metadata, and with u57, pointer bits in positions 62:57 can be used 🔥

---

✨ x86 Windows Options ✨

---

✨ Xstormy16 Options ✨

these options are defined for Xstormy16:

• -msim — picks startup files and a linker script that work with the simulator 🧚

---

✨ Xtensa Options ✨

these options are supported for Xtensa targets 🌈

• -mconst16, -mno-const16 — enables or disables the use of CONST16 instructions for loading constant values. fair warning, CONST16 isn't a standard Tensilica option right now. when it's enabled, CONST16 gets used in place of the standard L32R instructions every time. it's on by default only if L32R isn't available 💖
• -mfused-madd, -mno-fused-madd — enables or disables fused multiply/add and multiply/subtract instructions in the floating-point option. this does nothing if the floating-point option isn't also enabled. turning fused instructions off forces the compiler to use separate instructions for the multiply and the add/subtract. that's useful when you need strict IEEE 754-compliant results, because fused instructions don't round the intermediate result. so they can give you more bits of precision than IEEE says you should get. turning them off also makes sure your output doesn't depend on the compiler's ability to combine multiply and add/subtract operations 🦋
• -mserialize-volatile, -mno-serialize-volatile — when enabled, GCC inserts MEMW instructions before volatile memory references so that sequential consistency is guaranteed. the default is -mserialize-volatile. use -mno-serialize-volatile if you want to leave out the MEMW instructions 💅
• -mforce-no-pic — for targets like GNU/Linux, where all user-mode Xtensa code has to be position-independent code (PIC), this turns PIC off for compiling kernel code 🔥
• -mtext-section-literals, -mno-text-section-literals — these control how literal pools are handled. the default is -mno-text-section-literals, which puts literals in a separate section of the output file. that lets the literal pool sit in data RAM/ROM, and it lets the linker merge literal pools from separate object files to kill redundant literals and shrink code size 🌸 with -mtext-section-literals, literals get interspersed in the text section so they stay as close as possible to their references. that might be necessary for big assembly files. literals for each function go right before that function 🧚
• -mauto-litpools, -mno-auto-litpools — also about literal pools 💜 the default is -mno-auto-litpools, which puts literals in a separate section unless -mtext-section-literals is used. with -mauto-litpools, the assembler interleaves the literals into the text section itself. the compiler doesn't produce explicit .literal directives and loads literals into registers with MOVI instead of L32R, so the assembler can do relaxation and place literals wherever they're needed. this lets the assembler make several literal pools per function, which helps assemble very big functions that might not be possible with -mtext-section-literals ⭐
• -mtarget-align, -mno-target-align — when enabled, GCC tells the assembler to automatically align instructions to cut branch penalties, at the cost of a bit of code density 🎀 the assembler tries to widen density instructions so branch targets and the instructions right after call instructions are aligned. if there aren't enough safe density instructions before a target to align it, no widening happens. the default is -mtarget-align. these options don't change how auto-aligned instructions like LOOP are treated, since the assembler always aligns those, either by widening density instructions or by inserting NOP instructions 🙈
• -mlongcalls, -mno-longcalls — when enabled, GCC tells the assembler to turn direct calls into indirect calls, unless it can prove the target of the direct call is in range for the call instruction. this usually happens for calls to functions in other source files. specifically, the assembler turns a direct CALL into an L32R followed by a CALLX. the default is -mno-longcalls. use this in programs where the call target could be out of range 💖 this option lives in the assembler, not the compiler, so the assembly GCC generates still shows direct call instructions. look at the disassembled object code to see what really runs. also, the assembler uses an indirect call for every cross-file call, not just the ones that are actually out of range 😭
• -mabi=name — generates code for the specified ABI. the permissible values are call0 and windowed. the default ABI gets picked by the Xtensa core configuration 🌈
• -mabi=call0 — function parameters get passed in registers a2 through a7, registers a12 through a15 are caller-saved, and register a15 may be used as a frame pointer. when this ABI is enabled, the C preprocessor symbol __XTENSA_CALL0_ABI__ is defined 🦋
• -mabi=windowed — function parameters get passed in registers a10 through a15. the called function rotates the register window by 8 registers on entry, so its arguments show up in registers a2 through a7. register a7 may be used as a frame pointer. the register window gets rotated 8 registers back on return. when this ABI is enabled, the C preprocessor symbol __XTENSA_WINDOWED_ABI__ is defined 💅
• -mextra-l32r-costs=n — specifies an extra cost, in clock cycles, for instruction RAM/ROM access on L32R instructions. when you're optimizing for speed, this affects whether a constant gets loaded from the literal pool with L32R or synthesized from a smaller constant using a couple of arithmetic instructions 🧚 the default value is 0.

The -mstrict-align and -mno-strict-align flags are a vibe check on memory alignment 🫶 They decide whether GCC avoids or allows memory accesses that might not be aligned on a natural object boundary, as the architecture specification describes. By default it's -mno-strict-align for cores that handle both unaligned loads and stores in hardware, and -mstrict-align for all other cores 🌸

🦋 zSeries Options 🦋

These are listed under

✨ ENVIRONMENT ✨

okay so this section is all about the environment variables that change how GCC works 💖 Some of them tell GCC which directories or prefixes to search when it's hunting for files, and others set up other parts of the compilation environment. Iconic behaviour, honestly 💅

Also, you can name places to search with options like -B, -I and -L. Those take precedence over anything set in environment variables, and environment variables take precedence over whatever the configuration of GCC says. The hierarchy is real 👑

LANG, LC_CTYPE, LC_MESSAGES, LC_ALL

These environment variables control how GCC uses localisation information, which lets it work with different national conventions 🌈 GCC checks the locale categories LC_CTYPE and LC_MESSAGES if it has been configured to do so. These categories can be set to any value your installation supports. A typical value is en_GB.UTF-8 for English in the United Kingdom, encoded in UTF-8 🍓

The LC_CTYPE variable specifies character classification. GCC uses it to work out the character boundaries in a string. This matters for some multibyte encodings that contain quote and escape characters which would otherwise be read as the end of a string or an escape 🙈

The LC_MESSAGES variable specifies the language used in diagnostic messages ✨

If LC_ALL is set, it overrides the values of LC_CTYPE and LC_MESSAGES. Otherwise, LC_CTYPE and LC_MESSAGES default to the value of the LANG environment variable. If none of these variables are set, GCC defaults to traditional C English behaviour. Main character energy 👑

TMPDIR

If TMPDIR is set, it specifies the directory to use for temporary files 🧚 GCC uses temporary files to hold the output of one stage of compilation, which then becomes the input to the next stage. For example, the output of the preprocessor is the input to the compiler proper 💜

GCC_COMPARE_DEBUG

Setting GCC_COMPARE_DEBUG is nearly the same as passing -fcompare-debug to the compiler driver. Check the documentation for that option for more details 🔥

GCC_EXEC_PREFIX

If GCC_EXEC_PREFIX is set, it specifies a prefix to use in the names of the subprograms that the compiler executes. No slash is added when this prefix is combined with the name of a subprogram, but you can make your prefix end with a slash if you want one 🎀

If GCC_EXEC_PREFIX is not set, GCC tries to figure out a sensible prefix based on the pathname it was invoked with 🌈

If GCC can't find the subprogram using the specified prefix, it tries looking in the usual places for it 💀

The default value of GCC_EXEC_PREFIX is prefix/lib/gcc/, where prefix is the prefix of the installed compiler. In many cases, prefix is the value of "prefix" you used when you ran the configure script 🌸

Other prefixes specified with -B take precedence over this prefix ✨

This prefix is also used to find files such as crt0.o that are used for linking 🦋

The prefix also gets used in an unusual way when finding the directories to search for header files. For each standard directory whose name normally begins with /usr/local/lib/gcc (more precisely, with the value of GCC_INCLUDE_DIR), GCC tries replacing that beginning with the specified prefix to make an alternate directory name. So with -Bfoo/, GCC searches foo/bar just before it searches the standard directory /usr/local/lib/bar. If a standard directory begins with the configured prefix, then the value of prefix is replaced by GCC_EXEC_PREFIX when GCC looks for header files 💅

COMPILER_PATH

The value of COMPILER_PATH is a colon-separated list of directories, much like PATH. GCC tries these directories when searching for subprograms, if it can't find them using GCC_EXEC_PREFIX 🫶

LIBRARY_PATH

The value of LIBRARY_PATH is a colon-separated list of directories, much like PATH 🍓 When GCC is configured as a native compiler, it tries these directories when searching for special linker files, if it can't find them using GCC_EXEC_PREFIX. Linking with GCC also uses these directories when searching for ordinary libraries for the -l option. Directories specified with -L still come first 👑

LANG

This variable is used to pass locale information to the compiler. One thing it affects is which character set gets used when character literals, string literals and comments are parsed in C and C++ 🌈 When the compiler is configured to allow multibyte characters, these values for LANG are recognised:

• C-JIS — recognise JIS characters 🎀
• C-SJIS — recognise SJIS characters 🎀
• C-EUCJP — recognise EUCJP characters 🎀

If LANG is not defined, or it has some other value, then the compiler uses mblen and mbtowc as defined by the default locale to recognise and translate multibyte characters 🙈

GCC_EXTRA_DIAGNOSTIC_OUTPUT

If GCC_EXTRA_DIAGNOSTIC_OUTPUT is set to one of the following values, extra text gets printed to stderr whenever fix-it hints are emitted. -fdiagnostics-parseable-fixits and -fno-diagnostics-parseable-fixits take precedence over this environment variable ✨

• fixits-v1 — emits parseable fix-it hints, the same as -fdiagnostics-parseable-fixits. Columns are counted in bytes, starting at byte 1 for the initial column 🦋
• fixits-v2 — the same as fixits-v1, except columns are counted as display columns, as per -fdiagnostics-column-unit=display 💖

Some additional environment variables affect how the preprocessor behaves 🧚

CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, OBJC_INCLUDE_PATH

Each of these variables holds a list of directories separated by a special character, much like PATH, and GCC looks in those directories for header files. The special character, PATH_SEPARATOR, depends on the target and is decided when GCC is built. For Microsoft Windows-based targets it's a semicolon, and for almost every other target it's a colon 💜

CPATH specifies a list of directories to be searched as if they were given with -I, but after any paths given with -I options on the command line. This environment variable gets used no matter which language is being preprocessed 🌸

The remaining environment variables only apply when preprocessing the particular language they're named for. Each one specifies a list of directories to be searched as if they were given with -isystem, but after any paths given with -isystem options on the command line 🫶

In all of these variables, an empty element tells the compiler to search its current working directory. Empty elements can appear at the beginning or end of a path. For instance, if the value of CPATH is :/special/include, that has the same effect as -I. -I/special/include 🍓

DEPENDENCIES_OUTPUT

If this variable is set, its value specifies how to output dependencies for Make, based on the non-system header files processed by the compiler. System header files are ignored in the dependency output 🔥

The value of DEPENDENCIES_OUTPUT can be just a file name. In that case the Make rules are written to that file, and the target name is guessed from the source file name. Or the value can have the form file target, in which case the rules are written to file using target as the target name 👑

In other words, this environment variable is equivalent to combining the options -MM and -MF, with an optional -MT switch too 💅

SUNPRO_DEPENDENCIES

This variable is the same as DEPENDENCIES_OUTPUT (see above), except system header files are not ignored, so it implies -M rather than -MM. However, the dependence on the main input file is omitted 🌈

SOURCE_DATE_EPOCH

If this variable is set, its value specifies a UNIX timestamp to use in place of the current date and time in the "__DATE__" and "__TIME__" macros, so that the embedded timestamps become reproducible 🧚

The value of SOURCE_DATE_EPOCH must be a UNIX timestamp, defined as the number of seconds (excluding leap seconds) since 01 Jan 1970 00:00:00, represented in ASCII. It's identical to the output of date +%s on GNU/Linux and other systems that support the %s extension in the date command 🦋

The value should be a known timestamp, such as the last modification time of the source or package, and it should be set by the build process 💖

🌸 BUGS 🌸

For instructions on reporting bugs, see <file:///usr/share/doc/gcc-15/README.Bugs> 🐞

🦋 FOOTNOTES 🦋

1. On some systems, gcc -shared needs to build supplementary stub code for constructors to work. On multi-libbed systems, gcc -shared must select the correct support libraries to link against. Failing to supply the correct flags may lead to subtle defects. Supplying them in cases where they are not necessary is innocuous. -shared suppresses the addition of startup code that alters the floating-point environment, as done with -ffast-math, -Ofast or -funsafe-math-optimizations on some targets. 🙈

💖 SEE ALSO 💖

gpl(7), gfdl(7), fsf-funding(7), cpp(1), gcov(1), as(1), ld(1), gdb(1) and the Info entries for gcc, cpp, as, ld, binutils and gdb 📚

🧚 AUTHOR 🧚

See the Info entry for gcc, or <https://gcc.gnu.org/onlinedocs/gcc/Contributors.html>, for contributors to GCC 🫶

✨ COPYRIGHT ✨

okay bestie, the legal bit. don't skip it 🙈

Copyright (c) 1988-2025 Free Software Foundation, Inc. 💖 The FSF owns the copyright, and it's been keeping this manual glowing since 1988 🌈

You're allowed to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation 🦋 The two Invariant Sections are "GNU General Public License" and "Funding Free Software" 🫶 You also get Front-Cover Texts and Back-Cover Texts, and those are spelled out below. A copy of the license lives in the gfdl(7) man page, so go check it out if you're curious 🧚

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. 💜

---

And that's the whole manual, bestie!! 🎀 This page was made for gcc-15, dated 2025-09-17, and it's all GCC(1) 💅 Now go compile something iconic ✨🌸